The restore failure isn’t specific to VSS. It’s a bug in restic’s parsing of path prefixes when performing a backup on Windows. A source given as a UNC, .e.g. restic backup \\computer\share or from a drive letter, e.g. restic backup s: results in the path being prefixed with characters which make restore impossible on a Windows machine. Where the drive letter is affected this can be worked-around by ensuring that a trailing backslash is used.
If your VSS backup is created via a method which does not use UNC then you’re good to go. But test a restore just in case!
restic ls from a backup from UNC:
repository 7343250a opened successfully, password is correct
snapshot 4d323024 of [\\computer\c$\Users\Username\Documents\filename.txt]…
[snip]
-rw-rw-rw- 0 0 499653 2018-03-03 01:16:52 /\\computer\c$/Users/Username/Documents/filename.txt
restic restore:
repository 7343250a opened successfully, password is correct
restoring <Snapshot 4d323024 of [\\computer\c$\Users\Username\Documents\filename.txt] …
ignoring error for : invalid child node name \\computer\c$
ignoring error for : invalid child node name \\computer\c$
There were 2 errors
For drive letters, ls output:
/S/S:./Documents/filename.txt
and restore output:
ignoring error for \S\S:.\Documents\filename.txt: mkdir C:\RestoreTest\S\S:.: The filename, directory name, or volume label syntax is incorrect.
Only hitch I’ve ran into is sometimes DiskShadow won’t unexpose the X:\ and then subsequent backups fail until you notice there’s an X:\ hanging around and manually remove it (and the only way I know to remove it is to delete ALL shadow copies (diskshadow delete shadows all), which sucks if you actually need other shadow copies to, say, restore a file).
That said, if your VSS is screwed up for whatever reason, diskshadow delete shadows all is a handy command to reset things back to scratch. Unlike other tools, it really will delete them all - not just the ones it has made itself. Just a pro-tip!