Cloud Server Snapshot and Backup Strategy: The Last Line of Data Defense

Cloud Server Snapshot and Backup Strategy: The Last Line of Data Defense

Here's a real incident: a cross-border e-commerce team ran a database migration the day before a sales season. A DELETE statement missing its WHERE clause wiped out the entire orders table in one pass. They had no automated snapshots enabled, so recovery relied on a manual backup from two weeks earlier — losing 13 days of order data and all of that day's transactions. The sale went ahead, but support spent a week on "where is my order" complaints.

In that scenario, the cloud server itself was not at fault — no disk failure, no datacenter outage — yet the data was still gone. Without backups, there is no last line of defense. This guide walks through the difference between snapshots and backups, solution selection, policy design, and recovery drills that you can actually put into practice.

Know the difference between snapshots and backups

People often treat snapshots and backups as the same thing, but their roles are quite different:

Snapshots answer "can I quickly undo a bad change"; backups answer "can I survive losing the whole datacenter". A common mistake is doing snapshots only: if an account is compromised or a region-level failure occurs, snapshots stored in the same vendor may disappear together with the source. That's why the advice below pairs "snapshot + off-site backup".

Major cloud provider snapshot comparison

All three major providers support incremental snapshot storage — only the blocks changed since the last snapshot are saved, so costs stay manageable after the initial full snapshot:

Reference: AWS EBS snapshots docs https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html · Alibaba Cloud snapshot docs https://help.aliyun.com/zh/ecs/snapshot-overview

Take a 100GB data disk: the first full snapshot costs about $5 on AWS, and if only 2GB changes daily, monthly incremental cost lands around $3 — far cheaper than charging the whole disk as full. This is exactly why snapshot policy must be "scheduled + incremental" rather than "take one whenever you remember".

Third-party tools and database backups

Snapshots handle whole machines, but databases need application-level consistent backups so you never restore data in a half-committed transaction state:

# MySQL logical backup
mysqldump --single-transaction -u backup -p dbname > db_$(date +%F).sql

# PostgreSQL
pg_dump -Fc -U backup dbname > db_$(date +%F).dump

# MongoDB
mongodump --db dbname --gzip --archive=db_$(date +%F).archive

Among open-source tools, Restic and BorgBackup both support incremental, encrypted, deduplicated backups — ideal for automated push-to-object-storage / off-site jobs; Veeam suits enterprises managing many VMs through a GUI.

Policy design: frequency, retention, and the 3-2-1 rule

The 3-2-1 rule remains the gold standard: 3 copies of data, on 2 different media, with 1 copy off-site.

With AWS Backup you can create a daily plan with a single command that snapshots automatically and cleans up on schedule:

aws backup create-backup-plan --backup-plan '{
  "BackupPlanName": "daily-backup",
  "Rules": [{
    "RuleName": "daily-rule",
    "TargetBackupVaultName": "default",
    "ScheduleExpression": "cron(0 2 * * ? *)",
    "StartWindowMinutes": 60,
    "Lifecycle": { "DeleteAfterDays": 30 }
  }]
}'

Off-site backup: the final safety net

Snapshots are useless in a region-level failure. Pushing key data to off-site object storage with cron + rclone is the most cost-effective approach:

# Every day at 3am, sync the backup directory to off-site S3-compatible storage
30 3 * * * rclone sync /var/backup s3:my-bucket/backup --transfers 4 --fast-list

Recovery drills: an untested backup is no backup at all

RPO and RTO must not live only in a document. Run a real drill every quarter:

A drill should cover at least three actions: launch a new instance from a snapshot and verify boot, restore the database to the latest point in time, and pull off-site data back via rclone and verify integrity. You'll discover in one run whether recovery scripts have wrong paths, expired keys, or broken cross-account permissions.

Cost control

Frequently asked questions

Are snapshots enough? No. If an account is compromised or a region fails, snapshots may disappear with the source — always add off-site backups.

Do snapshots help against ransomware? They reduce the damage: as long as the retention window still holds an older version that the malware didn't delete, you can roll back. That's why you keep several days of snapshot versions.

Do databases need separate backups? Yes. Whole-machine snapshots can be transactionally inconsistent; application-level backups (mysqldump/pg_dump) guarantee logical consistency.

Combine snapshots, application backups, and an off-site copy, then back them with quarterly drills — only then is your "last line of defense" actually standing.