Why databases need their own backup design
Servers can be rebuilt from code. Databases cannot, because they hold the one thing code does not: your customers’ data. That makes database backups the most important copies in the whole estate, and also the easiest to get subtly wrong. A job runs every night and succeeds, yet the dump is truncated. Retention is seven days, and the corruption was introduced ten days ago. The dump is on the same disk as the database.
This page covers the practical mechanics for three common engines. It builds on the backup strategy and sits inside our wider backup and disaster recovery service.
What good looks like
- Every database has an RPO and a mechanism that meets it.
- Point-in-time recovery is enabled where the RPO is shorter than a day.
- Copies exist outside the primary account and region.
- Backup success, age and size are monitored.
- Restores are tested on a schedule into an isolated environment.
Amazon RDS and Aurora
RDS automated backups take a daily snapshot and store transaction logs, which allows restoring to any second within the retention period. The retention window is configurable, and you should set it deliberately rather than leaving a default. Manual snapshots are kept until deleted, so they suit long-term copies and pre-change checkpoints.
Key practices:
- Enable deletion protection and require a final snapshot on delete.
- Copy snapshots to another region and share or copy them into a separate account. Encrypted snapshots encrypted with the default AWS managed key cannot be shared across accounts, so use a customer-managed KMS key from the start.
- Take a manual snapshot before risky migrations.
- Alert on snapshot age, not only on job failure.
Restoring from a snapshot creates a new instance, with a new endpoint. Your runbook must account for repointing the application or DNS, which we cover in disaster recovery runbooks.
PostgreSQL
For self-managed PostgreSQL, there are two layers.
Physical backups with WAL archiving give point-in-time recovery. Tools such as pgBackRest or WAL-G take base backups and archive write-ahead log segments to object storage, compress and encrypt them, and manage retention. This is the approach for busy production systems.
Logical backups with pg_dump export schema and data in a portable form. They are slower to restore on large databases but are valuable for upgrades, partial restores and moving between environments:
# Custom-format dump: compressed, supports selective and parallel restore
pg_dump --format=custom --no-owner --dbname="$DATABASE_URL" \
--file="/backups/app-$(date +%F).dump"
# Restore into a clean database with four parallel jobs
createdb app_restore
pg_restore --no-owner --jobs=4 --dbname=app_restore /backups/app-2026-10-08.dump
Two cautions. A single pg_dump is consistent at the moment it starts but does not give point-in-time recovery. And the connection string should come from a secret store, never be typed into a crontab. On Kubernetes, a CronJob can run the dump and upload it, but a database running as a StatefulSet still needs a proper physical backup strategy, as covered in our Kubernetes consulting.
MongoDB
On MongoDB Atlas, use the managed continuous backup and tune retention. For self-managed replica sets, mongodump with --oplog produces a point-in-time consistent dump of a replica set, and mongorestore --oplogReplay applies it. Run it against a secondary to keep load off the primary. Sharded clusters need coordinated backups, which are considerably more delicate, and in that case we lean toward the vendor’s tooling or snapshots taken with the balancer stopped, following current MongoDB documentation. Always test restoring into a clean instance, including indexes and users.
Decisions and trade-offs
Managed or self-managed databases. Managed services remove much of the backup mechanics but not the need for off-site copies and tests. Moving to managed is often the cheapest reliability improvement, though migration has its own risk. See cloud migration.
Dump or snapshot. Snapshots restore faster for large data; dumps are portable and allow partial restore. Use the one that fits the recovery scenario, or both.
Backing up from replicas. Reduces load on the primary but adds replication lag to your effective RPO. Know the lag.
When automation is not the problem. If the database is tiny and rarely changes, a managed backup and a quarterly restore test are enough. Do not build a pipeline for it.
Common failure modes
- Backups on the database host. Disk loss takes both.
- Truncated or empty dumps that “succeed” because the script ignored an error. We use
set -euo pipefail, check exit codes and verify file size and checksum. - Unreadable backups due to missing encryption keys or version mismatches.
- Restore time never measured. A four hour restore against a one hour RTO is a failed design.
- Secrets in scripts. Credentials end up in logs or version control.
Recovery drills for databases
Database recovery has more moving parts than a volume restore, so we rehearse specific scenarios rather than a generic restore.
- Accidental deletion or bad migration: restore to a point just before the change into a separate instance, extract the affected rows and merge them back, leaving the live database running.
- Corruption or compromise: restore a clean copy, repoint the application, and keep the damaged instance isolated for investigation.
- Region or account loss: restore from the replicated copy in the recovery location and confirm the application connects with the right credentials and network settings.
- Replica promotion: where a read replica exists, promote it and check replication lag and data currency against your RPO.
For each scenario we record who runs it, the exact commands or console path, how long it took, and what data was lost compared with the recovery point. That measured time is the number you compare with your RTO, and it often differs from the vendor’s marketing claims. Where a scenario is slow or fragile, we raise it as a design question, for example whether a larger instance, a different engine feature or a standby would meet the objective more cheaply than faster hardware at restore time. See also RTO and RPO definition.
Delivery and handover
Backup jobs are defined as code in your repositories, scheduled by a managed scheduler or Kubernetes CronJobs, and write to an encrypted bucket with restricted deletion. We add alerts for missing or stale backups and a runbook for each database engine. Verified restores are handled by automated restore testing, and key handling by encryption and access control.
How to tell it is working
The newest backup of every database is younger than its schedule allows, restore tests pass with realistic timings, and you can name the last time you restored a specific table or a specific minute. To review your database protection, get in touch.