Windows VPS Backup: Windows Server Backup, VSS Snapshots, and Offsite Copies

Data loss on a Windows VPS is rarely caused by hardware failure. In practice it comes from bad updates, accidental deletions, ransomware, and misconfigured scripts — all of which are preventable with a working backup plan. Windows Server already ships the three tools you need: Windows Server Backup for file-level and system-state backups, the Volume Shadow Copy Service (VSS) for consistent snapshots, and robocopy for moving copies offsite. No paid backup agent required.

A backup strategy only matters if the underlying server is dependable — check uptime guarantees and storage options when you compare Windows VPS providers on our comparison table. Once the host is solid, the steps below give you a tested, native backup stack.

Install the Windows Server Backup Feature

Windows Server Backup is an optional feature, not installed by default on most VPS templates. Enable it with a single command or through Server Manager > Add Roles and Features:

Install-WindowsFeature -Name Windows-Server-Backup -IncludeManagementTools
Get-WindowsFeature Windows-Server-Backup | Select-Object Name, Installed

The feature adds the wbadmin command-line tool and the Windows Server Backup snap-in. On a VPS, attach a second virtual disk (for example E:) to use as the backup target — backing up to a folder on the same volume you are protecting defeats the purpose, because a failed disk or a ransomware run takes the backups with it.

How VSS Makes Backups Consistent

The Volume Shadow Copy Service coordinates with VSS-aware applications — SQL Server, Active Directory, Exchange — so they flush pending transactions before the snapshot is taken. A VSS backup of a database is crash-consistent in a way a raw file copy never is. Before you schedule anything, check that all writers report healthy:

vssadmin list writers | Select-String -Pattern "Writer name|State"

Every writer should show State: [1] Stable. A writer stuck in Failed or Retryable means that application’s data will not be captured correctly — fix the application first (usually by restarting its VSS writer service) before trusting the backup schedule.

Schedule a Full Server Backup with System State

A scheduled backup with wbadmin captures the OS volume, your data volume, and the system state (registry, AD database, boot files) needed to rebuild the server. Run this once from an elevated prompt:

wbadmin enable backup -addtarget:E: -schedule:02:00 `
  -include:C:,D: -systemState -quiet

Windows Server Backup keeps a rolling set of versions and ages out old ones automatically based on the target disk’s space. To control retention explicitly, run wbadmin delete backup -backupTarget:E: -keepVersions:7 -quiet from a scheduled task. For databases, prefer the application’s native backup (for example, SQL Server’s own BACKUP DATABASE jobs) and use the Windows-level backup as the safety net — the two layers protect against different failure modes.

Take One-Time Backups and VSS Snapshots

Before any risky change — a CU install, a schema migration, a permission overhaul — take a manual backup and a lightweight snapshot:

vssadmin create shadow /for=C:
wbadmin start backup -backupTarget:E: -include:C: -systemState -quiet

The vssadmin snapshot is nearly instant and is ideal as a pre-change rollback point, while wbadmin produces the restorable backup set. Many providers also offer scheduled hypervisor-level snapshots of the whole VM; treat those as an extra layer, not a replacement, because a snapshot stored on the same storage array as the VM disappears with it.

Copy Backups Offsite with Robocopy

An on-VPS backup disk protects against accidental deletion but not against losing the entire instance. The fix is an offsite copy — a second location that survives the primary host failing. Robocopy is the workhorse: it mirrors the WindowsImageBackup folder to a mounted network share or an object-storage drive with restartable, logged copy semantics:

robocopy E:\WindowsImageBackup \backup01\offsiteps1 /MIR `
  /R:2 /W:5 /LOG:C:\logs\offsite-copy.log
if %ERRORLEVEL% LEQ 7 (echo Offsite copy OK) else (echo Offsite copy FAILED)

Run that command from a scheduled task after the backup completes, and monitor the log path for failures. Add a second rotation layer by keeping daily copies for seven days, weekly copies for a month, and a monthly copy offsite — the /MIR flag plus a small retention script gives you that for free. Encrypt the offsite target (BitLocker on the destination volume, or the provider’s server-side encryption) since the backup set contains your data in cleartext.

Verify and Test Restores

An untested backup is a guess. List available versions and practice a file-level restore to an alternate location at least once per quarter:

wbadmin get versions -backupTarget:E:
wbadmin start recovery -version:06/01/2026-02:00 `
  -itemType:File -items:C:\data -recoveryTarget:F:
estore-test -quiet

Verify three things on each test: the restored file opens correctly, the system-state restore boots (test it on a scratch instance), and the offsite copy matches the local one (robocopy /L lists what would change). Record the test date and result next to your runbook so the plan stays honest.

Summary

Windows Server Backup plus VSS covers consistency, a second disk covers local resilience, and a robocopy mirror covers the offsite requirement — all native, all scriptable, all free. Install the feature, schedule the backup, mirror it offsite, and test a restore quarterly. When you pick or renew a host, make sure it offers a second attachable disk and snapshot support — see the full specs and pricing on the Windows VPS comparison table before you commit.

Database Mart provides Windows VPS plans with extra attachable storage and snapshot options for your backup targets — check Database Mart Windows VPS plans for storage-friendly configurations.