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.

Henr · May 31, 2026, 8:53am

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

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.

sgeklor · June 16, 2026, 12:59pm

An unwanted reply, but keeping with the theme of the original post.

I have used Duplicati for over ten years, I run it on multiple systems (laptops, desktops, servers) and I have never had the “STOP” feature work. Ever.

All I do is kill the process, or log out, or restart the machine, which kills it.

The damn thing just doesn’t work and I don’t recommend that anyone spends any time trying to make it work, there seems to be a low-level issue here and the devs will no doubt get to in once they have stamped out the millions of other bugs holding things up.