Snapshots, Images and a Rebuild Strategy

Snapshot and image are used interchangeably in conversation and mean different things in practice. The distinction decides how quickly you recover.

Snapshot

A point-in-time copy of a disk, tied to the machine it came from. Its purpose is restoration: put this machine back the way it was. Snapshots are quick to take and are the right thing to create immediately before a risky change.

Image

A template used to create new machines. Its purpose is reproduction: make more machines like this one. Images underpin autoscaling, environment cloning and disaster recovery in another region.

Why neither is a backup

Both usually live in the same account as the thing they protect. If the account becomes inaccessible, so do they. A genuine backup has a copy somewhere the original account cannot reach.

For most small teams the pragmatic arrangement is snapshots for quick rollback, plus a database dump copied out of the account for the data that genuinely matters.

The cost nobody plans for

Snapshots are storage and bill accordingly. An automated nightly policy with no retention limit produces a slowly growing charge that survives the machine it protected. Set retention when you set the schedule, not later. Old snapshots are a standard finding in an account audit.

A rebuild strategy worth having

Ask how you would recreate a server if it vanished. If the answer involves remembering, that is the gap.

1. Keep configuration in a script or a configuration-management tool rather than in the machine’s history.
2. Build an image when the machine reaches a known-good state.
3. Keep data separate from the machine, on an attached volume or in a managed service.
4. Test the rebuild once. An untested rebuild path is a hypothesis.

Before you change an inherited machine

Snapshot first. It costs a little storage and converts an irreversible mistake into a ten-minute recovery, which matters most on machines whose configuration you did not write.