Setting a custom directory for restore

I’m new to duplicacy and having a hard time wrapping my head around the restore procedure. As far as I understood the only way to restore files is to either use ‘duplicacy restore -overwrite’ and overwrite every single file of that snapshot in place, or I can cat single files into a custom directory. The last method requires that I know the absolute path of the files I want to restore.

Is there no way to mount a snapshot or restore it to a custom directory so I can browse and handpick the files/directories I want to restore?

You can restore to a different directory as long as you use the same repository id.

cd path\to\restore
duplicacy init original_repository_id storage_url
duplicacy restore -r 1 files_to_be_restored

This works even on a different computer. All Duplicacy cares is the repository id – repositories with the same id act like the same repository no matter where they are.

Thanks for the fast reply, I will try that out as soon as I have time.

May I still suggest adding a way to mount a snapshot. It makes skimming through the snapshot easy and doesn’t require to have disk space left on the device.

I made some snapshots of multiple repositories of a system. When restoring a snapshot (to a diferrent directory) I compared the content and found a lot of files missing. I’m trying to list every step, hoping you spot some obvious mistake.

root@m1:/etc# cat .duplicacy/preferences
“name”: “default”,
“id”: “m1-etc”,
“storage”: “sftp://user@backend/duplicacy”,
“encrypted”: true,
“no_backup”: false,
“no_restore”: false,
“no_save_password”: false,
“keys”: null

root@m1:/etc# l .duplicacy/
total 12K
drwxr-----. 3 root root 4.0K Jul 29 12:18 cache
-rw-------. 1 root root 408 Jul 29 12:17 known_hosts
-rw-r-----. 1 root root 274 Jul 29 12:17 preferences

root@m1:/etc# mkdir /tmp/restore && cd /tmp/restore

root@m1:/tmp/restore# duplicacy init -e m1-etc sftp://user@backend/duplicacy
The storage ‘sftp://user@backend/duplicacy’ has already been initialized
Compression level: 100
Average chunk size: 4194304
Maximum chunk size: 16777216
Minimum chunk size: 1048576
Chunk seed: f6c3a8afaf216db6deae075b16017688b83b68729c4ddf9c7629c82671eb8ae4
/tmp/restore will be backed up to sftp://user@backend/duplicacy with id m1-etc

root@m1:/tmp/restore# duplicacy list
Storage set to sftp://user@backend/duplicacy
Snapshot m1-etc revision 1 created at 2017-07-29 12:18 -hash
Snapshot m1-etc revision 2 created at 2017-07-29 14:30
Snapshot m1-etc revision 3 created at 2017-07-29 16:30

root@esus:/tmp/restore# duplicacy restore -r 3
Storage set to sftp://user@backend/duplicacy/duplicacy
Restoring /tmp/restore to revision 3
Downloaded sysconfig/run-parts (0)
Downloaded .updated (163)
Downloaded motd (0)
Downloaded environment (0)
Downloaded exports (0)
Restored /tmp/restore to revision 3
Total running time: 00:00:02

root@m1:/tmp/restore# diff -r ./ /etc/
Only in /etc/: binfmt.d
Only in /etc/: chkconfig.d
Only in /etc/: cron.monthly
Only in /etc/: cron.weekly
Only in /etc/dbus-1: session.d
Only in /etc/: dnsmasq.d
Only in /etc/firewalld: icmptypes
Only in /etc/firewalld: services

PS: This does happen on multiple systems!

Can you run duplicacy list -r 3 --files to see if those files are in the backup?

I think I know now what’s going on. Looks like duplicacy omits directories when they are empty. Sorry for not realizing that earlier, but that’s a ratter weird behavior.

Maybe that was a bad decision. A few others complained about that in the past. I’ll fix it next week.

Glad to hear that. Thanks!

The fix to restore empty directories has been checked in to the github branch. It will get into version 2.0.7.