Backup hangs on "Deleting unwanted files"

ts678 · May 30, 2026, 4:09pm

Unfortunately not really AFAIK. See below forum discussion and open issue on it.

Allow changing the archive passphrase?

github.com/duplicati/duplicati

[feature request] Changing volume encryption password

opened 12:03AM - 30 Jan 18 UTC

Pectojin

enhancement

I was browsing the forum and it was mentioned that Duplicacy supports changing t…he volume encryption password. At first this didn't seem like a big deal, but I'm starting to think it might actually be a requirement for some business/enterprise purposes. E.g. a data breach exposing the encryption password would mean you have to re-encrypt all the data and re-upload it outside of Duplicati before changing the backup config to use the new password. Even if we built the tool it would take a while. LUKS and ZFS get around the issue of having to re-encrypt an entire disk by using the password to unlock an encryption key. That way it's possible to change password and just re-encrypt the encryption key. This is safe as long as nobody has your old password AND the old encrypted key. Obviously, Duplicati shouldn't just store one volume with an encryption key in it because the backup would be lost if you lost that one volume. But perhaps it's _safe_ if you store the encryption key in each dlist file and encrypt those with the password. My logic being that if you lose all your dlist files you're probably not going to recover much from your backup anyway. So when you want to do a password reset, you download all your dlist files, decrypt them with the old password, re-encrypt them with the new password, and then re-upload the dlist files. My backup of 317980 files (200GB) produces 19MB dlist volumes, so that results in number of snapshots times the size 38*19MB = 722MB to be changed. That's somewhat painful to download and re-upload, but compared to downloading and re-uploading 200GB it's a breeze. And for my scenario I would need over 10k individual snapshots before we get to 200GB of dlist files... At which point my dlist files would take up more space than my data. While it certainly changes the implementation, I'm thinking it should be fairly straight forward to implement an encryption key based model without touching the architecture.