Backup and replication: what really protects you

If your database is replicated, are you protected? Not against everything. Replication protects you from a breakdown. A backup protects you from a mistake. You generally need both, and above all proof that you know how to restore.

Two words, two protections

Replication keeps a copy of your data on another server, updated continuously. If the first one fails, the second can take over.

A backup is a snapshot of your data at a given moment, stored separately. You can go back to yesterday's state, or last week's.

The analogy: a spare key and a photo of the flat

Replication is a spare key at a neighbour's: if you lose yours, you can still get in.

A backup is a photo of the flat before the renovation: if a wall is knocked down by mistake, you know what it looked like.

The spare key does not help you get the missing wall back. The photo does not get you inside tonight. They are not the same problems.

The classic trap

Replication faithfully copies everything, mistakes included. If someone accidentally deletes a table, or a faulty update corrupts rows, or malicious software encrypts the data, the copy receives the same disaster almost immediately. You then have two equally damaged databases.

That is why replication never replaces a backup.

What each one covers

• A server or hosting failure: replication helps, a backup helps too but with a delay to get running again.
• Accidental deletion or modification: only a backup (or a kept history) lets you go back.
• Data corrupted by a bug: the backup, provided it predates the bug.
• An attack that encrypts or wipes the data: a backup that is isolated and kept out of reach of the main system.

What makes a good backup

A few simple questions:

1. How often? If it runs every night, you can lose up to a day of data. Is that acceptable for your business?
2. Where is it stored? A backup in the same place as the data disappears with it. You need at least one copy elsewhere.
3. How long do you keep it? A mistake discovered three weeks later needs older backups.
4. Who can access it? It contains all your data: protect it like the database itself.
5. Have you ever restored? This is the most important question.

The backup you have never restored

A backup that has never been tested is a hypothesis, not a protection. It may be empty, incomplete, unreadable, or take hours you do not have. The only reliable test is to restore for real, in a separate environment, and check that the app works with that data. Note how long it takes: that duration decides how long an outage lasts.

To see why these trials are kept separate, read staging vs production. And for another example of a risky change to a database, see database migrations.

Key takeaway

Replication protects from breakdowns, backups protect from mistakes, and only a successful restore proves you are protected. Ask yourself: when did we last restore?

And for your product?

Where your backups are, how long they last, who can restore them: these are questions an audit of your app can review, along with the rest of how it runs. If you want to know where you stand, we can talk for 30 minutes.