I’m looking into using duplicacy + wasabi as a replacement for CrashPlan. I started with a small directory of about 2 GB which backed up fine. I then added a larger directory of about 500 GB.
The first time I tried on this larger directory, duplicacy stalled after about 1400 chunks. No crash, it just stopped printing output indicating that it was uploading chunks. It stayed like that for at least half an hour. I aborted it, restarted, and went to bed.
This morning I saw it had stopped after 4096 chunks. By looking at the wasabi dashboard I can tell that the newest chunk was uploaded about 4.5 hours before I checked it. It had stalled for that long.
Duplicacy version is 2.0.7. OS is FreeBSD 11.0-STABLE.
It’s actually a FreeNAS box and I have duplicacy running in a jail. One of the things that I found appealing about duplicacy is that it has native binaries for FreeBSD. CrashPlan was not easy to get going on FreeNAS because the only binaries you can use are Linux binaries.
I am now running it again with the -debug and -log options. I’ll update this issue when I have more data.
Something that makes this kind of annoying is that when I hit ctrl-c it doesn’t save the incomplete snapshot, so it has to rescan everything. I know that the incomplete snapshot functionality is there because I have seen it working. Now I’m scratching my head to figure out where. I think it would be on another jail on this machine. I don’t know why it would have worked before but it’s not working now. Maybe whatever issue is causing wasabi to hang is also preventing ctrl-c from saving the incomplete snapshot.
I saw on another issue that you said in this case you have to “force a crash” and send a stack trace, but I don’t know how to do that. I’ll gladly do it if you give me a little guidance.