Snapshots vs Backups

"I have snapshots, so I'm backed up" is one of the most expensive mistakes in storage operations. Snapshots and backups solve different problems with different failure modes. Snapshots are instant, free, and fragile — they live with the original data. Backups are slow, costly, and resilient — they live somewhere else. Both have a place; neither alone is sufficient.

What each protects against

ThreatSnapshotBackup
Accidental file deletion (5 minutes ago)Best — instant restorePossible but slower
Botched application upgradeBest — roll back the volumePossible but slower
Single disk failureRAID protects, snapshot survivesBackup is intact
Whole array failureSnapshots die with the arrayBackup is intact
Datacenter destroyed (fire, flood)Snapshots dieOff-site backup intact
Ransomware encrypts everything reachableSnapshots often deleted by attackerImmutable/offline backup intact
Silent data corruption found 6 months laterRecent snapshots also corruptOlder retained backup intact

What a snapshot is

A snapshot captures the state of a filesystem or volume at a moment in time. On copy-on-write filesystems (ZFS, Btrfs), creating one is essentially free — just remember the current block references. Storage cost grows as data diverges from the snapshot point; reading from the snapshot shows whatever existed at that moment.

Properties:

  • Instant creation. Microseconds, even for huge datasets.
  • Same storage. Snapshot lives on the same physical disks as the live data.
  • Browsable. Mount or open the snapshot like a regular filesystem.
  • Read-only. Cannot be modified (clones are the writable variant).

What a backup is

A backup is a copy of data on different storage, ideally in a different location, with no path from the primary storage's failure to the backup. Properties:

  • Independent storage. Different disks, different array, different vendor, ideally different geography.
  • Restorable. Can be restored even if the primary is completely destroyed.
  • Tested. Restores are verified; an untested backup is a wish.
  • Versioned. Multiple historical points retained.

The 3-2-1 rule

The classic backup guidance:

  • 3 copies of data. The live original plus two more.
  • 2 different media types or storage systems. Local NAS and cloud, for example.
  • 1 off-site copy. Geographically separate from the primary.

Snapshots don't count as one of the three because they share storage with the original. The three copies are: live data, local backup, off-site backup. See 3-2-1 backup strategy.

Snapshot schedules

Because snapshots are cheap, you can keep many:

  • Every 15 minutes for the last 4 hours.
  • Hourly for the last 24 hours.
  • Daily for the last 30 days.
  • Monthly for the last 12 months.

This Time-Machine-style retention costs essentially nothing in storage on copy-on-write filesystems with low change rates, and lets you recover from "I made a mistake N minutes ago" at fine granularity.

Backup schedules

Backups are expensive (bandwidth, storage cost, time). Typical retention:

  • Daily backup of changed files (incremental).
  • Weekly full or synthetic-full backup.
  • Monthly long-term retained backup.
  • Annual archival copies for compliance.

Cloud backup services typically charge per GB stored plus per GB transferred. Costs add up; design retention with this in mind.

The ZFS send / Btrfs send pattern

Modern copy-on-write filesystems can stream incremental snapshots to another system:

  • Take a snapshot on the source.
  • Send the difference between this snapshot and the previously-sent snapshot.
  • Receiver applies the diff to its own copy.

The receiving side ends up with a replica that includes all the snapshots from the source. The two ZFS pools (or Btrfs filesystems) hold the same data; deleting one snapshot on the source doesn't affect the receiver.

This is the bridge between snapshots and proper backups: the snapshots are replicated to a different system, becoming actual backups.

Immutability

Modern storage systems can mark snapshots and backups as immutable for a retention period — the storage system itself refuses deletion or modification until the period expires. Examples: AWS S3 Object Lock, ZFS's "received properties" with policy, Synology's Hyper Backup vault.

This is the defense against ransomware that deletes backups before encrypting. Even if attackers gain admin credentials, immutable backups can't be erased within the retention window.

Backup testing

An untested backup is a wish. Discipline:

  • Quarterly: restore at least one full backup to verify the restore process works.
  • Monthly: spot-restore individual files to confirm the catalog is correct.
  • Annually: a complete disaster-recovery drill — assume primary storage is gone, restore from scratch.

Discovering that backups are corrupt, missing files, or take 40 hours to restore is much better in a drill than in a real incident.

The combined strategy

A proper data-protection design uses both:

  1. Frequent snapshots on primary storage for fast recovery from logical errors.
  2. Replicated snapshots to a separate system for protection from primary storage failure.
  3. Off-site backups for protection from geographic disasters.
  4. Immutable retention for protection from ransomware.
  5. Tested restores for confidence that any of the above actually works.

Skipping any layer leaves a specific failure mode unprotected. The cost ranges from "free" (snapshots) to "ongoing operational cost" (off-site backup). Match the layers to the consequences of losing the data they protect.

Frequently Asked Questions

Are snapshots backups?

No. A snapshot is a point-in-time view of the same storage that holds the live data. If the storage dies — drives fail catastrophically, the array is destroyed, ransomware encrypts everything — the snapshots die with it. A backup is a copy on different storage, ideally in a different location. Snapshots protect against logical errors (accidental delete, bad config change); backups protect against everything else.

What is a snapshot?

A point-in-time reference to the state of a filesystem or volume. Copy-on-write filesystems make this efficient by just preserving the old block references when data changes. The snapshot can be browsed, mounted, or restored from. Storage cost is proportional to the changes made since the snapshot — not the total data size.

What does the 3-2-1 rule mean?

Three copies of data, on two different media types, with one off-site. The classic backup guidance. A snapshot doesn't count as one of the three copies because it shares the same storage. The three copies typically are: the live data, a local backup (different disk or NAS), and an off-site backup (cloud or remote location).

How often should I snapshot vs back up?

Snapshots can be frequent — hourly or every few minutes — because they're cheap. Backups are typically daily for working data, with longer-retention copies weekly or monthly. The schedule should match the recovery point objective (RPO): how much data are you willing to lose? Frequent snapshots support short RPOs for logical errors; backups support recovery from catastrophic loss.

Can ransomware destroy snapshots?

Often yes. Modern ransomware deliberately targets snapshots — finding them on the same storage and deleting them before encrypting. Immutable snapshots (the storage system prevents deletion before a retention window expires) and snapshots replicated off-system (e.g., ZFS send to a different server) are the defense. The same logic applies to backups: any backup on accessible storage can be erased.

Related Guides

More From This Section