Quote:
Originally Posted by dnanian
I really have no idea what happened here, Guy. It really sounds like the source drive was corrupt during the copy, which also caused the backup to be corrupt. This is, at some level, confirmed by the fact that you had post-backup corruption.
SD!, of course, can only return errors if it knows something is wrong. If the OS is providing us with an incorrect list of files, we're going to step through them normally, and do what's necessary to make the destination exactly correspond to the source.
In this case, at least as far as I can piece together the narrative, it looks like it returned rather incorrect data... without any indication of an error.
Did you run this backup manually, or was it on schedule? Running anything low-level like an AntiVirus program? Any recent weird failures on your system that might require a hard power down, unresponsive applications, things like that?
|
The backup was run manually. I never schedule.
One easy feature addition could keep this from happening silently. If SuperDuper gave a notification when it detects that the destination volume at the end of a clone operation has considerably fewer than when it started. i.e., drops more than 15% in file count. This could be made an optional notification and would not require SD to do much more calculation.
Such a simple warning would have prevented my continuing to produce multiple successive near empty backups. Every time that happened silently, I was unknowingly getter further and further away from a good backup. Since, SD's main purpose is to ensure data integrity across disasters, such a warning would be very welcome and need not be intrusive.
Not complaining or blaming, but I'd love to see this become nearly impossible to happen without noticing. Even if there is an errant structure on the source drive. I'd sure like to know if the clone drops in count from what the file count it started at.