I don't know Unraid, i only know FreeNAS/FreeBSD and in particular its raid5 driver named geom_raid5, by which i was involved in its development in particular testing and benchmarking.
Sorry if this is going to sound technical: RAID5 involving a write-back mechanism, without the use of strong journaling, will always present the risk of filesystem corruption in the case of a crash, power issue, overheating or an unclean shutdown. The data that is written and should be on the physical hard drives is actually still residing in the RAM memory, and will be lost.
The results depend on how good your filesystem is with coping with lost writes. NTFS uses "weak" metadata journaling, which is excellent for the write buffer found in all modern hard drives, which also say data is written while its still in their onboard RAM chip and will get lost if they unexpectedly loose power. NTFS can cope with that, but it cannot cope with large portions of writes missing, and writes being issued in the 'wrong' order.
Hardware controllers with onboard memory often allow you to use a Battery Backup Module (BBU) which will keep supplying power to the onboard memory in the case of an emergency. And due to it being Hardware RAID, it works independently from the Operating System so in the case of a crash, a press on the reset button etc, the RAID engine keeps working and keeps holding the data stored and keeps writing them out of disk, even as your PC is rebooting after the reset.
So, this is the protection Hardware RAID can give you to the problem of filesystem corruption on write-back mechanisms. What? Write-back means you lie when you say data has been written to disk, while in fact you store the data in a buffer (like your RAM or onboard memory chip). The data in this buffer is lost when power is lost. And the contents in the RAM are lost when the system crashes/freezes/hangs/etc. Also, bugs in Windows shutting down too early also caused many problems in the past. Conclusion: RAID5 alone is not enough 'protection' against data loss. As a sidenote, it has caused me to loose data in the past.
If you want to use Software RAID5, you can limit the risk of filesystem corruption in the cases described above by the use of either strong or smart journaling. This lowers the write performance for large files because all data has to be written
twice to the storage device.
ZFS uses the ZIL (ZFS Intent Log) to keep track of what it was doing so after a crash the situation can be recovered without loss of data, only going back in time to a situation like 30 seconds before the crash. This is possible due to the Copy-On-Write model ZFS uses. The only downside is privacy since zero-writing your files no longer removes all traces of the data and could be recovered by manual intervention.
On FreeNAS, you can use geom_raid5 for the RAID5 and put a journal on it called geom_journal. This is strong journaling and should offer a formidable protection against lost buffers. Just make sure to make the journal large enough for the maximum speed (not size) your array can take. 2GB journal size should be adequate for a small array. This space will be unavailable for file storage.
So, with both software RAID5 and hardware RAID5 you can be safe, but not without carefully configuring your systems. And even then there are risks:
- fire melts your disks to a nice glue
- you cause the computer case to drop sideways causing a head crash on multiple hard drives -> byebye parity protection
- a virus destroys your data (*)
- you accidentally delete files (*)
(*) preventable by using snapshots. ZFS is great for this, it can maintain a history of your files allowing you to browse 'back in time' without storing data multiple times. It simply stores the changes since the last snapshot. A snapshot is like a 'photograph' of the current data stored on a volume. It is comparable to the System Restore functionality in Windows.
Good luck
Facebook
Twitter
Instagram