[SOLVED] Entire Backup Missing

Support
#1

I am using the Duplicacy v0.2.1 Linux ARM web ui to back up data to Wasabi. Web ui shows 1 Storages, 2 Backups, and 2 schedules. I just watched Duplicacy spend 3 days uploading 170 GB to Wasabi. I am using default settings or have not changed anything except for options to be -threads 4.

Storage tab reports Size 0, Backup IDs 0, Chunks 0, Status Checked. And, “All reference chunks exist.”

Backup tab reports 2 IDs with their associated Directory, Storage, and Include/Exclude.

Schedule lists the backup as “Completed” and a job Check as “Checked”.

Restore reports accurate storage. Backup IDs is “No Backups found on this storage”. Revision is greyed out; Restore To and Options are blank.

Seems Duplicacy backed up 170GB, as reported on Wasabi, but does not see its own backup. Is there a way to get it to see its own backup and restore files when it doesn’t let me select any Backup IDs and they are clearly on Wasabi?

#2

Appears that your backup hasn’t properly completed, even though the Web UI says it has…

You should be able to open the log for those backups by clicking Completed under the Schedule screen. Look to the bottom for a BACKUP_END and several BACKUP_STATS lines. What does it say?

#3

Thanks for reply.

Clicking “Completed” in Schedule brings up the log file. Here is the output including BACKUP_END and BACKUP_STATS:

2019-04-26 17:20:25.764 INFO BACKUP_END Backup for /sharedfolders/Files-Backup at revision 1 completed
2019-04-26 17:20:25.764 INFO BACKUP_STATS Files: 194615 total, 236,948M bytes; 194615 new, 236,948M bytes
2019-04-26 17:20:25.764 INFO BACKUP_STATS File chunks: 48007 total, 236,948M bytes; 9877 new, 48,594M bytes, 48,787M bytes uploaded
2019-04-26 17:20:25.764 INFO BACKUP_STATS Metadata chunks: 26 total, 93,913K bytes; 26 new, 93,913K bytes, 35,887K bytes uploaded
2019-04-26 17:20:25.764 INFO BACKUP_STATS All chunks: 48033 total, 237,040M bytes; 9903 new, 48,686M bytes, 48,822M bytes uploaded
2019-04-26 17:20:25.764 INFO BACKUP_STATS Total running time: 15:23:44

Seems to indicate it has finished. Anything else I can look at as to why nothing appears in Restore?

#4

Check to see if you have a file called 1 in the snapshots/<repository> on Wasabi.

One thing you could try is simply run the backup schedule again and see what it does. Even if that snapshot revision can’t be found on Wasabi, it should de-duplicate most of the chunks, though it might take longer due to a full rehash and chunk index.

#5

Yes, there is a file “1” in that directory on Wasabi. It looks like a binary file.

I have re-run the backup from the Schedule page. The Status bar first said “Indexing” and then it appears to be re-uploading some data. There was a 6 hour estimate. It has finished but as you can see, there still are no reported BACKUP IDs and I am still unable to restore any data. Screenshot:

image

Can someone help to how I should be able to restore data from the web ui?

#6

Am at a loss to explain why it doesn’t show any backups. Maybe @gchen can suggest why? Does your repository ID have any odd characters or spaces in the name by chance?

#7

If by “repository ID” you mean “Backup IDs” then no, they are just two English words separated by a hyphen.

Not sure if this helps, but I ran a “Check” from the Schedule page. Its output seems to indicate Duplicacy does not see a snapshot, revision, or chunk…?! Check log output:

Running check command from /home/michael/.duplicacy-web/repositories/localhost/all
Options: [-log check -storage Wasabi-Sharedfolders -a -tabular]
2019-04-28 18:51:14.843 INFO STORAGE_SET Storage set to wasabi://us-east-1@s3.wasabisys.com/n2-box-data//n2-sharedfolders-backup
2019-04-28 18:51:16.522 INFO SNAPSHOT_CHECK Listing all chunks
2019-04-28 18:51:16.671 INFO SNAPSHOT_CHECK 0 snapshots and 0 revisions
2019-04-28 18:51:16.672 INFO SNAPSHOT_CHECK Total chunk size is 0 in 0 chunks
2019-04-28 18:51:16.673 INFO SNAPSHOT_CHECK

Also, I am using the trial version. Does that prevent users from restoring? Maybe that is the cause?

#8

Note the double slashes in the storage url. This is causing the issue.

You can manually edit ~/.duplicacy-web/duplicacy.json and then restart Duplicacy.

#9

I see. Guess I didn’t need to prepend a forward slash to that first directory. I’ve updated duplicacy.json and it seems to be working now.