Backups that actually restore

The failure modes nobody tests

Backup failures are rarely dramatic. The cron job ran, the file landed, the dashboard stayed green — and the dump is silently corrupt, or the WAL segments and binlogs needed for point-in-time recovery were never shipped. Nothing complains until you try to load it.

The human failures are just as common: the credentials for the backup bucket expired months ago, or the restore technically works but takes a full day because nobody ever measured it against a production-sized dataset. Every one of these passes a 'do we have backups?' checklist. None of them passes a restore.

What we back up, and how often

Every managed database on Anested Cloud — PostgreSQL, MongoDB and MySQL — gets a daily snapshot, automatically, with no configuration required. Retention windows scale with your plan, so you can reach further back into history as your needs grow, and the schedule never depends on someone remembering a cron job.

Just as important is where those backups live: in a separate failure domain from the database itself, on independent storage infrastructure. An incident that takes out your database host cannot take out its backups at the same time — that separation is the whole point.

Restore is a product feature, not a runbook

In too many stacks, 'restore' means a wiki page written two years ago, three ssh sessions and a prayer. We treat restore as a first-class product feature instead: from the dashboard, pick a snapshot and restore it to a new database with one click, while the original keeps running untouched.

That design removes the scariest part of a bad day — the fear of making things worse. You inspect the restored copy, verify it against the report we generate, and switch your connection string over only when you're satisfied.

• Restore to a fresh instance — never overwrite in place
• Verify with a checksum and row-count report
• Keep the original for 7 days

Do your part: test one restore

We handle the machinery, but only you know what 'correct' looks like for your data. The single best habit is a quarterly restore drill: pull a fresh backup into a staging database and check that the numbers make sense. It takes about 10 minutes, and it turns your backups from a hope into evidence.

For a PostgreSQL database the whole drill fits in three lines. Put it in a script, put a reminder in your calendar, and run it once a quarter:

# restore drill
pg_dump "$PROD_URL" | psql "$STAGING_URL"
psql "$STAGING_URL" -c "select count(*) from users;"

Backups for files too

Databases aren't the only thing worth protecting. User uploads and static assets on Nest Storage can be protected with object versioning, so an accidental overwrite or delete keeps the previous version recoverable instead of gone.

And for everything living on a VPS — configs, application code, that one directory nobody remembers creating — snapshot options let you capture the whole machine state and roll back to it. The principle is the same everywhere: a copy you can actually restore, kept apart from the thing it protects.