UNDERSTAND. CHOOSE. ENJOY.LESS NOISE. BETTER CHOICES.
Cloud & Infrastructure/Comparison

Snapshot or backup: recovery is what matters

Check what a copy protects, how independent it is and whether you can actually restore the service.

THE USEFUL ANSWER

A snapshot can be part of a backup strategy, but its name does not guarantee an independent copy or successful recovery. Check what is copied, where it is stored and how you would restore it.

  • Read the definition used by the particular provider.
  • Consider failures affecting the original and the copy together.
  • Practise recovery somewhere separate from production.

Different products use different definitions

DigitalOcean describes snapshots as on-demand disk images and backups as an automatic mechanism for Droplets. These are definitions for its products, not definitions to assume across every provider. Read the documentation for the offer you are considering.

The practical question is what you will get after restoration: a disk, an entire machine, a consistent database or selected files. A reassuring backup dashboard cannot answer that question for you.

Start with three incidents

Use these scenarios as preparation, not as a complete security audit.

  • A file was deleted several days ago. Which previous version is still available?
  • The machine no longer starts. Do you have the data and configuration needed to rebuild the service?
  • Your main account becomes inaccessible. Can you reach a copy and any necessary keys another way?

Write down what recovery needs

Keep a short record of scope, frequency, retention, access, location and the restoration procedure. Add the date of the latest exercise and what was actually recovered.

ItemWhat to record
ScopeFiles, databases, configuration and secrets required for recovery
VersionAvailable recovery point and retained history
IndependenceDependencies on the original account, machine or storage
RestorationSteps, permissions, keys and functional checks

Practise without touching production

Restore a copy to an isolated destination. Check the data, then open the application or essential files. Compare known items and document discrepancies. The objective is not a “restore completed” message; it is a usable service.

Do not automatically copy secrets or personal information into a less protected environment. Define access and clean up according to your policy afterwards. For a critical service, have the responsible person approve the exercise.

Four questions that change the discussion

How much work could you afford to lose? How long could you be without the service? Who holds the necessary access? What happens if the same incident affects the primary system and its copy? Answer in ordinary language before browsing supplier options.

These answers set objectives, not achieved results. Having a copy does not prove your application will restart within the desired time. The exercise provides an observation, together with its conditions and limitations.

A recovery record, not a promise

For a small website, list the essentials, copy locations, procedure and final checks. Do not put passwords or keys in a shared worksheet. Record how authorised people access the secrets manager instead.

Use our recovery worksheet to record the copy used and the observed result. A “success” entry needs evidence: files opened, expected recent data present, or the application accessible.

Improve one weakness at a time

Did finding credentials take longer than restoration? Were files missing from the inventory? Did the application rely on a forgotten external service? Capture these discoveries while testing, then address a specific weakness and repeat the relevant check.

A snapshot is not useless because of its name, and a product called “backup” is not sufficient by definition. Judge the incidents covered and your demonstrated ability to recover. Our VPS and managed hosting comparison helps clarify who is responsible for each step.