A backup you have never restored is a hypothesis
Backups fail silently and get discovered during the disaster. The only meaningful test is a restore you have actually performed.
Every site I am called to after a disaster had backups. What it did not have was a restore anybody had ever performed.
The ways they fail quietly
- Files backed up, database not — or the reverse. Either half alone is useless.
- A live database directory copied while the database was running, which produces a file that looks right and cannot be restored.
- The backup written to the same disk as the thing it is backing up.
- A retention policy that keeps seven days, when the corruption started three weeks ago.
- A job that has been failing for months, because nobody is alerted when it does not run.
What good looks like
- Dump the database properly, as part of the same run that captures the files, so the two are consistent with each other.
- Use a tool with history and deduplication rather than a mirroring copy. A file corrupted today must not silently overwrite last week’s good version.
- Keep one copy on separate local storage and one somewhere else entirely. Local gets you a fast restore; offsite is what survives fire, theft and ransomware.
- Restore it. On a schedule. Into a scratch environment, and confirm the site actually loads.
A mirror is not a backup
RAID protects against one drive dying. It does nothing against deletion, corruption or an encrypted filesystem, because every one of those writes to both members at once. Mirroring buys uptime, not safety, and confusing the two is how people end up with neither.