Restore in place on Windows

[luckydonald]

Output of restic version

https://restic.readthedocs.io/en/latest/050_restore.html

What should restic do differently? Which functionality do you think we should add?

There should be an --inplace parameter to allow restic to restore it's files in place. Basically what a git checkout would do.

What are you trying to do? What problem would this solve?

I need to restore a snapshot, keeping the folder structure exactly as it was recorded as. However it stores over different harddrives, C:\, G:\ and F:\. In other words, there's no parent folder those pathes are all relative to.

[luckydonald]

Also with snapshots like the following (450 GB total, but only 400mb changes) this would mean a big improvement, if I can get the diff applied only.

luckydonald@luckydonald-PC MINGW64 G:\Sicherung\restic\restic
$ ./restic_0.13.1_windows_amd64.exe --verbose backup --repo ../Backups/Hydrus/ --password-file passwords/Hydrus.txt --tag v554 --tag after-upgrade-before-run --tag after-upgrade --tag before-run --tag full --tag data --tag hydrus --files-from filelists/Hydrus.txt
open repository
lock repository
load index files
using parent snapshot af620963
start scan on [X:\Hydrus Network\]
start backup on [X:\Hydrus Network\]
scan finished in 21.925s: 383260 files, 454.287 GiB

Files:          38 new,  3396 changed, 379826 unmodified
Dirs:            1 new,   225 changed,   584 unmodified
Data Blobs:    573 new
Tree Blobs:    227 new
Added to the repo: 379.107 MiB

processed 383260 files, 454.287 GiB in 0:56
snapshot 89d76895 saved

[rawtaz]

It seems that you put two different feature requests in the same issue here. The second post is probably a duplicate of #2662.

[luckydonald]

Yeah, the second part is a duplicate of that linked. But also probably something which should be done before tackling this, as otherwise this would be inefficient as heck - which is why I listed it here as well.

[MichaelEischer]

I've removed this issue from the roadmap for restic 0.17.0. While reading through this issue I've noticed that this issue is not about restoring in place in general but rather Windows specific. Fixing it requires sorting out some filepath mess which I don't want to start for 0.17.0.

For now it's possible to somewhat workaround the problem by using the <snapshot id>:<subpath> syntax when specifying the snapshot to restore.

[luckydonald]

Oh? So it's possible already in other systems?

Also, the related issue (or rather the solution of it) doesn't seem to delete files as needed?

[luckydonald]

Ah, I've seen that #2348 is worked on, so that's probably the deletion bit. After that the remaining part left of this issue indeed is only the root path thing. And possibly having --inplace be an alias to the options of #2662 and #2348 combined