Vultr Snapshot vs Backup: Which One Actually Protects Your Data?

This post contains affiliate links. If you purchase through our links, we may earn a commission at no extra cost to you.

If you’ve dug into Vultr’s dashboard looking for a way to protect your VPS data, you’ve probably noticed two options sitting right next to each other — Snapshots and Automatic Backups — with almost no explanation of why you’d pick one over the other. The Vultr Snapshot vs Backup question has been asked on Vultr’s own community forum in some form every year since 2014, and the docs still don’t give you a straight answer. Here’s the short version: both capture the same kind of point-in-time disk image, but they’re billed completely differently, retained differently, and built for different jobs.

Vultr Snapshot vs Automatic Backup dashboard settings comparison
Vultr Snapshot vs Automatic Backup dashboard settings comparison

Vultr Snapshot vs Backup: The Quick Answer

Skip the theory for a second — here’s who wins for what.

Use CaseWinner
Cloning an instance to a new regionSnapshot
Cheapest way to protect a low-disk-usage instanceSnapshot
Zero-maintenance recurring protectionAutomatic Backup
Long-term archive of a known-good stateSnapshot (no expiration)
Production database with frequent writesBoth, used together
Lowest cost on a large, expensive instanceSnapshot (manual schedule)

The short version: Snapshots and Automatic Backups are the same underlying mechanism — Vultr takes a point-in-time image of your instance’s disk either way. The real difference is automation and billing, not data protection quality. Snapshots are something you trigger manually (or script), cost $0.05/GB per month based on compressed size, and never expire. Automatic Backups run on a schedule you set once, cost a flat 20% surcharge on your instance’s price regardless of how much data you actually have, and only keep the two most recent copies.

What Is a Vultr Snapshot

A Snapshot is a manually triggered image of your instance’s disk — the OS, installed software, configuration, and data, frozen exactly as it existed when you clicked “Create Snapshot.” Snapshots work across every Vultr region: take one from an instance running in London, and you can deploy a brand-new instance from that same image in New York, Tokyo, or any other Vultr datacenter. That portability is what makes snapshots the standard tool for cloning a working server or migrating between regions — not backups.

You can use a snapshot two ways: restore it directly onto the existing instance, overwriting whatever’s currently there, or use it to spin up a completely new instance by selecting “Snapshot” as the deployment source. One limitation worth knowing up front — snapshots aren’t available for Bare Metal instances. If you’re running Bare Metal, Vultr points you toward third-party backup software instead.

Diagram of restoring a Vultr snapshot to the same instance versus deploying it as a new instance
Diagram of restoring a Vultr snapshot to the same instance versus deploying it as a new instance

What Is Vultr Automatic Backup

Automatic Backups is an opt-in setting you enable per-instance. Once it’s on, Vultr captures the instance on a schedule you pick — daily, every other day, weekly, or monthly, with a specific time and day. Vultr doesn’t stop the server to do this; it uses hot-sector tracking so the instance keeps running through the capture. That’s convenient, but it comes with a real trade-off: Vultr’s own documentation compares booting from a backup to rebooting after a non-graceful restart. For a busy database taking writes mid-backup, that’s not a hypothetical risk — it’s a genuine chance of capturing an inconsistent state.

A few details that matter in practice: backups don’t include attached block storage volumes, only the instance’s primary file system. Retention is thin — only the two most recent backups are kept, with older ones deleted automatically as new ones complete. There’s no long-term archive here. And if your instance uses a static IP, restoring a backup means you’ll need to manually reset networking to DHCP afterward to get connectivity back — an easy step to miss if you’re restoring under pressure.

Vultr Snapshot vs Automatic Backup: Side-by-Side

SnapshotAutomatic Backup
TriggerManual (or scripted via API)Scheduled — daily/weekly/monthly
Price$0.05/GB/month, compressed sizeFlat 20% of instance price
RetentionNo expiration, capped at 10/accountOnly 2 most recent copies
Restore optionsOverwrite existing instance OR deploy new instanceBoots instance from saved state only
Cross-regionYes — deploy in any Vultr datacenterNot documented (see note below)
Downloadable off-platformNoNo
Works on Bare MetalNoYes
Includes block storage volumesYes (part of disk image)No

Last updated: July 2026

One gap worth flagging honestly: Vultr’s documentation confirms snapshots work across regions, but it never explicitly says whether Automatic Backups can be restored cross-region the same way. I couldn’t find anything in Vultr’s docs, blog, or support pages confirming it either way — so treat cross-region restore as a snapshot-only feature until Vultr documents otherwise.

The Real Cost Math

This is where most comparison posts get lazy, so let’s actually run the numbers across a few instance sizes.

Small instance — $6/month (1 vCPU/1GB plan): Automatic Backups add 20%, so you’re paying $1.20/month extra. A single compressed snapshot of roughly 10GB costs about $0.50/month. If you’re only keeping one or two snapshots, manual snapshots are clearly cheaper here.

Mid-size instance — $20/month (2–4GB plan): Backups add $4/month. An equivalent 40GB compressed snapshot runs about $2/month — but that’s a single snapshot with no auto-rotation. Backups buy you convenience and automatic retention; snapshots buy you raw storage economy.

Larger instance — $96/month (High Frequency plan): Backups add $19.20/month. Because the 20% surcharge scales with instance price, not disk usage, this is where the backup tax starts to sting — especially if your actual disk usage is modest. A cost-conscious setup here might use a weekly cron-triggered API snapshot instead of paying nearly $20/month for automation.

The pattern: Automatic Backups get proportionally more expensive as your instance price climbs, because the fee is a fixed percentage of price, not data size. Snapshots get proportionally cheaper per dollar of instance cost as your actual disk usage shrinks relative to plan size. Where the crossover point lands depends entirely on how much real data you’re storing versus what you’re paying for compute — which is exactly the nuance that Vultr’s own docs skip over.

Bar chart comparing monthly cost of Vultr Automatic Backup vs Snapshot across $6, $20, and $96 instance plans
Bar chart comparing monthly cost of Vultr Automatic Backup vs Snapshot across $6, $20, and $96 instance plans

If you’re spinning up a test instance to run these numbers yourself before committing to a plan, new Vultr accounts get $300 in free credit valid for 30 days — enough room to test snapshots and backups on a few instance sizes without spending anything out of pocket. You can grab that credit and start testing through Vultr. For a full breakdown of how Vultr’s plan pricing works before you pick an instance size, our Vultr pricing breakdown covers every tier, and our deep dive on the $300 credit walks through exactly what it does and doesn’t cover.

🎁 Get $300 free credit when you sign up (valid for 30 days, limited-time offer) — Claim your credit →

Retention Limits and Restore Behavior

Snapshots don’t expire as long as the source instance still exists, but Vultr caps accounts at 10 snapshots by default — a legacy limit that’s been in place for years and shows up repeatedly in forum threads going back to 2015. If you need more, you can raise the cap by opening a support ticket with a legitimate reason; it’s not a hard technical wall, just a default guardrail.

Restoring a snapshot gives you a real choice: overwrite the existing instance’s current state in place (this takes roughly 10–15 minutes longer than a standard restart), or deploy a fresh instance from that snapshot image instead. Automatic Backups don’t give you that flexibility — restoring a backup only boots the same instance from the saved state, and it’s an all-or-nothing restore of the entire disk, not individual files.

Here’s the detail that surprises people planning for compliance or disaster recovery: neither snapshots nor backups can be downloaded off Vultr’s platform. Both are restore-in-place only. If your data protection strategy depends on an offsite copy — the “1” in a 3-2-1 backup strategy — neither Vultr feature gets you there on its own. You’d need to pair either one with something like rsync or rclone pushing data to external storage if true offsite redundancy matters for your setup.

The Stopped-Instance Billing Myth

I’ve seen this assumption more than once in support forums: stop the VPS, and backup billing pauses too. It doesn’t. Vultr continues to reserve CPU, RAM, SSD, and your IP address for a stopped-but-not-destroyed instance, and all of that is billable regardless of power state. The 20% Automatic Backup surcharge keeps accruing the entire time the instance exists, stopped or running. The only way to actually stop being charged is to destroy the instance outright — at which point you lose the backups tied to it anyway. If you’re trying to save money on a server you’re not actively using, destroying it (after taking a final snapshot) is the only move that actually works.

Which One Should You Use?

Based on how each feature actually behaves, here’s how I’d split the decision:

Use Snapshots when you’re cloning an instance to a new region, taking a safety point before a risky upgrade or migration, or want to archive a known-good state indefinitely. Cost scales with your actual disk usage, not your instance price, so this is the economical choice for infrequent, deliberate protection.

Use Automatic Backups when you want zero-maintenance, continuous protection against accidental data loss on a production instance, and you’re fine paying the flat 20% tax for “set it and forget it” coverage. Just remember only two rotations are kept — this isn’t a long-term archive, it’s a rolling safety net.

Use both when you’re running anything in production. This is what Vultr’s own guidance points toward, and it’s the one thing every independent source on this topic agrees on: Automatic Backups catch accidental data loss on a regular cadence, and a manual snapshot right before any risky change (a major update, a migration, a schema change) gives you an instant rollback point that backups’ 2-copy rotation might not cover in time. If you’re running a self-managed database, this combination matters even more — our PostgreSQL on Vultr backup guide goes through exactly how to layer these protections around a live database.

On a $20/month instance, a common approach is running Automatic Backups on a daily schedule for routine safety and triggering a manual snapshot before every deployment. The backup rotation costs $4/month, and the deployment snapshots add another dollar or two depending on how many accumulate before cleanup — a small price for not having to think about it.

Snapshots for Cloning, Backups for Recovery

There’s no universal winner in the Vultr Snapshot vs Backup decision — the two solve different problems. If you want cheap, indefinite, cross-region-portable images for cloning and pre-change safety points, use Snapshots. If you want hands-off recurring protection and don’t mind paying a percentage of your instance price for it, turn on Automatic Backups. For anything running in production, run both — daily or weekly Automatic Backups for routine coverage, plus a manual snapshot before any change you’d hate to redo from scratch.

If you’re still deciding on the instance itself, our full Vultr review covers how the platform performs day-to-day beyond just backups and snapshots. And if you haven’t set up a Vultr account yet, the $300/30-day credit mentioned earlier is the cheapest way to test snapshot and backup costs on a real instance before you commit a card to a monthly plan.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top