Windows VSS support

#1

I’m looking to run restic on my wife’s Windows laptop.

I hope that this thread can serve as a “current state-of-play” for restic’s Windows VSS support.

Currently, I see:

I’ve asked for more details in the forum report in the link above.

The GitHub issue linked above is very long and dates back to 2015.

What is the 2019 solution to using restic with VSS? What are the associated risks?

Automating windows usage
Restic on Windows Clients
#3

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.

#5

Thanks @ProactiveServices for the issue link and the detailed explanation. Glad to know it’s not caused by VSS.

In summary, if I understand you:

  • Don’t use UNC paths (eg \\computer\share)
  • Always use a trailing \ if backing up a drive (Not C: but rather C:\)
#6

You might try DiskShadow to create another drive letter, which is actually a shadow copy - then back that up instead.

Here’s my DiskShadow file:

#backup.dsh

#Make shadows persistent
SET CONTEXT PERSISTENT
SET VERBOSE ON

#Cab location for process
SET METADATA C:\Users\akrabu\backup.cab

BEGIN BACKUP

#Alias volume with alias
ADD VOLUME C: ALIAS CVOL

#Create Snapshot
CREATE

#Expose the volume and run command file then unexpose
EXPOSE %CVOL% X:
EXEC C:\Users\akrabu\.restic\backup.bat
UNEXPOSE X:

END BACKUP

#Delete the shadow copy
DELETE SHADOWS SET %VSS_SHADOW_SET%

So that basically creates a shadow copy at X:\ then runs the backup script then “unexposes” (deletes) the shadow copy. You would call it by running:

C:\Users\akrabu\.restic\diskshadow.exe -s C:\Users\akrabu\.restic\backup.dsh

Then just make sure your backup script references X:\ (or whatever letter you choose in the .dsh file) instead of C:\

Another example:
https://ss64.com/nt/diskshadow.html

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!

1 Like