Exercise 3: Why an On-Server-Only Backup Is "Genuinely Close to Useless" — Possible Solution ==================================================================== WHY AN ON-SERVER BACKUP FAILS AT ITS ONE JOB ------------------------------ Per this chapter, "a backup stored only on the same server it's protecting is genuinely close to useless - if that server fails entirely or is compromised, the backup is lost right alongside everything it was meant to protect." A backup's entire purpose is to survive something bad happening to the original data. If the backup copy lives in exactly the same place as the original (the same physical or virtual server), then whatever destroys the original - hardware failure, a successful attack, accidental deletion at the hosting level - destroys the backup at the same time, for the same reason. WHY THIS IS SPECIFICALLY ABOUT THE FAILURE SCENARIOS THAT MATTER MOST ------------------------------ The scenarios a backup exists to protect against are precisely the ones most likely to also take down anything else stored on that same server - a full server crash, a ransomware-style compromise, a catastrophic hosting failure. An on-server backup protects effectively against much smaller-scale problems (like accidentally deleting one specific post and wanting to restore just that), but offers essentially no protection against the larger disasters that are the whole reason a serious backup strategy exists in the first place. WHY "GENUINELY CLOSE TO" RATHER THAN "COMPLETELY" USELESS ------------------------------ An on-server backup does still have some narrow value - it can help recover from a bad update, a mistaken edit, or a plugin conflict that corrupts data without taking the whole server down. The chapter's own careful wording ("close to useless," not simply "useless") reflects that narrower, real but limited value, while still making clear it falls far short of a genuine backup strategy. WHAT A CORRECT BACKUP LOCATION LOOKS LIKE INSTEAD ------------------------------ Per this chapter, "a real backup strategy stores copies off-site: a separate cloud storage location, a dedicated backup plugin... configured to push backups elsewhere automatically, or host-level automatic backups that are themselves stored independently of the live server." The defining requirement is genuine physical/logical separation from the original server - the backup has to live somewhere that a catastrophic failure of the live server wouldn't also destroy. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains the core mechanism (shared failure mode) behind why an on-server backup fails at its purpose, addresses the chapter's own careful "close to" qualifier rather than overstating the claim, and describes what genuine off-site separation actually requires per this chapter's own examples.