Files skipped/missed during first backup

[mrodent]

Hi,

I've been using this app for quite a few years now... I have some idea of the subtleties and complexities involved in mirror and backup operations, so this is not a criticism... I'm just puzzled about what might have happened. Version is Syncback Free V8.2.18.0 (32-bit). OS W10.

I did this mirror operation from the My Document directory on one computer (computer "A") to an external hard drive... then I did the same Syncback job in RESTORE mode to mirror from the external hard drive to another computer ("B").

I was puzzled that a handful of files got the "Failed to copy from Destination : Cannot copy file (2): The system cannot find the file specified The file may have been deleted between the time it was scanned and the attempt to copy it was made" message. So I went and looked at the result of the mirror on the external HD: they were missing. I went back to computer A and the files were definitely present. I repeated the mirror operation from computer A to the HD: this time those files were copied OK. Then they were restored OK to computer B.

I got no error message with the first mirror attempt. I had a look at the log (Ctrl-L) ... but it (obviously) gave me information only on the successful second mirror job. I don't know whether log info relating to the first mirror attempt is kept somewhere, but all I know is that I definitely got "success" as the result.

Can anyone say what might have happened?

[cliffhanger]

Those error messages (in the original log) are SB trying to tell you that certain files were reported by your system (computer-A) as present when SB scanned the files, but (after comparison/decision re all the files 'in scope') when SB tried to actually copy the files in question, your system then reported they were not/no longer present (hence the error messages and their wording). Note that it is SB that is calculating the extra 'was here before, now not' aspect; Windows itself only returns the error number/message '(2): The system cannot find the file specified'.

This can happen with temp files, which were indeed deleted/moved/renamed during that interim comparison/decision period by whatever process created / was using them (hence the extra wording in the warning/error messages). These tend to be files in 'system' locations, including 3rd-party applications' own 'system' folders/files. However...

...the location of the files in question ('Documents') suggests these may be 'real' long-term (i.e. not temp) data files, and 're-appearance' of the files under the exact-same names (?) in the exact-same locations (?) next run tends to reinforce this possibility - you may have a system problem. SB relies on Windows API calls to scan & copy files, and if one Windows API (called/used to scan your disk) reports certain files were present but a different Windows API called/used to attempt a copy of them reports they are not present, you may have problems with your copy of Windows or your (source) disk, so that the system is returning erratic information. The 'disk issue' possibility is more likely if all the files in question tend to be stored in one or two folder branches (though some files may be deeper in the path than others).

In any case, there is nothing SB can do about what it is told except to notify the user. You may be wise to run a system check on that source disk. But there is nothing anyone else can do 'forensically' to assist you remotely.


Keeping multiple logs (to a user-defined and settable-per-profile extent) is a feature of the commercial versions, and is not supported in the freeware. There is also an user-option in the SE/Pro versions to log the 'events' you are quoting as Warnings (warnings do not set overall Result as Failure in their own right) instead of Errors (which do), but this alternate-logging option is not available in the Free version. So I cannot see how a log could have quoted the messages you quoted here but reported Success, as it must have been listing those messages as Errors as there is no way to configure SBF otherwise.

BTW, you are using an older version of SBF - suggest update it to v8.4.5.0 (update 'over the top' to preserve your profiles and settings).
It will not have any effect on this particular issue, but keeping up to date is a good idea on general principles (especially for free)

[cliffhanger]

I just re-read your OP and it seems to me now that your issues (those messages) arose during the Restore from portable disk to computer-B (I originally read it as 'errors reported during mirror to portable disk', but I now think I maybe got 'wrong end of stick'). So, you may indeed have achieved a Success on the original mirror from computer-A to portable disk (which solves the other query re logging, Warnings, etc.).

In which case, it suggests issues on the portable disk whereby some files were not written to it 100%-successfully (but no error messages sent back to SBF, thus Result = Success of original mirror). And when you ran the Restore to computer-B, the disk reported to the scan-API that these files were present (disproving any suspicion that SBF had not actually copied those files at all during the initial mirror), but next-stage of the Restore run, the disk reported to the copy-API that they were not present.

This suggests you still have the possible same two (Windows or disk) issues, but any disk issue is on the portable drive. As you're probably aware, portable devices are much more damage/error-prone, so I would imagine the odds are much higher it is a disk issue. I strongly recommend you re-format that disk at the very least, and maybe give some thought to replacing it, especially if it is getting on in years.

[mrodent]

Sorry to take such a long time to reply.

Thanks for these answers ... Yes, this external HD is indeed getting on a bit. I'll try reformatting it and think of replacing it (although compared to the sorts of problems I've sometimes seen posted about EHDs I'm a bit reluctant: these EHDs - there are 3 so I can keep a sort of "offsite backup" thing going - have caused few problems over the years - Western Digital MyBooks).

Plus, as someone trying to move to Linux as much as possible, my prime suspect in a matter like this would be Windoze rather than the hardware!

I'm just wondering whether there is any way to do an "after check" using SB... i.e. to run an additional check comparing the source and the destination in order to make sure a "mirror" with all files present now exists.

[mrodent]

Ha... I need a cup of coffee, it's too early!

The obvious thing to do is, after your mirror op, do a simulated run of the same job!

Of course the suspicion is then that whatever hardware or software glitches caused the first run to (silently) fail to copy files may also give you erroneous results with the simulation... but this seems unlikely somehow. I just tried it and it spotted a deletion I had done in the target location ...

[mrodent]

And... just found out about (expert mode): Copy/Delete: check "Verify that files are copied correctly".

I wonder what sort of checking that is, i.e. how much it can be relied on?

As a belt-and-braces approach I think I'll do this *and* do a simulated run afterwards...

[cliffhanger]

More info on Verify here; Verify is done by hashing file contents on each side and looking for identical hash values / raising an error if not (IIRC, the hash method MD5 is used for disk<>disk profiles).

Your idea of a Simulated Run is a good one, but if your issue is such that the file table entries on a pair of disks for a given file match OK (bear in mind a scan only checks the tables for Size, LastMod & Name, by default - it doesn't check the files themselves), but the files' actual contents might not match (due to corruption, storage glitches, etc.) you may get some benefit from switching on the following option (possibly temporarily* - it will likely slow your 'scan stage' down a lot)

Modify > Expert > Compare Options > Use slower but more reliable method of file change detection

I would tend to recommend do not use the sub-option 'Always use slower but more reliable method of file change detection' because this will make the profile hash the files on either side (assuming there is one on each side) even if there is already a difference between the LastMod or Size parameters, which generally suggest the file has indeed been modified (hopefully intentionally!), and it is already going to be listed in the Differences window anyway. Not using the sub-option means the profile will not waste time hashing two files whose contents you would generally expect to be different anyway (especially if by Size). IOW, there is little point hashing files that default-scan differently already, as it is virtually certain the hash values will differ anyway. OTOH, two files which do match by name, size and [date/s as configured] will always be hashed providing the main option above is in force. Naturally such files will only show up in the Differences window if the hashes do not match. Hash values (if calculated) for the selected main-grid row are displayed in the lower left pane of the Differences window.


* you could have two versions of the profile, one with hashing-when-scanning switched on (and named accordingly), the other with the option off; that would save any toggling the option back & forth if that would be a factor for you