Hello, and first of all thank you for restic so much.
I am trying to restore a single file from the latest snapshot with the command:
restore latest --target /data/home/upback/restic/tmp --include “/data/nas3data/Downloads/Complete/All of Ben Liebrand on Radio Veronica Broadcast/Ben Liebrand - In The Mix Radio Show 2018 (radio 10)/#561 Ben Liebrand R10 - in the mix full hour format 2018-08-04_2100-2200 hours \[streamrip no re-encode\].mp3”
Note that the [ and ] characters are escaped, and that the filename has spaces in it so it is put between quotes.
The result of this is:
Fatal: more than one snapshot ID specified: [latest of Ben Liebrand on Radio Veronica Broadcast/Ben Liebrand - In The Mix Radio Show 2018 (radio 10)/#561 Ben Liebrand R10 - in the mix full hour format 2018-08-04_2100-2200 hours \[streamrip no re-encode\].mp3"]
And I can’t figure out why this specifies more than one snapshot?
If I do a find instead of restore:
find “/data/nas3data/Downloads/Complete/All of Ben Liebrand on Radio Veronica Broadcast/Ben Liebrand - In The Mix Radio Show 2018 (radio 10)/#561 Ben Liebrand R10 - in the mix full hour format 2018-08-04_2100-2200 hours \[streamrip no re-encode\].mp3” --long --snapshot latest
I would expect the result to be one single file, but instead a rather long list of files is returned with totally different files, p.e.:
dgrwxr-xr-x 100 100 0 2017-04-02 06:47:31 /data/nas3data/Apps/Traktor/Trainspotter2.3/configuration/org.eclipse.osgi/bundles/142/1/.cp/icons/full/dlcl16
The only reason I can think of is because of the word “full” in the filename requested, and the word “full” in the path of the unrelated file, but I am not sure.
How can I restore just the latest version of this one file?
The syntax is restic restore [flags] snapshotID. The snapshotID should be last.
I haven’t tested it myself and I’m not sure on this one but it might aswell be caused by wrong option order. The syntax should be restic find [flags] PATTERN.
You are correct, the order you were using is in the documentation and is working (just tested it). It looks like the # character is what is causing you problems. Maybe restic is interpreting the rest of the filename as comment?
Can you try this? restic restore latest --target /data/home/upback/restic/tmp --include "/data/nas3data/Downloads/Complete/All of Ben Liebrand on Radio Veronica Broadcast/Ben Liebrand - In The Mix Radio Show 2018 (radio 10)*"
Hello @764287, thank you for your reply.
I just tested the command you suggested but unfortunately, the same error occurs: 2021-04-07 12:05:58 Restic command restore latest --target /data/home/upback/restic/tmp --include '/data/nas3data/Downloads/Complete/All of Ben Liebrand on Radio Veronica Broadcast/Ben Liebrand - In The Mix Radio Show 2018 (radio 10)*' 2021-04-07 12:05:58 Starting restic restore, output follows Fatal: more than one snapshot ID specified: [latest of Ben Liebrand on Radio Veronica Broadcast/Ben Liebrand - In The Mix Radio Show 2018 (radio 10)*']
I also tried a find: find '/data/nas3data/Downloads/Complete/All of Ben Liebrand on Radio Veronica Broadcast/Ben Liebrand - In The Mix Radio Show 2018 (radio 10)*' --long --snapshot latest
Which also returns files that I would not expect, like, p.e.: Found matching entries in snapshot 50257878 from 2021-04-05 03:03:02 -rw-r--r-- 100 100 18193 2018-10-01 17:31:07 /data/nas3data/Iedereen/2018/BTW/1809.ods
Hi guys,
Besides a lot of joy restic gives me, I keep having this little issue. Today I ran into another file that can not be restored:
Restic version:
restic 0.12.0 compiled with go1.15.8 on linux/arm
I expect that this find command returns just one file:
find ‘/data/nas3data/Downloads/Complete/RARE FLAC/Unreleleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape’ --long --snapshot latest
And a restore fails:
restore latest --target /data/home/upback/restic/tmp --include ‘/data/nas3data/Downloads/Complete/RARE FLAC/Unreleleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape’
Fatal: more than one snapshot ID specified: [latest FLAC/Unreleleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape’]
For find, please see restic help find and notice that you’re supposed to provide the flags before the pattern you are searching for: restic find [flags] PATTERN.... Also make sure your quotes aren’t some funky ones, but plain single (') or double (") ones. Try e.g.:
find --long --snapshot latest '/data/nas3data/Downloads/Complete/RARE FLAC/Unreleleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape'
For restore, please see restic help restore and notice that you’re supposed to provide the flags before the snapshot you want to restore from: restic restore [flags] snapshotID. Also make sure your quotes aren’t some funky ones, but plain single (') or double (") ones. Try e.g.:
restore --target /data/home/upback/restic/tmp --include '/data/nas3data/Downloads/Complete/RARE FLAC/Unreleleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape' latest
I don’t remember off the top of my head if find accepts latest as a snapshot ID, but I guess you’ll see
I tried your suggestions, but unfortunately no luck:
find --long --snapshot latest “/data/nas3data/Downloads/Complete/RARE FLAC/Unreleleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape”
restore --target /data/home/upback/restic/tmp --include “/data/nas3data/Downloads/Complete/RARE FLAC/Unreleleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape” latest
Fatal: more than one snapshot ID specified: [FLAC/Unreleleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape" latest]
I tried single quotes (') and double quotes ("), behavior is the same.
You’re indeed right about the documentation there!
Reading the command and the output of your restore attempt, it appears that restic parsed "/data/nas3data/Downloads/Complete/RARE (including the starting ") as the value for the --include option, and either FLAC/Unreleleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape" (including the ending ") or each space-separated word of that as a snapshot ID (besides the latest one at the end). I’d guess it splits into all words.
I tried it here and it works fine to both find a file with spaces in it:
$ RESTIC_PASSWORD=apaapa ./restic -r apa find --long --snapshot latest "Another Suitcase In Another Hall (Tv Radio Edit).Ape"
repository ba330420 opened successfully, password is correct
Found matching entries in snapshot 844a6ba8 from 2021-04-13 19:20:18
-rw-r--r-- 502 20 7 2021-04-13 19:19:15 /foo/rare/RARE FLAC/Unreleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape
as well as restoring a file with spaces in it:
$ RESTIC_PASSWORD=apaapa ./restic -r apa restore --target tmp --include "/foo/rare/RARE FLAC/Unreleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape" latest
repository ba330420 opened successfully, password is correct
restoring <Snapshot 844a6ba8 of [/Users/rawtaz/go/src/github.com/restic/restic/foo] at 2021-04-13 19:20:18.436019 +0200 CEST by rawtaz@bleh.local> to tmp
$ find tmp
tmp
tmp/foo
tmp/foo/rare
tmp/foo/rare/RARE FLAC
tmp/foo/rare/RARE FLAC/Unreleased and rare tracks
tmp/foo/rare/RARE FLAC/Unreleased and rare tracks/Another Suitcase In Another Hall (Tv Radio Edit).Ape
My best guess right now is that you still have mangled characters in the command/path, for example I think that your spaces are not regular spaces. Please run the restore command again after editing it so that you replace each and every space in the command with a regular space (that is, delete each space and replace it with a regular new space).
Please accept my apologies because it was totally my own error. Somewhere in my script, quotes didn’t make it completely to the restic command that was issued by the script.
This is part of the problem. When you debug something, you should take all unnecessary potential culpruits out of the factor, and e.g. try the commands suggested manually. I presume that in this case you tested the things I suggested inside your script, which still contains the potential of error in the script. Better to try the commands all by yourself to make sure that they work as intended, then you can focus on the script being the problem.
