SECOND ROUND: Help final testing of Windows VSS support!


The VSS PR was merged into the master branch on 2020-10-24, feel free to test the latest master build at:

Thanks a lot to everyone who helped out!


  • After a very useful first round of testing the new VSS support in restic, @fgma and @MichaelEischer have been hard at work to polish it to a state where we’re can soon merge it.
  • We’d now like to ask everyone for a second round of testing before we hopefully merge this feature once and for all.
  • @fd0 has built a new executable binary based on this PR with VSS support. Please download and test it from:
  • What we want to know are the same things as mentioned in the list below for the first round of testing. Simply add your comments in this thread or in the PR at GitHub, whether successful or not.
  • Thank you very much!


Thanks to @fgma we currently have this PR for Windows VSS (Volume Shadow Copy) support. It’s been actively worked on and bug fixed for a while now. It has seen some testing and users using it, but we’d like to see more of that as we aren’t using Windows ourselves and thereby have limited testing done ourselves (in other words this feature is one of those that depend more on the community than many other features in restic do).

We’d like everyone who has the chance to do so to test this PR as soon as possible, so that we can get more information about how well it works out in the wild, and if there’s anything we’re missing in it regarding stability and potential bugs.

In particular we’d like to get feedback on the following, as mentioned by @fgma:

  • Does it work for you when backing up, or are there any problems with that phase of the process?
  • Does restoring files from it work fine, or are there any problems with that phase of the process?
  • Are the backups complete or is there any chance that you are missing some files or contents in your snapshots after using this PR?
  • Anything else you can think of that’s relevant.

So in short, please just test it, and as much as possible take some time to verify the result by restoring and checking the contents. I don’t have any particular reason to think it doesn’t work, but we’d like to just get that additional feedback besides the one we already got in the PR itself.

Thanks a lot to everyone helping out with this!

EDIT: Please let us know if you need help building restic from this PR! Or you can use a prebuilt (by @fd0) 64-bit binary with this PR in it by downloading .


You can find a pre-built binary for Windows (64bit only) here:


First, what might be a stupid question but do I need to turn on VSS myself or does the exe start and stop the service?

I copied my existing script and modified it to use the reference exe and a new repository. The following messages were written to stderr while backing up the C:\ drive -v -v --json
restic.exe : {“message_type”:“error”,“error”:{“Op”:“open”,“Path”:"\\?\C:\Users\x\AppData\Local\Comms\UnistoreDB\
At line:1 char:1

  • .${RESTICEXE} backup -r $RESTIC_REPOSITORY --exclude-file $RESTIC_EXC …
  •   + CategoryInfo          : NotSpecified: ({"message_type"...reDB\\USS.jtx"}:String) [], RemoteException
      + FullyQualifiedErrorId : NativeCommandError




rmsxrc.Default User\parent.lock",“Err”:32},“during”:“archival”,“item”:“C:\Users\x\AppData\Roaming\Mozilla\Firefox\
Profiles\r7rmsxrc.Default User\parent.lock”}

2.Default User\parent.lock",“Err”:32},“during”:“archival”,“item”:“C:\Users\x\AppData\Roaming\Thunderbird\Profiles\
o0khn7q2.Default User\parent.lock”}





Warning: failed to read all source data during backup
As you can guess from the messages I am running Firefox. Normally I will exist Thunderbird and Firefox before running restic so all the files I want can be backed up. I normally exclude directories or files which the operatng system (Windows 10) has open and exclude lots of cache and temp directories. I have not tried to recover any data from this backup.

Another drive on my machine was also backed up. Its stderr is:
restic.exe : {“message_type”:“error”,“error”:{“Op”:“open”,“Path”:"\\?\K:\Boot\BCD",“Err”:32},“during”:“archival”,“ite
At line:1 char:1

  • .${RESTICEXE} backup -r $RESTIC_REPOSITORY --exclude-file $RESTIC_EXC …
  •   + CategoryInfo          : NotSpecified: ({"message_type"...K:\\Boot\\BCD"}:String) [], RemoteException
      + FullyQualifiedErrorId : NativeCommandError

Warning: failed to read all source data during backup
The stdout for the backup of K;\ drive seemed to list all of the files but the stdout for the C:\ drive did not have any output but that may have been a quirk of my own doing because of non-perfect changes to the script.

Would you like me to try to do sample recoveries of portions of the c: and k: drives or run a restic check?

If you are going to test this version of restic be sure to tell your anti-virus program that this program is ok. Do a scan of the exe once but find the place to tell the anti-virus program that the restic.exe should be ignored. Otherwise it may do a lot of scanning because the exe opens so many, many files.

I’m in ! I’ll let you know in a few days how it’s been :slight_smile:

No, the VSS service should be running in the background all the time. You can check your running services for the VSS service. The only thing you need to do is run restic backup with the new flag --use-windows-vss --use-fs-snapshot. I don’t see this in the logs you posted. For more details and examples have a lookt at my first post in the PR at

The --use-window-vss is exactly what was needed and it worked. However I don’t think there is anything in the logs which would say that this option is being used. So I was able to backup C:\ without anything being written to stderr. I then did a restore of C:\Users\ to another drive then ran WinMerge, which actually is a diff style program, and it show that things were mostly identical. They were different mainly because of excluding cache. Actually excluding cache is excluding too much at least for one file. There is a python source file called which gets excluded. Is it possible to exclude only directories which match cache?

If you run with --use-windows-vss --use-fs-snapshot it will log information when creating snapshots. See or for an example log.

Yes it does log information
creating VSS snapshot for [c:]
successfully created snapshot for [c:]
but if it would be possible could it follow the --json flag and output the message with a message type of “status”? I have a program which reads the stderr and stdout so if the formatting is consistent things would be better.
Thanks for getting back to me so quickly.

It is already using the ArchiveProgressReporter in cmd_backup.go. This is passed down and used for all logging. I don’t see what to add here. Maybe someone with more experience in the logging architecture of restic can give me some hints on how to improve the PR.

I’ve been using this to backup my personal system for the last few weeks. To be thorough, I’ve been A/Bing this alongside v0.9.6 to a clone of the same repository (so I run a backup with v0.9.6, and then a backup with this an hour later). The PR has worked exactly as intended for me; backups (including open files) are fine, restores are fine, and the content of said backups appears exactly as it should be. The only critique I have is that if the restic backup run is interrupted, you wind up with a stale/orphaned VSS snapshot hanging around:

PS C:\restic-troix> .\restic.exe backup --use-windows-vss --verbose --repo 'c:/restic_repo' 'C:\Morrowind'
open repository
repository 068c0d8c opened successfully, password is correct
lock repository
load index files
start scan on [C:\Morrowind]
start backup on [C:\Morrowind]
creating VSS snapshot for [c:\]
successfully created snapshot for [c:\]
signal interrupt received, cleaning up
PS C:\restic-troix> vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Contents of shadow copy set ID: {89cca202-fb16-4278-becd-068acd1e7dee}
   Contained 1 shadow copies at creation time: 20/09/2020 12:03:26
      Shadow Copy ID: {ac84baa4-82b6-488b-ae79-cc39818b736e}
         Original Volume: (C:)\\?\Volume{92e176e0-2660-4d2f-ac02-d73f529c88a1}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy23
         Originating Machine: Elsenova
         Service Machine: Elsenova
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: Backup
         Attributes: Differential, Auto recovered

PS C:\restic-troix>

Subsequent runs don’t touch this shadow copy, so it remains on the system until cleaned up manually.

That said, the set of scripts I normally use for backups has exactly the same problem (, so I don’t consider it a deal-breaker, and would happily use the PR as-is!

1 Like

To the uninitiated whats the benefits of using vss over the current way that backups are conducted?

Also I just tested backing up files with vss executable and it went without a hitch. Il test restore tommorow and update this post.

It’s a matter of Windows locking certain files whereby you have to use VSS to back them up properly. It doesn’t matter much for your occasional Word document, but for things like MSSQL databases and other things it’s a must.

Is there a prebuilt binary for restic 0.10 with the VSS PR?

No, sorry. The code is polished quite fast as well (minor changes though).

If you want we can build one for you if you don’t want to build one yourself (very easy, just go run build.go after cloning the restic GitHub repository).

I compiled the lasted one about a week ago. Seems okay so far.

1 Like

Thought I would test the VSS enhancement but when I run that binary it says “unknown flag:–use-windows-vss”. That build identifies itself as “restic 0.10.0-dev (compiled manually) compiled with go1.15.2 on windows/amd64”
Is it just me?

1 Like

It’s called –use-fs-snapshot now.

1 Like