Setting a custom directory for restore

Feature
,
#1

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?

Restore has no option to pick destination
#2

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.

Restoring for another Backup Device/Job
#3

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.

#4

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!

#5

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

#6

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.

#7

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

#8

Glad to hear that. Thanks!

#9

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