Backups
RAID is not a backup: what redundancy protects and what it cannot recover
RAID improves availability against certain disk failures by keeping redundant live data, but it immediately mirrors corruption, deletion, ransomware, and application mistakes. Backup keeps historical recovery points and should survive failures outside the live array. They solve different problems.
Know what RAID can keep running through
A mirror or parity array can tolerate a defined number/type of drive failures while the array remains degraded. It can reduce downtime waiting for a disk replacement, but rebuild itself creates stress and does not guarantee protection from multiple failures.
Monitor SMART/array state so degraded operation is not ignored.
Know what RAID cannot undo
Deleting a directory, overwriting a database, encrypting files with ransomware, or an application writing bad data is reflected across redundant members. Controller/filesystem/server/site failures can also exceed the RAID boundary.
Snapshots add history but may still share the same system failure domain.
Design backup independently
Keep versioned copies on separate storage with credentials/retention appropriate to recovery objectives. Include application-consistent databases and the configuration needed to rebuild, not only raw filesystem bytes.
RAID status should not decide whether backup jobs run.
Test both disk and data recovery
Practice replacing/rebuilding a failed member according to the array procedure and separately practice restoring lost data from backup. These are distinct runbooks.
- RAID = live redundancy.
- Backup = historical recovery.
- Keep backup outside array failure domain.
- Test both runbooks separately.