Windows VSS support

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?

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]…
-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:


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.

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:\)

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:


#Make shadows persistent

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


#Alias volume with alias

#Create Snapshot

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


#Delete the shadow copy

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:

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!


Here’s a good solution for PowerShell:

I use to run restic backups on Windows machines. It uses VSS and works fine.

1 Like

That one uses Get-WmiObject as well. It will be fine if you’re using Powershell 5.x but not 7.x. That was my reason for writing the one linked above.

Though mine does considerably less than that project you should just be able to swap out the Get-WmiObject for the CimObject ones in mine and be fine.

1 Like

Please see HELP WANTED: Testing Windows VSS support .