SnapRAID

Frequently Asked Questions for SnapRAID.

General

What's SnapRAID?

SnapRAID is an application able to make a partial backup of your disk array. If some of the disks of your array fail, even if they are completely broken, you will be able to recover their content. It's only a partial backup, because it doesn't allow to recover from a failure of the whole array, but only if the number of failed disks are under a predefined limit.

How is it different than RAID?

RAIDs are mirroring solutions that propagate changes immediately to the parity data. In this sense, RAIDs are not backups, because they don't allow to restore an old state of the array.

SnapRAID is instead more similar at a backup solution, and you can restore the state of the last backup. For example, with SnapRAID, if you delete by accident a file, you can easily restore it.

Others advantages over traditional RAID5/6 solutions are:

All your data is hashed to ensure data integrity and to avoid silent corruption.
If the failed disks are too many to allow a recovery, you lose the data only on the failed disks. All the data in the other disks is safe.
If you accidentally delete some files in a disk, you can recover them.
You can start with already filled disks.
The disks can have different sizes.
You can add disks at any time.
It doesn't lock-in your data. You can stop using SnapRAID at any time without the need to reformat or move data.
To access a file, a single disk needs to spin, saving power and producing less noise.
You can have up to six parity levels compared to the one of RAID5 and the two of RAID6.

Obviously RAID has other advantages, like having a better speed due data striping. What is best for you, depends on your specific use case.

How is it different than ZFS/Btrfs snapshots and NTFS Shadow Copy?

SnapRAID creates a file-system snapshot conceptually similar at other snapshot solutions. The difference is that the purpose of SnapRAID is to be able to recover a disk to the saved state after a complete disk failure.

SnapRAID is more similar at the RAID-Z/RAID functionality of ZFS/Btrfs. Compared to them, SnapRAID has the following advantages:

If the failed disks are too many to allow a recovery, you lose the data only on the failed disks. All the data in the other disks is safe.
You can start with already filled disks.
You can add disks at any time (not possible with ZFS, but possible with Btrfs).
It doesn't lock-in your data. You can stop using SnapRAID at any time without the need to reformat or move data.
To access a file, a single disk needs to spin, saving power and producing less noise.
You can have up to six parity levels compared to the three of ZFS RAID-Z and the two of Btrfs RAID-5/6.

Obviously ZFS/Btrfs have other advantages, like being real-time solutions. What is best for you, depends on your specific use case.

How is it different than other backup solutions?

With a normal backup solution you always need as much space as the full disk array for the backup. With SnapRAID you need only one additional parity disk to be able to recover the most common case of a single disk failure. Adding more parity disks, you can recover from more disk failures.

Note that only a full backup allows to recover from a complete failure of the disk array and it's surely the preferred solution if you can afford it. SnapRAID is a good option if a full backup is not a possible solution.

What are the advantages of SnapRAID compared to similar solutions like unRAID/FlexRAID/Windows Storage Spaces?

You can see the Compare page to see it compared to other similar solutions.

A strong advantage of SnapRAID is the integrity and silent error management that is at the same level (if not better) of the ZFS and Btrfs file-systems. Instead, unRAID and Storage Space have no integrity check at all! FlexRAID is at least able to report silent errors, but not to fix them.

How much does it cost?

Nothing. It's a FreeSoftware application released with the GPLv3 license.

How to get support?

Go to the Forum.

Has SnapRAID a GUI?

No. SnapRAID is a command line application. But there is the Elucidate external GUI, and a plugin for OpenMediaVault.

Does SnapRAID provide encryption, virtual views/storage pooling, SMART monitoring and Power control?

SnapRAID provides a basic virtual views/storage pooling solution, but it's also compatible with any other pooling solutions.

For encryption, SMART monitoring, Power control and Data Recovery you can use other tools. Here some suggestions:

	Linux	Windows	Mac OS X
Encryption	dmcrypt/LUKS (tutorial)	VeraCrypt, FreeOTFE
Virtual views/storage pooling	mergerfs (tutorial), mhddfs (tutorial), aufs, Greyhole	Liquesce (free, BETA), DrivePool ($$), PoolHD ($$), DriveBender ($$)
SMART monitor	smartmontools, GSmartControl	smartmontools, GSmartControl, CrystalDiskInfo	smartmontools, GSmartControl, SMARTReporter
Power Control	hdparm	hdparm
Data recovering	ddrescue, safecopy, dd_rescue

Is SnapRAID suitable to backup the home/My Documents directory?

No. If you have a limited amount of data that can be easily saved in an external USB HD, or in online backup services, it doesn't make sense to use SnapRAID. SnapRAID should be used when you have to backup a very large amount of data, many Tera bytes, and a full backup copy of a such amount of data is not possible in any other way.

Is SnapRAID suitable to backup the boot OS disk?

No. For the disk used for booting your machine and containing the OS files, it's better to use another solution, like RAID1 or a mirror copy. SnapRAID needs an OS to run, and then it cannot recover the OS if the OS is missing.

Can SnapRAID hash files wihout parity computation?

No. It's not possible to use SnapRAID to only hash files. The hashing used by SnapRAID is meant to be used in combination of parity computation, and it's not the best implementation for a hash only solution.

You can find a list of file verification tools at: Wikipedia: Comparison_of_file_verification_software.

Setup

For a setup example in Ubuntu 14.04 you can check the SnapRAID Zack's tutorial.

Do I need one or more parity disks?

As a rule of thumb you can stay with one parity disk (RAID5) with up to four data disks, and then using one parity disk for each group of seven data disks, like in the table:

Parities	Data disks
1/Single Parity/RAID5	2 - 4
2/Double Parity/RAID6	5 - 14
3/Triple Parity	15 - 21
4/Quad Parity	22 - 28
5/Penta Parity	29 - 35
6/Hexa Parity	36 - 42

This table takes into account that more parity levels also help to recover from unsynced array, and that likely you are running all the disks in the same box and environment, meaning that their failures could be correlated.

Take care that multiple failures happen. At now the worst case reported in the SnapRAID history, is a four disks failure, successfully recovered using four parities.

Some interesting articles about number of parity levels and failure rate of disks are: Why RAID 5 stops working in 2009, Why RAID 6 stops working in 2019, Does RAID 6 stop working in 2019?, Triple-Parity RAID and Beyond, How long do disk drives last?.

Which file-system is recommended for SnapRAID ?

For the data disks, follow these suggestions:

Data	Result
Any	OK. In general you can use whatever file-sytem you like. Just see the following notes for some exceptions.
Btrfs	OK. Ensure to build SnapRAID with the libblkid library to get UUID support. You will be warned at every run if this doesn't happen. Note that multiple Btrfs snapshots are not supported.
ZFS	Partial. You won't get UUID support, but this doesn't prevent the use of the core SnapRAID functionalities. Note that multiple ZFS snapshots are not supported.
ReiserFS	Unsure. Where are reports of speed increase when switching from ReiserFS to other file-system. ext4 and XFS are anyway better. Use them instead.
FAT	Unsure. There are reports of duplicate inodes cases. NTFS is anyway a lot faster. Use it instead.
ReFS	No. ReFS uses 128 bit inodes, and SnapRAID doesn't support them yet.

For the parity disks, follow these suggestions:

Parity	Result
ext3	No. It doesn't support the fallocate() command needed to allocated the parity files. You can anyway use it if you limit the use of the parity disk to contain only the parity file.
ext4	OK if the disks are NOT bigger than 16 TB. The parity is stored in a single big file, and ext4 has a upper limit of 16 TB for file size.
XFS	OK
Btrfs	OK. But ensure to build SnapRAID with the libblkid library to get UUID support. You will be warned at every run if this doesn't happen.
JFS	No. It doesn't support the fallocate() command needed to allocated the parity files. It also doesn't seem to implement at the best the posix_fadvise() command.
ReiserFS	Unsure. Where are reports of speed increase when switching from ReiserFS to other file-system. ext4 and XFS are anyway better. Use them instead.
NTFS	OK in Windows. No in Linux, as it doesn't support fallocate() command needed to allocated the parity files. You can anyway use it if you limit the use of the parity disk to contain only the parity file.
FAT	No. You cannot store files bigger than 4 GB. It's also not journaled. Use NTFS instead.
HFS+	OK

In Linux, to get more space for the parity, it's recommended to format the parity file-system with the -m 0 -T largefile4 options. Like:

mkfs.ext4 -m 0 -T largefile4 DEVICE

On a 8 TB disk you can save about 400 GB. This is also expected to be as fast as the default, if not faster.

Which hardware configuration is recommended?

For best performance it's recommended to have all the disks connected with SATA and not with USB.

Check Raj's Prototype Builds for some examples of hardware setups.

For choosing harddisk, you can check Backblaze's What Hard Drive Should I Buy?, and Backblaze's Enterprise Drives: Fact or Fiction?.

Is a multi-core CPU recommended?

No. SnapRAID is usually not CPU bound. The limiting factor is the read performance from disks. So, also a single core CPU should be enough.

For example, in my system I get a combined read speed of 400 MiB/s, but SnapRAID is able to hash at 12000 MiB/s in a single core.

Is a 64 bit operating system recommended?

Yes. SnapRAID works better in a 64 bit operating system. It can access more than 4 GiB of memory, and use faster hashing and parity algorithms. Anyway, if you have less than 30 TB of data, it performs very well also using a 32 bit operating system.

How much memory SnapRAID requires to run?

Approximatively, SnapRAID requires 1 GiB of memory for 16 TB of data.

If you have less memory than required, the recommended option is to install more memory in the machine.

Otherwise you have to increase the blocksize option in the configuration file. The memory occupation is inversely proportional at the select block_size. For example, using "blocksize 512", instead of the default 256, halves the memory occupation. But take care that using a bigger block size will also increase the amount of wasted space in the parity files.

Note that running with memory swapped to disk is not recommended because it will be a huge slowdown.

Do I have to check the SMART attributes of my disks?

Yes! 20% of the disks die before 4 years of life, as reported by Backblaze's How long do disk drives last?. Monitoring SMART attributes you can anticipate the failures and avoid to lose data!

If you see one of the SMART attributes Reallocated_Sector_Ct (5), Reported_Uncorrect (187), Command_Timeout (188), Current_Pending_Sector (197), and Offline_Uncorrectable (198) different than zero, replace the disk as recommended by Backblaze's Hard Drive SMART Stats.

Check also Google's Failure trends in a large disk drive population where is found that:

after the first reallocation, drives are
over 14 times more likely to fail within
60 days than drives without reallocation
counts.

after the first probational event, drives
are 16 times more likely to fail within
60 days than drives with zero probational
counts.

after the first offline reallocation, drives have over
21 times higher chances of failure within 60 days than
drives without offline reallocations.

that also recommens to replace the disk after the first error in the SMART attributes Reallocated_Sector_Ct (5), Current_Pending_Sector (197) and Offline_Uncorrectable (198).

Is it possible to use SnapRAID in a dual boot configuration, like Windows and Linux?

Yes. It's possible to use SnapRAID in a dual boot configuration. Doesn't matter the OS combination used.

In such case it's recommended to run SnapRAID only from one OS. In theory, it should also work if run in both OS. But it's a scenario not really tested, and there is always the risk to mess-up things, like using different SnapRAID version, configuration, content files, and so on.

Configuration

What's the SnapRAID 'content' file?

It's the file used by SnapRAID to save the list of all files present in your array with all the checksum, timestamp and any other information needed.

These file will be of about few GiB depending of how big is your array. Approximatively for 10 TB of data, you'll need 500 MiB of content file.

What are the SnapRAID 'parity' and 'N-parity' files?

They are the files used by SnapRAID to store the parity data used in recovering.

These files will grow in size as the biggest amount of data stored in a single disk of the array.

How to configure SAMBA to share the Pool directory

To configure SAMBA to share the pool directory, for example /pool, you should add to your /etc/samba/smb.conf the following options:

# In the global section of smb.conf
unix extensions = no

# In the share section of smb.conf
[pool]
comment = Pool
path = /pool
read only = yes
guest ok = yes
wide links = yes

How to use more disks than drive letters in Windows?

You can use Volume Mount points. You can mount a disk in a directory without using a drive letter. Just like in Linux.

Use

What are the most important things to do to prevent damages?

If you want to minimize the probability to lose data, do this:

Before running the first "sync", check your RAM memory with a program like memtest86. Bad RAM is the most frequent cause of data loss when using SnapRAID!
Frequently run the "sync" command. From once a day to once a week.
Run the "scrub" command once a week.
Use smartmontools or similar utility to monitor the SMART attributes. At the first Reallocated_Sector_Ct, Current_Pending_Sector or Offline_Uncorrectable, replace the disk, even if it still works.

How can I add an additional data disk to an existing array?

To add a new data disk at the array, add the new "disk" option in the configuration file, and then run a "sync" command.

snapraid sync

If the disk is empty, the "sync" command will be immediate.

How can I remove a data disk from an existing array?

To remove a data disk from the array do:

Change in the configuration file the related "disk" option to point to an empty directory
Remove from the configuration file any "content" option pointing to such disk
Run a "sync" command with the "-E, --force-empty" option:
```
snapraid sync -E
```
The "-E" option tells at SnapRAID to proceed even when detecting an empty disk.
When the "sync" command terminates, remove the "disk" option from the configuration file.

Your array is now without any reference to the removed disk.

How can I add, or remove, a parity disk to an existing array?

To add a new parity level, add the proper "N-parity" option in the configuration file, and then run the "sync" command, using the "-F, --force-full" option:

snapraid -F sync

The "-F" option tells at SnapRAID to recompute the full parity.

During the process you will be always protected because the existing parity is not modified (note that this happens only from version 11.0).

If you wish to remove a parity, you can simply remove the highest "N-parity" option from the configuration and then delete the parity file.

Take care that after removing a parity file, you cannot reuse it anymore, because it gets outdated after the next "sync" command.

How can I verify a single data disk?

The "scrub" command verifies all the content of the array, and it's not possible to limit the verification to a single data disk. To verify only a data disk, you can run a "check" audit command limited to the disk you want to verify.

snapraid check -a -d DISK_NAME

This command will verify all the check-sums of the files in the disk specified. The other data and parity disks won't be read and they won't be verified.

How can I replace a data disk?

If you lost the disk, see the recovering section in the manual. Otherwise, copy all the files in the new disk, maintaining the same directory structure and names.

In Linux use the command:

cp -av /from_dir/. /to_dir

WARNING! If you want to use the 'rsync' or 'mc' commands, ensure that they are recent ones. 'rsync' must be at least version 3.1.0 (2013), and 'mc' at least version 4.8.19 (2017). Older versions are not able to copy the sub-second timestamps.

In Windows use the command:

robocopy F:\from_dir T:\to_dir /e /copyall

Then change the SnapRAID configuration to point the disk at the new mount point and run a "diff" command to ensure that everything is placed correctly.

snapraid diff

If "diff" reports some "added" or "removed" files likely you have copied files with a different directory structure. In such case you have to fix it, until "diff" reports only "equal", "restored" or "copied" files.

Now you can check that the files were really copied correctly, you can run a "check" audit command limited to the replaced disk to check the check-sum of all the files.

snapraid check -a -d DISK_NAME

Finally you can run "sync" to update the SnapRAID state. This command will be almost immediate.

snapraid sync

How can I replace a parity disk?

If the disk is still accessible, first ensure to have a synced array running a sync command:

snapraid sync

Then you can copy the big parity file to the new disk, and configure the new parity location in the configuration file.

Then run sync again to make snapraid to recognize the new disk. This command will be almost immediate.

snapraid sync

In Linux a good copy command is ddrescue. You can use:

ddrescue /OLD_DISK/parity /NEW_DISK/parity /tmp/copy.log

This will copy the parity file from the old to new location, and in case of errors, it will continue copying what can be copied. To retry to copy the problematic sections, you can just retry the same copy command.

Having a partial parity file, is still beneficial, as it will still allow to recover data as long it uses the valid part.

If you have a partially damaged or totally lost parity file, you can run the "fix" command to recreate it, but ensure to use the -d option to fix only the interested parity and not the other disks.

snapraid fix -d PARITY_NAME

How can I safely move files from one disk to another?

In case you need to move files from one data disk of the array to another disk also in the array, the 100% safe way to proceed is:

Copy the files to the new location.
Run a 'diff' command to verify that the just copied files are correctly identified as 'copy'.
Run a 'sync' command.
Delete the files from the original location.
Run again a 'sync' command.

This process gives the guarantee that even if disks die during the sync process, you will be able to recover everything. It also verifies that the hashes of all the moved files are matching the original ones.

Can I defragment the data and parity disks?

Yes, you can defragment data and parity disks. Defragmentation doesn't affect SnapRAID.

How can I make SnapRAID nicer with other processes?

In Linux, you can use the ionice command with Idle priority. Like:

ionice -c 3 snapraid sync

How can I upgrade to a newer version of SnapRAID ?

To upgrade SnapRAID to a new version, just replace the old SnapRAID executable with the new one. The new SnapRAID will use your existing configuration, content and parity files.

By time to time the format of the content file changes, but a newer SnapRAID is always able to read all old formats. So, it's always possible to upgrade. If necessary, the content file format is updated the next time it's written.

Instead, it's in general not possible to downgrade to an old SnapRAID. You can anyway try, and if the old SnapRAID is not able to read the new content file, you will be advised by a proper message.

Recover

How can I undelete a just deleted file?

Simply run the "fix" command using a filter for the specified file. Like:

snapraid fix -f my_just_deleted_file

To undelete a directory use:

snapraid fix -f my_just_deleted_dir/

To undelete all the missing files use:

snapraid fix -m

What happen if I add files and a disk breaks before I have updated the parity with "sync"?

All the files added in the broken disk after the last "sync" command are lost. All the other data is safe and it can be recovered.

What happen if I delete files and a disk breaks before I have updated the parity with "sync"?

In the worst case, any file deleted or modified in not broken disks may prevent to recover the same amount of data in the broken disk. For example, if you deleted 10GB of data, you may not be able to recover 10GB of data from the broken disk. The exact amount of data lost depends on how much the deleted and broken data overlaps in the parity.

To reduce this problem you can use two parity disks. This improves a lot the chances to recover the data.

A way to be always safe, is to don't delete files, but move them to another directory in the same disk, but outside the directory tree checked by SnapRAID. Then you can run the "sync" command and only after its completion really delete the files. In case you get a disk failure during the "sync", you have to just run the "fix" command specifying where the deleted files are stored:

snapraid fix -i dir_of_deleted_files

What happen if a disk breaks during a "sync" ?

You are still able to recover data. In the worst case, you will be able to recover as much data as if the disk would have broken before the "sync". But if the "sync" process already run for some time, SnapRAID is able to use the partially synced data to recover more. To improve the recovering you can also use the "autosave" configuration option to save the intermediate content file during the sync process.

What are and how to fix "Data errors" in "sync"?

Syncing...
309505: Data error for file d4/data/index.db at position 40960
WARNING! Unexpected data error in a data disk! The block is now marked as bad!
Try with 'snapraid -e fix' to recover!

Data errors happen when SnapRAID detects that the content of a file changed but the write time of the file didn't. This is a condition that normally should never happen and it may be the result of a silent error in the disk, or the signal that something got wrong at the file-system level, like when you poweroff the machine without a proper shutdown.

If a data error is found, the "sync" process continues, and erroneous blocks are marked as bad and fixed at the next "fix" command. To just fix the silent errors and not the whole array, you can use the "-e fix" command that usually takes only few seconds.

If you have errors in more than on file, it's also possible that something is not working at hardware level. The first thing to try is to check your PC memory with an automated tool like memtest86. Another thing to check is the disk cabling and the CPU heat.

Another possibility is that you are using programs that change files without modifying the time-stamp of the file itself.
In Linux this is almost guaranteed by the operating system. The only exception is for memory mapped files not yet closed.
In Windows it's a bit trickier. Even using normal writes, you have the guarantee of an updated time-stamp only after closing it. See the MSDN WriteFile():

When writing to a file, the last write time is not fully updated until
all handles used for writing have been closed. Therefore, to ensure an
accurate last write time, close the file handle immediately after writing
to the file.

When using memory mapped file, the program must ensure to update the time-stamp manually, because Windows doesn't do it automatically. See the MSDN CreateFileMapping():

When modifying a file through a mapped view, the last modification time-stamp
may not be updated automatically. If required, the caller should use SetFileTime
to set the time-stamp.

To avoid all these Windows problems, simply ensure to run "sync" when no program is using the files into the array.

How can I store in a file all the messages from a check and fix command

To generate a log file you can use the "-l" option.

snapraid check -l mylog.log

These log files could be really big, many GB. If they are too big to be opened for your editor, you can use HxD.

How can I recover the snapraid.conf file

There is the dedicated -C, --gen-conf command that writes a template configuration file compatible with your content file. Note that this configuration requires some manual adjustments to set the disk mount points, but in the comments you'll find the required information to do so.

snapraid -C snapraid.content > snapraid.conf.new

Tech

If the SnapRAID "check" command says it's all OK. Is it really OK?

Yes. SnapRAID checks all your files with a 128 bit check-sum. If it says that they are correct, they really are.

What integrity checksum is used?

SnapRAID uses Murmur3 and SpookyHash 128 bit hashes. Murmur3 is the default in 32 bit platforms, SpookyHash in the default for 64 bit ones.

Why integrity checksum are important?

Integrity check-sum are important to detect silent errors, when the HD is returning garbage without reporting any error.

An introduction to this problem is in this article: Data corruption is worse than you know

A good analysis of this risk is in the paper: An Analysis of Data Corruption in the Storage Stack

A significant number (8% on average) of corruptions
are detected during RAID reconstruction, creating the
possibility of data loss. In this case, protection against
double disk failures is necessary to prevent data loss.

How can SnapRAID recover also if a disk break during a 'sync'?

Before the sync process start, SnapRAID saves a special content file that contains a description of both the states before and after the sync. This allows SnapRAID to try two different recovery strategies.

For each block to recover, it first assumes that the parity was correctly computed, just like if "sync" was completed successfully. If this recovering fails, it then assumes that parity was not yet updated, ignoring any new file added in the array.

Also in this case, using a double parity helps to recover when there are overlapping changes in the array.

Does SnapRAID allow to access data disks during a 'sync'?

Yes. You can safely read from data disks while a 'sync' is running.

You can also write, and if this interferes with the SnapRAID 'sync', the process will continue anyway, just skipping that written part.

This obviously could affect a potential recovery, but it's just like if you wrote just after the 'sync' completed.

Does SnapRAID retry reads or writes if a disk is not working?

No. SnapRAID never retries disk operations. It reports the error and then it tries to continue anyway. After a limit of 100 errors, it then stops the execution.

In these conditions, it's better to allow the user to try to save manually as much as data possible before the disk dies definitively. Trying an automatic long sequence of retries, will likely kill the disk. If you want to retry, you have to just repeat the command.

You can control the 100 errors limit using the "-L, --error-limit" option.

In the case of "fix" and "check" commands you can restart from the interrupted point using the "-s, --start" option specifying the block number that generated the error.

In the case of "sync" command, the latest state is anyway saved before termination. So, just restarting it will continue where stopped.

What's the snapraid.content.lock file?

It's a file used by SnapRAID to check if another SnapRAID instance is already running. It's created where the first content file is placed.

What's the notice about zero sub-second timestamp?

In the 'status' command you may now get a notice like:

You have XXXXX files with zero sub-second timestamp.
Run the 'touch' command to set it to a not zero value.

It means that a number of your files have a timestamp approximated at the second value, when instead your filesystem can store a more precise timestamp, with a sub-second precision.

This is not a problem by itself, but it could limit the SnapRAID effectiviness to detect moved or copied files between different disks.

You have the option to set that subsecond timestamp to a random value using the new 'touch' command. Note that the second part of the timestamp is not modified.

Performance

Which is the optimal hardware configuration to get the best performance?

The most important factor is to connect all the disks using (E)SATA connections, to avoid slowdown caused by the controller. Avoid any kind of USB disks.

The second important factor is use disks with similar performance, because the read/write speed is limited by the slowest disk of the array. After a sync operation, it's printed a short stats with the wait times for each disk, that could help to identify a bottleneck caused by a slow disk.

As last, a fast CPU could improve the speed when having a lot of disks. You can detect if the CPU is a limiting factor, checking the CPU usage during sync operations.

Which is the optimal blocksize to get the best performance?

The default blocksize should be already the best one.

Note that increasing it doesn't necessarily improve the performance. In some cases, it could decrease it.

Which is the optimal Linux read-ahead size to get the best performance?

The default Linux read-ahead size of 128 KiB already ensures the best performance for the default SnapRAID block size of 256 KiB. If you use a bigger block size, you should configure the read-ahead size to be at least equal to half of the SnapRAID block size.

For example, if you want to use a SnapRAID block size of 512 KiB, it's recommended to configure a read-ahead size of 256 KiB for sdX using:

echo 256 > /sys/block/sdX/queue/read_ahead_kb

Note that if you want to use a SnapRAID block size smaller than 256 KiB, it's recommended to don't configure a specific read-ahead size, and just use the default value.

How fast are the hash and parity computation?

Murmur3 hash is very fast on 32 bits, SpookyHash is even faster on 64 bits. The speed of parity computation is always good up to double parity, even in architectures without SSE support. Beyond double parity having a CPU with SSSE3 support is recommended. For low end CPUs without SSE, there is a special, but incompatible, triple parity support working well also without SSE. See 'z-parity' in the manual for more info.

The following are the result on a Core i5-4670K @ 3.4 GHz. You can check your values with the -T option.

root@redstar:/root# snapraid  -T
snapraid v7.0 by Andrea Mazzoleni, http://www.snapraid.it
Compiler gcc 4.8.1
CPU GenuineIntel, family 6, model 60, flags mmx sse2 ssse3 sse42 avx2
Memory is little-endian 64-bit
Support nanosecond timestamps with futimens()

Speed test using 8 data buffers of 262144 bytes, for a total of 2048 KiB.
Memory blocks have a displacement of 1792 bytes to improve cache performance.
The reported values are the aggregate bandwidth of all data blocks in MiB/s,
not counting parity blocks.

Memory write speed using the C memset() function:
  memset   22233

CRC used to check the content file integrity:
   table    1261
   intel    9306

Hash used to check the data blocks integrity:
            best murmur3 spooky2
    hash spooky2    4715   14684

RAID functions used for computing the parity with 'sync':
            best    int8   int32   int64    sse2   sse2e   ssse3  ssse3e    avx2   avx2e
    gen1    avx2           13339   25438   45438                           50588
    gen2    avx2            4115    6514   19441   21840                   32201
    genz   avx2e            2337    2874    9803   10920                           18944
    gen3   avx2e     814                                    8934   10154           18613
    gen4   avx2e     620                                    6204    7569           14229
    gen5   avx2e     496                                    4777    5149           10051
    gen6   avx2e     413                                    3846    4239            8190

RAID functions used for recovering with 'fix':
            best    int8   ssse3    avx2
    rec1    avx2    1158    2916    3019
    rec2    avx2     517    1220    1633
    rec3    avx2     110     611     951
    rec4    avx2      71     395     631
    rec5    avx2      49     264     421
    rec6    avx2      36     194     316

Known Problems

Why does my machine reboots or crashes while SnapRAID is running?

SnapRAID pushes the system to extreme conditions, and if the machine has a latent problem, it could result in an unexpected system crash or reboot.

Even if the problem happens only when SnapRAID is running, it's without any doubt a hardware or driver issue because SnapRAID is just a standard user application that cannot reboot or crash the system.

Possible thing to checks are:

Check your system memory with memtest86.
Check your HD cabling.
Ensure that your power supply can sustatin all the HDs spinning at the same time.
Check that the temperature of your system is not too high.
Update any system driver related to storage.
Check in systemlog or EventViewer if there is any hint of the possible issue.

Why in Linux does SnapRAID abort without any error message?

Likely you have too few free memory, and the Linux OOM (out-of-memory) killer terminates SnapRAID because it's using too much memory. You can use the Linux 'free' command to check how much free memory you have.

free -m

If it's too small, you have to install more memory in the machine.

Why in 'sync' do I get the error 'Failed to grow parity file 'xxx' to size xxx due lack of space.'?

This means that SnapRAID needs to grow the parity file to a size that cannot be contained in the parity disk.

The first thing to check is to ensure that no other data is stored in the parity disk. Leave if only for the parity file. Otherwise you have to move the files mentioned in the output to another data disk to reduce the size of the needed parity.

If you are using Linux, an alternate approach is to reformat the parity disk using specific options to increase the available space, like:

mkfs.ext4 -m 0 -T largefile4 DEVICE

The '-T largefile4' and '-m 0' options should give more space available for the parity file.

Why do I get the error 'Internal inode xxx inconsistency...'?

This means that SnapRAID found two different files using the same inode. This is theoretically something that should never happen, but in some specific conditions is instead possible.

First ensure that the mentioned files were not modified while SnapRAID was running. If files are renamed, deleted or recreated while SnapRAID is running, it's possible that inodes are reused, causing this condition.

If you are using a FAT file-system in Windows, try to convert it to NTFS. Theoretically inodes (FileIndex) are unique even in FAT, but this condition was already seen in the field.

Why with .xls files do I get the error 'Data change at file...'?

Unfortunately the Excel application does dirty tricks when handling .xls files, that may cause the followings data error:

Data change at file '/xxx/xxx.xls' at position '0'
WARNING! Unexpected data modification of a file without parity!

This happens because Excel modifies the files after opening them, even if you don't press 'Save'. It stores the name of the last user that opened it to be able to report if another user tries to open the same file at the same time. To avoid to have the file triggered as modified, it restores the time-stamp to its original value. But the file was modified, and SnapRAID reports it.

To workaround the problem you can see How to prevent Excel from modifying the file on exit?, or you can switch to the .xlsx format.

Why are VeraCrypt containers never saved?

VeraCrypt (a fork of TrueCrypt) by default has enabled the option Preserve modification time-stamp of file containers that makes impossible at SnapRAID, and at other backup programs, to detect that a file container is changed. Ensure to disable this option in VeraCrypt.