Restore fails but no error is shown

Hello, thank you for restic!

I am currently testing it, and have a problem with restoring.

What I would like to do in a script is:

  1. (incremental) backup
  2. select one file from the source
  3. restore that file to a temp location
  4. compare that file with the restored one

This works perfectly when running as root on a linux system.

Now, for added security, I run the script (and the backup) as a non-root user. Step 1 and 2 from above still works. However, step 3 doesn’t. Restic produces no error (the exit code even is 0), but no restored file can be found. The non-root user has write-rights to the temp location.

It seems to me, that restic should produce an error in this case (which it doesn’t).
Furthermore, I am wondering why the restore would fail as a non-root user.

Thank you for your help!

Please provide more information. Which restic version and what exact commands are you using? Did you make sure that the specific file you want to restore was saved to the repository (e.g. restic find FILENAME --long --snapshot latest)?

Thank you for your reply, and thank you for the suggestion to use a find command.

This is restic restic_0.11.0_linux_arm

By testing with that find command, I found that when restoring a single file with a bracket in its name ([ or ]) , you need to escape that bracket on the commandline ([ or ]), even when putting the filename between double-quotes, so
restic restore latest --include “/path/to/file [name].txt”
restic restore latest --include “/path/to/file \[name\].txt”

Note that the space in the filename does not need to be escaped.

I am not used to the need of escaping brackets in filenames, as long as the filename is put between quotes.

Is this a restic-thing, and if so, are there any more characters that need to be escaped?

Thank you.

The reason behind this is that the string passed to --include can be a glob (e.g. *.go) and the brackets are used to specify a list of characters at that position (e.g. test[1234].go). I don’t think this is explicitly documented anywhere, so that’s a bug. :slight_smile:

Thank you for your explanation!

1 Like