Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for VSS (windows) #340

Closed
frederich opened this issue Nov 4, 2015 · 76 comments
Closed

Add support for VSS (windows) #340

frederich opened this issue Nov 4, 2015 · 76 comments

Comments

@frederich
Copy link

@frederich frederich commented Nov 4, 2015

The restic backup runs. In the mean time my work is going on. Restic come to the point where it saves my Outlook archive. But Outlook is still open, restic fails.

[2Kscanned 77389 directories, 924469 files in 7:49 GiBerror for e:\home\jf\archive\outlook\archive.pst: SaveFile() chunker.Next(): read e:\home\jf\archive\outlook\archive.pst: Der Prozess kann nicht auf die Datei zugreifen, da ein anderer Prozess e
@fd0
Copy link
Member

@fd0 fd0 commented Nov 4, 2015

Hm, what do other programs on Windows typically do? It looks like restic is denied opening the file...

@episource
Copy link
Contributor

@episource episource commented Nov 4, 2015

The way to go is Volume Shadow Copy Service (VSS) [1, 2]. It creates (at least) crash consistent copy-on-write snapshots and allows safely copying opened files. Additionally The Volume Shadow Copy service notifies compatible applications (like MS SQL Server) that a VSS Snapshot is to be taken so that they can provide consistent data to be included in the snapshot [1].

VSS support could be integrated into restic, but it's also possible to create a VSS snapshot externally and use that as a backup source. [3-7] might be of interest.

[1] https://technet.microsoft.com/en-us/library/ee923636.aspx
[2] https://en.wikipedia.org/wiki/Shadow_Copy
[3] https://technet.microsoft.com/en-us/library/cc754968.aspx
[4] http://flaming-grackles.tumblr.com/post/41091667883/some-notes-on-reinstating-shadow-copies-on-windows
[5] http://www.heise.de/ct/inhalt/2009/09/180/
[6] http://blogs.msdn.com/b/adioltean/archive/2008/02/28/a-simple-way-to-access-shadow-copies-in-vista.aspx
[7] https://technet.microsoft.com/en-us/library/cc772172.aspx

@fd0
Copy link
Member

@fd0 fd0 commented Nov 4, 2015

Thanks for linking the documentation! Integrating automatic VSS creation looks like a big endeavour, though.

@episource
Copy link
Contributor

@episource episource commented Nov 4, 2015

If someone is willing to integrate VSS directly into restic, the VSS API description can be found here.

@fd0 fd0 changed the title file already in use, backup fails Add support for VSS (windows) Apr 16, 2017
@turnkey-commerce
Copy link
Contributor

@turnkey-commerce turnkey-commerce commented Jun 11, 2017

To more easily integrate restic with automatic VSS creation I wrote a Windows PowerShell script that can be run to automate this without the complications mentioned above. It is available in the attached zip:
restic-backup-windows-vss.zip

If restic has a repository for external scripts but perhaps it could be included there.

The meat of the script is in these lines excerpted from the script (omitting the config part):

$ShadowPath = $rootVolume + 'shadowcopy\'

# Create a volume shadow copy and make it accessible
$s1 = (Get-WmiObject -List Win32_ShadowCopy).Create($rootVolume, "ClientAccessible")
$s2 = Get-WmiObject Win32_ShadowCopy | Where-Object { $_.ID -eq $s1.ShadowID }
$device  = $s2.DeviceObject + "\"

# Create a symbolic link to the shadow copy
cmd /c mklink /d $ShadowPath "$device"

# Run Restic on the data files in the shadowcopy

ForEach ($folderToBackup in $foldersToBackup) {
    cmd /c $resticExe backup -r $resticRepository ($ShadowPath + $folderToBackup)
}

# Delete the shadow copy and remove the symbolic link
$s2.Delete()
cmd /c rmdir $ShadowPath

@fd0
Copy link
Member

@fd0 fd0 commented Jun 11, 2017

Thank you very much! There's no contrib repo of some kind, but I'm sure that interested users will find this issue and your script.

@turnkey-commerce
Copy link
Contributor

@turnkey-commerce turnkey-commerce commented Jun 11, 2017

You're welcome and thanks for sharing this useful application!

@bwmarrin
Copy link

@bwmarrin bwmarrin commented Jun 12, 2017

That's a nice script @turnkey-commerce :) I've been using normal non-powershell batch file to do this with rsync, but your version is nicer.

On the topic of restic though. Adding VSS support somehow would be really really OMG really nice :) Without that, it's hard to break into the Windows Enterprise segment of backups where VSS is both expected and really needed. Of course, shell script work arounds like above will help mitigate that, especially if decently documented somewhere :)

@Alwaysin
Copy link

@Alwaysin Alwaysin commented Feb 16, 2018

I'm seconding this! We need this at my company!

@jcasale
Copy link

@jcasale jcasale commented Mar 25, 2018

Keep in mind when implementing this feature, if you are attempting to access a file in a shadow copy whose provider has data on other volumes in addition to the one you snapshot, the writer will be excluded from the shadow copy unless you add each volume that contains data.

The WMI example won't suffice as the Create signature only facilitates a single volume.

@aventrax
Copy link

@aventrax aventrax commented Jun 1, 2018

The script proposed by @turnkey-commerce work great. I have been able to schedule it on machine startup to backup some stuff including locked files. Anyway, I think that VSS must be used by a user with admin privileges (in elevated mode) to work, so restic should be able to manage this as "sudo" does on linux.

Moreover, It's true that the VSS support and a small set of remote commands for clients and repository (API), would be necessary to implement this in a company.

@fd0 : Great job with Restic, I discovered it a few weeks ago and it works great!

@bjoe2k4
Copy link

@bjoe2k4 bjoe2k4 commented Jun 10, 2018

I am trying to use the Powershell script by @turnkey-commerce, which works great, but i am having trouble writing the restic output to a logfile. No matter what i do, i always end up having a jammed logfile. For example, when replacing line 33 with:

cmd /c $resticExe backup -r $resticRepository ($ShadowPath + $folderToBackup) >> backup.log

there goes something horribly wrong:


�[2K[0:01] 0 files 0 B, total 1 files 11 B, 0 errors

�[2K[0:01] 15 files 199 B, total 25 files 995.782 KiB, 0 errors

�[2K
�[2K[0:01] 15 files 199 B, total 25 files 995.782 KiB, 0 errors
... and so on...

However, when i run a bare restic backup command on cmd.exe and redirect that to a logfile (here having -v -v options) all is fine.

open repository
lock repository
load index files
using parent snapshot 2709b9ff
start scan on [C:\ProgramData]
start backup on [C:\ProgramData]
unchanged /C/ProgramData/.asv2sfi
unchanged /C/ProgramData/.cld2sfi
unchanged /C/ProgramData/.dys1sfi
... and so on...

@mgumz
Copy link

@mgumz mgumz commented Jun 24, 2018

@bjoe2k4 try the cmd /c ... part without all the rest and see if your "logging problems" persists.

i suspect that you are just observing something that is unrelated to the VSS part. if you can confirm this by trying out what i suggested, then feel free to open another issue.


towards the backups-on-windows issue: i am not sure that adding the support for vss directly into restic is actually worth the effort: usually one creates one vss-snapshot, then one calls restic multiple times to back things up, maybe some more operations on the snapshot itself and only afterwards one destroys the snapshot (or even keep it). i can not see a way to integrate vss into restic (called multiple times) with that "create the snapshot once" workflow - without adding lots of complexity to restic. the powershell script of @turnkey-commerce is the best fit for the whole problem, actually. similar means are needed to operate on zfs or btrfs snapshots as well.

the real issue would then be to add a section to the restic documentation which describes how the "snapshot of a filesystem" issue can be solved for multiple filesystems. then, obviously, people need to keep that section up-to-date but it's still better than to add complexity to restic itself. imho.

@fd0
Copy link
Member

@fd0 fd0 commented Jun 24, 2018

Good point, thanks! I'm also not sure it's a good idea to add this to restic, so I'll move this to the "feature request" stage.

@mgumz
Copy link

@mgumz mgumz commented Jun 24, 2018

Well, it is more a "improve the documentation" thing than a feature. Especially if you think about the use cases and the given different filesystems which are able to create a snapshot. Tomorrow someone appears and wants snapshots of ReFS on Windows, UFS2 snapshots on FreeBSD, APFS from Apple etc :)

@bjoe2k4
Copy link

@bjoe2k4 bjoe2k4 commented Jun 24, 2018

@bjoe2k4 try the cmd /c ... part without all the rest and see if your "logging problems" persists.

The problems persist. I agree that this has nothing to do with VSS, I rather didn't want to open a new issue for this minor problem, as I was expecting some error on my side.

In the meantime I garthered new insights and also a workaround regarding my logging problems. It seems to be a interop problem with powershell and restic. I will open a new issue when i find time.

I also do agree that "managing snapshots of a filesystem" is outside the scope of restic.

@matthijskooijman
Copy link

@matthijskooijman matthijskooijman commented Aug 26, 2018

I wonder if this isn't something to put into restic after all. I can see that restic should not be trying to automatically manage snapshots on all kinds of systems. However:

  • I believe that Windows is a lot more picky about reading opened files, making it more important to use snapshotting to get a complete backup (so it's about completeness, not just consistency).
  • VSS is, AFAICS, a generic FS-agnostic feature, that handles this issue completely for the Windows platform, which makes it an implementation with a high bang-for-buck.
  • VSS is, AFAICS from the powershell example, fairly straightforward to get to work (unlike snapshotting on unix system snapshot which AFAIK are either filesystem-specific or operate on the block level, requiring a lot more insight in how the system is set up).

Additionally, doing this natively in restic seems a lot more reliable than from a script (in particular in terms of proper cleanup and guaranteeing a snapshot is removed after usage).

@matthijskooijman
Copy link

@matthijskooijman matthijskooijman commented Aug 31, 2018

One more consideration I found when looking more into VSS, is the handling or cleanup. Ideally, you want a non-persistent shadow copy, meaning it gets automatically cleaned up when it is released, which seems like an important feature to prevent shadow copies from piling up and taking up disk space. I assume this also means they are removed when the backup process somehow crashes or otherwise terminates without explicitly cleaning up, though I could not find definitive info on that (though non-persistent shadow copies are always cleaned up on reboot). See auto-release shadow copy on https://docs.microsoft.com/en-us/windows/desktop/vss/vssgloss-ahttps://docs.microsoft.com/en-us/windows/desktop/vss/vssgloss-a and all types on https://docs.microsoft.com/en-us/windows/desktop/api/Vss/ne-vss-_vss_snapshot_context

The powershell script shown above uses a "ClientAccessible" context. I'm not really sure what that means exactly, but it results in a persistent snapshot according to vssadmin list shadows (and I also confirmed that killing restic with ^C leaves the shadow copy behind). I tried modifying it to "Backup" (based on this doc) or "Volatile" (based on this doc), but both of these return code 5, which means "Unsupported shadow copy context". I'm not sure if I'm just using the wrong vocabulary, or non-persistent types are not supported. This post suggests that this type might not be supported for workstations, but I somehow doubt that (also because these docs say that VSS_CTX_BACKUP is the default, and also the only supported value on Windows XP).

A related observation is that you might need a persistent shadow copy to expose a shadow copy on a drive letter or folder. I somewhat suspect that the mklink approach used by the powershell script might also work on non-persistent snapshots. If it does not, that might be another reason to support VSS in restic - so restic can access the shadow copy directly, without needing any drive letter or link (though I think that accessing VSS files is a matter of using a magic filename, like \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy123, but that needs some kind of path-mapping like #1376 suggests)

Note even with the link approach in the above Powershell script there is still a caveat: When trying to backup the entire volume, the path to the link is passed to restic, which does not follow it (which relates to #542).

@mholt
Copy link
Contributor

@mholt mholt commented Nov 26, 2018

Using my change in StackExchange/wmi#45, all that is required to make a shadow copy in Go is this:

var vol string
connectArgs := []interface{}{nil, "root/CIMV2"}

_, err := wmi.CallMethod(connectArgs, "Win32_ShadowCopy", "Create", []interface{}{
	"C:\\",
	"ClientAccessible",
	&vol,
})
if err != nil {
	return err
}

fmt.Println("Shadow copy volume:", vol)

No idea how to clean it up (delete the shadow copy) yet.

@joonas-fi
Copy link

@joonas-fi joonas-fi commented Nov 28, 2018

I'm currently working on a super small library in Go taking cross-platform snapshots. Huge shout-out to @turnkey-commerce for giving me important pointers in #340 (comment) !

On Windows can be done entirely from command line, without PowerShell or (direct use of WMI) crap. This means that all we need on Go side is import "os/exec".

First, create snapshot:

> wmic shadowcopy call create Volume="D:"
Executing (Win32_ShadowCopy)->create()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
        ReturnValue = 0;
        ShadowID = "{984628B9-4972-4AF3-8748-E9EC2C810DEC}";
};

Microsoft being dick as usual, we have to go through WMI console because they deliberately cripple non-server versions of Windows by only removing the vssadmin create command. The implementation for snapshots clearly is there, but Microsoft actively wants to make things hard for people by requiring the use of workarounds for non-server OS versions.

You'll get back a GUID (because entreprise software, right?): {984628B9-4972-4AF3-8748-E9EC2C810DEC}

You can use this ID to query vssadmin for the volume path:

> vssadmin list shadows /Shadow={984628B9-4972-4AF3-8748-E9EC2C810DEC}
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Contents of shadow copy set ID: {2caa3819-940a-42ef-a39f-f01f4c75260d}
   Contained 1 shadow copies at creation time: 28/11/2018 15.08.49
      Shadow Copy ID: {984628b9-4972-4af3-8748-e9ec2c810dec}
         Original Volume: (D:)\\?\Volume{10eaffff-0000-0000-0000-602219000000}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
         Originating Machine: joonas3
         Service Machine: joonas3
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessible
         Attributes: Persistent, Client-accessible, No auto release, No writers, Differential

From that output we need to locate \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2

This can be symlinked so the files can be regularly accessed (NOTE: we had add the last backslash - that's important!):

> mklink /D d:\shadow \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\
symbolic link created for d:\shadow <<===>> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\

We can now use regular tools of accessing the files in the snapshot:

> dir d:\shadow
 Volume in drive D is Data-SSD
 Volume Serial Number is A876-6BA6

 Directory of d:\shadow

23/11/2018  14.04    <DIR>          Data
               0 File(s)              0 bytes
               1 Dir(s)  179 510 530 048 bytes free

Now we can delete the snapshot and the symlink:

> vssadmin delete shadows /Quiet /Shadow={984628b9-4972-4af3-8748-e9ec2c810dec}
> rmdir D:\shadow

The /Quiet is needed because otherwise it asks you if you really want to remove the snapshot.

@bherila
Copy link

@bherila bherila commented Nov 28, 2018

This is excellent; however, calling the API (as opposed to using wmic or vssadmin) has its advantages:

@joonas-fi
Copy link

@joonas-fi joonas-fi commented Nov 28, 2018

@bherila good point. I feel less dirty about not having to use WMI from Golang though.

I quickly open sourced my package so that if it helps in any way, even for inspiration: https://github.com/function61/bup/tree/master/pkg/fssnapshot

@joonas-fi
Copy link

@joonas-fi joonas-fi commented Nov 29, 2018

My package now transparently supports Linux (via LVM) also. I won't spam this issue more.

@nioncode
Copy link

@nioncode nioncode commented Dec 22, 2018

In a way, I feel like restic should not be responsible to cover snapshots on all systems. On Windows, it just needs VSS, but on Linux it might use either LVM or file system specific snapshot technologies (e.g. on btrfs).

However, since there is a universal way for doing snapshots on Windows and this can be added relatively easy through command line invocations, I think it makes sense to include VSS support in restic. On Linux, it is quite trivial to create snapshots before running restic and deleting them afterwards (or keep them for a local history of files).

@cdhowie
Copy link
Contributor

@cdhowie cdhowie commented Dec 23, 2018

I feel like restic should not be responsible to cover snapshots on all systems.

I think it makes sense to have restic support snapshots everywhere there is a consistent and unified service that will take care of the details. On Windows, this is VSS. On Linux, this doesn't exist yet, but it might some day when systemd decides it needs to do yet another thing.

@MB512
Copy link

@MB512 MB512 commented Jan 27, 2019

I found this short looking documentation from MS to create a snapshot for backup. Maybe this could help someone.

https://docs.microsoft.com/en-us/windows/desktop/VSS/simple-shadow-copy-creation-for-backup

@mholt
Copy link
Contributor

@mholt mholt commented Feb 8, 2019

If someone wants to help wrap up my pull request over at StackExchange/wmi#45 then we can probably make this possible in restic.

@fgma
Copy link
Contributor

@fgma fgma commented Jun 2, 2019

I've created a pull request to solve this a few weeks ago. Maybe someone is interested in testing it and give some feedback.

See #2274 for details.

@jcasale
Copy link

@jcasale jcasale commented Jun 2, 2019

It appear there is significant oversight here. Without consideration for writers, the operator must have sufficient knowledge of Windows VSS (not likely in most cases) otherwise they will succumb to confusing errors.

Consider a test host with SQL Server installed and data spread across more than one drive:

C:\Users\Administrator\Desktop>sqlcmd -W -Q "SELECT name, physical_name FROM sys.master_files WHERE database_id = DB_ID('test')"
name physical_name
---- -------------
test c:\test.mdf
test_log E:\test_Log.ldf

Now lets list the writers, (output significantly truncated):

C:\>diskshadow
Microsoft DiskShadow version 1.0
Copyright (C) 2013 Microsoft Corporation
On computer:  IDM,  6/2/2019 2:36:27 PM


DISKSHADOW> LIST WRITERS

...
        * WRITER "SqlServerWriter"
                - Writer ID   = {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
                - Writer instance ID = {92504559-51c7-45f5-abdd-6857da8794c9}
                - Supports restore events = TRUE
                - Writer restore conditions = VSS_WRE_ALWAYS
                - Restore method = VSS_RME_RESTORE_IF_CAN_REPLACE
                - Requires reboot after restore = FALSE
                - Excluded files:
                + Component "SqlServerWriter:\HOSTNAME\master"
                        - Name: master
                        - Logical path: HOSTNAME
                        - Full path: \HOSTNAME\master
                        - Caption:
                        - Type: VSS_CT_FILEGROUP [2]
                        - Is selectable: TRUE
                        - Is top level: TRUE
                        - Notify on backup complete: TRUE
                        - Paths affected by this component:
                                - C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA
                        - Volumes affected by this component:
                               - \\?\Volume{2af08413-0000-0000-0000-501f00000000}\ [C:\]
                        - Component Dependencies:
...
                + Component "SqlServerWriter:\HOSTNAME\test"
                        - Name: test
                        - Logical path: HOSTNAME
                        - Full path: \HOSTNAME\test
                        - Caption:
                        - Type: VSS_CT_FILEGROUP [2]
                        - Is selectable: TRUE
                        - Is top level: TRUE
                        - Notify on backup complete: TRUE
                        - Paths affected by this component:
                                - E:\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA
                        - Volumes affected by this component:
                               - \\?\Volume{f1a7c8cf-0000-0000-0000-100000000000}\ [E:\]
                        - Component Dependencies:

Note the Volumes affected by this component lines, two volumes must be included in the snapshot for the writer to activate.

This is where the problem arises.

If you do not explicitly verify writers, they are silently excluded. Note the exclusion of the writer verification:

C:\Users\Administrator\Desktop>dir E:
 Volume in drive E is Test
 Volume Serial Number is 5226-8C3C

 Directory of E:\

06/02/2019  02:48 PM         8,388,608 test_log.ldf
               1 File(s)      8,388,608 bytes
               0 Dir(s)  10,680,373,248 bytes free

C:\Users\Administrator\Desktop>dir Z:
The system cannot find the path specified.

C:\Users\Administrator\Desktop>diskshadow /s backup.dsh
Microsoft DiskShadow version 1.0
Copyright (C) 2013 Microsoft Corporation
On computer:  HOSTNAME,  6/2/2019 2:55:20 PM

-> SET VERBOSE ON
-> SET CONTEXT PERSISTENT
-> SET METADATA C:\Temp\metadata.tmp
The existing file will be overwritten.
-> # WRITER VERIFY {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
-> BEGIN BACKUP
-> ADD VOLUME e: ALIAS shadow_vol_e
-> CREATE
Excluding writer "Shadow Copy Optimization Writer", because all of its components have been excluded.
Component "\TasksStore" from writer "Task Scheduler Writer" is excluded from backup,
because it requires volume C:\ which is not in the shadow copy set.
...
Component "\HOSTNAME\master" from writer "SqlServerWriter" is excluded from backup,
because it requires volume C:\ which is not in the shadow copy set.
Component "\HOSTNAME\model" from writer "SqlServerWriter" is excluded from backup,
because it requires volume C:\ which is not in the shadow copy set.
Component "\HOSTNAME\msdb" from writer "SqlServerWriter" is excluded from backup,
because it requires volume C:\ which is not in the shadow copy set.
...
Component "\HOSTNAME\test" from writer "SqlServerWriter" is excluded from backup,
because it requires volume C:\ which is not in the shadow copy set.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Component "\BCD\BCD" from writer "ASR Writer" is excluded from backup,
because it requires volume  which is not in the shadow copy set.
...

Alias shadow_vol_e for shadow ID {b6998137-a589-4aef-ad5c-0f075522ebd3} set as environment variable.
Alias VSS_SHADOW_SET for shadow set ID {965642f7-1205-49ef-89e9-31dddbe41037} set as environment variable.
...

Querying all shadow copies with the shadow copy set ID {965642f7-1205-49ef-89e9-31dddbe41037}

        * Shadow copy ID = {b6998137-a589-4aef-ad5c-0f075522ebd3}               %shadow_vol_e%
                - Shadow copy set: {965642f7-1205-49ef-89e9-31dddbe41037}       %VSS_SHADOW_SET%
                - Original count of shadow copies = 1
                - Original volume name: \\?\Volume{f1a7c8cf-0000-0000-0000-100000000000}\ [E:\]
                - Creation time: 6/2/2019 2:55:40 PM
                - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
                - Originating machine: hostname
                - Service machine: hostname
                - Not exposed
                - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}
                - Attributes:  No_Auto_Release Persistent Differential

Number of shadow copies listed: 1
-> EXPOSE %shadow_vol_e% z:
-> %shadow_vol_e% = {b6998137-a589-4aef-ad5c-0f075522ebd3}
The shadow copy was successfully exposed as z:\.
-> END BACKUP
-> EXIT

C:\Users\Administrator\Desktop>dir Z:
 Volume in drive Z is Test
 Volume Serial Number is 5226-8C3C

 Directory of Z:\

06/02/2019  02:48 PM         8,388,608 test_log.ldf
               1 File(s)      8,388,608 bytes
               0 Dir(s)  10,684,567,552 bytes free

Now, with writer verification enabled:

C:\Users\Administrator\Desktop>diskshadow
Microsoft DiskShadow version 1.0
Copyright (C) 2013 Microsoft Corporation
On computer:  IDM,  6/2/2019 3:07:36 PM


DISKSHADOW> DELETE SHADOWS ALL
Deleting shadow copy {b6998137-a589-4aef-ad5c-0f075522ebd3} on volume \\?\Volume{f1a7c8cf-0000-0000-0000-100000000000}\ from provider {b5946137-7b9f-4925-af80-51abd60b20d5} [Attributes: 0x00120009]...

Number of shadow copies deleted: 1

DISKSHADOW>
C:\Users\Administrator\Desktop>diskshadow /s backup.dsh
Microsoft DiskShadow version 1.0
Copyright (C) 2013 Microsoft Corporation
On computer:  HOSTNAME,  6/2/2019 3:08:34 PM

-> SET VERBOSE ON
-> SET CONTEXT PERSISTENT
-> SET METADATA C:\Temp\metadata.tmp
The existing file will be overwritten.
-> WRITER VERIFY {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
-> BEGIN BACKUP
-> ADD VOLUME e: ALIAS shadow_vol_e
-> CREATE
Excluding writer "Shadow Copy Optimization Writer", because all of its components have been excluded.
Component "\TasksStore" from writer "Task Scheduler Writer" is excluded from backup,
because it requires volume C:\ which is not in the shadow copy set.
...
Component "\HOSTNAME\master" from writer "SqlServerWriter" is excluded from backup,
because it requires volume C:\ which is not in the shadow copy set.
Component "\HOSTNAME\model" from writer "SqlServerWriter" is excluded from backup,
because it requires volume C:\ which is not in the shadow copy set.
Component "\HOSTNAME\msdb" from writer "SqlServerWriter" is excluded from backup,
because it requires volume C:\ which is not in the shadow copy set.
...
Component "\HOSTNAME\test" from writer "SqlServerWriter" is excluded from backup,
because it requires volume C:\ which is not in the shadow copy set.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
The writer "WMI Writer" is now entirely excluded from the backup,
because it does not contain any components that can be included.

ERROR: The writer "{a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}" was not included. Aborting ...
       Check the syntax of the writer name and writer ID.

@fgma
Copy link
Contributor

@fgma fgma commented Jun 5, 2019

@jcasale Thanks for the detailed analysis. To summarize it:

  • enabling VSS writers will provide a consistent snapshot even when data is on different volumes
  • each writer provides information about its affected paths

my proposed solution would be:

  • enable all writers for a snapshot
  • include all volumes in the snapshot that are affected by any writer that affects the current volume

To get a consistent backup of e.g. SQLServer one would need to include all affected paths manually in the backup as this depends on the data you want to backup.

@jcasale
Copy link

@jcasale jcasale commented Jun 6, 2019

The problem is significantly complicated, take for example MS Exchange where if you include its associated writer and facilitate it by adding all related volumes, it truncates its logs when the backup completes.

That is a horrible side effect with a detrimental impact to an existing backup strategy if it relies on the logs remaining available.

I would recommend never automatically doing anything for the operator, but rather verbosely display exclusions for them. Provide a means to verify or exclude writers, roughly implement a subset of the useful commands diskshadow offers.

This provides the operator with no unexpected caveats but allows them to ensure their use case remains valid. For example, if I am actually backing up Exchange and I automate my script, by verifying the writer, my backup will fail if another admin adds a new volume later. This is consistent with a robust process free of surprises. I could then also explicitly exclude other writers I don't want involved and filter out paths on the volume that are unrelated to my use case.

By the way, thanks for work here and for the effort towards hashing out a great implementation.

@fbkopp
Copy link

@fbkopp fbkopp commented Jun 8, 2019

In my opinion, Restic is not a tool to create backup as an operating system image.
I believe Writers are just to back up the system image as a whole, inside the operating system where the backup is being done. Restic has always been a file backup tool, folders, non-operating system image, restic can be used to backup virtual machine disks. Using writers does not make much sense in backing up the SQL Server folder with database data for example. For me, it makes more sense to back up files generated from a SQL Server backup, because the process of restoring a backup of SQL Server is much easier and more intuitive than restoring an installation of it.

@zoggdotorg
Copy link

@zoggdotorg zoggdotorg commented Jul 26, 2019

I beg to differ fbkopp. A specific case is Outlook which locks the Outlook data files. So any use of a backup program to back up personal files on Windows really requires VSS support. Or at least that's what I find.

@iceymanz
Copy link

@iceymanz iceymanz commented Jul 26, 2019

fbkopp I think you're confused. While VSS freezes a volume, it has nothing to do with operating system images.

We need VSS support to access consistent copies of files locked by applications (of which there are many in a running system).

VSS writers specific to SQL and Exchange are another step more complex as detailed in links below, and are probably unnecessary unless restic wants to specifically target the enterprise space.

A Guide for SQL Server Backup Application Vendors (dated but all I could find quickly):
https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2005/administrator/cc966520(v=technet.10)

An image showing all the steps for a SQL VSS quiece and backup:
https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2005/administrator/images/cc966520.sqlwriter03%28en-us%2ctechnet.10%29.gif

@fbkopp
Copy link

@fbkopp fbkopp commented Jul 26, 2019

Maybe I was not very clear in the example of MS SQL Server. As shown by @iceymanz it is a very complicated process to back up. But not only backing up, you have to be able to restore, there are much more practical specific tools for this function. It has PR #2274 which covers file backup using VSS and can backup (locked) outlook files, thunderbird, among others for example.

@fgma
Copy link
Contributor

@fgma fgma commented Aug 7, 2019

My main idea for the pull-request was the basic use-case @iceymanz described: Backing up locked files e.g. outlook or thunderbird profiles.

For more complex enterprise scenarios I'm lacking the knowledge. I might upgrade the VSS integration to cover those cases as a second step if someone can help to create a concept how to do so.

@kmwoley
Copy link

@kmwoley kmwoley commented Feb 9, 2020

Based on the help in this bug/thread, I created a whole set of scripts to automate Restic backup on Windows - including VSS support. Hope this helps someone else out there: https://github.com/kmwoley/restic-windows-backup

@fgma
Copy link
Contributor

@fgma fgma commented Apr 28, 2020

Hello everyone,
I already posted in my pull request two weeks ago. I'm still lacking any official feedback on how to continue with my PR (#2274) merged. Maybe someone here can help.

Seeing people like @kmwoley or @olarriga build scripts around restic to integrate it with VSS clearly shows the need for it.

@rawtaz
Copy link
Contributor

@rawtaz rawtaz commented Apr 28, 2020

FWIW, I use @kmwoley's restic-windows-backup, and it works great. If one needs VSS with restic right now, just use that and be happy :)

@azurefreecovid
Copy link

@azurefreecovid azurefreecovid commented Jun 25, 2020

I just found @fgma's PR and have started using it as it is by far the best way I've seen to use Restic with VSS. Without VSS on Windows, any backup utility, including Restic is significantly reduced in its usefulness.

Anyway I've been testing @fgma's PR all morning and it seems to be working flawlessly (for my use case's anyway). I'm so comfortable with it I've switched all my Windows machines over to this branch.

If other people out there are looking for a Windows VSS solution for Restic I'd highly encourage you to give the PR a try. If more people try it and test it I should imagine there is a higher change it will be included in the Restic code base.

Given Restic is all written in Go, it is trivial to compile a binary. I cross compiled mine on my Linux box and it takes no time at all. If you are new to compiling Go there are some great instructions in the PR itself at this comment which will point you in the right direction.

@rawtaz
Copy link
Contributor

@rawtaz rawtaz commented Oct 21, 2020

There's an updated restic binary that includes the VSS support in @fgma's PR at: https://beta.restic.net/pr-2274/ - please try it and report any problems!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.