Duplicati has shipped four different ways of talking to Windows Volume Shadow Copy Service (VSS) over the years, and the 2.4.0.100 canary adds a fifth while retiring one. This article explains what each provider does, why it exists, and which one you should be using.

Why Duplicati uses VSS at all

On Windows, files that are open or locked by another program cannot be read reliably. Outlook data files, SQL Server databases, Hyper-V disks and browser profiles are typical examples. VSS solves this by taking a point-in-time snapshot of the volume, which Duplicati then reads instead of the live files.

A good VSS snapshot does more than freeze the disk. Before the snapshot is taken, VSS asks registered applications ("VSS writers") to flush their in-memory state to disk. That is what turns a merely crash-consistent snapshot into an application-consistent one, where a database backup restores cleanly rather than looking like the machine lost power.

Whether Duplicati takes a snapshot at all is controlled by --snapshot-policy (off, auto, on, required). How the snapshot is taken is controlled by --vss-provider, and that option is what the rest of this article is about.

The reason there are several providers is mostly historical. VSS is a COM API, and calling COM from .NET has always needed either a native helper library or a lot of hand-written interop. Each provider represents a different answer to that problem, with different trade-offs around maintenance, dependencies and correctness.

AlphaVSS: the original

AlphaVSS is the provider most long-time Duplicati users know. It is a managed wrapper around the VSS COM API, and for years it was the only way Duplicati could take snapshots. It does the job properly: it involves the VSS writers, so snapshots are application-consistent.

It has three problems that have grown over time:

• It is no longer maintained. The upstream project has stopped receiving updates, so any breakage on newer Windows or .NET versions has to be worked around rather than fixed.

• It requires the Visual C++ Redistributable. The managed part is thin; the real work happens in a native DLL built against the VC++ runtime. If that runtime is missing, snapshots fail with an unhelpful error, and shipping the redistributable adds an installer dependency Duplicati would rather not have.

• No ARM64 support. The native component was never built for Windows on ARM, so AlphaVSS cannot be used on those machines at all.

AlphaVSS is still available in 2.4.0.0 as --vss-provider=alphavss, but it is no longer the default and is slated for removal.

Vanara: the current stable default

When it became clear that AlphaVSS was not coming back, the search began for a maintained replacement. Vanara is a large, actively maintained collection of P/Invoke bindings for the Windows API, and it includes VSS bindings. It became the default provider in Duplicati 2.4.0.0 (--vss-provider=vanara).

Functionally it is on par with AlphaVSS: writers are involved and snapshots are application-consistent. Being maintained upstream was the main win, and it fixed the immediate concern of depending on abandoned code.

In practice it turned out to be a partial solution:

• It is heavy. Vanara covers a very large surface of the Windows API, and Duplicati uses a small corner of it. Pulling in the library adds size and complexity out of proportion to what is needed.

• It still requires the VC++ Redistributable. The VSS bindings rely on the same native runtime, so the installer dependency that motivated the move away from AlphaVSS did not go away.

• No ARM64 support either. The same native dependency means Vanara does not work on Windows on ARM, so the switch did nothing for those users.

Vanara remains the safe default for 2.4.0.0 stable, but like AlphaVSS it is planned for removal once the native provider has proven itself.

WMIC: the lightweight fallback

WMIC takes a completely different route. Instead of calling the VSS API in-process, it runs the wmic.exe command-line tool and asks it to create a shadow copy through the Win32_ShadowCopy WMI class. Because nothing native is loaded into Duplicati, it needs no VC++ Redistributable and works wherever wmic.exe exists.

The price is correctness. Win32_ShadowCopy.Create produces a snapshot but does not run the VSS writer flush. The resulting snapshot is crash-consistent, not application-consistent: locked files can be read, but a database captured this way may need recovery when restored. For plain documents and media that distinction rarely matters; for application data it can.

WMIC also has an expiry date. Microsoft deprecated wmic.exe and has removed it from recent Windows 11 builds, so a provider that shells out to it stops working on up-to-date systems.

WMIC is available in 2.4.0.0 stable (--vss-provider=wmic) and was removed in the 2.4.0.100 canary in favor of the WMI provider described below.

Native: the new default (canary 2.4.0.100+)

The Native provider is Duplicati's own implementation of the VSS COM interop, written directly against the VSS interfaces with no third-party library in between. It is the default in the 2.4.0.100 canary (--vss-provider=native).

It was built to fix the two problems the library-based providers kept dragging along:

• Full control. The code is in the Duplicati repository. When Windows or .NET changes something, the fix is a pull request rather than a wait on an upstream project or a workaround layered on top of one.

• No VC++ Redistributable. The interop is done entirely from managed code, so there is no native helper DLL and no runtime to install first. Snapshots work on a clean Windows install.

Because there is no prebuilt native component, it also runs on Windows ARM64, closing the gap AlphaVSS and Vanara both left.

Like AlphaVSS and Vanara, Native involves the VSS writers, so snapshots are application-consistent. It is meant to be the only full-featured provider going forward. As a canary feature it has had less field exposure than Vanara, which is exactly why it is shipping in canary first; reports of any difference in behavior compared with the older providers are welcome on the forum or on GitHub.

WMI: the fallback, done properly (canary 2.4.0.100+)

WMI replaces WMIC. It does the same thing, creating a shadow copy through the Win32_ShadowCopy class, but it talks to WMI directly from .NET through System.Management instead of launching wmic.exe. WMI itself is a supported part of Windows and is not going anywhere, so this provider keeps working on builds where wmic.exe has been removed.

Everything else about WMIC carries over, good and bad:

• No VC++ Redistributable and no native components, so it works on any Windows machine, including ARM64.

• No VSS writer flush. Snapshots are crash-consistent only. Locked files become readable, but application data is captured as it sits on disk at that instant.

WMI exists as a safety net. If the Native provider fails on a particular machine, --vss-provider=wmi still gets you a snapshot and a working backup while the underlying problem is investigated. It is not the right choice as a permanent setting for machines that back up databases or other writer-aware applications.

Side by side

Which one should you use?

For most people the answer is: none in particular. Leave --vss-provider unset and Duplicati picks the default for your version, Vanara on 2.4.0.0 stable and Native on the 2.4.0.100 canary.

Set it explicitly in these cases:

• On stable, without the VC++ Redistributable installed: --vss-provider=wmic gets you crash-consistent snapshots with no extra install. Or install the redistributable and keep Vanara.

• On stable, on Windows ARM64: --vss-provider=wmic is the only option; neither Vanara nor AlphaVSS works there. The canary with Native is the better choice for these machines.

• On canary, if Native fails: switch to --vss-provider=wmi to keep backups running, and please report what went wrong.

• On canary, if you want to compare behavior: vanara and alphavss are still there for the moment, which makes it easy to check whether a problem is specific to the Native provider.

Remember that --vss-provider only chooses the mechanism. If --snapshot-policy is off, no provider is used at all, and with auto Duplicati will silently fall back to reading live files when the snapshot fails. If a consistent snapshot matters to you, set --snapshot-policy=required so a failure stops the backup instead of quietly downgrading it.

What comes next

The end state is two providers: Native as the full-featured default and WMI as the dependency-free fallback. AlphaVSS and Vanara will be removed once the Native provider has enough mileage in the canary channel, which also removes the last reason Duplicati needed the Visual C++ Redistributable on Windows.

If you run the canary, the most useful thing you can do is nothing special: let it use Native, and tell us if a backup that worked with Vanara/AlphaVSS behaves differently. Every report shortens the road to a stable release with a single, well-understood snapshot path.