Backup ID not showing up in restore tab

Support
#1

Hey all,

I am running Duplicacy in a Docker container on UNRAID. My backup target is Wasabi S3 storage. This has been working fine for some time, but now I am in the situation where I need to restore data.
For some reason, when I want to select the backup ID that contains the data I need, it’s not available. In fact, I am only able to select two of the six backups I configured.

When I select one of the available Backup IDs, all the revisions etc. show up fine.

One other thing I noticed: When I log in to the Wasabi web interface and check my bucket, it’s completely empty except for one file named “config”. The other folders only show up when I select “Show Versions”.

I tried to run the backup I need again, and the process of backing up itself works fine. The backup ID still doesn’t show up in the restore tab however. When I check the log, I can even see the entry “2023-08-27 15:00:10.554 INFO BACKUP_START Last backup at revision 230 found”, so it seems like the revisions should all still be there.

Maybe worth noting: I did have a Puning task with the following settings in place: 0:180 7:30 1:7

I hope someone can help me with this. If more information/logs/etc. is needed, please let me know.

Thanks!

I also made a quick video to hopefully make the issue clearer:

#2

If you can only see a single config in your Wasabi, that’s where I’d find out why.

There was some stuff here about you should disable versioning on Wasabi (tho I’d make sure your current version is correct and you’ve done a check job before disabling that).

#3

Hey,

thanks for your feedback. To be honest, I am not quite sure what you mean.
When I try to check the config (in VS Code), I can’t read the content because it’s binary.

I have been trying some stuff, there is some other weird behaviour I found:

  • When I delete one of the backup jobs/ids (not the one I need data from) and add it again with the same name, the backups run fine and it says that it was able to find my old revision. The backup ID still doesn’t show up in the restore tab however.
  • If I create an entirely new backup job and start it, it’s stuck with an empty progress bar (no text within the bar). Checking the log file, this is the last entry: 2023-08-28 19:23:47.847 INFO BACKUP_LIST Listing all chunks. Maybe it needs some time, I will report back should anything change.

Currently I am trying to restore a previous version of the config file from Wasabi (should be possible since versioning is enabled), but so far I did not find a way to do so.

Also, when I run a check job, it only checks the two backup ids I am also able to select for restore.

#4

Update on the new backup job:
The upload finished fine, and I am able to select the new backup id for restore.

Update on trying to restore the config file:
There is only one version, and the version is from 01.01.2023. So I don’t think there is anything relevant there.

#5

Another update on this: I restored all files in the /snapshots/“backup id I need” (thank god I have versioning turned on in Wasabi!), and now the backup ID is available for restore again. Each revision is also showing up.
I am trying to restore now, but so far it looks good. I made sure to use a restore point which wasn’t yet pruned, so I wouldn’t have to restore chunks as well. Given the folder structure, that would be a whole lot of pain.

So for me it currently looks like Duplicacy deleted snaphots it needs to find the backup id (not sure on this, just guessing based on the information I gained), which is worrying to say the least. I don’t know what would have happened if versioning would not have been enabled. Maybe someone can give some more insight on what happened here…

#6

Duplicacy won’t delete 100% of snapshots in any given ID unless you specify -exclusive as part of your prune. Did you? Otherwise, it’s much more likely to be a Wasabi issue…

IMO it’s far more likely version history is the reason you’re encountering issues. There’s no reason to have it switched on, because Duplicacy takes care of ‘versions’. It also makes sense that you only have 1 config version. That’s why I posted the link to the previous discussion - from a user who used Wasabi in the past - to disable versioning, else you’ll run into this kinda trouble.

You should have a snapshots and chunks directory alongside config (which is encrypted, and why vscode won’t show anything of value), so if you only see the latter, you still need to figure out why.

Personally, I would delete my local cache and run a full check (add the -v global option so you can better see its progress). It will take a long time, if you have a lot of chunks, so be patient.

#7

I did not have -exclusive enabled for the prune job. Maybe I was unclear, most of the snapshot files were still there (not deleted), only some where. After restoring those, that where deleted, the backup showed up again in Duplicacy.

Using this workaround I was able to recover the data I need. Moving forward I will set up new backups to a new Wasabi bucket without versioning and keep the old bucket for now (just in case). This way I feel safer, compared to checking and possibly repairing the backups I currently have.