RAID has exactly one job: keep the server running when a drive fails. The three disasters that actually destroy office data walk straight past it. Here they are, and the backup shape that stops them.
Ask a room of office admins what protects their server and someone will say "we have RAID" as if the conversation were over. RAID is genuinely good at its one job - when a drive dies, work continues. But drive failure is only one way data dies, and honestly not the most common one in a small office. This page covers the three disasters RAID does not even slow down, why each one defeats an array completely, and what a real backup plan looks like when it is built with the same care as the hardware. If you take one page from this whole set to a budget meeting, take this one.
RAID's strength is that every drive always agrees. That is also its weakness. When someone deletes the wrong folder - or a faulty application overwrites a database file, or a user saves a broken spreadsheet over the good one - the array does its duty flawlessly: the mistake is written to every drive at once, with the same reliability as real data. There is no "other copy" inside the array to go back to, because an array is one logical drive wearing several bodies. A backup is the opposite design: copies taken at points in time, kept apart, so yesterday's version still exists after today's mistake. Versioning is the whole point - a backup that only ever holds the latest copy is just a slower way to replicate the deletion.
Modern ransomware does not care how many drives you have. It runs with a user's or admin's permissions, walks the shares, and encrypts everything it can reach - and an array is simply everything, reachable, in one place. Your RAID will faithfully store the encrypted files across all its drives, with parity. The offices that recover from ransomware are the ones whose backup the malware could not reach: a copy that is offline (a rotated USB drive that spends most of its life unplugged), offsite (a NAS at another location, or cloud storage), or immutable (backup storage the backup account itself cannot delete or overwrite). Any backup the server can write to at any moment, the ransomware can usually write to as well - which is why "the backup is on the same server, in a second folder" is not a backup at all.
Fire, theft, a burst pipe over the server, a power event that fries the board - when the box itself is lost, every drive in it is lost together, and all that careful redundancy was redundancy against the wrong thing. There is a smaller cousin of this disaster worth knowing: the RAID controller dies while the drives are perfectly healthy. A hardware array's layout lives in the controller's metadata, so the replacement needs to be the same family, sometimes the same firmware line, before those healthy drives become readable again. Software RAID like Windows Storage Spaces is kinder here - its drives can be read by another Windows machine - but kinder is not safe. Geographic separation is the only answer to a lost room: at least one copy of the data must live somewhere the disaster is not.
The classic shape is called 3-2-1, and it survives because it is simple enough to actually follow:
Around that shape, three working rules. Versions: keep several points in time - a week of dailies and a month of weeklies is a sane office pattern - so a slow corruption discovered late can still be rolled back. Separation of accounts: the backup should be written with credentials the daily admin accounts do not hold, so a compromised login cannot delete it. Tests: a backup is a rumour until you have restored from it - restore a folder, then a whole server image, on a schedule, and write down how long it took. The restore test is also your honest answer to "how long would we be down?"
The uncomfortable arithmetic: a modest NAS and a rotated pair of USB drives, or a cloud backup subscription for the critical data, costs a small fraction of one server - and a fraction of a fraction of one day of a whole office unable to work, or of paying for professional data recovery with no guarantee at the end. Price the backup against the question "what does it cost us if every file on this server is simply gone on Monday morning?" For most offices that answer buys the backup several times over. Plan it alongside the hardware - the array layout, the spare drive and the backup target are one purchase, not three.
The hardware half of this story - servers and RAID explained before the install - is in the full video guide.
Watch Full VideoBecause RAID 10 only survives drive failures. A deleted folder is mirrored instantly to both copies, ransomware encrypts the whole array through the shares, and fire or theft takes all four drives together. A backup is a separate copy, with older versions, kept somewhere else - it covers the disasters RAID was never designed for.
No. It shares the same array, the same machine and usually the same permissions - so deletion, ransomware and hardware loss all take it along with the original. A backup must be separated: a different device, different credentials, and at least one copy offsite or offline.
Daily is the sane floor for shared office data, with versions kept for several weeks so a problem discovered late can still be rolled back. Whatever the schedule, restore from the backup on a test basis regularly - an untested backup is a hope, not a plan.