**Parent Topic**: [[Software/README]] ## Replication Replicates Your Mistakes "The first and most obvious thing is to use the slave itself as a backup. Unfortunately, this isn't a real backup." A replica protects against losing a server, but not against "a malicious attack that corrupts data" or "an accidental DROP TABLE" — because it "will merrily replicate the offending changes and duplicate the corruption or loss on its own copy." See also [[Replication Is Not Recoverability]]. ## Backup Principles Schwartz's lecture: "Stop procrastinating on backups." "Don't build something awesome; just build something recoverable." Document acceptable data loss, acceptable downtime, retention policy, and security requirements. "Practice and document the recovery process. **Recovery is more important than backing up.**" And get **external verification** of a backup's success — "don't rely on the job itself to notify you." ## The Delayed Slave Trick A real backup means stopping a spare slave and copying its data, or using a nonblocking tool like XtraBackup. A complementary technique: run a slave **delayed by an hour** (e.g. `mk-slave-delay`). It keeps fetching the master's updates without applying them, giving a near-current recovery point *and* a grace period — "that accidental DROP TABLE won't get replayed for an hour," so you can skip it and promote the slave. But use a delayed slave "in addition to backups, not instead of them." Test restore time too — [[Test Your Restore Time]]. --- *Source: [[Web Operations]] (Allspaw & Robbins, O'Reilly 2010) — Ch 12 — Relational Database Strategy and Tactics for the Web*