Rebased. Fixed some error checking/ignoring.

@DRON-666 : Is it too late to ask you to consider one more option to add in this PR?

-o vss.provider="{GUID}"

Backstory: https://forum.restic.net/t/windows-shadow-copy-snapshot-vss-unexpected-provider-error/3674

What do you think? I've done a proof-of-concept hack/patch with a hard-coded GUID for the standard MS system VSS provider, and it solved my problem. I could try rolling my own PR (it would be my first; I have no real experience with Go), but it would seem more expedient to piggy-back on yours, if you're amenable to it.

@jdiercks As I expected, the go-ole package is not compatible with all targets.
I don't know how to fix it, but you can compile and use this PR without problems.

Tested in my sandbox environment.
Smooth as silk so far.
Hope to roll it into production tomorrow.
Thanks very much!

C:\>restic -r test-repo backup --use-fs-snapshot -o vss.provider=b5946137-7b9f-4925-af80-51abd60b20d5 C:\ N:\ X:\
enter password for repository:
repository 273d5070 opened successfully, password is correct
creating VSS snapshot for [n:\]
use non default vss provider: {B5946137-7B9F-4925-AF80-51ABD60B20D5}
successfully created snapshot for [n:\]
creating VSS snapshot for [x:\]
use non default vss provider: {B5946137-7B9F-4925-AF80-51ABD60B20D5}
successfully created snapshot for [x:\]
creating VSS snapshot for [c:\]
use non default vss provider: {B5946137-7B9F-4925-AF80-51ABD60B20D5}
successfully created snapshot for [c:\]

@jdiercks I'd suggest to use the name of the provider instead of its GUID. GUIDs are a somewhat hard to understand for end users.

@fgma Microsoft iSCSI Target VSS Hardware Provider looks no better and, if I remember correctly, can be localized.

@fgma I have to agree with @DRON-666 on that one. GUID is more straightforward and reliable for this scenario. If a user is far enough along to be in a situation where explicitly specifying the provider even matters, then they can probably figure out they need to copy and paste a GUID from VSSADMIN LIST PROVIDERS.

@fgma @jdiercks Maybe automatic fallback to Microsoft Software Shadow Copy provider 1.0 can resolve all basic provider issues?

@DRON-666 that seems to be what VSSADMIN itself does. I would still leave the option in place to override if needed, but fallback would probably save a few people some confusion and grief.

that seems to be what VSSADMIN itself does.

@jdiercks I want to check this with API monitor, but I need to find system with more than one provider.
Can you try latest commit without specifying vss.provider option?

I'm currently using restic in a powershell script that creates a VSS snapshot in the beginning, then calls restic 3 times to backup the same data to 3 different repos (redundancy) and at the end deletes the snapshot. Is there any way this can be simplified with restics own VSS snapshots, but without creating 3 (different) snapshots on every restic call?

Can you try latest commit without specifying vss.provider option?

@DRON-666 Looks like without vss.provider it's still using IID_NULL in all the VSS calls.

@jdiercks @fgma I just checked: vssadmin always uses VSS_SWPRV_ProviderId not IID_NULL and I would suggest to do the same.
@bjoe2k4 No, you can't do this.

@DRON-666 I think I'm fine with restic defaulting to VSS_SWPRV_ProviderId as long as there is an option to override and specify a different provider if needed.

There is a slight risk that changing restic's default behavior would break some other user's backup, if they have multiple providers and they were relying on the hierarchical behavior produced by using IID_NULL, but I suspect that's a corner case at worst, and as long as it's documented they can just start using the new option to get back the results they want.

@bjoe2k4 can you share your powershell script? Curious to see how you implemented that. Could be useful to me in a different context.

@DRON-666 ok thanks, that would have been too good to be true.
@jdiercks unfortunately it is not really polished, so i'm uncomfortable to share. However, for creating snapshots with powershell, have a look at old versions of https://github.com/kmwoley/restic-windows-backup/releases

@fgma @jdiercks Now you can use vss.provider={guid}, vss.provider="name" or vss.provider=MS (alias for vss.provider={b5946137-7b9f-4925-af80-51abd60b20d5})

@DRON-666 Wow, that's a lot more code! But definitely very flexible. Am I reading right that you decided to keep the original default behavior, with restic passing IID_NULL as provider if none specified via options? I'm not seeing anything that looks like it's doing a fallback to ms sys provider.

@jdiercks somehow missed your question, sorry for that.
Yes, I removed the fallback, because in some situations all code can run without errors, but resulting shadow copy just doesn't work, and at this point it's too late for fallback.

@DRON-666 Thanks for clarifying. Good call.

I've been running nightly backups with this PR for several weeks now, and it seems pretty solid.

I think the VSS implementation in restic doesn't support setting the VSS backup type so far?

Differentiation between "full" backups and "copy" backups can be important when for example backing up an Exchange Server or an MS SQL Server.

Support for this would be really nice :)

See: https://docs.microsoft.com/en-us/windows/win32/vss/vss-backup-state

@kscheel VSS backup types irrelevant to restic backup/restore and you link confirms this:

It is possible for requesters to implement these backups using information and methods outside of VSS. Only when a requester implements a backup using the VSS API should it be said to have one of the listed backup types.

restic doesn't use VSS for backup, only for reading locked files. The restore operation doesn't use VSS at all.

@DRON-666 oh sorry, I guess I misunderstood a few things, nevermind then 🙈 Thanks for the explanation!