SnapRAID is only one of the available not standard RAID solutions for disk arrays.
The best known others are:
- unRAID - Commercial and OpenSource GPL2 solution. A modified version of the Linux Reiserfs filesystem with real-time redundancy. No integrity checksum is supported.
- FlexRAID - Commercial and proprietary C++/Java application for Windows, with some limited support for Linux. It supports both snapshot redundancy and real-time redundancy, with integrity checksum.
- ZFS - OpenSource filesystem (but GPL incompatible) with real-time redundancy and integrity checksum.
- Btrfs - OpenSource filesystem GPL2 with real-time redundancy. From Linux 3.9 it supports RAID5/6 redundancy and integrity checksums. Recently various issues were found and the official wiki now states: The parity RAID code has multiple serious data-loss bugs in it. It should not be used for anything other than testing purposes.
- Storage Spaces - The last contender from Microsoft, and integrated into Windows 8. Proprietary with real-time redundancy. Checksumming is not supported. It also has some other limitations.
The main factor to categorize them is when the redundancy information is updated. In real-time solutions the parity data is updated in real-time, without an explicit action from the user. Like in standard RAID. In snapshot solutions the parity data is updated only upon an explicit request from the user. Like in backups.
Other important factors are the support of an integrity checksum to identify silent data corruption and the possibility to fix it, if you can use already filled disk, if you can recover your data from not broken disks when you get too many failures to have a full recover, and if all your disks are spinning when reading one file.
Real-time computes parity at real-time like RAID, snapshot at request time, like Backup.
If data is validated with some kind of checksum, and which one is the default.
|Fix silent errors
If silent errors are detected and fixed before they can propagate into the parity.
|Yes||No ||No ||Yes ||Yes ||No|
|Number of failures
How many disk failures are supported? 1 is for RAID5, 2 for RAID6.
|1 2 3 4 5 6||1 2||1 2 3 4 5 6+||1 2 3||1 2||1 2|
If more disks fail than the supported redundancy model, is it possible to recover the data in the not failed disks?
How many disks are spinning when reading a single file?
Can you start with already filled disks?
Can you add disks at later time?
Which OS is supported?
Mac OS X
Mac OS X
The year of the first official release supporting at least RAID5 redundancy.
|2011||2005||2008||2005||not yet stable ||2012|
Software license and price.
|Open Source GPL3|
|Open Source GPL2|
|Open Source CDDL|
|Open Source GPL2|
Which interface is provided? GUI or command line?
or Elucidate GUI, or plugin for for OpenMediaVault
 - unRAID doesn't have any kind of checksum, and it just ignores silent errors. Even worse, if a parity error is detected as result of a silent error in the data, the parity is automatically recomputed, making impossible to recover the silent error, even manually.
 - Flexraid uses checksums to validate files, but such checksums
are not verified when data is read to update the parity.
This means that any silent error present will propagate into the parity,
making impossible to fix it later, even if it can be still detected comparing the file checksum.
You can get in a state where the "Validate" operation reports errors, but the "Verify" one reports no problem in the parity, making impossible to fix the errors.
 - ZFS and Btrfs provide a bit-rot protection at the same level of SnapRAID,
always checking data before using it.
In this regards all the three solutions represent the state-of-the-art.
A cons of ZFS is that the default Fletcher checksum is a choice that favorites speed over quality. The same for the default CRC32C used by Btrfs. The 128 bits SpookyHash used by SnapRAID is instead the state-of-the-art in checksumming quality, without compromising in speed.
Another cons of ZFS is that it lacks a fast RAID implementation in assembler. It only has a C implementation, that is from two to four times slower than SnapRAID/Btrfs.
ZFS also uses a sub-optimal RAID-Z3 algorithm, that requires double computations than the equivalent SnapRAID's z-parity.
Instead, both SnapRAID and Btrfs use top-notch assembler implementations to compute the RAID parity, always using the best known RAID algorithm and implementation.
 - unRAID allows to use filled disks but only if they are already formatted with the ReiserFS, XFS or Btrfs filesystems. But not ext4 or NTFS, the two most common filesystems used in Linux and Windows.
 - unRAID can have integrity checksum using a plugin like Dynamix File Integrity, Checksum Suite or bunker but they are all independent at the parity processing and not used to help the recovering process. For example, when recovering a single failed disk with double parity, the checksum can be used to identify additional silent errors, and still be able to recover.
 - Storage Spaces can be used with ReFS that support integrity checksum, but not in the Parity mode: "Although, you may be able to select Simple (no resiliency) or Parity, both of these options will fail the process".
 - Btrfs supports RAID5 from 2013, but recently some serious issues in the RAID5/6 support were found. At present they aren't fixed yet. The official wiki says: "The parity RAID code has multiple serious data-loss bugs in it. It should not be used for anything other than testing purposes".
If you think that some information reported is incorrect or simply unfair, please report it in the Forum.