I am running Duplicati - 188.8.131.52_canary_2022-06-15 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.
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.
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.
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.
I made a backup of both folders. The I copied the files from root to my users folder, and changed permissions (755) and owner.
Since 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.
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?