Backup vs filesystem snapshots

Filesystem snapshots and backups are often discussed as if one replaces the other. In practice, they solve different recovery problems. A snapshot is excellent when the source platform is healthy and the team needs a fast rollback point. A backup is needed when the recovery plan must survive a larger failure domain.

The difference matters during real incidents. If a bad patch corrupts an application and the storage platform is healthy, a snapshot may be the quickest path back. If the storage account, administrator boundary, host, region, or security posture is part of the problem, the team needs a backup strategy that is independent enough to keep options open.

The right question is not "Do we have snapshots?" or "Do we have backups?" The right question is which incidents each mechanism is expected to handle, and whether the team has tested that expectation.

Snapshots often live close to the system they protect. That closeness is why they are fast. It is also why they may fail as a disaster recovery strategy. If the same platform, account, credentials, replication policy, or deletion path controls both the production system and its snapshots, the snapshot may not be isolated from the incident.

A backup plan should deliberately widen the failure boundary. The copy may be stored in another account, another storage system, another cloud target, or an object store with stronger retention controls. The exact architecture varies, but the goal is consistent: production failure should not automatically remove the recovery copy.

When reviewing either approach, ask what has to remain healthy for recovery to work. The answer will show whether the copy is a rollback convenience, a recovery asset, or both.

Snapshots are usually strongest over short windows. They are efficient for frequent points, quick operator mistakes, and recent rollbacks. Over longer periods, storage pressure, platform limits, and operational cleanup often reduce how much history is practical.

Backups are usually the better place to express business retention policy. If the organization needs recovery points across days, weeks, months, or audit periods, the backup system should make those windows explicit and reviewable.

Retention should map to incidents, not just policy language. Ransomware, accidental deletion, database corruption, and failed migrations may each require a different point in time. The team should know which mechanism covers each case.

Snapshots can help ransomware recovery when they are clean, protected, and reachable through an uncompromised path. They are weaker when the attacker can delete them, encrypt the same storage boundary, or compromise the account that controls both production and rollback points.

Backups are more useful in ransomware planning when retention, access separation, clean restore selection, and isolated validation are part of the design. The backup is not magic by itself; it becomes valuable when the team can choose a trustworthy restore point and prove it before reconnecting services.

A ransomware review should ask whether the newest copy is safe, whether older copies are protected, and whether restore validation can happen away from compromised systems.

Both snapshots and backups can create false confidence when teams only verify that a recovery point exists. Existence is not usability. A point can exist while the restored workload fails to boot, lacks metadata, misses a dependency, or cannot be trusted after a security event.

Restore proof should include the path back to service: selecting the recovery point, restoring into a target, booting or mounting the workload, validating application health, and recording the result. The amount of testing can vary by workload priority, but the habit should be consistent.

If a snapshot is part of the recovery plan, test snapshot restore. If a backup is part of the recovery plan, test backup restore. Do not let either label stand in for evidence.

A mature recovery strategy usually uses both. Snapshots cover fast local rollback. Backups cover independent retention, wider incident recovery, and recovery evidence. The mistake is pretending one tool covers every failure mode.

Document the decision tree in simple language. For recent operator error on a healthy platform, try snapshot rollback. For suspected compromise, platform loss, account risk, or long recovery windows, move to backup recovery and isolated validation.

Then test the decision tree. A plan that says "use snapshots first" should prove that snapshot recovery is safe. A plan that says "use backups for ransomware" should prove that clean restore selection and validation are possible.