Creating a shadow copy using the "Backup" context in a PowerShell

Question

I am in the process of writing a PowerShell script for backing up a Windows computer using rsync. To this end, I am attempting to use WMI from said script to create a non-persistent Shadow copy with writer participation (as is apparently recommended for backups).

I found out from another question (Accessing Volume Shadow Copy (VSS) Snapshots from Powershell) a way to create a shadow copy in general, but the example given there uses "ClientAccessible" as the context parameter, which results in the creation of a persistent shadow copy without writer participation.

While searching for a solution, I found that I could use the following command to obtain a list of contexts, which I assume are understood by WMI:

Get-WmiObject win32_shadowcontext | Out-GridView

It does have a context named "Backup", which is conveniently what I want. I proceeded to attempt creating a non-persistent shadow copy using that context:

$shadow = (Get-WmiObject -list win32_shadowcopy).Create("C:\", "Backup")

However, this seems to fail, and the content of the $shadow variable is set to

ReturnValue      : 5
ShadowID         : {00000000-0000-0000-0000-000000000000}

According to the relevant documentation (Create method of the Win32_ShadowCopy class), the return value means "Unsupported shadow copy context."

I couldn't find any relevant documentation as to why this context is unsupported or whether it is possible to use it at all. I have also tried the "FileShareBackup" and "AppRollback" contexts without success.

I assume I am either missing something obvious, that for some reason, WMI really doesn't support anything else than "clientAccessible" when creating shadow copies, or that this is OS-dependent (I am testing this on Windows 7, 64-bit).

How can I get this to work?

Hinder

I am just wrote the same thing myself (but it was with C# and the library AlphaVSS), here is what I learned: You are going to need to mount the snapshot to get the files to sync it, but to be mountable a snapshot must have the NoAutoRelease flag set to true. Also to have NoAutoRelease set to true you must have Persistent set to true, so just a fyi so you don't spend too much time trying to get something other than ClientAccessable to work (ClientAccessable has both variables set to true) – Cung

Shadow copies created with NoAutoRelease set to False are automatically removed once the process requesting them ends (link). I was originally suspecting that that was the issue that I was seeing, but the fact that I have the same problem with the AppRollback context suggests it may not be the case. But in general it is possible to mount auto-release shadow copies as described at link. However, I would prefer using powershell rather than the solution proposed there. – Hinder

If you can't get WMI to work, maybe try loading the AlphaVSS assembly in to Powershell. Here is how to create a snapshot, mount it, and delete it in C#, you should be able to translate that in to powershell. – Cung

I figure I should probably respond to this, for the benefit of anyone who reads this. In short: Yes, it is possible to use AlphaVSS to accomplish what I wanted, but it isn't a simple undertaking. Writing code to properly support backups with writers pretty much means rewriting most of VShadow in PowerShell, which felt like a pointless exercise. Anyway, when it comes to using nonpersistant snapshots, the key is to perform all the actual backup operations before calling BackupComplete(). As far as I understood, the snapshot will be destroyed as soon as BackupComplete() is called. – Hinder

@JulienPicalausa, unless you think there's a better answer than that, you should probably paste that and mark it as answer ;) – Tyrannosaur

@JulienPicalausa did you find a solution for yet? I'm also unable to create a shadow copy with WMI with a context other then the ClientAccessable one – Interested

It appears to work if I use 'NASRollback' for the context. Not sure why yet. – Alisander

Hello! Did you manage to find a solution for this Shadow Copy context issue? I have the same problem, I wrote a backup script in PowerShell, but it does not allow me to use Backup context. Only ClientAccessible and NASRollback, which are not appropriate for me. – Crossbones

From what I've been able to gather, the Backup context is only valid on servers and it does not work on a desktop OS. Desktop OSes must use the ClientAccessible context. – Neurath

In case of WMI could be involved in the problem, you can try to directly use the VSS Win32 API in powershell with the DllImport clause. Regarding the SC Context VSS_CTX_Backup, it tickles me but can't remember why, i vaguely remember something about writers trouble (maybe policy trouble...). – Valero

Answer 1

Okay, Technoob1984 here with the scoop. See my attached screen shot.

This one is tricky, because you have to use x64 version of Powershell (located under system32 not wow64)

The Shadow Copy Context are the .properties of the object.

Also I used the static method in my screenshots below.

https://learn.microsoft.com/en-us/previous-versions/windows/desktop/vsswmi/create-method-in-class-win32-shadowcopy

# get existing shadow copies
$shadow = get-wmiobject win32_shadowcopy
"There are {0} shadow copies on this sytem" -f $shadow.count
""

# get static method
$class=[WMICLASS]"root\cimv2:win32_shadowcopy"

# create a new shadow copy
"Creating a new shadow copy"
$class.create("C:\", "ClientAccessible")

# Count again
$shadow = get-wmiobject win32_shadowcopy

so in the example there, you would want to use $class.Properties to see what you can use as a Shadow Context.

See my screen shot:

So Shadow Context is 'Caption, Count, Description' and anything else under the 'Name:' value of .Properties. I do not see 'Backup' as one of the options.

• Enjoy

Timbuktu

This is an old thread with a lot of views. You can find a ton of similar questions. The docs from Microsoft are confusing. This comment is the answer though, I promise!! – Timbuktu

Caption, Count, and Description are the names of Win32_ShadowCopy properties, not the names of contexts. ClientAccessible happens to be the name of a context and the name of a property in both classes. The question has it right by querying for Win32_ShadowContext instances. – Maemaeander

Answer 2

Your $shadow has a 5 on return value looking at the error message, your shadow id has all zeros , you would need to add a 1 or a 2 to the end of the volume shadow copy in the registry using binary or dword.

find the folder in the registry named volsnap in your regedit search .volsnap.sys is found in the C:\Windows\System32\drivers directory. The file size is 52,352 bytes.The volsnap file contains Microsoft's digital signature make sure its the correct bytes.

This confirms its authenticity. volsnap.sys appears to be a file that was compressed by an EXE-Packer. This technique is often used by trojans to keep the file size small and also hamper debugging efforts.

However, this in itself is not sufficient reason to presume malicious intent, since even well-intentioned, professional software producers take advantage of compressed files. For this reason, 2% of all experts consider this file to be a possible threat. The probability that it can cause harm is high. Please consider the additional Comments from other users.

  shadow id          default 
                        00000000-0000-0000-0000-000000000000
                        00000000-0000-0000-0000-000000000005

if it already has a 5 which it probably doesn't change it to 1

or create new code

Shadow id           $shadow 00000000-0000-0000-0000-0000000000001

not exactly as shown.you may have to try different wording I'm not sure if $will work, if not, try the js standalone version.

Manouch

This answer appears to be nonsensical. The problem is that the shadow copy is not created. I have no idea what locating the volsnap.sys file has to do with this, nor why you think changing the default ID from the empty GUID to -01 will help. – Twinkling

Is this written by GPT? – Cottonseed