ts678
May 30, 2026, 4:09pm
21
Unfortunately not really AFAIK. See below forum discussion and open issue on it.
Allow changing the archive passphrase?
opened 12:03AM - 30 Jan 18 UTC
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.
Henr
May 31, 2026, 8:53am
22
Okay. Thank you for your reply.
New warning:
After recreating the local database, all automatic backups gives this warning:
2026-05-30 21:34:01 +02 - [Warning-Duplicati.Library.Main.Operation.TestHandler-FaultyIndexFiles]: Found 1 faulty index files, repairing now
It worries me that “repairing now” does not solve anything. Is this a problem?
ts678
May 31, 2026, 1:51pm
23
I don’t think you have presented enough information to reach any conclusion.
The test that occurs after backup samples files, trying to sample them evenly.
If it finds FaultyIndexFiles, it fixes those (we hope), but hasn’t seen any other.
You could make a log-file at information level to see if the same dindex
file is repeatedly deleted and reuploaded after a backup. That’d be wrong, but
dindex files are not critical. They’re small files that say where blocks are in the
dblock files. If a block is missing, dblock files are searched, so recreate slows.
Forum search in top right corner above has several developer comments, e.g.
2.1.1.100 > Found 1 faulty index files, repairing now
There is also a way there to deeply inspect all the dindex files, if you want that.