Duplicati error while restoring

Support
1

Hi

I am trying to restore files from Duplicati backup. One of the archive folder is giving me error the following 3 errors.

Screenshot 2022-11-06 at 10.32.37
Screenshot 2022-11-06 at 10.32.37863×518 64 KB

Screenshot 2022-11-06 at 10.33.00
Screenshot 2022-11-06 at 10.33.00872×449 56.3 KB

Any help or direction to resolve this issue would be greatly appreciated.

Thanks.
Aroul.

Follow up to my previous post -

After stopping/restarting server and the backup archive disk, the restore process moved on and now got a new error (below). The database was re-created but the backup restore point is not listed.

Screenshot 2022-11-06 at 13.13.29
Screenshot 2022-11-06 at 13.13.29887×355 42.2 KB

I am novice here, so any help/guidance will be appreciated.

2

Welcome to the forum @aroul

Restoring files from a backup and later give several options. The easy way:

By clicking the backup name and click Restore files ? under Operations

Restoring files if your Duplicati installation is lost is slower and riskier due to database creation.
The screenshots look like it’s downloading dlist files in Direct restore from backup files.
Did you lose a system, and need to do disaster recovery? If so, do you want the latest backup?

3

Could you please be more specific about what you are doing (step by step), to connect it to any error?
I’m not sure where Chronos came from. Did you get to the point of selecting things in the restore tree?
If so, there are several ways.

4

Hi

Thanks for the reply. Yes, I am doing a disaster recovery of our NAS.

We have a backup copy of our NAS in an external disk with 3 folders of files encrypted and archived by Duplicati.

Now due to an emergency, I am trying to restore the files from this disk. I followed the steps noted in ‘Direct restore from backup files…’.

Restoration of files worked for 2 folders in the disk without any problem. The third folder ‘Chronos’ is giving the error.

I can select the folder in the restore tree. After selection, I got the above error. Dismissing it the task proceeded to create database and I can see the ‘Select files…’ page. But here the ‘Restore from…’ time point list has no value.

I see this issue only for the ‘Chronos’ folder but didn’t encounter any problems for the other 2 folders. Could it be corruption of files? If so, is it possible to work out which file?

5

Do you mean Options screen Backup retention was set to keep 1 backup? That might be bad news.
You can look in Destination folders to count files with dlist in the file name to see how many are there.

Do you mean three separate backup jobs, each with a Destination screen set to its own folder there?

Still also looking for answer to question above on at least your end of “moved on”. The more the better…

6

There are 10 files with dlist extension.

Yes, three separate jobs with separate Destination screen. Restoring from 2 of them was fine. Ironically, they had only one dlist extension file in them. But the job/folder that is giving me error has 10 files with dlist extension.

7

What I think is supposed to happen is on screen 3 you get a dropdown selector of backup times, along with a tree view of what’s at that time. You can pick a different time if you like (but I’m not sure how many you saved). There’s a Search box to use, or one might prefer to expand folders and check things. When done, Continue goes to Restore options screen for setup, then Restore creates partial temporary database, then restores.

8

I’m still not quite sure what you did, but there were initially (and still are) signs of a bad dlist file, possibly related to timestamp somewhere (maybe even on the filename if you want to look at all to see if they look reasonable).

Possible workaround is to find the desired dlist file (maybe the newest, and note times are in UTC), and move other ones somewhere else (you might want them later). In initial problem you bypassed (maybe), watching About → Show log → Live → Retry might have shown a dlist come in just before error seen, which would make it a suspect of having caused the error. But without that data, maybe just hide some.

If you don’t want to move them elsewhere, you can hide by prefix change so it doesn’t start with duplicati-.

9

that’s not very good unless you deliberately choosed to keep only one version. Something to look out for the future otherwise.

About your failing job, I’d say that using the command line for restoring is very underrated in comparison to the rather awkward UI.
I have tried it today and I find it vastly easier to handle.
And for the most important task you have to do with a backup, it’s certainly worth it to test it to get the syntax right on some paper saved in a safe place, available when you have a problem and you need to start the restore immediately without having to search memory and/or documentation.

And using the command line makes it easy to test the restore to an alternate path so you can check your backups without having to do any copy to another computer (provided the disk space is enough but it’s often doable to add an USB hard drive), given that there are sadly some limits in the current state of Duplicati to the usability of auto tests.

a few examples (the options order seems to matter)
with encryption:

mono Duplicati.CommandLine.exe restore "ssh://ftp.example.com:822//files/test1?auth-username=test&auth-password=xyz" --passphrase=badsecret --restore-path=/home/gp/testAAA --ssh-accept-any-fingerprints

without encryption

mono Duplicati.CommandLine.exe restore "ssh://ftp.example.com:822//files/test2?auth-username=test&auth-password=xyz" --restore-path=/home/gp/testBBB --no-encryption=true --ssh-accept-any-fingerprints

the cherry on the cake IMO is that you can easily add a higher log level and see what happens in real time without having to guess.

mono Duplicati.CommandLine.exe restore --log-level=verbose "ssh://ftp.example.com:822//files/test2?auth-username=test&auth-password=xyz" --no-encryption=true --restore-path=/home/gp/testBBB --ssh-accept-any-fingerprints

EDIT:
to check that a restore succeeds or not in the same conditions than a recovery backup, it’s needed to stop Duplicati to scan for data in the local directories.
If not, when there is an error in a remote file, it will be displayed by the commands given above, BUT the concerned files will not be displayed and will in fact be ‘magically’ restored. A way could be to rename or move the concerned files, but it is assuming they are known, and it may be very annoying to manage.
A better option is to add the --no-local-blocks=true flag and then the failed files will be displayed to explain what could be missed from a blank state restore. As there is no free lunch, the restore will be longer (in fact it will be about as fast as a real recovery from scratch)

10

You are a star :star2: . Yes, turned out it was one of the dlist file is the culprit. Renamed it and now recovering the files. Thank you very much for the help.

11

Hi gpatel, Thanks for the suggestion and the cmds. Will definitely give it a go.

12

Another cherry (which I’m hoping we won’t need now) is Duplicati.CommandLine.RecoveryTool.exe:

This tool can be used in very specific situations, where you have to restore data from a corrupted backup. The procedure for recovering from this scenario is covered in Disaster Recovery.

What sort of wrong name did it have? I had been wondering if maybe the timestamp got a bad value.

13

The nomenclature of the file itself looks normal, no different to others with proper UTC value. Digging through the logs helped to find the file. So took a guess and did what you suggested - added a prefix and tried restore.