Pick up former backup


I am running Duplicati - on manjaro with linux 6.0.8.
I discovered today that duplicati isn’t started automatically during login anymore. When I got it working using the commands
systemctl enable duplicati
systemctl start duplicati, it showed the duplicati front-page, with no backup configured. I expected one backup configured.

I found a configuration-file of the backup from mid 2022 and loaded it. Source, Destination and so on appear. However, it shows “Last successful backup: Never”. A db-repair failed. Currently, I am verifying the files - but this seems to take a long time.

Could you please advise how to proceed? I’d like to pick up where I left off.

When I choose to repair the database, it duplicati says

Failed to decrypt data (invalid passphrase?): Invalid password or corrupted data

I cannot recall that I was asked for a pw. Here is the first part of the log. It’s seems like 50 pages long, so I dont want to paste all…


I’d really appreciate if someone would comment on this. I feel very uncomfortable not creating daily backups…


your backups shows files with extension .aes, that means they are crypted. If not, you’d have files with a .zip extension.
If you don’t have the encryption key, your backups are a waste of space - I can’t see how you can ‘verify’ them or repair the database.
On how to proceed, without the encryption key, the only way is to delete everything and start again.
Additional advice: you say that you ‘discovered that duplicati isn’t started automatically’, having a daily mail report in your inbox and reading it, acting on it without delay if errors are reported, goes a long way to have healthy backups.

Thank you very much for your reply.

It seems you are right: when I try to restore a file from the backup in the remote location, I successfully test the connection, but then I get

Failed to connect: Failed to decrypt data (invalid passphrase?): Invalid password or corrupted data

This is strange, because my pw-manager tells me the same pw for the encrypted files as the pw that is storen in the configuration-file I imported (mid 2022).


When I booted my PC right now, Duplicati tells me

The database was attempted repaired, but the repair did not complete. This database may be incomplete and the backup process cannot continue. You may delete the local database and attempt to repair it again.

If no other idea comes to mind, I guess I will have to create a new backup and delete the current backup files.

Configuration seems to have disappeared after reboot? has info and links relevant to Manjaro.
Duplicati team does not provide their package. If need be, you can contact packagers directly.

You might need to recall what workaround (if any) you did long ago to get their package going.
What user were you running Duplicati as before? Old backup files would show creating user.

Ideally you want to find a Duplicati-server.sqlite file somewhere on drive, dated at last backup.
~user/.config/Duplicati is the default Duplicati folder. The user might be you, root, or duplicati.
They might have used /var/lib/duplicati/.config. If you find the file, copy it to intended new spot.

It seems you identified the issue, ts678. This is what my users .config/Duplicati-folder looks like:

This is what the roots/.config/Duplicati-folder looks like:

I made a backup of both folders. The I copied the files from root to my users folder, and changed permissions (755) and owner.

systemctl daemon-reload && systemctl reastart duplicati
did not change anything. Possibly because I did not “fix the service file”, as NBoumakis did in the post you linked. So instead, created a new backup and imported from the file “Duplicati-Server.sqlite” (the version from root overwrote the one of my user). It instanly reports.

Unexpected character encountered while parsing value: S. Path ‘’, line 0, position 0.

I have now initiated the process creating a new backup from the file called CLXU…, but it seems importing takes a long time. I will report here tomorrow.

That file isn’t an export, so it won’t import. Databases get used directly, by being in the right location.
Backup job databases are the random-letter.sqlite ones. A recent one might be what you ran before.
Server database is typically in the same folder, but it’s easy to update its timestamp by doing things.
That database is where job configs live, including AES encryption passwords (if you still want them).

I ended up uninstalling duplicati, and re-installed it exactly the same way as previously (fortunately, I had documented the process fairly well in a wiki). Afterwards, my “lost” backup reappears in duplicati, including all previous versions. Duplicati started instantly to pick up where it left off last wendsday. Cause of the troubles were probably an update.

I feel much better, now that I can access the backups again. It would not have been a problem to start over again - but why doing backups, if you can’t access them? This was a good test. Test passed, but not by much. lessons learned: 1) As recommended by gpatel-fr, I will now configure email reports. 2) I am considering to turn-off encryption: ransfer-protocol is SFTP, and the remote-destination is my own, well protected. This might make things easier.

Thank you very much for your support!

1 Like

What is actually happening, when I change the configuration of an existing backup, and turn off the encryption? Get the files decrypted on the remote? Or are only future files unencrypted? Or do all remote files get deleted, and a huge transfer takes place?

Before you do that, you will be warned that it may break things.
The only exception is when you have never backed up anything, actually.

1 Like