<metaname="description"content="A backup program for disk arrays. It stores parity information of your data and it recovers from up to six disk failures"/>
<metaname="keywords"content="snapraid snapshot raid backup disk array redundancy parity"/>
<aid="bakhome"><h3>Is SnapRAID suitable to backup the home/My Documents directory?</h3></a>
<p>
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 <b>very large</b> amount of data,
many Tera bytes, and a full backup copy of a such amount of data is not possible
in any other way.
</p>
<aid="bakos"><h3>Is SnapRAID suitable to backup the boot OS disk?</h3></a>
<p>
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.
</p>
<h2>Setup</h2>
For a setup example in Ubuntu 14.04 you can check the <ahref="http://zackreed.me/articles/72-snapraid-on-ubuntu-12-04">SnapRAID Zack's tutorial</a>.
<aid="howmanypar"><h3>Do I need one or more parity disks?</h3></a>
<p>
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:
<p>
<tableclass="download">
<tr><th>Parities</th><th>Data disks</th></tr>
<tr>
<td>1/Single Parity/RAID5</td>
<td>2 - 4</td>
</tr>
<tr>
<td>2/Double Parity/RAID6</td>
<td>5 - 14</td>
</tr>
<tr>
<td>3/Triple Parity</td>
<td>15 - 21</td>
</tr>
<tr>
<td>4/Quad Parity</td>
<td>22 - 28</td>
</tr>
<tr>
<td>5/Penta Parity</td>
<td>29 - 35</td>
</tr>
<tr>
<td>6/Hexa Parity</td>
<td>36 - 42</td>
</tr>
</table>
</p>
<p>
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.
</p>
<p>
Take care that multiple failures happen. At now the worst case reported in the SnapRAID history,
is a <ahref="https://sourceforge.net/p/snapraid/discussion/1677233/thread/eca5ed3d/">four disks failure, succesfully recovered using four parities</a>.
</p>
<p>
Some interesting articles about number of parity levels and failure rate of disks are:
<ahref="http://www.zdnet.com/blog/storage/why-raid-5-stops-working-in-2009/162">Why RAID 5 stops working in 2009</a>,
<ahref="http://www.zdnet.com/blog/storage/why-raid-6-stops-working-in-2019/805">Why RAID 6 stops working in 2019</a>,
<ahref="http://storagemojo.com/2010/02/27/does-raid-6-stops-working-in-2019/">Does RAID 6 stop working in 2019?</a>,
<ahref="http://queue.acm.org/detail.cfm?id=1670144">Triple-Parity RAID and Beyond</a>,
<ahref="http://blog.backblaze.com/2013/11/12/how-long-do-disk-drives-last/">How long do disk drives last?</a>.
</p>
<aid="fs"><h3>Which filesystem is recommended for SnapRAID ?</h3></a>
For the data disks, you can use whatever filesystem you like.
For the parity disks, follow these suggestions:
<p>
<tableclass="download">
<tr><th>FileSystem</th><th>Result</th></tr>
<tr>
<td>ext4</td>
<td>OK</td>
</tr>
<tr>
<td>ext3</td>
<td>No. It doesn't support the <ahref="http://www.kernel.org/doc/man-pages/online/pages/man2/fallocate.2.html">fallocate()</a> 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.
</td>
</tr>
<tr>
<td>XFS</td>
<td>OK</td>
</tr>
<tr>
<td>JFS</td>
<td>No. It doesn't support the <ahref="http://www.kernel.org/doc/man-pages/online/pages/man2/fallocate.2.html">fallocate()</a> command needed to allocated the parity files.
<br/>
It also doesn't seem to implement at the best the <ahref="http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_fadvise.html">posix_fadvise()</a> command.</td>
</tr>
<tr>
<td>ReiserFS</td>
<td>Unsure. Where are user <ahref="https://sourceforge.net/p/snapraid/discussion/1677233/thread/194dee16">reports</a> reporting speed increase when switching from ReiserFS to other filesystem.
</tr>
<tr>
<td>NTFS</td>
<td>OK in Windows. No in Linux, as it doesn't support <ahref="http://www.kernel.org/doc/man-pages/online/pages/man2/fallocate.2.html">fallocate()</a> 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.
</td>
</tr>
<tr>
<td>FAT</td>
<td>No. You cannot store files bigger than 4 GB. It's also not journaled. Use NTFS instead.</td>
</tr>
<tr>
<td>HFS+</td>
<td>OK</td>
</tr>
</table>
</p>
<p>
In Linux, to get more space for the parity, it's recommended to format the parity filesystem with the <em>-m 0 -T largefile4</em> options.
For choosing harddisk, you can check <ahref="https://www.backblaze.com/blog/what-hard-drive-should-i-buy/">Backblaze's What Hard Drive Should I Buy?</a>,
and <ahref="https://www.backblaze.com/blog/enterprise-drive-reliability/">Backblaze's Enterprise Drives: Fact or Fiction?</a>.
</p>
<aid="cpu"><h3>Is a multi-core CPU recommended?</h3></a>
<p>
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.<br/>
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.
</p>
<aid="64"><h3>Is a 64 bit operating system recommended?</h3></a>
<p>
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.
</p>
<aid="mem"><h3>How much memory SnapRAID requires to run?</h3></a>
<p>
Approximatively, the 32 bits version of SnapRAID requires 1 GiB of memory for 9 TB of data.
The 64 bits version requires 1 GiB of memory for 7 TB of data.
</p>
<p>
If you have less memory than required, the recommended option is to install more memory in the machine.
</p>
<p>
Otherwise you have to increase the block_size option in the configuration file.
The memory occupation is inversely proportional at the select block_size.
For example, using "block_size 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.
</p>
<p>
Note that running with memory swapped to disk is not recommended because it will be a huge slowdown.
</p>
<aid="smart"><h3>Do I have to check the SMART attributes of my disks?</h3></a>
<p>
Yes! 20% of the disks die before 4 years of life, as
reported by <ahref="https://www.backblaze.com/blog/how-long-do-disk-drives-last/">Backblaze's How long do disk drives last?</a>.
Monitoring SMART attributes you can anticipate the failures and avoid to lose data!
</p>
<p>
If you see one of the SMART attributes
<b>Reallocated_Sector_Ct (5)</b>,
<b>Reported_Uncorrect (187)</b>,
<b>Command_Timeout (188)</b>,
<b>Current_Pending_Sector (197)</b>,
and <b>Offline_Uncorrectable (198)</b>
different than zero, replace the disk as recommended by
<ahref="https://www.backblaze.com/blog/hard-drive-smart-stats/">Backblaze's Hard Drive SMART Stats</a>.
</p>
<p>
Check also <ahref="http://research.google.com/pubs/pub32774.html">Google's Failure trends in a large disk drive population</a>
where is found that:
<pre>after the first reallocation, drives are
over 14 times more likely to fail within
60 days than drives without reallocation
counts.</pre>
<pre>after the first probational event, drives
are 16 times more likely to fail within
60 days than drives with zero probational
counts.</pre>
<pre>after the first offline reallocation, drives have over
21 times higher chances of failure within 60 days than
drives without offline reallocations.</pre>
</p>
that also recommens to replace the disk after the first error in the SMART attributes <b>Reallocated_Sector_Ct (5)</b>,
<b>Current_Pending_Sector (197)</b> and <b>Offline_Uncorrectable (198)</b>.
<aid="multios"><h3>Is it possible to use SnapRAID in a dual boot configuration, like Windows and Linux?</h3></a>
<p>
Yes. It's possible to use SnapRAID in a dual boot configuration. Doesn't matter the OS combination used.
</p>
<p>
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.
</p>
<h2>Configuration</h2>
<aid="fcontent"><h3>What's the SnapRAID 'content' file?</h3></a>
<p>
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.
</p>
<p>
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.
</p>
<aid="fparity"><h3>What are the SnapRAID 'parity' and 'N-parity' files?</h3></a>
<p>
They are the files used by SnapRAID to store the parity data used in recovering.
</p>
<p>
These files will grow in size as the biggest amount of data stored in a single disk
of the array.
</p>
<aid="samba"><h3>How to configure SAMBA to share the Pool directory</h3></a>
<p>
To configure SAMBA to share the pool directory, for example /pool, you should add to
your /etc/samba/smb.conf the following options:
</p>
<pre>
# 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
</pre>
<aid="winmanydisk"><h3>How to use more disks than drive letters in Windows?</h3></a>
<p>
You can use <ahref="http://technet.microsoft.com/en-us/library/cc938934.aspx">Volume Mount points</a>. You can mount a disk in a directory without
using a drive letter. Just like in Linux.
</p>
<h2>Use</h2>
<aid="guidelines"><h3>What are the most important things to do to prevent damages?</h3></a>
<p>
If you want to minimize the probability to lose data, do this:
<ul>
<li>Before running the first "sync", check your RAM memory with a program
like <ahref="http://www.memtest86.com/">memtest86</a>.
Bad RAM is the most frequent cause of data loss when using SnapRAID!</li>
<li>Frequently run the "sync" command. From once a day to once a week.</li>
<li>Run the "scrub" command once a week.</li>
<li>Use <ahref="http://en.wikipedia.org/wiki/Smartmontools">smartmontools</a> or similar utility
to monitor the SMART attributes.
At the first <b>Reallocated_Sector_Ct</b>, <b>Current_Pending_Sector</b> or <b>Offline_Uncorrectable</b>, replace the disk,
even if it still works.</li>
</ul>
</p>
<aid="adddatadisk"><h3>How can I add an additional data disk to an existing array?</h3></a>
<p>
To add a new data disk at the array, add the new "disk" option in the configuration file,
and then run a "sync" command.
<pre>
snapraid sync
</pre>
</p>
<aid="remdatadisk"><h3>How can I remove a data disk from an existing array?</h3></a>
<p>
To remove a data disk from the array do:
</p>
<ul>
<li>Change in the configuration file the related "disk" option to point to an empty directory</li>
<li>Remove from the configuration file any "content" option pointing to such disk</li>
<li>Run a "sync" command with the "-E, --force-empty" option:
<pre>
snapraid sync -E
</pre>
The "-E" option tells at SnapRAID to proceed even when detecting an empty disk.</li>
<li>When the "sync" command terminates, remove the "disk" option from the configuration file.</li>
</ul>
<p>
Your array is now without any reference to the removed disk.
</p>
<aid="addpardisk"><h3>How can I add an additional parity disk to an existing array?</h3></a>
<p>
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:
<pre>
snapraid -F sync
</pre>
The "-F" option tells at SnapRAID to recompute the full parity.
</p>
<p>
Note that in the process, you will be always protected, because the existing parity is not modified.
</p>
<p>
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.
</p>
<p>
Take care that after removing a parity file, you cannot reuse it anymore,
because it gets outdated after the next "sync" command.
</p>
<aid="repdatadisk"><h3>How can I replace a data disk?</h3></a>
<p>
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.
</p>
<p>
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.
<pre>
snapraid diff
</pre>
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.
</p>
<p>
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 checksum of all the files.
<pre>
snapraid check -a -d DISK_NAME
</pre>
</p>
<p>
Finally you can run "sync" to update the SnapRAID state. This command will be almost immediate.
<pre>
snapraid sync
</pre>
</p>
<aid="reppardisk"><h3>How can I replace a parity disk?</h3></a>
<p>
If the disk is still accessible, first ensure to have a synched array running a sync command:
<pre>
snapraid sync
</pre>
</p>
<p>
Then you can copy the big parity file to the new disk,
and configure the new parity location in the configuration file.
</p>
<p>
In Linux a good copy command is <ahref="http://www.gnu.org/software/ddrescue/">ddrescue</a>.
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.
</p>
<p>
Having a partial parity file, is still beneficial, as it will still allow to recover
data as long it uses the valid part. To restore it to full functionality,
just run a "fix" command.
</p>
<p>
If instead you completely lost the parity file, you can run the "fix" command to recreate it.
<pre>
snapraid fix
</pre>
</p>
<aid="defrag"><h3>Can I defragment the data and parity disks?</h3></a>
<p>
Yes, you can defragment data and parity disks. Defragmentation doesn't invalidate the SnapRAID data.
</p>
<aid="upgrade"><h3>How can I upgrade to a newer version of SnapRAID ?</h3></a>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<aid="truecrypttimestamp"><h3>Why TrueCrypt containers are never saved by SnapRAID?</h3></a>
<p>
TrueCrypt by default has enabled the option <i>Preserve modification timestamp of file containers</i>
that makes impossible to SnapRAID, and other backup programs, to detect that a file container is changed.
Ensure to disable this option in TrueCrypt.
</p>
<h2>Recover</h2>
<aid="undelete"><h3>How can I undelete a just deleted file?</h3></a>
<p>
Simply run the "fix" command using a filter for the specified file. Like:
<pre>
snapraid fix -f my_just_deleted_file
</pre>
To undelete a directory use:
<pre>
snapraid fix -f my_just_deleted_dir/
</pre>
To undelete all the missing files use:
<pre>
snapraid fix -m
</pre>
</p>
<aid="addandbreak"><h3>What happen if I add files and a disk breaks before I have updated the parity with "sync"?</h3></a>
<p>
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.
</p>
<aid="delandbreak"><h3>What happen if I delete files and a disk breaks before I have updated the parity with "sync"?</h3></a>
<p>
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.
</p>
<p>
To reduce this problem you can use two parity disks. This improves a lot the chances to recover the data.
</p>
<p>
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:
<pre>
snapraid fix -i dir_of_deleted_files
</pre>
</p>
<aid="syncandbreak"><h3>What happen if a disk breaks during a "sync" ?</h3></a>
<p>
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.
</p>
<aid="dataerror"><h3>What are and how to fix "Data errors" in "sync"?</h3></a>
<pre>
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!
</pre>
<p>
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 filesystem level, like when you poweroff the machine without a
proper shutdown.
</p>
<p>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.
</p>
<p>
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 <ahref="http://www.memtest86.com/">memtest86</a>.
Another thing to check is the disk cabling and the CPU heat.
</p>
<p>
Another possibility is that you are using programs that change files without modifying the time-stamp of the file itself.
<br/>
In Linux this is almost guaranteed by the operating system. The only exception is for memory mapped files
not yet closed.
<br/>
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 <ahref="http://msdn.microsoft.com/en-us/library/windows/desktop/aa365747%28v=vs.85%29.aspx">MSDN WriteFile():</a>
<pre>
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.
</pre>
When using memory mapped file, the program must ensure to update the time-stamp manually,
because Windows doesn't do it automatically.
See the <ahref="http://msdn.microsoft.com/en-us/library/windows/desktop/aa366537%28v=vs.85%29.aspx">MSDN CreateFileMapping():</a>
<pre>
When modifying a file through a mapped view, the last modification timestamp
may not be updated automatically. If required, the caller should use SetFileTime
to set the timestamp.
</pre>
To avoid all these Windows problems, simply ensure to run "sync" when no program is using the files into the array.
</p>
<aid="log"><h3>How can I store in a file all the messages from a check and fix command</h3></a>
<p>
To generate a log file you can use the "-l" option.
<pre>
snapraid check -l mylog.log
</pre>
</p>
<aid="recconf"><h3>How can I recover the snapraid.conf file</h3></a>
<p>
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.
<pre>
snapraid -C snapraid.content > snapraid.conf.new
</pre>
</p>
<h2>Tech</h2>
<aid="checkinfo"><h3>If the SnapRAID "check" command says it's all OK. Is it really OK?</h3></a>
Yes. SnapRAID checks all your files with a 128 bit checksum.
If it says that they are correct, they really are.
<aid="checksum"><h3>What integrity checksum is used?</h3></a>
SnapRAID uses <ahref="http://code.google.com/p/smhasher/">Murmur3</a> and <ahref="http://burtleburtle.net/bob/hash/spooky.html">SpookyHash</a> 128 bit hashes.
Murmur3 is the default in 32 bit platforms, SpookyHash in the default for 64 bit ones.
<aid="checksuminfo"><h3>Why integrity checksum are important?</h3></a>
Integrity checksum are important to detect silent errors,
when the HD is returning garbage without reporting any error.
<p>
An introduction to this problem is in this article:
<ahref="http://www.zdnet.com/blog/storage/data-corruption-is-worse-than-you-know/191">Data corruption is worse than you know</a>
</p>
<p>
A good analysis of this risk is in the paper:
<ahref="http://www.cs.toronto.edu/~bianca/papers/fast08.pdf">An Analysis of Data Corruption in the Storage Stack</a>
<pre>
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.
