Integrity Check

[Spitfire_ch]

Hi

Since I am currently dealing with a defective hard-drive, the following idea started to worry me: Because I never know, when the drive is going to fail again, I keep writing backups to an external drive using Synchronize IT on a daily basis. Because I don't have an infinite amount of space, I don't keep a history but rather overwrite the old backups on the external drive.

But ... what happens, if the data on the source drive is corrupt? Will Synchronize It start overwriting the target files and suddenly realize, that it can't read all of the source files? In such a case, it would already be too late, because the backup files would have been partially overwritten and probably also corrupt. That would leave me with a corrupt backup and a corrupt source. Would it be possible to have Synchronize It check the integrity of the source BEFORE it starts overwriting the target?

Maybe this is already implemented. If so, could you please confirm that, so that I can calm my troubled soul?

Thank you very much and have a nice weekend!
- spitfire

[grigsoft]

Hello,
No, this is not implemented. I would recommend backuping by dates, to have at least 2-3 copy of data. You can do this by using %M%D in folders, as an example. I will think about an option to verify a source file. Or write file without overwriting previous one.

[Spitfire_ch]

Ok, that's good to know. Thanks for the hint!

An option to check integrity before overwriting the target would be very suitable. Keeping multiple copies is not so easy if it's a lot of data. Even a TB-Drive will soon hit its limits.

Best regards
- spitfire

[Spitfire_ch]

P.S. I was wondering: if you use compare by "date or content", or maybe rather just by content, should a read error on the source not automatically be detected? I mean, how could it compare by content if it can't read the content?

In the help file you write:

Modification of default rule, suitable if you think you have same files with different dates. Files with same date and size are still considered as same, but in addition files with same size and different dates are compared byte-by-byte to check if they are same.

Judging from that I would assume I am on the safe side:

• If date and size are the same, the target file will not be overwritten -> no damage can occur.
• If they differ, a byte-by-byte comparison will be performed, which should "crash" if the source can't be read.

Is this assumption correct?

Thank you very much for your reply and best regards
- spitfire

[grigsoft]

Well, this can be solution too. If you are using binary comparison, then whole files are scanned. However make sure you are not using Smart text compare for these files - it will stop on first difference.

[Spitfire_ch]

Thanks for pointing that out - I wasn't aware of that option. So, by simply unchecking "Enable Smart file comparison" I should be fine?

And what exactly would happen if it scanned a file in a faulty sector of the harddrive? Would it throw an error that the file cannot be read or something alike? I just need to be sure it wouldn't "replicate" the error, for example by writing 0 to the target whenever a read-error occurs.

Regards
- spit