A file copy of a running Hyper-V guest or SQL Server database is not a backup. It is a picture of a moving target, and the worst time to discover it will not boot or attach is during a restore.

File backup works because a file nobody is writing to is complete and self-describing. A virtual disk and a database are the opposite: constantly written, and only meaningful together with what is still in memory. Here is what that means for backup, scheduling and restore, with Duplicati's Hyper-V and MSSQL source providers as the worked example.

Why you cannot just copy the file

Three things go wrong when a backup tool treats a live VHDX or MDF like a document.

Open handles. Hyper-V holds the virtual disk open for exclusive access while the VM runs; SQL Server does the same with its data and log files. A naive copy either fails with a sharing violation or reads a file the owner is still changing underneath it.

In-flight transactions. At any moment some changes exist only in the transaction log, some only in memory, and some are half-written to data pages. SQL Server reconciles these at startup, but only if data and log files describe the same instant. Copy them seconds apart and recovery can fail or silently drop committed work. Inside a VM the same thing happens one level down, in the guest's cache.

Torn writes. A copy that takes minutes reads the first block at the start and the last at the end. If the application rewrote a structure spanning both in between, the copy holds a mix that never existed on disk: a corrupt VHDX allocation table, or a database that refuses to attach.

Crash-consistent vs application-consistent

The fix is to copy a snapshot rather than the live file: a frozen, read-only view of the volume at a single instant. On Windows that is the job of the Volume Shadow Copy Service (VSS). But snapshots come in two grades.

A crash-consistent snapshot captures what was on disk at that instant and nothing else. It is equivalent to pulling the power cord. Databases usually survive it, but recovery can be slow, the last minutes of transactions are lost, and multi-file applications can come back inconsistent with themselves.

An application-consistent snapshot adds a handshake. Before the volume is frozen, each application is told to flush memory, complete or roll back open transactions, and mark a clean point. A restore then looks to the application like a clean shutdown rather than a crash.

For an MSP this is the SLA: crash-consistent is "we will probably get it back," application-consistent is "we will get it back and it will work." Clients assume they are paying for the second.

How VSS writers produce a consistent point

The handshake is done by VSS writers: components shipped with each application that know how to quiesce it. The backup tool asks for a snapshot, VSS tells every writer to freeze, the writers do their application-specific work, VSS snapshots the volume, and the writers thaw. The freeze typically lasts a few seconds.

The SQL Server writer handles each database on the instance. On freeze it checkpoints so dirty pages reach the data files, holds new writes for the duration, and records the backup in SQL Server's own history so the chain stays coherent. The MDF, NDF and LDF files come out as a matched set.

The Hyper-V writer works on the host and reaches into each guest. For a running VM with integration services it asks the guest to run its own VSS snapshot first, so SQL Server or Exchange inside gets quiesced too, then snapshots the virtual disk. Guests without integration services fall back to a crash-consistent copy, and the writer reports which.

Two consequences follow. Writers must be healthy: vssadmin list writers showing one in a failed state means the next backup is quietly crash-consistent or fails outright. And the backup tool must actually drive the writers. A product that snapshots the volume and copies the VHDX out of it still gets a crash-consistent image, however reliable the copy. That is the line between a file-backup product with a VSS checkbox and one that understands these workloads.

Scheduling around maintenance windows and log truncation

Pick the quiet hour, then check it is quiet. Nightly is the obvious slot, but nightly is also when index rebuilds, integrity checks and patch reboots run. A backup that starts under DBCC CHECKDB, or is cut off by a host reboot, takes four times longer or fails. Put the backup, the SQL maintenance plan and the patch window on one calendar.

Decide who truncates the log. In full recovery model the transaction log grows until something backs it up. If the DBA already runs native log backups, the VSS backup should leave the log alone so it does not break their chain. If nobody does, which is common on small-business servers, either the backup product truncates it or the database moves to simple recovery. Not deciding is what fills disks at 3 a.m.

Mind the snapshot's own lifetime. If the backup process dies without releasing its snapshot set, every later backup can fail with "snapshot set in progress" until a restart. A tool should abort and clean up a failed set; test this before putting it on a production host.

Restore: whole VM, single database, and proving it worked

Whole VM. The case after hardware failure or ransomware. What goes wrong is rarely the data: the original path is gone, the old VM is still registered and holding the disk open, the virtual switch has a different name, or the restored machine is never registered and sits as an orphaned folder. A good restore flow names the files in use up front, offers to put the VM back where it came from, and registers it so it appears in Hyper-V Manager ready to start.

Single database. More often the request is one database, as of last Tuesday, because someone ran an UPDATE without a WHERE clause. Picking one database out of the backup, restoring its files to a side folder and attaching them under a new name recovers the rows while production keeps running.

Verify the copy, not the job status. A green job means the bytes were written, not that the VM boots or the database attaches. Restore the VM to an isolated network and watch it reach the login screen; attach the restored database to a test instance and run DBCC CHECKDB; compare a known recent record against the source. Do it on a schedule, and write down how long it took: a 400 GB VM over a 100 Mbit link takes most of a working day, and if the SLA says four hours the plan needs a local copy.

How Duplicati does it

Duplicati has backed up Hyper-V and SQL Server through VSS for some time, but until recently you reached them through placeholder paths (%HYPERV%, %MSSQL%) expanded into raw file lists. Starting with the 2.4.0.104 canary, both are proper source providers.

Each VM and each database appears in the source picker as its own virtual folder under its real name rather than a GUID or a path. The name travels with the backup as metadata, so the restore view and the Console show "Finance-SQL01" and "Northwind" instead of asking you to decode paths. Duplicati acts as the VSS requestor and drives the Hyper-V and SQL Server writers, so the snapshot is application-consistent where the writers allow it.

On restore, Duplicati lists files that are in use before it begins, so a running VM or an attached database is flagged rather than half-overwritten. Restore-to-original-location reads the destination from metadata, and --register-restored-items registers a restored machine with Hyper-V. The same release fixed a cleanup bug where a failed snapshot set could block later VSS backups.

Both providers are Windows-only and currently in the canary release channel (2.4.0.104 and later); the current stable release, 2.4.0.0, still uses the placeholder paths. If you run Hyper-V or SQL Server hosts for clients, we would like to hear how the providers behave on real workloads before they move to beta and stable.

Run it from the Console

The Duplicati Console turns this into a service rather than a per-host chore: enroll each Hyper-V host and SQL Server once, push the same configuration to all of them, watch every job on one page, and open a remote session when a writer needs attention, with no VPN or RDP hop. If you are building a Windows-heavy backup offering, start a Duplicati Console trial and point it at your canary test host.