Backing up/restoring relative paths

Getting Help
1

I’m trying to understand behavior that I’m seeing with restic during backup and restore.

Let’s say I have a data directory that I want to back up, /Users/steve/tmp/restic-test/data.

Scenario #1

  1. Change pwd to my data dir: cd /Users/steve/tmp/restic-test/data
  2. Take backup: restic backup .
  3. See backup has full directory stored: restic snapshots -> /Users/steve/tmp/restic-test/data
  4. Restore into a new directory: restic restore --target /Users/steve/tmp/restic-test/restored-data <snapshotID>
  5. See contents of /Users/steve/tmp/restic-test/data restored into /Users/steve/tmp/restic-test/restored-data.

So far, so good.

Scenario #2

  1. Change pwd to the parent of my data dir: cd /Users/steve/tmp/restic-test
  2. Take backup: restic backup data/
  3. See backup has full directory stored: restic snapshots -> /Users/steve/tmp/restic-test/data
  4. Restore into a new directory: restic restore --target /Users/steve/tmp/restic-test/restored-data <snapshotID>
  5. See the data dir itself restored into /Users/steve/tmp/restic-test/restored-data, i.e. now I see /Users/steve/tmp/restic-test/restored-data.

OK, so it seems that restic is internally keeping track of the relative path I used when I took the backup, and restoring based on that.

Scenario #3

  1. (from any pwd) take backup specifying absolute path: restic backup /Users/steve/tmp/restic-test/data
  2. See backup has full directory stored: restic snapshots -> /Users/steve/tmp/restic-test/data
  3. Restore into a new directory: restic restore --target /Users/steve/tmp/restic-test/restored-data <snapshotID>
  4. See the full tree of the backed up dir’s path itself restored into /Users/steve/tmp/restic-test/restored-data, i.e. now I see /Users/steve/tmp/restic-test/Users/steve/tmp/restic-test/data.

So, it seems that restic is retaining info about the relative or absolute path that I’m using when backing up, even though it only displays the absolute path when looking at restic snapshots.

Is this expected behavior? If so, is it documented anywhere? It is actually useful for use to have, but if it is intended, it would be really useful to be able to view the relative paths somewhere in the restic snapshots output so we know ahead of time what will happen when we restore a given snapshot.

2

This is indeed expected behavior, and I agree that it isn’t obvious when you’re only looking at the output of restic snapshots. restic’s behavior is modeled after what tar does. The program logic here is still pretty simple, the idea is that in a snapshot, the absolute path to the data is saved, so on a subsequent backup we can find it again.

Did you know that you can list a snapshot with restic ls <id>?

1 Like
3

Oh, great, that definitely helps make it clear. Thanks for the quick response!

4

Thanks for clarifying, I am wondering if there is a way to change the relative path just during the restore somehow?

I had backed up my workstation’s home folder with an absolute path /home/myuser and reinstalled with a different username.
I thought that I could restore the folder’s content to something like /home/mydifferentuser but could not find an option so far.

My workaround was to restore to a different folder and use rsync to copy to the right folder, but that feels a bit inconvenient.

Does anyone know a more direct way to solve that use case?

Thanks in advance :slightly_smiling_face:

5

The other option would be the restic mount command and copy files from there, probably that is the way to go in that case.

6

Ok, according to Help with full home directory restore linux (pop_os) - #2 by MichaelEischer it is not a good idea to restore to an existing home folder directly anyway… :sweat_smile:

7

Let me advertise rustic (disclaimer: I’m the author) which allows to use

rustic restore <SNAP>:/home/myuser /home/differentuser

and handles already existing files. You also might want to check out the --delete option (removes existing files not present in the snapshot) and always first run a dry run using --dry-run to check out what would be done.
Note there is also rustic diff <SNAP>:/home/myuser /home/differentuser at hand to show differences between a snapshot path and a local path.

For restic, there is Restore only subtree of snapshot via <hash>:<subtree> syntax · Issue #3871 · restic/restic · GitHub but this wouldn’t solve the problem restoring to an existing dir.

There is another problem with setting the correct ownership of your files as the user changed. If your old and new user/group have identical uid/gid, you can use rustic restore --numeric-id to take care of this, else you have to chown your restored files.

1 Like
8

Thanks @alexweiss,
Interesting, I wasn’t aware of these features in rustic.
As of now I sticked to upstream restic, but if I read the description correctly, it’s not a problem to mix both tools as the repo format is in sync, so I could use rustic restore for just the given use case.
Yes, I expected to use chown afterwards, but I was a bit surprised to not have an option like --strip-components (no offense, I really love using restic just an honest surprise considering the list of other options in the cli :sweat_smile:).

9

Correct :+1:

1 Like