In short
A backup strategy is defined by two numbers: how much data you can afford to lose, and how long you can afford to be down. Those determine frequency and method. The critical practice is restoring regularly to a separate environment and verifying the data, because a backup that has never been restored is an assumption rather than a safeguard.
Start with two numbers
Everything else follows from these, and most teams have never stated them.
How much data can you afford to lose? If backups run nightly, a failure at 5pm loses a day. Is that acceptable? For a blog, probably. For a system taking payments, certainly not.
How long can you afford to be down? Restoring a large database takes real time, and if you have never measured it, you do not know how long.
Answer these and the strategy becomes obvious. Avoid them and you end up with whatever the hosting default provides, discovering its limits during an incident.
Types of backup
Full backups copy everything. Simple to restore, slow and large to produce.
Incremental backups capture what changed since the last one. Faster and smaller, but restoring means replaying a chain, and a break in that chain is a problem.
Continuous archiving with point-in-time recovery streams the write-ahead log, letting you restore to a specific moment. This is what closes the gap between nightly snapshots — the difference between losing a day and losing a minute, and it is available on most managed services.
Logical dumps export data in a portable form. Useful for moving between environments and for long-term archives, slower to restore at size.
A common combination: managed automated backups with point-in-time recovery for operational restores, plus periodic logical dumps stored separately for the case where the managed service itself is the problem.
The rule that matters
A backup you have never restored is not a backup.
Backups fail silently in ways nobody notices until they are needed: the job stopped weeks ago, the file is truncated, the credentials rotated, the schema changed, the encryption key is gone, the storage bucket filled.
So restore regularly — monthly is a reasonable minimum — into a separate environment, and verify the data rather than only the process completing. Check row counts against production, spot-check recent records, and confirm the application actually runs against the restored copy.
Time it while you do. That measurement is the only honest answer to how long recovery takes, and it is usually longer than people assume.
Where backups are stored
Not on the same server. A failure taking out the machine takes out the backups with it.
Not in the same account, ideally. If someone compromises your cloud account, backups in that account are reachable. A separate account or provider for at least one copy protects against this.
Encrypted at rest, with the key managed somewhere you can actually reach in an incident. A key stored only in the system that is down is a well-known trap.
With versioning and deletion protection, so an accidental or malicious deletion does not remove the backups too. Ransomware specifically targets backups.
The conventional shape — several copies, more than one medium or location, at least one off-site and offline or immutable — is conventional because it survives the failure modes that catch people.
What else belongs in a restore
A database alone is often not enough to bring a service back.
Uploaded files. If user content lives in object storage, it needs its own backup and its own restore test.
Configuration and secrets. A restored database with no application configuration is not a running system.
Schema and migration state, so the application matches the data.
The runbook. Written down, findable when the primary system is unavailable, and specific enough that someone who did not build it can follow it.
That last one is repeatedly missing. The person who knows how to restore is on a plane, and the instructions are in a wiki hosted on the system that is down.
The failures that leave teams with nothing
Backups silently stopped. Nobody monitors the job, so nobody notices for months. Alert on backup failure and on backup age — the second catches the case where the job stopped without erroring.
Restore never tested, so it fails when first attempted.
Backups on the same infrastructure, lost with the primary.
Encryption key lost, making backups unreadable.
Retention too short, so a corruption discovered after three weeks predates every copy. Silent data corruption is the argument for keeping some backups longer than feels necessary.
Nobody knows the procedure except one person.
Backups are not the only protection
Most data loss is not infrastructure failure. It is someone running the wrong statement, or a bug deleting records.
So pair backups with defences against those: soft deletes so removal is reversible, restricted production access, mandatory transactions for destructive operations, and an audit log recording what happened.
Those prevent the incident. Backups are what you use when prevention failed.
A reasonable setup
Managed automated backups with point-in-time recovery. A weekly logical dump to separate storage in a different account, encrypted, with versioning and deletion protection. Alerting on failure and on age. A monthly restore test into a scratch environment, timed and verified. A written runbook someone else has followed at least once.
That is achievable for a small team and covers the realistic failures.
If you have backups but have never restored one, that test is the single highest-value hour available to you — book a call if you want it run properly.
Common questions
How often should a database be backed up?
It depends on how much data you can afford to lose. Nightly backups mean a failure at 5pm loses a day, which is fine for some systems and unacceptable for anything taking payments. Point-in-time recovery through continuous archiving closes that gap to minutes and is available on most managed services.
Why isn't having backups enough?
Because backups fail silently — the job stopped weeks ago, the file is truncated, credentials rotated, the encryption key is missing. A backup that has never been restored is an assumption. Restore monthly into a separate environment, verify the data rather than just the process, and time it.
Where should backups be stored?
Not on the same server, and ideally not in the same cloud account, since a compromised account reaches backups stored in it. Encrypt at rest with the key held somewhere reachable during an incident, and enable versioning and deletion protection, because ransomware specifically targets backups.
What besides the database needs backing up?
Uploaded files in object storage, which need their own restore test; configuration and secrets, without which a restored database is not a running system; schema and migration state so the application matches the data; and a written runbook findable when the primary system is down.
What causes teams to lose data despite having backups?
Backup jobs that silently stopped with nobody monitoring, restores never tested until needed, backups stored on the same infrastructure as the primary, lost encryption keys, retention too short to predate a corruption discovered weeks later, and only one person knowing the procedure.
