RAID isn’t backup, or even redundancy, it’s for creating large storage pools. It’s at the mercy of the controller and all the hardware. In fact, the more disks you have, the more likely you are to be impacted by a failure.

In a typical RAID 5, if one drive fails, the entire array is at risk until the drive can be replaced, and resilvered. During resilvering (rebuilding the drive with all the data it should have, parity, etc), the entire array is at even more risk because of the load on the other disks.

With dual parity and hot spare (less data storage total), you get a little more security since the parity is doubled and the hot spare will be automatically resilvered if a drive fails, but that’s not without similar risks during that process.

You still need backup.

Here’s a real-world example of RAID risks. I have a 5-drive NAS with 5 1TB drives, which gives me roughly 4TB of usable space (1TB parity). It runs software RAID using ZFS (a highly resilient file system, that can build arrays using varying disk sizes, and has some self-healing capability). I’ve had a drive go bad, replacing took 30 hours to rebuild. During that time, the entire array is “degraded”, meaning no parity protecting the data. If another drive were to have failed during this read/write intensive period, I would have lost ALL the data.

To protect against this, I have 2 other large drives which this data is replicated to. And then I use a cloud storage for backup (storj.io).

This is a modified version of the 3-2-1 method that works for my risk assessment.

Without offsite backup, you’re always at risk of local issues - fire, flood, etc. Or even just a massive power spike (though that’s not much of a risk, especially if you use a UPS).