RAID is not a backup
You will hear the phrase "RAID is not a backup" in almost every storage discussion. Here is exactly why it is true.
RAID protects against one specific problem: a drive failing. It does that by keeping data on more than one drive at the same moment. But that also means every change you make is instantly copied to all the drives. If you accidentally delete a folder, RAID deletes it from every drive. If ransomware encrypts your files, RAID faithfully stores the encrypted versions on every drive. If a software bug corrupts a database, the corruption is mirrored. If the server is stolen, catches fire, or is flooded, all the drives in the array are in the same box and are lost together.
A backup is different because it is separate in time and place. It holds older versions of your data, it lives on different equipment, and ideally at least one copy lives somewhere else entirely. RAID keeps you running through a dead drive without any downtime. Backups get you back after everything else.
A backup you have never restored is a hope, not a plan
Backups fail quietly in many ways. The job may have stopped running months ago. It may be backing up the wrong folder. Files may be excluded by mistake. The encryption password may be lost. Or the restore may work but take far longer than your recovery time objective (RTO) allows.
The only way to know is to practice. First, verify the backup repository itself. Second, regularly restore a sample of files to a separate test folder, never on top of your live data, and compare them with the originals. Third, at least occasionally, do a full restore drill: pretend the server is gone, time the rebuild, and compare it with your RTO. Write down every surprise and fix your documentation.
This is the "0" in 3-2-1-1-0: zero errors when you verify. Record each test with the date, what was restored, how long it took and whether it passed.
