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?
opened 02:18PM - 22 Sep 18 UTC
type: bug
category: restore
platform: windows
Output of `restic version`
--------------------------
restic 0.9.2 compiled wi… th go1.10.3 on windows/amd64
How did you run restic exactly?
-------------------------------
restic -r D:\backups backup E:\
restic -r D:\backups restore <id> -t target_dir
What backend/server/service did you use to store the repository?
----------------------------------------------------------------
Expected behavior
-----------------
It should be able to store/restore properly
Actual behavior
---------------
Restic apparently stores : in the paths, which make the repo unable to be restored?
When I run ls against my repo, it shows something like the following:
/E/E:./repo/.git/objects/info
/E/E:./repo/.git/objects/pack
/E/E:./repo/.git/refs
/E/E:./repo/.git/refs/heads
/E/E:./repo/.git/refs/heads/git-annex
/E/E:./repo/.git/refs/heads/synced
/E/E:./repo/.git/refs/heads/synced/git-annex
/E/E:./repo/.git/refs/heads/synced/master
/E/E:./repo/.git/refs/tags
When I try to restore, it shows something like the following:
ignoring error for C:\Users\brad\a\E\E:.\repo\.git\objects\f6: mkdir C:\Users\brad\a\E\E:.: The filename, directory name, or volume label syntax is incorrect.
ignoring error for C:\Users\brad\a\E\E:.\repo\.git\objects\f6\65cfca35e159a0a47237041d1d20edd0218ba3: mkdir C:\Users\brad\a\E\E:.: The filename, directory name, or volume label syntax is incorrect.
ignoring error for C:\Users\brad\a\E\E:.\repo\.git\objects\info: mkdir C:\Users\brad\a\E\E:.: The filename, directory name, or volume label syntax is incorrect.
ignoring error for C:\Users\brad\a\E\E:.\repo\.git\objects\pack: mkdir C:\Users\brad\a\E\E:.: The filename, directory name, or volume label syntax is incorrect.
ignoring error for C:\Users\brad\a\E\E:.\repo\.git\refs: mkdir C:\Users\brad\a\E\E:.: The filename, directory name, or volume label syntax is incorrect.
ignoring error for C:\Users\brad\a\E\E:.\repo\.git\refs\heads: mkdir C:\Users\brad\a\E\E:.: The filename, directory name, or volume label syntax is incorrect.
ignoring error for C:\Users\brad\a\E\E:.\repo\.git\refs\heads\git-annex: mkdir C:\Users\brad\a\E\E:.: The filename, directory name, or volume label syntax is incorrect.
ignoring error for C:\Users\brad\a\E\E:.\repo\.git\refs\heads\synced: mkdir C:\Users\brad\a\E\E:.: The filename, directory name, or volume label syntax is incorrect.
ignoring error for C:\Users\brad\a\E\E:.\repo\.git\refs\heads\synced\git-annex: mkdir C:\Users\brad\a\E\E:.: The filename, directory name, or volume label syntax is incorrect.
ignoring error for C:\Users\brad\a\E\E:.\repo\.git\refs\heads\synced\master: mkdir C:\Users\brad\a\E\E:.: The filename, directory name, or volume label syntax is incorrect.
ignoring error for C:\Users\brad\a\E\E:.\repo\.git\refs\tags: mkdir C:\Users\brad\a\E\E:.: The filename, directory name, or volume label syntax is incorrect.
There were 371 errors
Steps to reproduce the behavior
-------------------------------
Basically, backup the root of a drive letter on windows, and then try to restore it.
For example:
restic -r repo backup E:\
Do you have any idea what may have caused this?
-----------------------------------------------
I think restic is storing colons in the paths, which it can't properly restore on windows.
Do you have an idea how to solve the issue?
-------------------------------------------
I think restic is storing colons in the paths, which it can't properly restore on windows.
Did restic help you or made you happy in any way?
-------------------------------------------------
All the darn time, I absolutely love this project.
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.
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:\
)
akrabu
August 18, 2019, 7:02am
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!
2 Likes
akrabu
June 10, 2020, 2:22am
7
Here’s a good solution for PowerShell:
I saw there’s already discussion on implementing VSS but hasn’t been built as of yet.
I wanted to write something for myself that creates/destroys shadow copies before/after restic runs.
I came across this comment on the issue which lead me in the right direction but then I discovered that these Get-WmiObject commands don’t work in Powershell 7.
If you try, you get:
Get-WmiObject: The term ‘Get-WmiObject’ is not recognized as the name of a cmdlet, function, script file, or operable program. …
rawtaz
June 10, 2020, 8:20pm
8
I use https://github.com/kmwoley/restic-windows-backup 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
rawtaz
August 29, 2020, 10:06am
10