I have a profile in which Syncovery backs up a local source, over wifi, to destination drives attached to another machine via USB. I'm using block-level copying, with the remote service running on the destination machine.
Sometimes this works well. But sometimes I have large files skipped because (per the log) it "gave up waiting for checksum file". Typically this is after a long run of log entries of "Still working at (timestamp)", so initially I thought this was essentially saying "the checksum calculation is taking too long". But I've also had it happen only 20 seconds into a file's backup, which seems to suggests this is more like "the service isn't responding." ?
Is there anything I can do about this? A backup plan (pun unintended!) is to go back to database checksums, but I like that daily checksum calculation is more robust.
Remote Service / "Gave up waiting for checksum file"
Re: Remote Service / "Gave up waiting for checksum file"
Hello,
is the destination machine also running Linux?
Could you send two log files, one working and one not working to support@syncovery.com?
is the destination machine also running Linux?
Could you send two log files, one working and one not working to support@syncovery.com?
Re: Remote Service / "Gave up waiting for checksum file"
OK, just sent.
Yes, both are Linux. Same version of Syncovery.
Yes, both are Linux. Same version of Syncovery.
Re: Remote Service / "Gave up waiting for checksum file"
Is there any word on this? The problem seemed to go away for awhile, but it comes back sometimes.
Last night's backup was a mix, some failed, some succeeded. One of them gave up after only two minutes:
Still Working At 10/21/2021 03:42:15
Still Working At 10/21/2021 03:42:45
Still Working At 10/21/2021 03:43:15
Still Working At 10/21/2021 03:43:45
Still Working At 10/21/2021 03:44:15
Still Working At 10/21/2021 03:44:45
03:45:10 Gave up waiting for checksum file: /path/to/Win10/Win10.vdi
Not copying Win10.vdi (remote MD5 checksums not found)
I'm not completely sure the following is errant behavior, but it might be related. It seems to not be deleting *.SyncoveryMD5 files on the destination. I think one time the log actually warned me that it wasn't able to delete these files. But I see these files there now (after backup completion) despite the lack of a warning -- one for every large target file that used the service. Both the ones that were successful and the ones for which it gave up.
Let me know if I can contribute more logs or debug.
Last night's backup was a mix, some failed, some succeeded. One of them gave up after only two minutes:
Still Working At 10/21/2021 03:42:15
Still Working At 10/21/2021 03:42:45
Still Working At 10/21/2021 03:43:15
Still Working At 10/21/2021 03:43:45
Still Working At 10/21/2021 03:44:15
Still Working At 10/21/2021 03:44:45
03:45:10 Gave up waiting for checksum file: /path/to/Win10/Win10.vdi
Not copying Win10.vdi (remote MD5 checksums not found)
I'm not completely sure the following is errant behavior, but it might be related. It seems to not be deleting *.SyncoveryMD5 files on the destination. I think one time the log actually warned me that it wasn't able to delete these files. But I see these files there now (after backup completion) despite the lack of a warning -- one for every large target file that used the service. Both the ones that were successful and the ones for which it gave up.
Let me know if I can contribute more logs or debug.
Re: Remote Service / "Gave up waiting for checksum file"
Hi,
thanks for the additional info. Do you think the problem could be that sometimes it just doesn't wait long enough? I will check the logic and improve it in the next update.
thanks for the additional info. Do you think the problem could be that sometimes it just doesn't wait long enough? I will check the logic and improve it in the next update.
Re: Remote Service / "Gave up waiting for checksum file"
Hello,
I had an idea, if you are using a non-default copying order, this could happen. Can you check the copying order under "Special" in the profile?
Can you send a complete log file to support@syncovery.com?
I had an idea, if you are using a non-default copying order, this could happen. Can you check the copying order under "Special" in the profile?
Can you send a complete log file to support@syncovery.com?