[Resolved] Syncovery, the tool that mostly could... and does

[backup_user_123]

Update 2018-04-05:
I'm now a happily licensed user of Syncovery (Family Pack). The freezing behavior seems to have been limited to backups involving Amazon Cloud Drive. I've been successfully using Syncovery to do backups to my Google GDrive for a few months now and it's been working flawlessly

Prior Posting:

I gave Syncovery the best possible shot I could give.

I used Syncovery to download 13.2 TB from ACD to my local system. (Once Amazon did away with their unlimited data plan, I acquired a Synology DS916 and moved all my data from ACD to local storage)
Once that was secure, I used Syncovery to transfer those same 13.2 TB from Amazon Cloud Drive to Google Drive using Google Compute virtual servers.

My issue is that I had to restart Syncovery no less than 75 times in order to transfer the data (both to my local instance, the Synology system, and when using a purely virtual instance, the Google Compute VM). I did sabotage myself initially in the Google compute VM area (1 core, 4 GB RAM, 10 GB of hard disk). Note to other virtual users: Syncovery uses local storage to store temp files. (Check ~/.Syncovery/tmp. In my case there were at least 3 TMP[5letters].$$$ files in this directory, in constant flux. That would imply that your virtual machine should be able to hold 3 of your largest files simultaneously if doing a site to site transfer. My 2nd VM instance had 2 core, 14 GB RAM, 100GB static hard disk). Even with this second configuration, I found that Syncovery would "freeze" quite often. I determined the system was freezing by monitoring the ~/.Syncovery/tmp directory and checking time stamps of the TMP[multiple-chars].$$$ files. I also watched incoming and outgoing traffic using the speedometer network monitoring tool (speedometer -r ens4 -t ens4). Many MANY times, Syncovery just froze, doing nothing for several hours. I also monitored process usage via htop. Although Syncovery froze, the system remained responsive and I was able to sudo processes to my hearts content.

My cleanup procedure was to kill Syncovery (sudo pkill SyncoveryCL), clear the temp files (sudo rm ~/.Sycnovery/tmp/*), restart Syncovery (sudo SyncoveryCL &). Then I'd log back in to the Syncovery WebUI and restart my Syncovery profile. Over... and over ... and over again.

I feel bad because I'm complaining about something that worked successfully for me... eventually. Re-using this same recovery procedure eventually gave me all my data, both restoring locally and restoring to my alternate cloud location.

I'm just... frustrated, that it took so long.

I did make Syncovery technical support aware of my issue. They asked for my logs and configuration, both of which I provided, but I have yet to hear back an answer.

In any case, the point is now moot. I now have my data. I used Syncovery to transfer it. 100% of it. Twice. I'm grateful for the utility (we need more vendors to support Linux). I'm grateful for the 30 day trial period (which I totally made use of). I'm not enthusiastic about the support (I still don't know why this happened and support hasn't yet responded to my answers to their initial response).

Syncovery could be such an awesome tool but it's proven behavior of freezing midst backup concerns the hell out of me.

[superflexible]

Hello,
yes this issue still needs looking into. We are currently working on V8 and will do more testing of such large transfers on Linux, as well as look at your logs. Due to summer holidays, we could not come up with an immediate solution. Sorry for that. The Linux version will definitely be improved. The Windows version does not have that problem.

Best wishes,
Tobias Giessen

[superflexible]

FYI, the new version 7.88 has been released for all Linux platforms and includes various GUI and stability improvements.