DB Replication vs Backups: What Each Protects

Database replication and backups both protect data, but they guard against different failures: replication protects against server and hardware outages by keeping a live copy ready to take over, while backups protect against data loss from corruption, accidental deletion, and ransomware by letting you restore an older state. You need both, because replication alone cannot undo a bad query that deletes rows, and backups alone cannot keep your application online during a hardware failure.

Formula

This calculator compares two numbers that define your recovery point objective (RPO): the replication lag (how stale the replica can be) and your stated data loss tolerance (how much data you are willing to lose). The effective RPO is the larger of the two, because you cannot guarantee recovery to a point better than the worst of both.

Effective RPO = max(replication lag, data loss tolerance)

• Replication lag (seconds): the maximum time a replica can fall behind the primary before it is considered out of sync.
• Data loss tolerance (seconds): the maximum amount of recent data you accept losing in a disaster.

The second output, “Meets RPO?”, is a simple ratio: 1 means your replication is fast enough to meet your tolerance, 0 means it is not. Values between 0 and 1 show partial margin.

Worked Example

Using the default values: replication lag = 5 seconds, data loss tolerance = 60 seconds.

1. Effective RPO = max(5, 60) = 60 seconds.
2. Meets RPO? = 1 – min(1, max(0, 5 / 60)) = 1 – min(1, 0.0833) = 1 – 0.0833 = 0.9167, rounded to 0.92.

The effective RPO is 60 seconds, and the replication lag is well within the tolerance, so the ratio is close to 1. If the lag were 70 seconds, the ratio would be 0, indicating you are losing more data than you planned.

What Replication Actually Protects Against

Replication copies changes from a primary database to one or more secondary databases in near real time. Its purpose is availability and read scaling, not historical recovery. If the primary server crashes, the replica can be promoted to primary with minimal downtime, often seconds. This is what protects you from:

• Hardware failure (disk, memory, power supply) on the primary server.
• Network partition that isolates the primary from its clients.
• Planned maintenance, because you can fail over to a replica while patching the primary.
• Regional outages if replicas are in different availability zones or data centers.

Replication does not protect against logical errors. If a developer runs DELETE FROM users without a WHERE clause, that statement replicates to every replica, deleting the data everywhere. The same applies to a buggy migration that drops a column or a ransomware process that encrypts files on the database server. Replication faithfully copies the bad change.

What Backups Actually Protect Against

Backups are point-in-time snapshots of the database, stored separately from the live system. They exist to restore data after it is lost or corrupted. A proper backup strategy protects against:

• Accidental deletion of rows, tables, or entire databases.
• Application bugs that corrupt data over time.
• Malicious attacks, including ransomware that encrypts both primary and replicas.
• Human errors such as running a script against the wrong environment.
• Disasters that destroy the entire data center, including all replicas.

Backups are not a substitute for replication because restoring from backup takes time. A typical restore involves loading the last full backup plus applying transaction logs up to the desired point, which can take minutes to hours depending on size. During that time, the application is down or serving stale data.

Key Differences at a Glance

Aspect	Replication	Backups
Primary goal	Availability and failover	Recovery after data loss
Data freshness	Seconds behind primary	Hours or days old (snapshot)
Protects against hardware failure	Yes	Partially (if backup is offsite)
Protects against bad queries	No	Yes
Protects against ransomware	No	Yes, if backups are immutable
Recovery time	Seconds to minutes	Minutes to hours
Storage cost	High (full copy of data)	Lower (compressed, deduplicated)

Common Misconception: “Replication Replaces Backups”

A widespread belief is that having a replica means you do not need backups. That is false for two reasons. First, replication does not protect against logical corruption, as noted above. Second, replicas are often in the same cloud account or data center, so a single incident (account compromise, fire, or a misconfigured script) can destroy both. Backups stored in a separate location, ideally with versioning and write-once-read-many (WORM) protection, are the only defense against that scenario.

Another misconception is that backups alone are enough for high availability. If your database is down, restoring from backup takes time, and during that time your users cannot access the service. Replication provides the fast failover that keeps the service online.

How to Choose What You Need

Your choice depends on your recovery objectives and your tolerance for downtime.

• If you need near-zero downtime (a few seconds), you need replication with automatic failover.
• If you need to recover from accidental deletes, you need backups with point-in-time recovery.
• If you are subject to ransomware, you need immutable backups stored offsite, plus replication for availability.
• If you have a small application with low traffic, a daily backup might be enough, but you still need to test restores.

In practice, most production systems use both. The standard pattern is: primary database, one or more replicas for failover and reads, and regular backups (full + transaction logs) stored in a different location. The backups provide the safety net, and the replicas provide the speed.

Practical Considerations and Costs

Replication adds complexity. You must monitor lag, handle schema changes carefully (a bad migration replicates), and ensure the replica has enough resources to keep up. Some databases require special configuration for synchronous replication, which can slow writes.

Backups also have costs: storage space, network transfer for offsite copies, and the time to test restores. A common mistake is never testing backups until a disaster happens, only to discover the backup is corrupted or incomplete. Regular restore drills are essential.

For both, define your RPO (how much data you can lose) and RTO (how long you can be down). These numbers drive everything. If your RPO is 5 minutes, a daily backup is insufficient; you need transaction log shipping or continuous replication. If your RTO is 4 hours, a restore from backup may be acceptable, and replication is a luxury.

Frequently Asked Questions

Can replication be used to recover from a dropped table?

No. If you drop a table on the primary, the drop statement replicates to all replicas, so the table is gone everywhere. You need a backup to restore that table, and ideally a point-in-time recovery to just before the drop.

How often should I take backups if I have replication?

You still need regular backups, but the frequency depends on your RPO. If you can afford to lose 24 hours of data, daily backups are fine. If you need to lose at most 15 minutes, you need transaction log backups every few minutes, or continuous archiving. Replication does not change this requirement.

What is the difference between RPO and RTO?

RPO (recovery point objective) is the maximum amount of data you can afford to lose, measured in time. RTO (recovery time objective) is the maximum time you can afford to be down. Replication improves RTO, backups improve RPO (by giving you an older point to restore to).

Are cloud database managed services automatically backed up?

Most managed database services (like AWS RDS, Azure SQL Database, Google Cloud SQL) enable automated backups by default, but you should verify the retention period and whether point-in-time recovery is enabled. Some services also offer read replicas, but those are for availability, not backups.

Can I use a replica as a backup?

Not as a substitute. A replica is a live copy that can be promoted, but it does not protect against logical corruption or account compromise. Some teams take a replica and pause it to create a “backup” that is slightly stale, but that is still a backup, not replication. The two serve different purposes.

What is a good backup retention policy?

There is no universal answer, but a common practice is to keep daily backups for 30 days, weekly backups for a few months, and monthly backups for a year or more, depending on compliance requirements. Also keep at least one backup offsite and test restores regularly.

Related

• Color-Changing Camouflage: Forest & Desert Use
• Steam DLC Not Downloading? Fixes That Work
• Breville Kitchen Wizz 8 BFP560: Know Before Buying

in t | Replication lag (seconds) | s | 5 | 0 | 3600
in d | Data loss tolerance (seconds) | s | 60 | 0 | 86400
out rpo | Effective RPO | s | max(d, t) | 0
out note | Meets RPO? | - | 1 - min(1, max(0, t / d)) | 2