Backing Up and Restoring a Managed Database Without Losing Data

The worst time to learn how your backups work is the moment you need them. A dropped table, a bad migration, or a buggy DELETE without a WHERE clause can wipe out data in seconds — and a backup you’ve never tested is just a hopeful guess. This guide covers a backup routine you can trust, and how to restore calmly when something goes wrong.

The one rule: a restore should never make things worse

The most dangerous restore is one that overwrites your live data with an older copy before you’ve confirmed the copy is good. On Kerit Cloud, managed database restores are non-destructive — a restore brings your data back without clobbering the current state, so recovery can’t turn a small problem into a catastrophe. Combined with daily automated backups, that means the safety net is already there before you do anything.

But you should still understand manual backups, because they’re your portable, off-platform copy.

Manual backups

MySQL

# Full logical backup (safe on a live DB thanks to a consistent snapshot)
mysqldump --single-transaction --routines --triggers \
  -h HOST -u USER -p DBNAME > backup.sql

# Restore into a fresh/empty database
mysql -h HOST -u USER -p DBNAME < backup.sql

--single-transaction gives you a consistent snapshot without locking the whole database, so your bot or app keeps running during the dump.

PostgreSQL

# Custom format is compressed and lets you restore selectively
pg_dump -h HOST -U USER -Fc DBNAME -f backup.dump

# Restore
pg_restore --no-owner --no-acl -h HOST -U USER -d DBNAME backup.dump

Tip: Store at least one backup off the server — download it to your machine or push it to object storage. A backup that lives only on the same box disappears with the box.

The step everyone skips: test the restore

A backup you’ve never restored is unverified. Once a month:

1. Restore your latest backup into a throwaway database (never your production one).
2. Run a couple of sanity queries — row counts, your most important table, a recent record.
3. Delete the throwaway database.

Five minutes a month turns “I think we have backups” into “I know we can recover.”

Recovering without panic

When something breaks, slow down — the instinct to fix fast is how one problem becomes three.

1. Stop writes if you can. Take the bot or app offline for a minute so nothing new lands on top of the damage.
2. Restore to a separate database first, not over production. Confirm the data is what you expect.
3. Then point your app at the restored copy, or copy the good tables back.

Because Kerit Cloud restores are non-destructive, step 2 is the default rather than a workaround — and if you’d rather not do it alone, open a ticket and the team will walk through the restore with you.

A backup routine that actually holds

That’s it — a few minutes a month buys you the ability to undo almost any mistake.

Want managed backups handled for you? See database plans, or if you’re still deciding on an engine, read MySQL vs PostgreSQL.