I completed the upgrade from what I remember as being the version just before this. When the system came back online, there were no versions of backups available. Overnight it performed a backup as if it were the first time.
This morning, I attempted to repair the database. When that didn’t work, I did the delete and repair. That didn’t work either. The backup files are in the backup location, so I’m at a loss as to where to go from here. We’ve been using Duplicati for about two years and this is the first time I’ve had a problem that wasn’t easy to resolve.
Not sure what this means exactly? How do you see that there were no versions? Locally or on the remote? Do you have a screenshot?
That sounds like both the local and the remote data is wiped? Is this what it looks like? Did the backup configuration stay in place, or did you re-import it?
Do you get any error messages?
If so, it should be a matter of using the repair command to recreate the local database.
I assume the local database got lost, but is it possible that it still exists somewhere?
Duplicati usually stores all files in ~/.config/Duplicati but there could be some changes if you are running as the root user. It could then be that data is stored in /root/.config/Duplicati but 2.1.0.5 wants to store it in /Duplicati.
If so, you can use the commandline option --server-datafolder=/root/.config/Duplicati to make it look in the previous location.
Thank you for getting back with me. At this point, I’m having to start over completely.
When I first did the upgrade, multiple versions of each backup job were still on the server. This server does nothing but run Duplicati and it is never touched by anyone but me. Somehow through my troubleshooting or other means, they are now gone. The only files that exist there now are the new backups generated since I brought the updated version online.
The database is showing exactly what is actually on the drive now, so there isn’t anything further I can do to look into the issue. The “Stored” logs page on the web interface is blank.
The database and the Duplicati service runs as my logged in user. The config file is and has always been as you said in the ~/.config/Duplicati directory. I never experienced any issues with configurations. All the jobs stayed as originally set.
At this point, things are working and I have backups going back a full week. Restore seems to work as well. Moving forward, I am extremely scared to do any further updates without first duplicating my backup location. Something went very wrong with this upgrade and I don’t have any proof to show it nor any way to further troubleshoot it.
I don’t have any guesses as to what happened, but there is no code that will cause Duplicati to delete any remote files on update.
There is a function to delete all remote files, but I have never heard of it being invoked at random.
The repair function can delete remote files, but you would somehow have to get an empty database created, then see a message about “file found on remote, please run repair” and then running repair.
This case has been prevented with the latest canary, and it will refuse to delete remote files, if there are no known files in the database.
I am concerned about this report, but as you say there seems to be no further way to troubleshoot.
You actually peeked at database level, e.g. sqlitebrowser on Remotevolume table?
If you can do that, there are other databases you can look in, but what is still there?
lost one useful one. Do you recall any messages from that or from the repair before?
What happened later to get from “didn’t work” to “things are working”? If it involved a database deletion again, are you saving any of the old databases for historical data?
If it’s under systemd, journalctl should have logs. May or may not hold good clues.
Might have some clues in files named with backup, bak, dates, etc., however those are mostly before update (to allow revert). The more interesting ones are the updated ones, however they’re more likely to get wiped out by recovery efforts like database Recreate.
