Accidentally purged config directory. Question on backup sets, etc

[Father_Redbeard]

I’m using the @saspus docker template on my Unraid server and just bought the personal license. I had 3 backup sets running to one B2 bucket but it wasn’t firing off on the designated schedule, so I was attempting to figure that part out. While looking at the settings in the template, I noticed I didn’t specify a config folder, so it dumped the machine-id, licenses.json, settings.json, etc in the root of /mnt/user/appdata/Duplicacy. I then set the config folder and applied changes. Not thinking clearly, I deleted the files sitting in root.

Searching in this forum I was able to “adopt” the previous backup data and reapply the license to the server/container. But I’m curious, will I now need to reconfigure the backup sets I had? Or is there another way to recover that? I’m assuming that answer is no without a backup of the original config directory, but thought I’d check.

Assuming the answer is in fact ‘no’, if I recreate the exactly backup sets in Duplicacy WebUI, and point it to the exact b2 bucket, am I going to run into any difficulty running new backups? Will it see the existing chunks and deduplicate accordingly?

And if anyone can lend a hand on the scheduling thing, that would be great. I saw that you need to create a new variable DWE_PASSWORD but I’m not understanding which password that needs. Is it the master webUI password? Or the encryption password for the B2 storage?

[saspus]

@Father_Redbeard

Assuming the answer is in fact ‘no’, if I recreate the exactly backup sets in Duplicacy WebUI, and point it to the exact b2 bucket, am I going to run into any difficulty running new backups? Will it see the existing chunks and deduplicate accordingly?

Yes, this is the supported scenario. If your machine burns in flames you can setup duplicacy from scratch, point to the same storage, and continue as if nothing happened.

@Father_Redbeard

so it dumped the machine-id, licenses.json, settings.json, etc in the root of /mnt/user/appdata/Duplicacy.

The schedules were in duplicacy.json.

@Father_Redbeard

DWE_PASSWORD but I’m not understanding which password that needs. Is it the master webUI password?

Yes. It’s one variable and you may have 15 cloud storages. Hence, it can’t be cloud storage password.

You should not need it since long ago, however:

@gchen

Store the master password encrypted by a UUID on Linux if keyring isn’t available [3]

FreeNas + Webui startup password

Right, this keyring change in the latest version was only made for linux, not freebsd. I’ll fix this in the next release.

[Father_Redbeard]

Great! Thank you for the detailed response. I’ll have to double-check now that I’ve got it set up again, but I want to say the schedule was not running. I have 2 running daily and a third running once/week.

But I will confirm and come back this way if I run into more difficulties.

Any input on best practices around backing up the config files? I can back it up in any number of cloud or server storage, just want to make sure I’m not shooting myself in the foot if there’s a recommended method for that specifically.

[alind]

@Father_Redbeard

Any input on best practices around backing up the config files? I can back it up in any number of cloud or server storage, just want to make sure I’m not shooting myself in the foot if there’s a recommended method for that specifically.

Hello @Father_Redbeard!

I’m not sure about best practices, but I always include the .duplicacy-web folder in my backups. You’ll probably want to exclude repositories/ and logs/ though to avoid backing up temporary stuff.