I was beginning to do a restore and wanted to check if the resulting download was exactly what I expected, so I used “-n” i.e. “–dryrun”. Apparantly, that does not work with restore.
Is there a reason why it is excluded? Or did I misunderstand?
1 Like
I think it is simply not implemented in restic. Besides this, a dry-run IMO makes sense as soon as in-place restores are possible. Only supporting full-restore there is not much more information than an ls/mount or stats command could offer.
1 Like
First, thank you for your response. I never considered in place restore and I am not sure how it differs from just a restore.
The reason I wanted to do a dry run, was to see whether my complete command, including “include” and “exclude”, “target” and “path” was working as I expected it would work. Unfortunately, as I could not do a dry run, I just executed and found out that one of my excluded directories was still restored. Also, the first time I used restore, I was not sure whether the directory I pointed to would be restored itself or just its contents.
So, for me a dry run would make sense. It also gives me the opportunity to check my assumptions, whether they are arguments in the command or the resulting restore of files. I think I would appreciate a dry run for restore, especially if I use it only now and again.
1 Like
For clarification: With in-place restore I mean the case that there is already some content in the restore destination dir. Currently, restic doesn’t support this and if you do have existing content in the destination, you may get wrong restore results. Moreover, in this situation typically (parts of) the existing content can be used as it is already correct and identical to the snapshot-to-restore. This can heavily speed-up the restore and here some more information in a dry run is actually very nice to have.
On the other side, you are right that a dry-run may also help you with the syntax of the restore.