Restore data from backup archives

Hello Experts,

I am newbie user of Duplicati, Where I have configured the duplication on my Linux (RHEL7) over Docker container using lscr.io/linuxserver/duplicati:development, I’m testing the backup and restore mechanism which works well in some of my testing, however i am facing a problem while doing a restore again from the backup, what i realize that my colleague removed the config data and now while I’m trying to restore data from my backup Point.

Below is the little detail about data.

snowclient-1 #  docker images
REPOSITORY                              TAG                 IMAGE ID            CREATED             SIZE
lscr.io/linuxserver/duplicati           development         5357d07d4ca2        13 days ago         675 MB
ghcr.io/tecnativa/docker-duplicity-s3   latest              628dea616136        13 days ago         369 MB

snowclient-1 #  pwd
/duplicati

snowclient-1 #  ll
total 8
drwxr-x---. 6 root root 125 May 26 13:31 config
-rw-r-----. 1 root root 362 May 26 13:31 docker-compose.yml
-rwxr-x---. 1 root root 668 May 25 08:05 rerun_duplicati.sh

My Backup Dataset:

snowclient-1 #  ls -l /scratch/tmp-restore
total 1448
-rw-r--r--. 1 root btscel  12568 May 23 16:09 duplicati-20220523T140915Z.dlist.zip
-rw-r--r--. 1 root btscel  12945 May 23 16:09 duplicati-20220523T140945Z.dlist.zip
-rw-r--r--. 1 root btscel  13271 May 23 16:13 duplicati-20220523T141304Z.dlist.zip
-rw-r--r--. 1 root btscel 460637 May 23 16:09 duplicati-b3d3ac82763d3496c90d09768373dd46b.dblock.zip
-rw-r--r--. 1 root btscel 469673 May 23 16:13 duplicati-b7dc2b675c6cc472089cbb93b27702d62.dblock.zip
-rw-r--r--. 1 root btscel 459449 May 23 16:09 duplicati-bc6601913177c425e8b19d26094ec0550.dblock.zip
-rw-r--r--. 1 root btscel   1335 May 23 16:13 duplicati-i066782a3810944709dc797de458537f1.dindex.zip
-rw-r--r--. 1 root btscel  14173 May 23 16:09 duplicati-i7198a74a7241499982db90bf65df26b9.dindex.zip
-rw-r--r--. 1 root btscel   1334 May 23 16:09 duplicati-id1b751305cfb41da9b5628efbde36e94.dindex.zip

My restore Point:

snowclient-1 #  ls -ld /scratch/test-restore/
drwxr-x---. 2 root root 4096 May 26 05:53 /scratch/test-restore/

Now while I am trying to restore via GUI it just stay’s there saying like Waiting for task to begin and that i understand because i do not have the backup and restore point mapped to my DB which is why it keeps on waiting for a long. Below is the screenshot…

Is there a way to rebuild or modify something which can seek the information quick to process the data restore quickly.

Thank you in advance.

Note that the Duplicati team doesn’t maintain the LinuxServer Docker, and I don’t use Docker at all.
There are others here who do, and I’d ask them to keep an eye out for possible Docker issue here.

From https://hub.docker.com/r/linuxserver/duplicati

-v /config Contains all relevant configuration files.

and https://github.com/linuxserver/docker-duplicati/blob/master/root/etc/services.d/duplicati/run

–server-datafolder=/config

did colleague empty the host folder or do something else? Can you look at container /config?
Would config removal have wound up in some sort of recycle bin that you can get it back from?

Recreating the backup configuration from the Export To File that I hope you ran may be a plan.
After the configuration is back, hit the Database screen Repair button to recreate the database.
All of this is contingent on getting the Docker environment put back together (not my specialty).

What are you trying now? The screenshot’s 4 steps looks like a Direct restore from backup files.
That’s the usual way for a semi-quick restore without a configuration. I’m not sure why it’s stuck.
When you use the screen 2 Connect button, it builds a partial temporary database (not instant):

but this database is a temporary file so should be in a temporary file folder, not the /config folder.
Regardless, above was from a tab in About → Show log → Live → Verbose. You can test yours.

EDIT:

Even if you don’t have a job configuration export, you can attempt to approximately type it again.
Get Docker set up correctly first, then you can run a Repair and recreate a permanent database.
This is probably slower than Direct restore, but is a little closer to getting you back to normal.
If the backup was carefully built around certain files and folders, seeing will help remembering…

1 Like

Thanks @ts678 for the great explanation.

1 Like