In short
A snapshot freezes your server's disk at one point in time so you can roll the whole machine back in minutes, and it lives on the same platform as the VM it protects. A backup is an independent copy of your data on separate storage: it survives the loss of the server itself and can restore a single file or the full system. Snapshots are the safety net before a risky change; backups are the actual data protection. Production Windows servers need both, used for different jobs.
Quick verdict by use case
| If you are... | Use | Why |
|---|---|---|
| About to install updates or new software | Snapshot, taken right before the change | Whole-machine rollback in minutes if the change goes wrong |
| Protecting QuickBooks, Sage, or SQL Server data | Scheduled backups | Independent copies with retention, application-consistent when done properly |
| Recovering a file someone deleted last week | Backup | File-level restore from a retention history a snapshot does not have |
| Meeting a client or compliance retention requirement | Backups with a retention policy | Snapshots have no meaningful retention story |
| Running any production workload | Both | Snapshots for changes, backups for protection |
What a snapshot actually is
A snapshot is a point-in-time image of the server's virtual disk. When you take one, the platform marks the current state of the disk and starts recording changes separately, so the original state stays recoverable. Restoring a snapshot rolls the entire machine back to that moment: operating system, applications, settings, and data together.
Three properties follow from that design, and all three matter for how you should use snapshots.
Snapshots are whole-machine. You cannot pull one file out of most platform snapshots. Rolling back means everything on the server returns to the snapshot moment, including work saved after it was taken.
Snapshots are usually crash-consistent. A snapshot of a running server captures the disk as if the power cord had been pulled at that instant. Windows and NTFS recover from that fine, but a database engine in the middle of a write may not. Microsoft draws the same line in its own virtualization documentation: standard checkpoints capture running state without application awareness, while production checkpoints use the Volume Shadow Copy Service to quiesce applications first. On most hosting platforms, an on-demand snapshot behaves like the first kind. Microsoft is also blunt about the limits: its checkpoint documentation states that checkpoints are not a replacement for backups.
Snapshots live with the platform. The snapshot of a VM is stored by the same infrastructure that runs the VM. That is what makes rollback fast, and it is also the weakness: a snapshot does not protect you from anything that takes out the server or the account it belongs to.
What a backup actually is
A backup is an independent copy of your data written to separate storage on a schedule, with a retention history. Where a snapshot answers "undo the last change", a backup answers "give me back what I had", at three different levels: a single file, a folder or application dataset, or the full system.
The properties are the mirror image of a snapshot's.
Backups survive the server. Because the copy is independent, deleting the VM, losing the disk, or a platform-level failure does not take the backup with it. This is the reason backups, not snapshots, are the foundation of any disaster recovery plan.
Backups have retention. A schedule produces a history: yesterday's copy, last week's, last month's. That history is what lets you recover the spreadsheet that was corrupted nine days ago and nobody noticed, and it is the only honest answer to ransomware, where the most recent copy may already be encrypted.
Backups can be application-consistent. Proper Windows backup tooling uses the Volume Shadow Copy Service (VSS). VSS tells registered applications such as SQL Server to flush in-flight transactions to disk before the copy is taken, so the restored database opens cleanly instead of entering recovery. This is the difference between backing up a database server and merely copying its disk.
Side-by-side comparison
| Property | Snapshot | Backup |
|---|---|---|
| What it captures | Entire disk at one moment | Selected data or full system, on a schedule |
| Restore granularity | Whole machine only | Single file, folder, application, or full system |
| Restore speed | Minutes | Minutes to hours depending on size |
| Consistency | Crash-consistent as a rule | Application-consistent when VSS-aware |
| Storage location | Same platform as the VM | Independent storage |
| Survives loss of the server | No | Yes |
| Retention history | One or a few points, short-lived | Scheduled history with a retention policy |
| Cost behavior | Grows as the disk changes while it exists | Proportional to protected data and retention |
| Best at | Rollback before a risky change | Data protection and recovery |
Where snapshots win
Snapshots are unbeatable immediately before a change you might regret. Windows updates on a production server, a QuickBooks year upgrade, a new line-of-business app, a registry edit you half trust: take a snapshot, make the change, verify, delete the snapshot. If the change breaks something, rollback takes minutes and restores the machine exactly as it was, with no reinstalling and no reconfiguring.
They also win on simplicity. There is nothing to schedule and no agent to configure. One action, one rollback point.
Where backups win
Everything else. Backups are the only one of the two that can return a deleted file, recover data from before the most recent copy, survive the loss of the VM itself, or produce a consistent copy of a running database. If the server holds company files, client records, or a SQL Server instance, the question is not whether to run backups but how often and with what retention.
Backups are also the answer to ransomware. A snapshot stored with the platform can be rolled back, which helps, but only if the snapshot predates the infection and still exists. A backup history on independent storage gives you multiple restore points to walk back through and a copy the attacker never touched.
Where they tie
Neither replaces testing. A rollback you have never rehearsed and a backup you have never restored are both assumptions, not protection. Quarterly test restores of one file and one full recovery are cheap insurance.
Neither covers configuration drift by itself. Both protect a machine's state; documenting what the machine is supposed to look like is still on you.
What each costs on a Windows VPS
On Raff, snapshot storage and backup storage are priced the same, per GB per month. Current rates are on the pricing page; the table below reflects the rate as of August 2026.
| Item | Rate | Example |
|---|---|---|
| Snapshot storage | $0.06/GB/month | Short-lived pre-change snapshot of a lightly changing 80 GB disk: well under $4 for the days it exists |
| Backup storage | $0.06/GB/month | 40 GB of protected data: $2.40/month per retained copy equivalent |
Two cost behaviors are worth knowing. A snapshot's footprint grows with every change written to the disk while it exists, which is one more reason to delete snapshots after the change is verified rather than keeping them for weeks. Backup cost scales with how much you protect and how long you retain it, which makes retention policy a budgeting decision, not just a compliance one.
Windows licensing is unaffected by either: the monthly Windows Server licence covers the VM regardless of how you protect its data.
Three failures and what actually saves you
The cleanest way to see the difference is to walk through the incidents that actually happen to small-business Windows servers.
The botched update. Tuesday evening you install a Windows cumulative update and a new version of a line-of-business app. Wednesday morning printing is broken and the app will not start. If you took a snapshot before the change, this is a five-minute rollback and a calmer retry with the vendor's guidance. If you only have last night's backup, you can still get back, but you are restoring a full system instead of flipping a switch, and anything written between the backup and the failure needs care. This scenario is the one snapshots exist for.
The quietly corrupted file. A shared workbook was damaged nine days ago and nobody noticed until month-end. A snapshot cannot help: even if one still existed from that week, rolling the whole server back would destroy nine days of everyone else's work to save one file. A backup history restores that single file from the day before the corruption and touches nothing else. Retention depth decides whether this story ends well, which is why 14 to 30 days is the practical floor for business data.
The dead server. The VM is deleted by mistake, the disk fails, or ransomware encrypts everything including any snapshot the platform would happily roll back into. The only thing that matters now is a copy that lived somewhere else: platform backups first, and for the truly irreplaceable files, the off-platform export from the 3-2-1 rule. Recovery time is measured in hours, and the difference between a bad day and a company-ending one is entirely about whether the backups exist and have been tested.
One pattern runs through all three: snapshots shine exactly when you know a risky moment is coming, and backups carry every failure you did not see coming.
Common mistakes
Keeping a snapshot for weeks as the backup. It grows in cost the whole time, it cannot restore individual files, and it dies with the server. Microsoft's guidance on checkpoints says the same thing: not a backup substitute.
Snapshotting a busy database server and assuming the data is safe. A crash-consistent image of SQL Server or a QuickBooks company file mid-write can restore into an inconsistent state. Databases need VSS-aware, application-consistent backups.
No copy that leaves the platform. The classic 3-2-1 rule wants three copies on two kinds of storage with one off-site. For critical business data, pair platform backups with a periodic export of the irreplaceable files to somewhere independent, such as object storage.
Never testing a restore. The first restore you ever attempt should not be the one that matters. Schedule a test restore and treat a failure as a production incident.
Backing up the machine but not the data that matters. If company files live on a second volume or a mapped path, verify the backup job actually includes them. A completed job is not the same as a complete backup.
Our recommendation
Run scheduled backups on every production Windows VPS, sized to the data and retained long enough to survive slow-burn problems: 14 to 30 days covers most small-business cases. Take a snapshot before every risky change and delete it once the change is verified. Test a restore quarterly.
If you are an accounting firm hosting QuickBooks or Sage, treat application-consistent backups of the company files as non-negotiable and rehearse the restore before tax season, not during it. If you are running SQL Server, combine platform backups with native SQL backups as described in our MSSQL backup strategy guide. If the server is a shared file store for your team, our cloud file server guide covers the sharing side of the same coin.