Design backups you can restore from
Replicas protect against losing a copy. They do not protect against the copy being wrong: a bad migration, a corrupting deploy, an operator's DROP TABLE, ransomware. Replication copies those within milliseconds. A backup protects by being separated from the system in time and in authority, and an untested backup is a hypothesis, not a backup. How do you build one that will actually restore?
You will end with a backup plan with a stated data-loss window, a restore time you have measured, a backup the damaging path cannot reach, and a restore test on a schedule.
Work through these in order.
Work through it
Name what the backup must survive
Replication and backup defend against disjoint classes of failure, and the number of copies does not change that. A copy-on-write snapshot shares blocks with the live data: it protects against a bad UPDATE or deploy and nothing else, not media failure, not the deletion of the whole pool, not a stolen credential. Only a copy in an independent failure domain is a backup.
Set the data-loss window by log shipping, not backup frequency
A backup is a base image plus the retained log. How often the log is archived sets how much you can lose: archive every 60 seconds and you lose at most a minute, whether the full backup is hourly or weekly. People often tune the wrong one.
Set the restore time by base age and restore bandwidth
Backup frequency sets restore time: with a weekly base, a disaster on day 5.5 means replaying 5.5 days of log; a daily base cuts that to about 12 hours, with the same loss window. Then measure the restore path itself: 10 TB at 500 MB/s is about 5.6 hours before any log replay, index rebuild or cache warming. For incremental backups, restore time grows with the chain, so re-base periodically.
Decouple the backup in time and in authority
The backup must be old enough that the damage has not reached it, and held under credentials the damaging path does not have. A backup in the same account, reachable with the same credentials and deleted by the same automation, is not independent. Immutable retention (storage that refuses deletes until a date) is the escape, and it costs the ability to delete, which collides with erasure obligations.
Test it by restoring
A backup that silently fails to capture data shows the same green dashboard as one that works, for years. Restore periodically into a scratch environment and compare row counts and checksums. Track the time since the last successful restore test, not the backup success rate.