I’m testing my backups and trying to restore a handful of files from a clean Windows installation. I was able to find some files with the find operation, but when I try to restore a single ~100MB file, I get a message every ~second saying “Downloading file (xx KB) …” This happens for much longer than I’d expect to restore that file over my internet connection. I’m also confused because the size mismatches, almost like it’s trying to restore all files.
I think I made the backup with 2.0.4.18_canary_2019-05-12, but am trying the restore with 2.0.4.23_beta_2019-07-14. I didn’t get any messages about a version mismatch, and it’s a pretty realistic scenario to test; after a disk failure, I might not know which Duplicati version I made the backup with.
If you use the Command Line method like that, Duplicati has to create a local (temporary) database from scratch. This requires downloading the dlist and dindex files, and possibly some dblock files.
To complicate things, you are using a version with a known bug that sometimes causes all dblock files to be downloaded during a database recreation. That bug has been fixed and is available in the latest beta version, 2.0.5.1.
Are you only using the Command Line tools for backing up and restoring your data? The more typical usage is to use the Web UI to define and schedule backup jobs or to restore data. This method uses a persistent local database so restores are much faster.
you are using a version with a known bug that sometimes causes all dblock files to be downloaded during a database recreation.
That explains it. It ended up finishing successfully, but after 12+ hours. I’ll try the new version.
The reason I did a restore from the command line is that I’m testing disaster recovery, so it’s on another system, and I had a fear the web UI would change the remote DB or try to start backing up local files. Can I use --dbpath to save the DB?
There is no remote database, but yeah you wouldn’t want this test machine to alter the files on the remote side. When I do such testing I just make sure to disable the backup schedule on the test machine.
I’m afraid I don’t know the answer to that. I rarely use the Command Line tools so am not very familiar with it. Maybe someone else can offer advice.
But in general I have no problem using the standard Web UI to test DR. I set up Duplicati on a test machine, configure the backup job (make sure not to schedule backups!), and then run a database recreate process. After that I do some test restores.
I use Duplicati command line all the time and always use --dbpath to point to correct DB.
I believe Web UI can tell where that DB is, so as long as there is no concurrent Web UI job is running, regular command line tool should be able to do its job.
It may need more parameters though, like logins and passphrases…
Although the direct restore disaster recovery test should run just fine (and remote-safely) from web UI (don’t import backup jobs casually, because you might run them, then that would make a mess on the remote if it bumped into another job), Export As Command-line is one good way to make sure all your parameters are there. You’ll have to change its backup command to the syntax for desired command.
