I recently had a BSoD following a routine system restart on my workstation which, long story short, resulted in a lot of lost and corrupted files across the two hard drives and three partitions on the system. Some of the files were just lost (basically deleted), a handful were corrupted, and bunch ended up becoming empty files (i.e. they became 0 bytes in length). Fortunately, I lost nothing of value as a result of this thanks in no small part to SyncBack.
However, something troubling I noticed as a result of this is that my automatic "Backup" type profiles that ran as scheduled early the next morning ended up destroying data in the backup copy before I understood the extent of the corruption on the source. What happened was that SyncBack noticed that the file length was different on the source and on the backup and so decided that the file had been modified on the source even though the time stamps were identical in both places and then proceeded to copy the empty file from the source and replace the good copy on the backup. This actually destroyed good copies of the file on the backup before I realized the files had been damaged. Nearly all of these files I had other copies of on external drives that I backup to manually but I did actually lose a couple of files (either replaceable or of little importance) that had been created since the last time I ran a manual backup and so had only existed in the automatic nightly backup copy.
I guess this is not a bug per se because this appears to be both the default and recommended behavior. In the profile settings if you go to Expert >> Compare Options >> File Size you can see there is a setting to make SyncBack ignore file size changes as an indicator that the file has changed. This is off by default and there is a message stating that enabling it is not recommended due to, apparently, some unspecified performance concerns. This is puzzling to me for several reasons not the least of which is that I would personally expect a change in the file contents and/or length without an accompanying timestamp change to be a strong indication of corrupt. The idea that we'd assume a file which changed length but not its time stamp could be safe to automatically replace in the backup is not what I would expect.
I for one will be switching all my automatically running profiles to ignore file length changes to avoid this problem in the future. I also would suggest adding an option that would ignore files that change to length zero if you are otherwise going to use file size as a indicator of changed contents. Backup profiles are supposed to never delete files even if they are removed on the source but deleting a file and blanking its contents are nearly the same thing so it might be worth reconsidering this design choice at least for backup profiles.
Could anyone elaborate on what the performance issue would be with ignoring size? How is getting the file length ever any faster than getting the time stamps? They both seem like file system metadata to me which I'd expect to both be readily accessible.
Thanks!
However, something troubling I noticed as a result of this is that my automatic "Backup" type profiles that ran as scheduled early the next morning ended up destroying data in the backup copy before I understood the extent of the corruption on the source. What happened was that SyncBack noticed that the file length was different on the source and on the backup and so decided that the file had been modified on the source even though the time stamps were identical in both places and then proceeded to copy the empty file from the source and replace the good copy on the backup. This actually destroyed good copies of the file on the backup before I realized the files had been damaged. Nearly all of these files I had other copies of on external drives that I backup to manually but I did actually lose a couple of files (either replaceable or of little importance) that had been created since the last time I ran a manual backup and so had only existed in the automatic nightly backup copy.
I guess this is not a bug per se because this appears to be both the default and recommended behavior. In the profile settings if you go to Expert >> Compare Options >> File Size you can see there is a setting to make SyncBack ignore file size changes as an indicator that the file has changed. This is off by default and there is a message stating that enabling it is not recommended due to, apparently, some unspecified performance concerns. This is puzzling to me for several reasons not the least of which is that I would personally expect a change in the file contents and/or length without an accompanying timestamp change to be a strong indication of corrupt. The idea that we'd assume a file which changed length but not its time stamp could be safe to automatically replace in the backup is not what I would expect.
I for one will be switching all my automatically running profiles to ignore file length changes to avoid this problem in the future. I also would suggest adding an option that would ignore files that change to length zero if you are otherwise going to use file size as a indicator of changed contents. Backup profiles are supposed to never delete files even if they are removed on the source but deleting a file and blanking its contents are nearly the same thing so it might be worth reconsidering this design choice at least for backup profiles.
Could anyone elaborate on what the performance issue would be with ignoring size? How is getting the file length ever any faster than getting the time stamps? They both seem like file system metadata to me which I'd expect to both be readily accessible.
Thanks!