I am trying to restore a backup from an SMB-target on a remote NAS to a local disk on the machine running duplicati.
The database of the backup does no longer exist (And was located on another server) so I am trying to restore from files.
I go to restore directly from files, enter my target \NAS02\backupstorage02\SERVERNAME
The remote storage contains several versions, so I get to choose which version - selecting the latest and Duplicati begins to “Building partial temporary database …”
Now I started this process friday 2021-06-18 16:00 and today (Monday 2021-06-21 12:50) it suddenly started doing regular backups (that were clearly missed because it spent the entire weekend building a database). No files have been restored, to no error is produced, it just stops building the database and that’s it.
Stored profiling or verbose logs shows entries only from the 18th, none of which have anything to do with the restore job. (They’re timed prior to it started).
I have tried this multiple times now, and I am not sure where I am going wrong or what the problem is?
Any guidiance at what to do would be appreciated.
My duplicati is configured to send emails upon error as well:
Did you also lose the Duplicati-server.sqlite database that has the job names and configurations?
Somehow it seems like you had a scheduled job start. Was that for destination trying the restore?
If so, it should have complained about the remote files that it doesn’t know about in its database…
Please don’t run Repair until this settles a bit. Sometimes Repair fixes extra files by deleting them.
Is logging configured as server start option or job options? You’re not in a job during direct restore.
You can add –log-file=<path> and log-file-log-level=verbose (or whatever you can usually tolerate)
Alternatively you can watch About → Show log → Live to see how things end, but turn off scheduled jobs.
If it took from Friday to today to build a partial temporary database, what exactly could be tried repeatedly?
There is no scheduled job / configuration remaining.
It was deleted back in march (And was located on another virtual server host) when the virtual server was retired. However, we need to retrieve a PST-file located on it.
Thus, there is nothing left and Duplicati is tasked to look for the backup in the files created, from there it should build a database and then restore files.
We’ve tested this on much smaller servers and that works great from the exact same source to the exact same destination, but given the size of this server and the backup target, it goes sideways.
Okey, I just noticed that out of nowhere the files have now appeared in the destination path. Must have happened over night, despite Duplicati doing the backup jobs inbetween.
I will try to get logging on this, clearly a bug here somewhere.
I’m still confused by what woke up and ran on Monday, but it sounds like this is a one-time limited restore, without intention of resuming backup. You want a PST from an old destination inactive since about March.
It “should” normally work. If you can get verbose logs, that may show something. Even progress is useful information. I forget if this DB recreate has a progress bar, but if it does, 70% to 100% is downloading the dblock files in search of missing information, and 90% to 100% searches everything left. It can be slow…
If you actually have destination damage, another thing to try is Duplicati.CommandLine.RecoveryTool.exe which takes a simpler approach that withstands damage better. The UI is unfortunately also kind of crude. Fastest way to restore part of a backup is an example of how to awkwardly get one file with an exclude…
