Almost everyone who has run a server has heard — or lived — the same story: one mistyped command, one delete in the wrong directory, one migration script pointed at production, and years of data vanish in seconds. What separates "a scare" from "a catastrophe" is never luck. It's whether a usable backup exists.

Snapshots and Backups Are Not the Same Thing

Many people assume enabling snapshots covers them. The two serve different jobs:

  • Snapshots: a whole-machine image at a point in time. Fast to restore and ideal as an undo button before an OS upgrade or major change. But they usually live on the same infrastructure as the instance and are too coarse for recovering a single file.
  • Backups: file-level copies you can store elsewhere and keep in multiple historical versions — the right tool against accidental deletion, corruption and ransomware.

The conclusion: you need both, and neither substitutes for the other.

3-2-1 Is Still the Most Useful Framework

  • 3 copies of the data: production plus two backups.
  • 2 different media or locations: never keep the backup on the same machine or disk as the source.
  • 1 copy off-site: at least one with a different provider or in a different region, so a single failure or account problem can't wipe out everything.

Making It Real

  • Back databases up logically: copying the data directory often captures an inconsistent state. Use mysqldump, pg_dump or equivalents and compress the output.
  • Use incremental backup tools: restic and borg support deduplication, increments and encryption, so keeping many versions long-term costs far less space than a daily full copy.
  • Automate on a schedule: cron or a systemd timer, running daily. Manual backups get forgotten — reliably.
  • Encrypt before shipping off-site: backups usually contain user data and credentials, so encrypt before uploading to object storage.
  • Set a retention policy: for example seven daily, four weekly, six monthly — so storage doesn't grow without bound.
  • Monitor that backups actually succeed: a silently failing cron job is more dangerous than no backup at all, because you believe you're covered. Alert on failure.

The Step That Matters Most: Rehearse the Restore

This is the part almost everyone skips and nobody should. A backup whose restore path has never been tested is not a backup. Once a quarter, spend thirty minutes restoring your latest backup onto a throwaway instance: confirm the data is complete, the service comes up, and you still remember the steps. On the day it really matters, you want a rehearsed procedure — not a pile of archives nobody has ever opened.

SharkCloud supports instance snapshots and flexible sizing, so you can spin up a temporary instance for restore drills whenever you like — a small price for the certainty that you can actually recover.