2025-10-02 18:36:40 +02:00
|
|
|
.TH "SnapRAID Backup for Disk Arrays" 1
|
2011-03-22 23:22:18 +01:00
|
|
|
.SH NAME
|
2025-10-02 18:36:40 +02:00
|
|
|
snapraid \- SnapRAID Backup for Disk Arrays
|
2011-03-22 23:22:18 +01:00
|
|
|
.SH SYNOPSIS
|
2013-11-14 22:02:26 +01:00
|
|
|
snapraid [\-c, \-\-conf CONFIG]
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2011-10-09 23:41:08 +02:00
|
|
|
.PD
|
2013-11-14 22:02:26 +01:00
|
|
|
[\-f, \-\-filter PATTERN] [\-d, \-\-filter\-disk NAME]
|
2013-08-18 19:35:40 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2013-11-14 22:02:26 +01:00
|
|
|
[\-m, \-\-filter\-missing] [\-e, \-\-filter\-error]
|
2011-10-09 23:41:08 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2012-10-07 23:18:10 +02:00
|
|
|
.PD
|
2014-02-12 22:04:14 +01:00
|
|
|
[\-a, \-\-audit\-only] [\-h, \-\-pre\-hash] [\-i, \-\-import DIR]
|
2012-10-10 23:32:09 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2013-08-22 23:03:13 +02:00
|
|
|
.PD
|
2015-11-10 19:37:23 +01:00
|
|
|
[\-p, \-\-plan PERC|bad|new|full]
|
2013-08-22 23:03:13 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2014-12-30 10:44:11 +01:00
|
|
|
.PD
|
2015-11-08 16:52:29 +01:00
|
|
|
[\-o, \-\-older\-than DAYS] [\-l, \-\-log FILE]
|
2014-12-30 10:44:11 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2025-03-27 12:57:41 -07:00
|
|
|
.PD
|
2025-09-26 09:49:20 +02:00
|
|
|
[\-s, \-\-spin\-down\-on\-error] [\-w, \-\-bw\-limit RATE]
|
2025-03-27 12:57:41 -07:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD
|
2013-11-14 22:02:26 +01:00
|
|
|
[\-Z, \-\-force\-zero] [\-E, \-\-force\-empty]
|
2013-08-18 19:35:40 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2013-11-14 22:02:26 +01:00
|
|
|
[\-U, \-\-force\-uuid] [\-D, \-\-force\-device]
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2014-05-15 23:45:51 +02:00
|
|
|
.PD
|
2014-06-15 19:01:07 +02:00
|
|
|
[\-N, \-\-force\-nocopy] [\-F, \-\-force\-full]
|
2014-05-15 23:45:51 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2016-10-01 22:19:29 +02:00
|
|
|
.PD
|
|
|
|
|
[\-R, \-\-force\-realloc]
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2011-03-23 18:54:08 +01:00
|
|
|
.PD
|
2014-12-30 10:44:11 +01:00
|
|
|
[\-S, \-\-start BLKSTART] [\-B, \-\-count BLKCOUNT]
|
2011-03-23 18:54:08 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD
|
2014-12-30 10:44:11 +01:00
|
|
|
[\-L, \-\-error\-limit NUMBER]
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2025-09-29 15:53:43 +02:00
|
|
|
.PD
|
|
|
|
|
[\-A, \-\-stats]
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
2014-12-30 10:44:11 +01:00
|
|
|
.PD
|
2015-02-22 14:31:03 +01:00
|
|
|
[\-v, \-\-verbose] [\-q, \-\-quiet]
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2025-09-23 22:38:13 +02:00
|
|
|
status|smart|probe|up|down|diff|sync|scrub|fix|check
|
2015-04-12 21:25:16 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2025-09-23 22:38:13 +02:00
|
|
|
|list|dup|pool|devices|touch|rehash
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.PP
|
2014-02-12 22:04:14 +01:00
|
|
|
snapraid [\-V, \-\-version] [\-H, \-\-help] [\-C, \-\-gen\-conf CONTENT]
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.SH DESCRIPTION
|
2023-12-09 15:48:34 +01:00
|
|
|
SnapRAID is a backup program designed for disk arrays, storing
|
|
|
|
|
parity information for data recovery in the event of up to six
|
|
|
|
|
disk failures.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
2023-12-09 15:48:34 +01:00
|
|
|
Primarily intended for home media centers with large,
|
|
|
|
|
infrequently changing files, SnapRAID offers several features:
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.IP \(bu
|
2023-12-09 15:48:34 +01:00
|
|
|
You can utilize disks already filled with files without the
|
|
|
|
|
need to reformat them, accessing them as usual.
|
2019-05-19 20:03:33 +02:00
|
|
|
.IP \(bu
|
2023-12-09 15:48:34 +01:00
|
|
|
All your data is hashed to ensure data integrity and prevent
|
2013-09-05 22:25:29 +02:00
|
|
|
silent corruption.
|
2011-03-22 23:22:18 +01:00
|
|
|
.IP \(bu
|
2023-12-09 15:48:34 +01:00
|
|
|
When the number of failed disks exceeds the parity count,
|
|
|
|
|
data loss is confined to the affected disks; data on
|
|
|
|
|
other disks remains accessible.
|
2011-03-22 23:22:18 +01:00
|
|
|
.IP \(bu
|
2023-12-09 15:48:34 +01:00
|
|
|
If you accidentally delete files on a disk, recovery is
|
|
|
|
|
possible.
|
2011-03-22 23:22:18 +01:00
|
|
|
.IP \(bu
|
2023-12-09 15:48:34 +01:00
|
|
|
Disks can have different sizes.
|
2013-09-05 22:25:29 +02:00
|
|
|
.IP \(bu
|
|
|
|
|
You can add disks at any time.
|
2011-03-22 23:22:18 +01:00
|
|
|
.IP \(bu
|
2023-12-09 15:48:34 +01:00
|
|
|
SnapRAID doesn\'t lock in your data; you can stop using it
|
|
|
|
|
anytime without reformatting or moving data.
|
2015-09-02 18:52:17 +02:00
|
|
|
.IP \(bu
|
2023-12-09 15:48:34 +01:00
|
|
|
To access a file, only a single disk needs to spin, saving
|
|
|
|
|
power and reducing noise.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD
|
|
|
|
|
.PP
|
2023-12-09 15:48:34 +01:00
|
|
|
For more information, please visit the official SnapRAID site:
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2015-07-20 20:02:26 +02:00
|
|
|
http://www.snapraid.it/
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.SH LIMITATIONS
|
2025-10-02 18:36:40 +02:00
|
|
|
SnapRAID is a hybrid between a RAID and a backup program, aiming to combine
|
|
|
|
|
the best benefits of both. However, it has some limitations that you should
|
2011-03-22 23:22:18 +01:00
|
|
|
consider before using it.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The main limitation is that if a disk fails and you haven\'t recently synced,
|
2025-10-06 15:43:51 +02:00
|
|
|
you may not be able to fully recover.
|
2024-01-10 07:14:21 -06:00
|
|
|
More specifically, you may be unable to recover up to the size of
|
2025-10-02 18:36:40 +02:00
|
|
|
the changed or deleted files since the last sync operation.
|
|
|
|
|
This occurs even if the changed or deleted files are not on the
|
2024-01-10 07:14:21 -06:00
|
|
|
failed disk. This is why SnapRAID is better suited for
|
2025-10-02 18:36:40 +02:00
|
|
|
data that rarely changes.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
On the other hand, newly added files don\'t prevent recovery of already
|
|
|
|
|
existing files. You will only lose the recently added files if they
|
|
|
|
|
are on the failed disk.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
2024-01-10 07:14:21 -06:00
|
|
|
Other SnapRAID limitations are:
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.IP \(bu
|
2025-10-02 18:36:40 +02:00
|
|
|
With SnapRAID, you still have separate file systems for each disk.
|
|
|
|
|
With RAID, you get a single large file system.
|
2011-04-23 08:58:00 +02:00
|
|
|
.IP \(bu
|
2024-01-10 07:14:21 -06:00
|
|
|
SnapRAID doesn\'t stripe data.
|
2025-10-02 18:36:40 +02:00
|
|
|
With RAID, you get a speed boost with striping.
|
2011-03-22 23:22:18 +01:00
|
|
|
.IP \(bu
|
2024-01-10 07:14:21 -06:00
|
|
|
SnapRAID doesn\'t support real\-time recovery.
|
2025-10-02 18:36:40 +02:00
|
|
|
With RAID, you do not have to stop working when a disk fails.
|
2011-03-22 23:22:18 +01:00
|
|
|
.IP \(bu
|
2025-10-02 18:36:40 +02:00
|
|
|
SnapRAID can recover data only from a limited number of disk failures.
|
|
|
|
|
With a backup, you can recover from a complete
|
|
|
|
|
failure of the entire disk array.
|
2011-03-30 17:47:29 +02:00
|
|
|
.IP \(bu
|
2025-10-02 18:36:40 +02:00
|
|
|
Only file names, timestamps, symlinks, and hardlinks are saved.
|
|
|
|
|
Permissions, ownership, and extended attributes are not saved.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD
|
|
|
|
|
.SH GETTING STARTED
|
2025-10-02 18:36:40 +02:00
|
|
|
To use SnapRAID, you need to first select one disk in your disk array
|
|
|
|
|
to dedicate to \[dq]parity\[dq] information. With one disk for parity, you
|
|
|
|
|
will be able to recover from a single disk failure, similar to RAID5.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If you want to recover from more disk failures, similar to RAID6,
|
|
|
|
|
you must reserve additional disks for parity. Each additional parity
|
|
|
|
|
disk allows recovery from one more disk failure.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
As parity disks, you must pick the largest disks in the array,
|
|
|
|
|
as the parity information may grow to the size of the largest data
|
2011-04-23 21:38:26 +02:00
|
|
|
disk in the array.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
These disks will be dedicated to storing the \[dq]parity\[dq] files.
|
|
|
|
|
You should not store your data on them.
|
2011-09-18 22:43:41 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Then, you must define the \[dq]data\[dq] disks that you want to protect
|
2015-04-19 22:07:06 +02:00
|
|
|
with SnapRAID. The protection is more effective if these disks
|
2025-10-02 18:36:40 +02:00
|
|
|
contain data that rarely changes. For this reason, it\'s better to
|
|
|
|
|
NOT include the Windows C:\\ disk or the Unix /home, /var, and /tmp
|
|
|
|
|
directories.
|
2015-04-19 22:07:06 +02:00
|
|
|
.PP
|
2014-03-17 22:06:20 +01:00
|
|
|
The list of files is saved in the \[dq]content\[dq] files, usually
|
2025-10-02 18:36:40 +02:00
|
|
|
stored on the data, parity, or boot disks.
|
|
|
|
|
This file contains the details of your backup, including all the
|
|
|
|
|
checksums to verify its integrity.
|
|
|
|
|
The \[dq]content\[dq] file is stored in multiple copies, and each copy must
|
|
|
|
|
be on a different disk to ensure that, even in case of multiple
|
|
|
|
|
disk failures, at least one copy is available.
|
2011-04-23 21:38:26 +02:00
|
|
|
.PP
|
2025-10-06 15:43:51 +02:00
|
|
|
For example, suppose you are interested in only one parity level
|
2025-10-02 18:36:40 +02:00
|
|
|
of protection, and your disks are located at:
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2013-11-14 22:02:26 +01:00
|
|
|
/mnt/diskp <\- selected disk for parity
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2015-04-19 22:07:06 +02:00
|
|
|
/mnt/disk1 <\- first disk to protect
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2015-04-19 22:07:06 +02:00
|
|
|
/mnt/disk2 <\- second disk to protect
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2015-04-19 22:07:06 +02:00
|
|
|
/mnt/disk3 <\- third disk to protect
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You must create the configuration file /etc/snapraid.conf with
|
2011-04-23 08:58:00 +02:00
|
|
|
the following options:
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2014-03-18 19:34:18 +01:00
|
|
|
parity /mnt/diskp/snapraid.parity
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-18 19:34:18 +01:00
|
|
|
content /var/snapraid/snapraid.content
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-18 19:34:18 +01:00
|
|
|
content /mnt/disk1/snapraid.content
|
2011-12-08 10:34:32 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-18 19:34:18 +01:00
|
|
|
content /mnt/disk2/snapraid.content
|
2011-09-19 20:45:35 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d1 /mnt/disk1/
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d2 /mnt/disk2/
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d3 /mnt/disk3/
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If you are on Windows, you should use the Windows path format, with drive
|
2015-07-14 19:29:25 +02:00
|
|
|
letters and backslashes instead of slashes.
|
2011-04-23 08:58:00 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2014-03-18 19:34:18 +01:00
|
|
|
parity E:\\snapraid.parity
|
2011-04-23 08:58:00 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-18 19:34:18 +01:00
|
|
|
content C:\\snapraid\\snapraid.content
|
2011-04-23 08:58:00 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-18 19:34:18 +01:00
|
|
|
content F:\\array\\snapraid.content
|
2011-12-08 10:34:32 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-18 19:34:18 +01:00
|
|
|
content G:\\array\\snapraid.content
|
2011-09-19 20:45:35 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d1 F:\\array\\
|
2011-04-23 08:58:00 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d2 G:\\array\\
|
2011-04-23 08:58:00 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d3 H:\\array\\
|
2011-04-23 08:58:00 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If you have many disks and run out of drive letters, you can mount
|
|
|
|
|
disks directly in subfolders. See:
|
2015-07-14 19:29:25 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
https://www.google.com/search?q=Windows+mount+point
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
At this point, you are ready to run the \[dq]sync\[dq] command to build the
|
2013-11-29 23:06:09 +01:00
|
|
|
parity information.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
snapraid sync
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This process may take several hours the first time, depending on the size
|
|
|
|
|
of the data already present on the disks. If the disks are empty,
|
2011-03-22 23:22:18 +01:00
|
|
|
the process is immediate.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You can stop it at any time by pressing Ctrl+C, and at the next run, it
|
|
|
|
|
will resume where it was interrupted.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
|
|
|
|
When this command completes, your data is SAFE.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Now you can start using your array as you like and periodically
|
|
|
|
|
update the parity information by running the \[dq]sync\[dq] command.
|
2013-08-20 12:23:46 +02:00
|
|
|
.SS Scrubbing
|
2013-11-29 23:06:09 +01:00
|
|
|
To periodically check the data and parity for errors, you can
|
2014-03-17 22:06:20 +01:00
|
|
|
run the \[dq]scrub\[dq] command.
|
2011-04-25 13:43:51 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2013-08-20 12:23:46 +02:00
|
|
|
snapraid scrub
|
2012-03-31 09:49:52 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This command compares the data in your array with the hash computed
|
|
|
|
|
during the \[dq]sync\[dq] command to verify integrity.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Each run of the command checks approximately 8% of the array, excluding data
|
2015-11-08 16:52:29 +01:00
|
|
|
already scrubbed in the previous 10 days.
|
2025-10-02 18:36:40 +02:00
|
|
|
You can use the \-p, \-\-plan option to specify a different amount
|
2013-11-14 22:02:26 +01:00
|
|
|
and the \-o, \-\-older\-than option to specify a different age in days.
|
2025-10-06 15:43:51 +02:00
|
|
|
For example, to check 5% of the array for blocks older than 20 days, use:
|
2013-08-20 12:23:46 +02:00
|
|
|
.PP
|
2013-08-22 23:03:13 +02:00
|
|
|
.RS 4
|
2013-11-14 22:02:26 +01:00
|
|
|
snapraid \-p 5 \-o 20 scrub
|
2013-08-22 23:03:13 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If silent or input/output errors are found during the process,
|
|
|
|
|
the corresponding blocks are marked as bad in the \[dq]content\[dq] file
|
2014-12-30 18:30:11 +01:00
|
|
|
and listed in the \[dq]status\[dq] command.
|
2012-03-31 09:49:52 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2013-08-20 12:23:46 +02:00
|
|
|
snapraid status
|
2013-02-24 11:33:09 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
To fix them, you can use the \[dq]fix\[dq] command, filtering for bad blocks with
|
|
|
|
|
the \-e, \-\-filter\-error option:
|
2013-02-24 11:33:09 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2013-11-14 22:02:26 +01:00
|
|
|
snapraid \-e fix
|
2011-04-25 13:43:51 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
2013-08-20 12:23:46 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
At the next \[dq]scrub,\[dq] the errors will disappear from the \[dq]status\[dq] report
|
|
|
|
|
if they are truly fixed. To make it faster, you can use \-p bad to scrub
|
|
|
|
|
only blocks marked as bad.
|
2013-08-22 23:03:13 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2015-09-13 15:48:05 +02:00
|
|
|
snapraid \-p bad scrub
|
2013-08-22 23:03:13 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
2014-12-07 00:07:36 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Running \[dq]scrub\[dq] on an unsynced array may report errors caused by
|
|
|
|
|
removed or modified files. These errors are reported in the \[dq]scrub\[dq]
|
|
|
|
|
output, but the related blocks are not marked as bad.
|
2013-08-20 12:23:46 +02:00
|
|
|
.SS Pooling
|
2025-10-12 19:17:32 +02:00
|
|
|
Note: The pooling feature described below has been superseded by the
|
|
|
|
|
mergefs tool, which is now the recommended option for Linux users in
|
|
|
|
|
the SnapRAID community. Mergefs provides a more flexible and efficient
|
|
|
|
|
way to pool multiple drives into a single unified mount point,
|
|
|
|
|
allowing seamless access to files across your array without relying
|
|
|
|
|
on symbolic links. It integrates well with SnapRAID for parity
|
|
|
|
|
protection and is commonly used in setups like OpenMediaVault (OMV)
|
|
|
|
|
or custom NAS configurations.
|
|
|
|
|
.PP
|
2013-08-20 12:23:46 +02:00
|
|
|
To have all the files in your array shown in the same directory tree,
|
2025-10-02 18:36:40 +02:00
|
|
|
you can enable the \[dq]pooling\[dq] feature. It creates a read\-only virtual
|
|
|
|
|
view of all the files in your array using symbolic links.
|
2013-12-16 18:56:51 +01:00
|
|
|
.PP
|
2014-03-17 22:06:20 +01:00
|
|
|
You can configure the \[dq]pooling\[dq] directory in the configuration file with:
|
2013-08-18 19:35:40 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2013-08-20 12:23:46 +02:00
|
|
|
pool /pool
|
2013-08-18 19:35:40 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
or, if you are on Windows, with:
|
2013-08-18 19:35:40 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2014-03-17 22:06:20 +01:00
|
|
|
pool C:\\pool
|
2013-08-18 19:35:40 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2014-03-17 22:06:20 +01:00
|
|
|
and then run the \[dq]pool\[dq] command to create or update the virtual view.
|
2013-08-18 19:35:40 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2013-08-20 12:23:46 +02:00
|
|
|
snapraid pool
|
2013-08-18 19:35:40 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
2013-10-01 21:32:48 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If you are using a Unix platform and want to share this directory
|
|
|
|
|
over the network to either Windows or Unix machines, you should add
|
|
|
|
|
the following options to your /etc/samba/smb.conf:
|
2013-10-01 21:32:48 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
# In the global section of smb.conf
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
unix extensions = no
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
# In the share section of smb.conf
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
[pool]
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
comment = Pool
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
path = /pool
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
read only = yes
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
guest ok = yes
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
wide links = yes
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2013-12-16 18:56:51 +01:00
|
|
|
follow symlinks = yes
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
2013-10-01 21:32:48 +02:00
|
|
|
.RE
|
2013-12-16 18:56:51 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
In Windows, sharing symbolic links over a network requires clients to
|
|
|
|
|
resolve them remotely. To enable this, besides sharing the pool directory,
|
|
|
|
|
you must also share all the disks independently, using the disk names
|
|
|
|
|
defined in the configuration file as share points. You must also specify
|
|
|
|
|
in the \[dq]share\[dq] option of the configuration file the Windows UNC path that
|
|
|
|
|
remote clients need to use to access these shared disks.
|
2013-12-18 19:26:57 +01:00
|
|
|
.PP
|
2014-03-17 22:06:20 +01:00
|
|
|
For example, operating from a server named \[dq]darkstar\[dq], you can use
|
2013-12-18 19:26:57 +01:00
|
|
|
the options:
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2016-01-10 21:19:20 +01:00
|
|
|
data d1 F:\\array\\
|
2013-12-18 19:26:57 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d2 G:\\array\\
|
2013-12-18 19:26:57 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d3 H:\\array\\
|
2013-12-18 19:26:57 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-17 22:06:20 +01:00
|
|
|
pool C:\\pool
|
2013-12-18 19:26:57 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-17 22:06:20 +01:00
|
|
|
share \\\\darkstar
|
2013-12-18 19:26:57 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
and share the following directories over the network:
|
2013-12-18 19:26:57 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2014-03-17 22:06:20 +01:00
|
|
|
\\\\darkstar\\pool \-> C:\\pool
|
2014-01-08 17:13:20 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-17 22:06:20 +01:00
|
|
|
\\\\darkstar\\d1 \-> F:\\array
|
2014-01-08 17:13:20 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-17 22:06:20 +01:00
|
|
|
\\\\darkstar\\d2 \-> G:\\array
|
2014-01-08 17:13:20 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-17 22:06:20 +01:00
|
|
|
\\\\darkstar\\d3 \-> H:\\array
|
2014-01-08 17:13:20 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
2013-12-18 19:26:57 +01:00
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
to allow remote clients to access all the files at \\\\darkstar\\pool.
|
2013-12-18 19:26:57 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You may also need to configure remote clients to enable access to remote
|
2015-08-16 17:29:41 +02:00
|
|
|
symlinks with the command:
|
2013-12-18 19:26:57 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
2014-12-30 18:30:11 +01:00
|
|
|
.SS Undeleting
|
2025-10-06 15:43:51 +02:00
|
|
|
SnapRAID functions more like a backup program than a RAID system, and it
|
2014-12-30 18:30:11 +01:00
|
|
|
can be used to restore or undelete files to their previous state using
|
2025-10-02 18:36:40 +02:00
|
|
|
the \-f, \-\-filter option:
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
snapraid fix \-f FILE
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
or for a directory:
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
snapraid fix \-f DIR/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
You can also use it to recover only accidentally deleted files inside
|
2025-10-02 18:36:40 +02:00
|
|
|
a directory using the \-m, \-\-filter\-missing option, which restores
|
|
|
|
|
only missing files, leaving all others untouched.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
snapraid fix \-m \-f DIR/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Or to recover all the deleted files on all drives with:
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
snapraid fix \-m
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.SS Recovering
|
2025-10-02 18:36:40 +02:00
|
|
|
The worst has happened, and you have lost one or more disks!
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2016-12-28 09:39:06 +01:00
|
|
|
DO NOT PANIC! You will be able to recover them!
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The first thing you must do is avoid further changes to your disk array.
|
|
|
|
|
Disable any remote connections to it and any scheduled processes, including
|
|
|
|
|
any scheduled SnapRAID nightly sync or scrub.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
|
|
|
|
Then proceed with the following steps.
|
|
|
|
|
.SS STEP 1 \-> Reconfigure
|
2025-10-02 18:36:40 +02:00
|
|
|
You need some space to recover, ideally on additional
|
2025-10-06 15:43:51 +02:00
|
|
|
spare disks, but an external USB disk or remote disk will suffice.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Modify the SnapRAID configuration file to make the \[dq]data\[dq] or \[dq]parity\[dq]
|
|
|
|
|
option of the failed disk point to a location with enough empty
|
2014-12-30 18:30:11 +01:00
|
|
|
space to recover the files.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
For example, if disk \[dq]d1\[dq] has failed, change from:
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2016-01-10 21:19:20 +01:00
|
|
|
data d1 /mnt/disk1/
|
2014-12-30 18:30:11 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
to:
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2016-01-10 21:19:20 +01:00
|
|
|
data d1 /mnt/new_spare_disk/
|
2014-12-30 18:30:11 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
2016-12-28 09:39:06 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If the disk to recover is a parity disk, update the appropriate \[dq]parity\[dq]
|
2016-12-28 09:39:06 +01:00
|
|
|
option.
|
2025-10-02 18:36:40 +02:00
|
|
|
If you have multiple failed disks, update all their configuration options.
|
2014-12-30 18:30:11 +01:00
|
|
|
.SS STEP 2 \-> Fix
|
|
|
|
|
Run the fix command, storing the log in an external file with:
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
snapraid \-d NAME \-l fix.log fix
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Where NAME is the name of the disk, such as \[dq]d1\[dq] in our previous example.
|
|
|
|
|
If the disk to recover is a parity disk, use the names \[dq]parity\[dq], \[dq]2\-parity\[dq],
|
|
|
|
|
etc.
|
|
|
|
|
If you have multiple failed disks, use multiple \-d options to specify all
|
2016-12-28 09:39:06 +01:00
|
|
|
of them.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
|
|
|
|
This command will take a long time.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Ensure you have a few gigabytes free to store the fix.log file.
|
|
|
|
|
Run it from a disk with sufficient free space.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Now you have recovered all that is recoverable. If some files are partially
|
|
|
|
|
or totally unrecoverable, they will be renamed by adding the \[dq].unrecoverable\[dq]
|
|
|
|
|
extension.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You can find a detailed list of all unrecoverable blocks in the fix.log file
|
|
|
|
|
by checking all lines starting with \[dq]unrecoverable:\[dq].
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If you are not satisfied with the recovery, you can retry it as many
|
|
|
|
|
times as you wish.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
|
|
|
|
For example, if you have removed files from the array after the last
|
2025-10-02 18:36:40 +02:00
|
|
|
\[dq]sync\[dq], this may result in some files not being recovered.
|
2014-12-30 18:30:11 +01:00
|
|
|
In this case, you can retry the \[dq]fix\[dq] using the \-i, \-\-import option,
|
2025-10-02 18:36:40 +02:00
|
|
|
specifying where these files are now to include them again in the
|
|
|
|
|
recovery process.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If you are satisfied with the recovery, you can proceed further,
|
|
|
|
|
but note that after syncing, you cannot retry the \[dq]fix\[dq] command
|
2014-12-30 18:30:11 +01:00
|
|
|
anymore!
|
|
|
|
|
.SS STEP 3 \-> Check
|
2025-10-02 18:36:40 +02:00
|
|
|
As a cautious check, you can now run a \[dq]check\[dq] command to ensure that
|
|
|
|
|
everything is correct on the recovered disk.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
snapraid \-d NAME \-a check
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Where NAME is the name of the disk, such as \[dq]d1\[dq] in our previous example.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The \-d and \-a options tell SnapRAID to check only the specified disk
|
|
|
|
|
and ignore all parity data.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This command will take a long time, but if you are not overly cautious,
|
2014-12-30 18:30:11 +01:00
|
|
|
you can skip it.
|
|
|
|
|
.SS STEP 4 \-> Sync
|
2025-10-02 18:36:40 +02:00
|
|
|
Run the \[dq]sync\[dq] command to resynchronize the array with the new disk.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
snapraid sync
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
If everything is recovered, this command is immediate.
|
2011-03-22 23:22:18 +01:00
|
|
|
.SH COMMANDS
|
2025-10-02 18:36:40 +02:00
|
|
|
SnapRAID provides a few simple commands that allow you to:
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.IP \(bu
|
2025-10-02 18:36:40 +02:00
|
|
|
Print the status of the array \-> \[dq]status\[dq]
|
2015-01-30 22:32:22 +01:00
|
|
|
.IP \(bu
|
2025-10-02 18:36:40 +02:00
|
|
|
Control the disks \-> \[dq]smart\[dq], \[dq]probe\[dq], \[dq]up\[dq], \[dq]down\[dq]
|
2013-08-20 12:23:46 +02:00
|
|
|
.IP \(bu
|
2025-10-02 18:36:40 +02:00
|
|
|
Make a backup/snapshot \-> \[dq]sync\[dq]
|
2013-12-16 17:08:58 +01:00
|
|
|
.IP \(bu
|
2025-10-02 18:36:40 +02:00
|
|
|
Periodically check data \-> \[dq]scrub\[dq]
|
2011-03-22 23:22:18 +01:00
|
|
|
.IP \(bu
|
2014-03-17 22:06:20 +01:00
|
|
|
Restore the last backup/snapshot \-> \[dq]fix\[dq].
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD
|
2011-06-20 20:35:04 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Commands must be written in lowercase.
|
2013-12-16 17:08:58 +01:00
|
|
|
.SS status
|
|
|
|
|
Prints a summary of the state of the disk array.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
It includes information about parity fragmentation, how old
|
|
|
|
|
the blocks are without checking, and all recorded silent
|
2013-12-16 17:08:58 +01:00
|
|
|
errors encountered while scrubbing.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The information presented refers to the latest time you
|
|
|
|
|
ran \[dq]sync\[dq]. Later modifications are not taken into account.
|
2014-11-09 22:24:20 +01:00
|
|
|
.PP
|
2015-07-19 08:21:21 +02:00
|
|
|
If bad blocks were detected, their block numbers are listed.
|
|
|
|
|
To fix them, you can use the \[dq]fix \-e\[dq] command.
|
|
|
|
|
.PP
|
2020-05-02 14:21:40 +02:00
|
|
|
It also shows a graph representing the last time each block
|
2015-11-10 21:27:56 +01:00
|
|
|
was scrubbed or synced. Scrubbed blocks are shown with \'*\',
|
|
|
|
|
blocks synced but not yet scrubbed with \'o\'.
|
|
|
|
|
.PP
|
2013-12-16 17:08:58 +01:00
|
|
|
Nothing is modified.
|
2015-01-30 22:32:22 +01:00
|
|
|
.SS smart
|
2025-09-23 22:38:13 +02:00
|
|
|
Prints a SMART report of all the disks in the system.
|
2015-01-30 22:32:22 +01:00
|
|
|
.PP
|
|
|
|
|
It includes an estimation of the probability of failure in the next
|
2025-10-02 18:36:40 +02:00
|
|
|
year, allowing you to plan maintenance replacements of disks that show
|
2015-04-12 21:25:16 +02:00
|
|
|
suspicious attributes.
|
2015-01-30 22:32:22 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This probability estimation is obtained by correlating the SMART attributes
|
|
|
|
|
of the disks with the Backblaze data available at:
|
2015-04-12 21:25:16 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
https://www.backblaze.com/hard\-drive\-test\-data.html
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
If SMART reports that a disk is failing, \[dq]FAIL\[dq] or \[dq]PREFAIL\[dq] is printed
|
|
|
|
|
for that disk, and SnapRAID returns with an error.
|
2025-10-02 18:36:40 +02:00
|
|
|
In this case, immediate replacement of the disk is highly recommended.
|
2015-01-30 22:32:22 +01:00
|
|
|
.PP
|
2025-10-06 15:43:51 +02:00
|
|
|
Other possible status strings are:
|
2015-04-12 21:25:16 +02:00
|
|
|
.RS 4
|
|
|
|
|
.PD 0
|
|
|
|
|
.HP 4
|
|
|
|
|
.I logfail
|
2025-10-02 18:36:40 +02:00
|
|
|
In the past, some attributes were lower than
|
2015-04-12 21:25:16 +02:00
|
|
|
the threshold.
|
|
|
|
|
.HP 4
|
|
|
|
|
.I logerr
|
|
|
|
|
The device error log contains errors.
|
|
|
|
|
.HP 4
|
|
|
|
|
.I selferr
|
|
|
|
|
The device self\-test log contains errors.
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If the \-v, \-\-verbose option is specified, a deeper statistical analysis
|
|
|
|
|
is provided. This analysis can help you decide if you need more
|
2015-01-30 22:32:22 +01:00
|
|
|
or less parity.
|
|
|
|
|
.PP
|
2025-09-23 22:38:13 +02:00
|
|
|
This command uses the \[dq]smartctl\[dq] tool and is equivalent to running
|
|
|
|
|
\[dq]smartctl \-a\[dq] on all devices.
|
2015-01-30 22:32:22 +01:00
|
|
|
.PP
|
2025-09-23 22:38:13 +02:00
|
|
|
If your devices are not auto\-detected correctly, you can specify
|
|
|
|
|
a custom command using the \[dq]smartctl\[dq] option in the configuration
|
|
|
|
|
file.
|
|
|
|
|
.PP
|
|
|
|
|
Nothing is modified.
|
|
|
|
|
.SS probe
|
|
|
|
|
Prints the POWER state of all disks in the system.
|
|
|
|
|
.PP
|
|
|
|
|
\[dq]Standby\[dq] means the disk is not spinning. \[dq]Active\[dq] means
|
|
|
|
|
the disk is spinning.
|
|
|
|
|
.PP
|
|
|
|
|
This command uses the \[dq]smartctl\[dq] tool and is equivalent to running
|
|
|
|
|
\[dq]smartctl \-n standby \-i\[dq] on all devices.
|
|
|
|
|
.PP
|
|
|
|
|
If your devices are not auto\-detected correctly, you can specify
|
2015-04-08 22:56:44 +02:00
|
|
|
a custom command using the \[dq]smartctl\[dq] option in the configuration
|
|
|
|
|
file.
|
|
|
|
|
.PP
|
2015-01-30 22:32:22 +01:00
|
|
|
Nothing is modified.
|
|
|
|
|
.SS up
|
|
|
|
|
Spins up all the disks of the array.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You can spin up only specific disks using the \-d, \-\-filter\-disk option.
|
2016-01-23 15:31:30 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Spinning up all the disks at the same time requires a lot of power.
|
|
|
|
|
Ensure that your power supply can sustain it.
|
2017-03-26 10:50:21 +02:00
|
|
|
.PP
|
2015-01-30 22:32:22 +01:00
|
|
|
Nothing is modified.
|
|
|
|
|
.SS down
|
|
|
|
|
Spins down all the disks of the array.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This command uses the \[dq]smartctl\[dq] tool and is equivalent to running
|
|
|
|
|
\[dq]smartctl \-s standby,now\[dq] on all devices.
|
2015-01-30 22:32:22 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You can spin down only specific disks using the \-d, \-\-filter\-disk
|
2025-09-26 09:49:20 +02:00
|
|
|
option.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
To automatically spin down on error, you can use the \-s, \-\-spin\-down\-on\-error
|
|
|
|
|
option with any other command, which is equivalent to running \[dq]down\[dq] manually
|
|
|
|
|
when an error occurs.
|
2016-01-23 15:31:30 +01:00
|
|
|
.PP
|
2015-01-30 22:32:22 +01:00
|
|
|
Nothing is modified.
|
2015-01-02 15:53:15 +01:00
|
|
|
.SS diff
|
2025-10-02 18:36:40 +02:00
|
|
|
Lists all the files modified since the last \[dq]sync\[dq] that need to have
|
2015-01-02 15:53:15 +01:00
|
|
|
their parity data recomputed.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This command doesn\'t check the file data, but only the file timestamp,
|
|
|
|
|
size, and inode.
|
2015-01-02 15:53:15 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
After listing all changed files, a summary of the changes is
|
|
|
|
|
presented, grouped by:
|
2016-02-14 10:37:44 +01:00
|
|
|
.RS 4
|
|
|
|
|
.PD 0
|
|
|
|
|
.HP 4
|
|
|
|
|
.I equal
|
2025-10-02 18:36:40 +02:00
|
|
|
Files unchanged from before.
|
2016-02-14 10:37:44 +01:00
|
|
|
.HP 4
|
|
|
|
|
.I added
|
|
|
|
|
Files added that were not present before.
|
|
|
|
|
.HP 4
|
|
|
|
|
.I removed
|
|
|
|
|
Files removed.
|
|
|
|
|
.HP 4
|
|
|
|
|
.I updated
|
2025-10-02 18:36:40 +02:00
|
|
|
Files with a different size or timestamp, meaning they
|
|
|
|
|
were modified.
|
2016-02-14 10:37:44 +01:00
|
|
|
.HP 4
|
|
|
|
|
.I moved
|
2025-10-02 18:36:40 +02:00
|
|
|
Files moved to a different directory on the same disk.
|
|
|
|
|
They are identified by having the same name, size, timestamp,
|
|
|
|
|
and inode, but a different directory.
|
2016-02-14 10:37:44 +01:00
|
|
|
.HP 4
|
|
|
|
|
.I copied
|
2025-10-02 18:36:40 +02:00
|
|
|
Files copied on the same or a different disk. Note that if
|
|
|
|
|
they are truly moved to a different disk, they will also be
|
|
|
|
|
counted in \[dq]removed\[dq].
|
2016-02-14 10:37:44 +01:00
|
|
|
They are identified by having the same name, size, and
|
2025-10-02 18:36:40 +02:00
|
|
|
timestamp. If the sub\-second timestamp is zero,
|
|
|
|
|
the full path must match, not just the name.
|
2016-02-14 10:37:44 +01:00
|
|
|
.HP 4
|
|
|
|
|
.I restored
|
2025-10-02 18:36:40 +02:00
|
|
|
Files with a different inode but matching name, size, and timestamp.
|
|
|
|
|
These are usually files restored after being deleted.
|
2016-02-14 10:37:44 +01:00
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2015-04-28 19:15:16 +02:00
|
|
|
If a \[dq]sync\[dq] is required, the process return code is 2, instead of the
|
2025-10-02 18:36:40 +02:00
|
|
|
default 0. The return code 1 is used for a generic error condition.
|
2015-03-02 23:01:15 +01:00
|
|
|
.PP
|
2015-01-02 15:53:15 +01:00
|
|
|
Nothing is modified.
|
2011-09-03 11:17:25 +02:00
|
|
|
.SS sync
|
2025-10-02 18:36:40 +02:00
|
|
|
Updates the parity information. All modified files
|
2014-12-30 18:30:11 +01:00
|
|
|
in the disk array are read, and the corresponding parity
|
|
|
|
|
data is updated.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You can stop this process at any time by pressing Ctrl+C,
|
2011-03-22 23:22:18 +01:00
|
|
|
without losing the work already done.
|
2025-10-02 18:36:40 +02:00
|
|
|
At the next run, the \[dq]sync\[dq] process will resume where
|
|
|
|
|
it was interrupted.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If silent or input/output errors are found during the process,
|
2014-12-30 18:30:11 +01:00
|
|
|
the corresponding blocks are marked as bad.
|
|
|
|
|
.PP
|
|
|
|
|
Files are identified by path and/or inode and checked by
|
2025-10-02 18:36:40 +02:00
|
|
|
size and timestamp.
|
|
|
|
|
If the file size or timestamp differs, the parity data
|
|
|
|
|
is recomputed for the entire file.
|
|
|
|
|
If the file is moved or renamed on the same disk, keeping the
|
2015-11-08 18:22:30 +01:00
|
|
|
same inode, the parity is not recomputed.
|
2014-12-30 18:30:11 +01:00
|
|
|
If the file is moved to another disk, the parity is recomputed,
|
2025-10-02 18:36:40 +02:00
|
|
|
but the previously computed hash information is retained.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2014-03-17 22:06:20 +01:00
|
|
|
The \[dq]content\[dq] and \[dq]parity\[dq] files are modified if necessary.
|
2011-03-29 18:57:13 +02:00
|
|
|
The files in the array are NOT modified.
|
2013-06-29 17:53:40 +02:00
|
|
|
.SS scrub
|
2014-12-30 18:30:11 +01:00
|
|
|
Scrubs the array, checking for silent or input/output errors in data
|
|
|
|
|
and parity disks.
|
2013-02-22 22:17:54 +01:00
|
|
|
.PP
|
2025-10-06 15:43:51 +02:00
|
|
|
Each invocation checks approximately 8% of the array, excluding
|
2025-10-02 18:36:40 +02:00
|
|
|
data already scrubbed in the last 10 days.
|
|
|
|
|
This means that scrubbing once a week ensures every bit of data is checked
|
|
|
|
|
at least once every three months.
|
2013-06-29 17:53:40 +02:00
|
|
|
.PP
|
2015-11-10 19:37:23 +01:00
|
|
|
You can define a different scrub plan or amount using the \-p, \-\-plan
|
2025-10-02 18:36:40 +02:00
|
|
|
option, which accepts:
|
2015-09-13 15:48:05 +02:00
|
|
|
bad \- Scrub blocks marked bad.
|
2025-10-02 18:36:40 +02:00
|
|
|
new \- Scrub just\-synced blocks not yet scrubbed.
|
2015-09-13 15:48:05 +02:00
|
|
|
full \- Scrub everything.
|
2025-10-02 18:36:40 +02:00
|
|
|
0\-100 \- Scrub the specified percentage of blocks.
|
2015-08-30 16:53:23 +02:00
|
|
|
.PP
|
2015-09-13 15:48:05 +02:00
|
|
|
If you specify a percentage amount, you can also use the \-o, \-\-older\-than
|
|
|
|
|
option to define how old the block should be.
|
2025-10-02 18:36:40 +02:00
|
|
|
The oldest blocks are scrubbed first, ensuring an optimal check.
|
|
|
|
|
If you want to scrub only the just\-synced blocks not yet scrubbed,
|
|
|
|
|
use the \[dq]\-p new\[dq] option.
|
2015-08-30 16:53:23 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
To get details of the scrub status, use the \[dq]status\[dq] command.
|
2014-12-30 18:30:11 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
For any silent or input/output error found, the corresponding blocks
|
2014-12-30 18:30:11 +01:00
|
|
|
are marked as bad in the \[dq]content\[dq] file.
|
2025-10-02 18:36:40 +02:00
|
|
|
These bad blocks are listed in \[dq]status\[dq] and can be fixed with \[dq]fix \-e\[dq].
|
|
|
|
|
After the fix, at the next scrub, they will be rechecked, and if found
|
2014-12-30 18:30:11 +01:00
|
|
|
corrected, the bad mark will be removed.
|
2015-09-13 15:48:05 +02:00
|
|
|
To scrub only the bad blocks, you can use the \[dq]scrub \-p bad\[dq] command.
|
2013-08-22 23:03:13 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
It\'s recommended to run \[dq]scrub\[dq] only on a synced array to avoid
|
|
|
|
|
reported errors caused by unsynced data. These errors are recognized
|
2013-08-22 23:03:13 +02:00
|
|
|
as not being silent errors, and the blocks are not marked as bad,
|
2013-11-29 23:06:09 +01:00
|
|
|
but such errors are reported in the output of the command.
|
2013-08-22 23:03:13 +02:00
|
|
|
.PP
|
2014-03-17 22:06:20 +01:00
|
|
|
The \[dq]content\[dq] file is modified to update the time of the last check
|
2025-10-02 18:36:40 +02:00
|
|
|
for each block and to mark bad blocks.
|
2014-03-17 22:06:20 +01:00
|
|
|
The \[dq]parity\[dq] files are NOT modified.
|
2013-10-13 12:13:34 +02:00
|
|
|
The files in the array are NOT modified.
|
2013-12-16 17:08:58 +01:00
|
|
|
.SS fix
|
2025-10-02 18:36:40 +02:00
|
|
|
Fixes all the files and the parity data.
|
2013-08-20 12:23:46 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
All files and parity data are compared with the snapshot
|
2014-12-30 18:30:11 +01:00
|
|
|
state saved in the last \[dq]sync\[dq].
|
2025-10-02 18:36:40 +02:00
|
|
|
If a difference is found, it is reverted to the stored snapshot.
|
2013-12-16 17:08:58 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
WARNING! The \[dq]fix\[dq] command does not differentiate between errors and
|
2015-11-08 18:22:30 +01:00
|
|
|
intentional modifications. It unconditionally reverts the file state
|
2025-10-02 18:36:40 +02:00
|
|
|
to the last \[dq]sync\[dq].
|
2013-12-16 17:08:58 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If no other option is specified, the entire array is processed.
|
2014-12-30 18:30:11 +01:00
|
|
|
Use the filter options to select a subset of files or disks to operate on.
|
2014-03-28 21:30:41 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
To fix only the blocks marked bad during \[dq]sync\[dq] and \[dq]scrub\[dq],
|
2014-12-30 18:30:11 +01:00
|
|
|
use the \-e, \-\-filter\-error option.
|
2025-10-02 18:36:40 +02:00
|
|
|
Unlike other filter options, this one applies fixes only to files that are
|
|
|
|
|
unchanged since the latest \[dq]sync\[dq].
|
2013-12-16 17:08:58 +01:00
|
|
|
.PP
|
2025-10-06 15:43:51 +02:00
|
|
|
SnapRAID renames all files that cannot be fixed by adding the
|
2015-11-08 18:22:30 +01:00
|
|
|
\[dq].unrecoverable\[dq] extension.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Before fixing, the entire array is scanned to find any files moved
|
|
|
|
|
since the last \[dq]sync\[dq] operation.
|
|
|
|
|
These files are identified by their timestamp, ignoring their name
|
|
|
|
|
and directory, and are used in the recovery process if necessary.
|
2015-11-08 18:22:30 +01:00
|
|
|
If you moved some of them outside the array, you can use the \-i, \-\-import
|
|
|
|
|
option to specify additional directories to scan.
|
2013-12-16 17:08:58 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Files are identified only by path, not by inode.
|
2013-12-16 17:08:58 +01:00
|
|
|
.PP
|
2014-03-17 22:06:20 +01:00
|
|
|
The \[dq]content\[dq] file is NOT modified.
|
|
|
|
|
The \[dq]parity\[dq] files are modified if necessary.
|
2013-12-16 17:08:58 +01:00
|
|
|
The files in the array are modified if necessary.
|
|
|
|
|
.SS check
|
2025-10-02 18:36:40 +02:00
|
|
|
Verifies all the files and the parity data.
|
2013-12-16 17:08:58 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
It works like \[dq]fix\[dq], but it only simulates a recovery and no changes
|
|
|
|
|
are written to the array.
|
2013-12-16 17:08:58 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This command is primarily intended for manual verification,
|
|
|
|
|
such as after a recovery process or in other special conditions.
|
|
|
|
|
For periodic and scheduled checks, use \[dq]scrub\[dq].
|
2013-12-16 17:08:58 +01:00
|
|
|
.PP
|
|
|
|
|
If you use the \-a, \-\-audit\-only option, only the file
|
|
|
|
|
data is checked, and the parity data is ignored for a
|
|
|
|
|
faster run.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Files are identified only by path, not by inode.
|
2013-08-20 12:23:46 +02:00
|
|
|
.PP
|
|
|
|
|
Nothing is modified.
|
2013-10-19 13:24:35 +02:00
|
|
|
.SS list
|
|
|
|
|
Lists all the files contained in the array at the time of the
|
2014-12-30 18:30:11 +01:00
|
|
|
last \[dq]sync\[dq].
|
2013-10-19 13:24:35 +02:00
|
|
|
.PP
|
|
|
|
|
Nothing is modified.
|
2011-12-08 20:37:27 +01:00
|
|
|
.SS dup
|
2025-10-02 18:36:40 +02:00
|
|
|
Lists all duplicate files. Two files are assumed equal if their
|
|
|
|
|
hashes match. The file data is not read; only the
|
|
|
|
|
precomputed hashes are used.
|
2011-12-08 20:37:27 +01:00
|
|
|
.PP
|
|
|
|
|
Nothing is modified.
|
2013-08-20 12:23:46 +02:00
|
|
|
.SS pool
|
2025-10-02 18:36:40 +02:00
|
|
|
Creates or updates a virtual view of all
|
|
|
|
|
the files in your disk array in the \[dq]pooling\[dq] directory.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The files are not copied but linked using
|
2013-08-20 12:23:46 +02:00
|
|
|
symbolic links.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
When updating, all existing symbolic links and empty
|
|
|
|
|
subdirectories are deleted and replaced with the new
|
|
|
|
|
view of the array. Any other regular files are left in place.
|
2011-10-10 20:42:52 +02:00
|
|
|
.PP
|
2013-08-20 12:23:46 +02:00
|
|
|
Nothing is modified outside the pool directory.
|
2015-04-06 17:11:27 +02:00
|
|
|
.SS devices
|
2025-10-02 18:36:40 +02:00
|
|
|
Prints the low\-level devices used by the array.
|
2015-04-06 17:11:27 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This command displays the device associations in the array
|
|
|
|
|
and is mainly intended as a script interface.
|
2015-04-06 17:11:27 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The first two columns are the low\-level device ID and path.
|
|
|
|
|
The next two columns are the high\-level device ID and path.
|
|
|
|
|
The last column is the disk name in the array.
|
2015-04-06 17:11:27 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
In most cases, you have one low\-level device for each disk in the
|
2015-04-21 21:13:59 +02:00
|
|
|
array, but in some more complex configurations, you may have multiple
|
2025-10-02 18:36:40 +02:00
|
|
|
low\-level devices used by a single disk in the array.
|
2015-04-06 17:11:27 +02:00
|
|
|
.PP
|
|
|
|
|
Nothing is modified.
|
2016-01-18 19:38:42 +01:00
|
|
|
.SS touch
|
2025-10-02 18:36:40 +02:00
|
|
|
Sets an arbitrary sub\-second timestamp for all files
|
|
|
|
|
that have it set to zero.
|
2016-01-11 22:15:57 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This improves SnapRAID\'s ability to recognize moved
|
|
|
|
|
and copied files, as it makes the timestamp almost unique,
|
2025-10-06 15:43:51 +02:00
|
|
|
reducing possible duplicates.
|
2016-01-11 22:15:57 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
More specifically, if the sub\-second timestamp is not zero,
|
2016-01-11 22:15:57 +01:00
|
|
|
a moved or copied file is identified as such if it matches
|
2025-10-02 18:36:40 +02:00
|
|
|
the name, size, and timestamp. If the sub\-second timestamp
|
2025-10-06 15:43:51 +02:00
|
|
|
is zero, it is considered a copy only if the full path,
|
|
|
|
|
size, and timestamp all match.
|
2016-01-11 22:15:57 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The second\-precision timestamp is not modified,
|
2025-10-06 15:43:51 +02:00
|
|
|
so all the dates and times of your files will be preserved.
|
2013-07-01 23:08:25 +02:00
|
|
|
.SS rehash
|
2025-10-02 18:36:40 +02:00
|
|
|
Schedules a rehash of the entire array.
|
2013-07-01 23:08:25 +02:00
|
|
|
.PP
|
2015-04-06 17:11:27 +02:00
|
|
|
This command changes the hash kind used, typically when upgrading
|
2025-10-02 18:36:40 +02:00
|
|
|
from a 32\-bit system to a 64\-bit one, to switch from
|
2015-04-06 17:11:27 +02:00
|
|
|
MurmurHash3 to the faster SpookyHash.
|
2013-09-11 21:46:22 +02:00
|
|
|
.PP
|
|
|
|
|
If you are already using the optimal hash, this command
|
2025-10-02 18:36:40 +02:00
|
|
|
does nothing and informs you that no action is needed.
|
2013-07-01 23:08:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The rehash is not performed immediately but takes place
|
2014-12-30 18:30:11 +01:00
|
|
|
progressively during \[dq]sync\[dq] and \[dq]scrub\[dq].
|
2013-07-01 23:08:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You can check the rehash state using \[dq]status\[dq].
|
2013-07-01 23:08:25 +02:00
|
|
|
.PP
|
|
|
|
|
During the rehash, SnapRAID maintains full functionality,
|
2025-10-02 18:36:40 +02:00
|
|
|
with the only exception that \[dq]dup\[dq] cannot detect duplicated
|
2014-12-30 18:30:11 +01:00
|
|
|
files using a different hash.
|
2011-03-22 23:22:18 +01:00
|
|
|
.SH OPTIONS
|
2011-06-26 20:40:35 +02:00
|
|
|
SnapRAID provides the following options:
|
2011-03-22 23:22:18 +01:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-c, \-\-conf CONFIG
|
2025-10-02 18:36:40 +02:00
|
|
|
Selects the configuration file to use. If not specified, in Unix
|
|
|
|
|
it uses the file \[dq]/usr/local/etc/snapraid.conf\[dq] if it exists,
|
|
|
|
|
otherwise \[dq]/etc/snapraid.conf\[dq].
|
|
|
|
|
In Windows, it uses the file \[dq]snapraid.conf\[dq] in the same
|
|
|
|
|
directory as \[dq]snapraid.exe\[dq].
|
2011-03-22 23:22:18 +01:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-f, \-\-filter PATTERN
|
2014-12-30 18:30:11 +01:00
|
|
|
Filters the files to process in \[dq]check\[dq] and \[dq]fix\[dq].
|
2025-10-02 18:36:40 +02:00
|
|
|
Only the files matching the specified pattern are processed.
|
|
|
|
|
This option can be used multiple times.
|
|
|
|
|
See the PATTERN section for more details on
|
2011-03-30 00:14:43 +02:00
|
|
|
pattern specifications.
|
2025-10-02 18:36:40 +02:00
|
|
|
In Unix, ensure globbing characters are quoted if used.
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]check\[dq] and \[dq]fix\[dq].
|
2025-10-02 18:36:40 +02:00
|
|
|
It cannot be used with \[dq]sync\[dq] and \[dq]scrub\[dq], as they always
|
|
|
|
|
process the entire array.
|
2011-03-30 00:14:43 +02:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-d, \-\-filter\-disk NAME
|
2025-10-02 18:36:40 +02:00
|
|
|
Filters the disks to process in \[dq]check\[dq], \[dq]fix\[dq], \[dq]up\[dq], and \[dq]down\[dq].
|
|
|
|
|
You must specify a disk name as defined in the configuration
|
2012-10-10 23:32:09 +02:00
|
|
|
file.
|
2015-10-17 17:36:40 +02:00
|
|
|
You can also specify parity disks with the names: \[dq]parity\[dq], \[dq]2\-parity\[dq],
|
2025-10-02 18:36:40 +02:00
|
|
|
\[dq]3\-parity\[dq], etc., to limit operations to a specific parity disk.
|
|
|
|
|
If you combine multiple \-\-filter, \-\-filter\-disk, and \-\-filter\-missing options,
|
|
|
|
|
only files matching all the filters are selected.
|
|
|
|
|
This option can be used multiple times.
|
|
|
|
|
This option can be used only with \[dq]check\[dq], \[dq]fix\[dq], \[dq]up\[dq], and \[dq]down\[dq].
|
|
|
|
|
It cannot be used with \[dq]sync\[dq] and \[dq]scrub\[dq], as they always
|
|
|
|
|
process the entire array.
|
2013-02-24 11:33:09 +01:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-m, \-\-filter\-missing
|
2014-12-30 18:30:11 +01:00
|
|
|
Filters the files to process in \[dq]check\[dq] and \[dq]fix\[dq].
|
2025-10-02 18:36:40 +02:00
|
|
|
Only the files missing or deleted from the array are processed.
|
|
|
|
|
When used with \[dq]fix\[dq], this acts as an \[dq]undelete\[dq] command.
|
|
|
|
|
If you combine multiple \-\-filter, \-\-filter\-disk, and \-\-filter\-missing options,
|
|
|
|
|
only files matching all the filters are selected.
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]check\[dq] and \[dq]fix\[dq].
|
2025-10-02 18:36:40 +02:00
|
|
|
It cannot be used with \[dq]sync\[dq] and \[dq]scrub\[dq], as they always
|
|
|
|
|
process the entire array.
|
2012-10-10 23:32:09 +02:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-e, \-\-filter\-error
|
2025-10-02 18:36:40 +02:00
|
|
|
Processes the files with errors in \[dq]check\[dq] and \[dq]fix\[dq].
|
2021-05-22 22:17:42 +02:00
|
|
|
It processes only files that have blocks marked with silent
|
2025-10-02 18:36:40 +02:00
|
|
|
or input/output errors during \[dq]sync\[dq] and \[dq]scrub\[dq], as listed in \[dq]status\[dq].
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]check\[dq] and \[dq]fix\[dq].
|
2013-08-18 19:35:40 +02:00
|
|
|
.TP
|
2015-11-10 19:37:23 +01:00
|
|
|
.B \-p, \-\-plan PERC|bad|new|full
|
2015-11-09 23:21:39 +01:00
|
|
|
Selects the scrub plan. If PERC is a numeric value from 0 to 100,
|
2025-10-02 18:36:40 +02:00
|
|
|
it is interpreted as the percentage of blocks to scrub.
|
|
|
|
|
Instead of a percentage, you can specify a plan:
|
|
|
|
|
\[dq]bad\[dq] scrubs bad blocks, \[dq]new\[dq] scrubs blocks not yet scrubbed,
|
|
|
|
|
and \[dq]full\[dq] scrubs everything.
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]scrub\[dq].
|
2013-08-22 23:03:13 +02:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-o, \-\-older\-than DAYS
|
2025-10-02 18:36:40 +02:00
|
|
|
Selects the oldest part of the array to process in \[dq]scrub\[dq].
|
|
|
|
|
DAYS is the minimum age in days for a block to be scrubbed;
|
|
|
|
|
the default is 10.
|
|
|
|
|
Blocks marked as bad are always scrubbed regardless of this option.
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]scrub\[dq].
|
2013-08-22 23:03:13 +02:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-a, \-\-audit\-only
|
2025-10-02 18:36:40 +02:00
|
|
|
In \[dq]check\[dq], verifies the hash of the files without
|
|
|
|
|
checking the parity data.
|
|
|
|
|
If you are interested only in checking the file data, this
|
|
|
|
|
option can significantly speed up the checking process.
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]check\[dq].
|
2012-10-07 23:18:10 +02:00
|
|
|
.TP
|
2014-02-12 22:04:14 +01:00
|
|
|
.B \-h, \-\-pre\-hash
|
2025-10-02 18:36:40 +02:00
|
|
|
In \[dq]sync\[dq], runs a preliminary hashing phase of all new data
|
|
|
|
|
for additional verification before the parity computation.
|
|
|
|
|
Usually, in \[dq]sync\[dq], no preliminary hashing is done, and the new
|
|
|
|
|
data is hashed just before the parity computation when it is read
|
2015-09-29 22:31:13 +02:00
|
|
|
for the first time.
|
2025-10-02 18:36:40 +02:00
|
|
|
This process occurs when the system is under
|
|
|
|
|
heavy load, with all disks spinning and a busy CPU.
|
2015-09-29 22:31:13 +02:00
|
|
|
This is an extreme condition for the machine, and if it has a
|
2025-10-02 18:36:40 +02:00
|
|
|
latent hardware problem, silent errors may go undetected
|
|
|
|
|
because the data is not yet hashed.
|
|
|
|
|
To avoid this risk, you can enable the \[dq]pre\-hash\[dq] mode to have
|
|
|
|
|
all the data read twice to ensure its integrity.
|
|
|
|
|
This option also verifies files moved within the array
|
|
|
|
|
to ensure the move operation was successful and, if necessary,
|
|
|
|
|
allows you to run a fix operation before proceeding.
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]sync\[dq].
|
2014-02-12 22:04:14 +01:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-i, \-\-import DIR
|
2025-10-02 18:36:40 +02:00
|
|
|
Imports from the specified directory any files deleted
|
2014-12-30 18:30:11 +01:00
|
|
|
from the array after the last \[dq]sync\[dq].
|
2025-10-02 18:36:40 +02:00
|
|
|
If you still have such files, they can be used by \[dq]check\[dq]
|
|
|
|
|
and \[dq]fix\[dq] to improve the recovery process.
|
|
|
|
|
The files are read, including in subdirectories, and are
|
2013-02-27 21:07:16 +01:00
|
|
|
identified regardless of their name.
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]check\[dq] and \[dq]fix\[dq].
|
2013-02-27 21:07:16 +01:00
|
|
|
.TP
|
2025-09-26 09:49:20 +02:00
|
|
|
.B \-s, \-\-spin\-down\-on\-error
|
2025-10-02 18:36:40 +02:00
|
|
|
On any error, spins down all managed disks before exiting with
|
2025-09-26 09:49:20 +02:00
|
|
|
a non\-zero status code. This prevents the drives from
|
|
|
|
|
remaining active and spinning after an aborted operation,
|
2025-10-02 18:36:40 +02:00
|
|
|
helping to avoid unnecessary heat buildup and power
|
2025-09-26 09:49:20 +02:00
|
|
|
consumption. Use this option to ensure disks are safely
|
|
|
|
|
stopped even when a command fails.
|
|
|
|
|
.TP
|
2025-03-27 12:57:41 -07:00
|
|
|
.B \-w, \-\-bw\-limit RATE
|
|
|
|
|
Applies a global bandwidth limit for all disks. The RATE is
|
|
|
|
|
the number of bytes per second. You can specify a multiplier
|
2025-10-02 18:36:40 +02:00
|
|
|
such as K, M, or G (e.g., \-\-bw\-limit 1G).
|
2025-03-27 12:57:41 -07:00
|
|
|
.TP
|
2025-09-29 15:53:43 +02:00
|
|
|
.B \-A, \-\-stats
|
|
|
|
|
Enables an extended status view that shows additional information.
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
The screen displays two graphs:
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
The first graph shows the number of buffered stripes for each
|
|
|
|
|
disk, along with the file path of the file currently being
|
|
|
|
|
accessed on that disk. Typically, the slowest disk will have
|
|
|
|
|
no buffer available, which determines the maximum achievable
|
|
|
|
|
bandwidth.
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
The second graph shows the percentage of time spent waiting
|
|
|
|
|
over the past 100 seconds. The slowest disk is expected to
|
2025-10-02 18:36:40 +02:00
|
|
|
cause most of the wait time, while other disks should have
|
|
|
|
|
little or no wait time because they can use their buffered stripes.
|
2025-09-29 15:53:43 +02:00
|
|
|
This graph also shows the time spent waiting for hash
|
|
|
|
|
calculations and RAID computations.
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
All computations run in parallel with disk operations.
|
|
|
|
|
Therefore, as long as there is measurable wait time for at
|
|
|
|
|
least one disk, it indicates that the CPU is fast enough to
|
|
|
|
|
keep up with the workload.
|
|
|
|
|
.RE
|
|
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-Z, \-\-force\-zero
|
2011-03-22 23:22:18 +01:00
|
|
|
Forces the insecure operation of syncing a file with zero
|
2025-10-02 18:36:40 +02:00
|
|
|
size that was previously non\-zero.
|
|
|
|
|
If SnapRAID detects such a condition, it stops proceeding
|
2011-03-22 23:22:18 +01:00
|
|
|
unless you specify this option.
|
2025-10-02 18:36:40 +02:00
|
|
|
This allows you to easily detect when, after a system crash,
|
2014-09-12 19:00:40 +02:00
|
|
|
some accessed files were truncated.
|
2011-09-03 11:17:25 +02:00
|
|
|
This is a possible condition in Linux with the ext3/ext4
|
2025-10-02 18:36:40 +02:00
|
|
|
file systems.
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]sync\[dq].
|
2011-03-22 23:22:18 +01:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-E, \-\-force\-empty
|
2011-07-05 21:45:24 +02:00
|
|
|
Forces the insecure operation of syncing a disk with all
|
|
|
|
|
the original files missing.
|
|
|
|
|
If SnapRAID detects that all the files originally present
|
2025-10-02 18:36:40 +02:00
|
|
|
on the disk are missing or rewritten, it stops proceeding
|
2011-03-22 23:22:18 +01:00
|
|
|
unless you specify this option.
|
2025-10-02 18:36:40 +02:00
|
|
|
This allows you to easily detect when a data file system is not
|
2011-03-22 23:22:18 +01:00
|
|
|
mounted.
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]sync\[dq].
|
2011-03-22 23:22:18 +01:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-U, \-\-force\-uuid
|
2025-10-02 18:36:40 +02:00
|
|
|
Forces the insecure operation of syncing, checking, and fixing
|
2013-09-11 21:46:22 +02:00
|
|
|
with disks that have changed their UUID.
|
2013-03-04 21:37:26 +01:00
|
|
|
If SnapRAID detects that some disks have changed UUID,
|
2013-03-03 22:39:46 +01:00
|
|
|
it stops proceeding unless you specify this option.
|
2025-10-02 18:36:40 +02:00
|
|
|
This allows you to detect when your disks are mounted at the
|
2013-03-03 22:39:46 +01:00
|
|
|
wrong mount points.
|
2025-10-02 18:36:40 +02:00
|
|
|
It is, however, allowed to have a single UUID change with
|
|
|
|
|
single parity, and more with multiple parity, because this is
|
|
|
|
|
the normal case when replacing disks after a recovery.
|
|
|
|
|
This option can be used only with \[dq]sync\[dq], \[dq]check\[dq], or
|
2014-12-30 18:30:11 +01:00
|
|
|
\[dq]fix\[dq].
|
2013-03-03 22:39:46 +01:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-D, \-\-force\-device
|
2025-10-02 18:36:40 +02:00
|
|
|
Forces the insecure operation of fixing with inaccessible disks
|
2015-10-16 23:17:38 +02:00
|
|
|
or with disks on the same physical device.
|
2025-10-02 18:36:40 +02:00
|
|
|
For example, if you lost two data disks and have a spare disk to recover
|
|
|
|
|
only the first one, you can ignore the second inaccessible disk.
|
|
|
|
|
Or, if you want to recover a disk in the free space left on an
|
2015-10-16 23:17:38 +02:00
|
|
|
already used disk, sharing the same physical device.
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]fix\[dq].
|
2013-09-11 21:46:22 +02:00
|
|
|
.TP
|
2014-05-15 23:45:51 +02:00
|
|
|
.B \-N, \-\-force\-nocopy
|
2025-10-02 18:36:40 +02:00
|
|
|
In \[dq]sync\[dq], \[dq]check\[dq], and \[dq]fix\[dq], disables the copy detection heuristic.
|
|
|
|
|
Without this option, SnapRAID assumes that files with the same
|
|
|
|
|
attributes, such as name, size, and timestamp, are copies with the
|
2014-05-15 23:45:51 +02:00
|
|
|
same data.
|
2025-10-02 18:36:40 +02:00
|
|
|
This allows identification of copied or moved files from one disk
|
|
|
|
|
to another and reuses the already computed hash information
|
2014-10-19 22:25:30 +02:00
|
|
|
to detect silent errors or to recover missing files.
|
2025-10-02 18:36:40 +02:00
|
|
|
In some rare cases, this behavior may result in false positives
|
|
|
|
|
or a slow process due to many hash verifications, and this
|
|
|
|
|
option allows you to resolve such issues.
|
|
|
|
|
This option can be used only with \[dq]sync\[dq], \[dq]check\[dq], and \[dq]fix\[dq].
|
2014-06-15 19:01:07 +02:00
|
|
|
.TP
|
|
|
|
|
.B \-F, \-\-force\-full
|
2025-10-02 18:36:40 +02:00
|
|
|
In \[dq]sync\[dq], forces a full recomputation of the parity.
|
|
|
|
|
This option can be used when you add a new parity level or if
|
|
|
|
|
you reverted to an old content file using more recent parity data.
|
2021-05-02 08:18:39 +02:00
|
|
|
Instead of recreating the parity from scratch, this allows
|
2025-10-02 18:36:40 +02:00
|
|
|
you to reuse the hashes present in the content file to validate data
|
|
|
|
|
and maintain data protection during the \[dq]sync\[dq] process using
|
|
|
|
|
the existing parity data.
|
2016-10-01 22:19:29 +02:00
|
|
|
This option can be used only with \[dq]sync\[dq].
|
|
|
|
|
.TP
|
|
|
|
|
.B \-R, \-\-force\-realloc
|
2025-10-02 18:36:40 +02:00
|
|
|
In \[dq]sync\[dq], forces a full reallocation of files and rebuild of the parity.
|
|
|
|
|
This option can be used to completely reallocate all files,
|
|
|
|
|
removing fragmentation, while reusing the hashes present in the content
|
2016-10-01 22:19:29 +02:00
|
|
|
file to validate data.
|
2014-12-30 18:30:11 +01:00
|
|
|
This option can be used only with \[dq]sync\[dq].
|
2025-10-02 18:36:40 +02:00
|
|
|
WARNING! This option is for experts only, and it is highly
|
|
|
|
|
recommended not to use it.
|
2021-05-02 08:18:39 +02:00
|
|
|
You DO NOT have data protection during the \[dq]sync\[dq] operation.
|
2014-05-15 23:45:51 +02:00
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-l, \-\-log FILE
|
2025-10-02 18:36:40 +02:00
|
|
|
Writes a detailed log to the specified file.
|
2015-06-20 16:48:07 +02:00
|
|
|
If this option is not specified, unexpected errors are printed
|
2025-10-02 18:36:40 +02:00
|
|
|
to the screen, potentially resulting in excessive output in case of
|
|
|
|
|
many errors. When \-l, \-\-log is specified, only
|
|
|
|
|
fatal errors that cause SnapRAID to stop are printed
|
|
|
|
|
to the screen.
|
|
|
|
|
If the path starts with \'>>\', the file is opened
|
2014-04-02 21:48:47 +02:00
|
|
|
in append mode. Occurrences of \'%D\' and \'%T\' in the name are
|
2014-02-16 10:03:02 +01:00
|
|
|
replaced with the date and time in the format YYYYMMDD and
|
2025-10-02 18:36:40 +02:00
|
|
|
HHMMSS. In Windows batch files, you must double
|
|
|
|
|
the \'%\' character, e.g., result\-%%D.log. To use \'>>\', you must
|
|
|
|
|
enclose the name in quotes, e.g., \[dq]>>result.log\[dq].
|
2014-09-12 19:00:40 +02:00
|
|
|
To output the log to standard output or standard error,
|
2025-10-02 18:36:40 +02:00
|
|
|
you can use \[dq]>&1\[dq] and \[dq]>&2\[dq], respectively.
|
2013-07-26 14:50:52 +02:00
|
|
|
.TP
|
2025-10-02 18:36:40 +02:00
|
|
|
.B \-L, \-\-error\-limit NUMBER
|
2014-12-30 10:44:11 +01:00
|
|
|
Sets a new error limit before stopping execution.
|
2025-10-02 18:36:40 +02:00
|
|
|
By default, SnapRAID stops if it encounters more than 100
|
|
|
|
|
input/output errors, indicating that a disk is likely failing.
|
|
|
|
|
This option affects \[dq]sync\[dq] and \[dq]scrub\[dq], which are allowed
|
|
|
|
|
to continue after the first set of disk errors to try
|
|
|
|
|
to complete their operations.
|
|
|
|
|
However, \[dq]check\[dq] and \[dq]fix\[dq] always stop at the first error.
|
2014-12-30 10:44:11 +01:00
|
|
|
.TP
|
2014-12-29 09:00:14 +01:00
|
|
|
.B \-S, \-\-start BLKSTART
|
2025-10-02 18:36:40 +02:00
|
|
|
Starts processing from the specified
|
|
|
|
|
block number. This can be useful for retrying to check
|
|
|
|
|
or fix specific blocks in case of a damaged disk.
|
|
|
|
|
This option is mainly for advanced manual recovery.
|
2011-03-23 18:54:08 +01:00
|
|
|
.TP
|
2014-12-29 19:20:34 +01:00
|
|
|
.B \-B, \-\-count BLKCOUNT
|
2013-09-11 21:46:22 +02:00
|
|
|
Processes only the specified number of blocks.
|
2025-10-02 18:36:40 +02:00
|
|
|
This option is mainly for advanced manual recovery.
|
2011-03-23 18:54:08 +01:00
|
|
|
.TP
|
2025-10-02 18:36:40 +02:00
|
|
|
.B \-C, \-\-gen\-conf CONTENT
|
2013-09-21 15:53:46 +02:00
|
|
|
Generates a dummy configuration file from an existing
|
|
|
|
|
content file.
|
2025-10-02 18:36:40 +02:00
|
|
|
The configuration file is written to standard output
|
|
|
|
|
and does not overwrite an existing one.
|
2013-09-21 15:53:46 +02:00
|
|
|
This configuration file also contains the information
|
2025-10-02 18:36:40 +02:00
|
|
|
needed to reconstruct the disk mount points in case you
|
2013-09-21 15:53:46 +02:00
|
|
|
lose the entire system.
|
|
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-v, \-\-verbose
|
2025-10-02 18:36:40 +02:00
|
|
|
Prints more information to the screen.
|
|
|
|
|
If specified once, it prints excluded files
|
|
|
|
|
and additional statistics.
|
2015-06-20 16:48:07 +02:00
|
|
|
This option has no effect on the log files.
|
2015-02-22 14:31:03 +01:00
|
|
|
.TP
|
|
|
|
|
.B \-q, \-\-quiet
|
2025-10-02 18:36:40 +02:00
|
|
|
Prints less information to the screen.
|
|
|
|
|
If specified once, it removes the progress bar; twice,
|
|
|
|
|
the running operations; three times, the info
|
|
|
|
|
messages; four times, the status messages.
|
|
|
|
|
Fatal errors are always printed to the screen.
|
2015-06-20 16:48:07 +02:00
|
|
|
This option has no effect on the log files.
|
2011-03-22 23:22:18 +01:00
|
|
|
.TP
|
2014-03-20 22:08:46 +01:00
|
|
|
.B \-H, \-\-help
|
2011-03-22 23:22:18 +01:00
|
|
|
Prints a short help screen.
|
|
|
|
|
.TP
|
2013-11-14 22:02:26 +01:00
|
|
|
.B \-V, \-\-version
|
2011-03-22 23:22:18 +01:00
|
|
|
Prints the program version.
|
|
|
|
|
.SH CONFIGURATION
|
|
|
|
|
SnapRAID requires a configuration file to know where your disk array
|
2025-10-02 18:36:40 +02:00
|
|
|
is located and where to store the parity information.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
In Unix, it uses the file \[dq]/usr/local/etc/snapraid.conf\[dq] if it exists,
|
|
|
|
|
otherwise \[dq]/etc/snapraid.conf\[dq].
|
|
|
|
|
In Windows, it uses the file \[dq]snapraid.conf\[dq] in the same
|
|
|
|
|
directory as \[dq]snapraid.exe\[dq].
|
2011-04-26 23:41:15 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
It must contain the following options (case\-sensitive):
|
2016-05-16 21:56:42 +02:00
|
|
|
.SS parity FILE [,FILE] ...
|
|
|
|
|
Defines the files to use to store the parity information.
|
2025-10-02 18:36:40 +02:00
|
|
|
The parity enables protection from a single disk
|
|
|
|
|
failure, similar to RAID5.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You can specify multiple files, which must be on different disks.
|
2016-08-31 22:26:17 +02:00
|
|
|
When a file cannot grow anymore, the next one is used.
|
2025-10-02 18:36:40 +02:00
|
|
|
The total space available must be at least as large as the largest data disk in
|
2016-05-16 21:56:42 +02:00
|
|
|
the array.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You can add additional parity files later, but you
|
2017-03-26 10:36:28 +02:00
|
|
|
cannot reorder or remove them.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Keeping the parity disks reserved for parity ensures that
|
|
|
|
|
they do not become fragmented, improving performance.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
In Windows, 256 MB is left unused on each disk to avoid the
|
2016-08-31 22:26:17 +02:00
|
|
|
warning about full disks.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This option is mandatory and can be used only once.
|
2016-05-16 21:56:42 +02:00
|
|
|
.SS (2,3,4,5,6)\-parity FILE [,FILE] ...
|
2013-10-26 00:05:23 +02:00
|
|
|
Defines the files to use to store extra parity information.
|
2016-05-16 21:56:42 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
For each parity level specified, one additional level of protection
|
2013-10-26 00:05:23 +02:00
|
|
|
is enabled:
|
|
|
|
|
.PD 0
|
|
|
|
|
.IP \(bu
|
2016-05-16 21:56:42 +02:00
|
|
|
2\-parity enables RAID6 dual parity.
|
2013-10-26 00:05:23 +02:00
|
|
|
.IP \(bu
|
2025-10-02 18:36:40 +02:00
|
|
|
3\-parity enables triple parity.
|
2013-10-26 00:05:23 +02:00
|
|
|
.IP \(bu
|
2025-10-02 18:36:40 +02:00
|
|
|
4\-parity enables quad (four) parity.
|
2013-10-26 00:05:23 +02:00
|
|
|
.IP \(bu
|
2025-10-02 18:36:40 +02:00
|
|
|
5\-parity enables penta (five) parity.
|
2013-10-26 00:05:23 +02:00
|
|
|
.IP \(bu
|
2025-10-02 18:36:40 +02:00
|
|
|
6\-parity enables hexa (six) parity.
|
2013-10-26 00:05:23 +02:00
|
|
|
.PD
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Each parity level requires the presence of all previous parity
|
2016-05-16 21:56:42 +02:00
|
|
|
levels.
|
2013-10-26 00:05:23 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The same considerations as for the \'parity\' option apply.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
These options are optional and can be used only once.
|
2016-05-16 21:56:42 +02:00
|
|
|
.SS z\-parity FILE [,FILE] ...
|
2025-10-02 18:36:40 +02:00
|
|
|
Defines an alternate file and format to store triple parity.
|
2013-11-05 19:40:32 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This option is an alternative to \'3\-parity\', primarily intended for
|
|
|
|
|
low\-end CPUs like ARM or AMD Phenom, Athlon, and Opteron that do not
|
|
|
|
|
support the SSSE3 instruction set. In such cases, it provides
|
|
|
|
|
better performance.
|
2013-11-05 19:40:32 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This format is similar to but faster than the one used by ZFS RAIDZ3.
|
|
|
|
|
Like ZFS, it does not work beyond triple parity.
|
2013-11-05 19:40:32 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
When using \'3\-parity\', you will be warned if it is recommended to use
|
|
|
|
|
the \'z\-parity\' format for performance improvement.
|
2013-11-05 19:40:32 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
It is possible to convert from one format to another by adjusting
|
|
|
|
|
the configuration file with the desired z\-parity or 3\-parity file
|
2014-03-17 22:06:20 +01:00
|
|
|
and using \'fix\' to recreate it.
|
2011-09-03 11:17:25 +02:00
|
|
|
.SS content FILE
|
2025-10-02 18:36:40 +02:00
|
|
|
Defines the file to use to store the list and checksums of all the
|
2011-04-29 23:21:27 +02:00
|
|
|
files present in your disk array.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
It can be placed on a disk used for data, parity, or
|
2011-09-20 22:35:15 +02:00
|
|
|
any other disk available.
|
2011-09-18 22:43:41 +02:00
|
|
|
If you use a data disk, this file is automatically excluded
|
2014-03-17 22:06:20 +01:00
|
|
|
from the \[dq]sync\[dq] process.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This option is mandatory and can be used multiple times to save
|
|
|
|
|
multiple copies of the same file.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You must store at least one copy for each parity disk used
|
|
|
|
|
plus one. Using additional copies does not hurt.
|
2016-01-10 21:19:20 +01:00
|
|
|
.SS data NAME DIR
|
2025-10-02 18:36:40 +02:00
|
|
|
Defines the name and mount point of the data disks in
|
|
|
|
|
the array. NAME is used to identify the disk and must
|
2016-01-10 21:19:20 +01:00
|
|
|
be unique. DIR is the mount point of the disk in the
|
2025-10-02 18:36:40 +02:00
|
|
|
file system.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You can change the mount point as needed, as long as
|
|
|
|
|
you keep the NAME fixed.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You should use one option for each data disk in the array.
|
2016-01-10 21:19:20 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
You can rename a disk later by changing the NAME directly
|
|
|
|
|
in the configuration file and then running a \'sync\' command.
|
|
|
|
|
In the case of renaming, the association is done using the stored
|
2016-01-10 21:19:20 +01:00
|
|
|
UUID of the disks.
|
2011-12-08 22:40:30 +01:00
|
|
|
.SS nohidden
|
2025-10-02 18:36:40 +02:00
|
|
|
Excludes all hidden files and directories.
|
|
|
|
|
In Unix, hidden files are those starting with \[dq].\[dq].
|
|
|
|
|
In Windows, they are those with the hidden attribute.
|
2011-09-03 11:17:25 +02:00
|
|
|
.SS exclude/include PATTERN
|
2025-10-02 18:36:40 +02:00
|
|
|
Defines the file or directory patterns to exclude or include
|
2011-04-26 18:51:42 +02:00
|
|
|
in the sync process.
|
2025-10-02 18:36:40 +02:00
|
|
|
All patterns are processed in the specified order.
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2014-03-17 22:06:20 +01:00
|
|
|
If the first pattern that matches is an \[dq]exclude\[dq] one, the file
|
2025-10-02 18:36:40 +02:00
|
|
|
is excluded. If it is an \[dq]include\[dq] one, the file is included.
|
2011-04-26 18:51:42 +02:00
|
|
|
If no pattern matches, the file is excluded if the last pattern
|
2014-03-17 22:06:20 +01:00
|
|
|
specified is an \[dq]include\[dq], or included if the last pattern
|
|
|
|
|
specified is an \[dq]exclude\[dq].
|
2011-09-03 11:17:25 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
See the PATTERN section for more details on pattern
|
2011-09-03 11:17:25 +02:00
|
|
|
specifications.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This option can be used multiple times.
|
2014-02-12 22:10:06 +01:00
|
|
|
.SS blocksize SIZE_IN_KIBIBYTES
|
2025-10-02 18:36:40 +02:00
|
|
|
Defines the basic block size in kibibytes for the parity.
|
|
|
|
|
One kibibyte is 1024 bytes.
|
|
|
|
|
.PP
|
|
|
|
|
The default blocksize is 256, which should work for most cases.
|
|
|
|
|
.PP
|
|
|
|
|
WARNING! This option is for experts only, and it is highly
|
2025-10-06 15:43:51 +02:00
|
|
|
recommended not to change this value. To change this value in the
|
2025-10-02 18:36:40 +02:00
|
|
|
future, you will need to recreate the entire parity!
|
|
|
|
|
.PP
|
|
|
|
|
A reason to use a different blocksize is if you have many small
|
|
|
|
|
files, on the order of millions.
|
|
|
|
|
.PP
|
|
|
|
|
For each file, even if only a few bytes, an entire block of parity is allocated,
|
|
|
|
|
and with many files, this may result in significant unused parity space.
|
|
|
|
|
When you completely fill the parity disk, you are not
|
|
|
|
|
allowed to add more files to the data disks.
|
|
|
|
|
However, the wasted parity does not accumulate across data disks. Wasted space
|
|
|
|
|
resulting from a high number of files on a data disk limits only
|
|
|
|
|
the amount of data on that data disk, not others.
|
|
|
|
|
.PP
|
|
|
|
|
As an approximation, you can assume that half of the block size is
|
|
|
|
|
wasted for each file. For example, with 100,000 files and a 256 KiB
|
|
|
|
|
block size, you will waste 12.8 GB of parity, which may result
|
|
|
|
|
in 12.8 GB less space available on the data disk.
|
|
|
|
|
.PP
|
|
|
|
|
You can check the amount of wasted space on each disk using \[dq]status\[dq].
|
|
|
|
|
This is the amount of space you must leave free on the data
|
|
|
|
|
disks or use for files not included in the array.
|
|
|
|
|
If this value is negative, it means you are close to filling
|
2015-03-13 19:34:45 +01:00
|
|
|
the parity, and it represents the space you can still waste.
|
2014-11-01 18:13:09 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
To avoid this issue, you can use a larger partition for parity.
|
|
|
|
|
For example, if the parity partition is 12.8 GB larger than the data disks,
|
|
|
|
|
you have enough extra space to handle up to 100,000
|
|
|
|
|
files on each data disk without any wasted space.
|
2014-02-19 19:44:15 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
A trick to get a larger parity partition in Linux is to format it
|
2014-02-19 19:44:15 +01:00
|
|
|
with the command:
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
mkfs.ext4 \-m 0 \-T largefile4 DEVICE
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This results in about 1.5% extra space, approximately 60 GB for
|
|
|
|
|
a 4 TB disk, which allows about 460,000 files on each data disk without
|
2014-02-19 19:44:15 +01:00
|
|
|
any wasted space.
|
2016-04-07 22:37:11 +02:00
|
|
|
.SS hashsize SIZE_IN_BYTES
|
2025-10-02 18:36:40 +02:00
|
|
|
Defines the hash size in bytes for the saved blocks.
|
2016-04-10 19:41:56 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The default hashsize is 16 bytes (128 bits), which should work
|
2016-04-07 22:37:11 +02:00
|
|
|
for most cases.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
WARNING! This option is for experts only, and it is highly
|
2025-10-06 15:43:51 +02:00
|
|
|
recommended not to change this value. To change this value in the
|
2025-10-02 18:36:40 +02:00
|
|
|
future, you will need to recreate the entire parity!
|
2016-04-07 22:37:11 +02:00
|
|
|
.PP
|
2016-04-10 19:41:56 +02:00
|
|
|
A reason to use a different hashsize is if your system has
|
2025-10-02 18:36:40 +02:00
|
|
|
limited memory. As a rule of thumb, SnapRAID typically requires
|
|
|
|
|
1 GiB of RAM for each 16 TB of data in the array.
|
2016-04-10 19:41:56 +02:00
|
|
|
.PP
|
|
|
|
|
Specifically, to store the hashes of the data, SnapRAID requires
|
2025-10-02 18:36:40 +02:00
|
|
|
approximately TS*(1+HS)/BS bytes of RAM,
|
|
|
|
|
where TS is the total size in bytes of your disk array, BS is the
|
2016-04-07 22:37:11 +02:00
|
|
|
block size in bytes, and HS is the hash size in bytes.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
For example, with 8 disks of 4 TB, a block size of 256 KiB
|
|
|
|
|
(1 KiB = 1024 bytes), and a hash size of 16, you get:
|
2016-04-07 22:37:11 +02:00
|
|
|
.PP
|
|
|
|
|
RAM = (8 * 4 * 10^12) * (1+16) / (256 * 2^10) = 1.93 GiB
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.PP
|
2016-04-10 19:41:56 +02:00
|
|
|
Switching to a hash size of 8, you get:
|
2016-04-07 22:37:11 +02:00
|
|
|
.PP
|
|
|
|
|
RAM = (8 * 4 * 10^12) * (1+8) / (256 * 2^10) = 1.02 GiB
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
2016-04-10 19:41:56 +02:00
|
|
|
.PP
|
|
|
|
|
Switching to a block size of 512, you get:
|
|
|
|
|
.PP
|
|
|
|
|
RAM = (8 * 4 * 10^12) * (1+16) / (512 * 2^10) = 0.96 GiB
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Switching to both a hash size of 8 and a block size of 512, you get:
|
2016-04-10 19:41:56 +02:00
|
|
|
.PP
|
|
|
|
|
RAM = (8 * 4 * 10^12) * (1+8) / (512 * 2^10) = 0.51 GiB
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
2015-03-29 23:18:30 +02:00
|
|
|
.SS autosave SIZE_IN_GIGABYTES
|
2025-10-02 18:36:40 +02:00
|
|
|
Automatically saves the state when syncing or scrubbing after the
|
2025-09-21 19:54:10 +02:00
|
|
|
specified amount of GB processed.
|
2025-10-02 18:36:40 +02:00
|
|
|
This option is useful to avoid restarting long \[dq]sync\[dq]
|
|
|
|
|
commands from scratch if interrupted by a machine crash or any other event.
|
2025-09-21 19:54:10 +02:00
|
|
|
.SS temp_limit TEMPERATURE_CELSIUS
|
|
|
|
|
Sets the maximum allowed disk temperature in Celsius. When specified,
|
|
|
|
|
SnapRAID periodically checks the temperature of all disks using the
|
2025-09-29 15:53:43 +02:00
|
|
|
smartctl tool. The current disk temperatures are displayed while
|
|
|
|
|
SnapRAID is operating. If any disk exceeds this limit, all operations
|
2025-10-02 18:36:40 +02:00
|
|
|
stop, and the disks are spun down (put into standby) for the duration
|
2025-10-16 17:42:29 +02:00
|
|
|
defined by the \[dq]temp_sleep\[dq] option. After the sleep period, operations
|
|
|
|
|
resume, potentially pausing again if the temperature limit is reached
|
|
|
|
|
once more.
|
2025-09-29 15:53:43 +02:00
|
|
|
.PP
|
|
|
|
|
During operation, SnapRAID also analyzes the heating curve of each
|
|
|
|
|
disk and estimates the long\-term steady temperature they are expected
|
|
|
|
|
to reach if activity continues. This predicted steady temperature is
|
|
|
|
|
shown in parentheses next to the current value and helps assess
|
2025-10-16 17:42:29 +02:00
|
|
|
whether the system\'s cooling is adequate. This estimated temperature
|
|
|
|
|
is for informational purposes only and has no effect on the behavior
|
|
|
|
|
of SnapRAID. The program\'s actions are based solely on the actual
|
|
|
|
|
measured disk temperatures.
|
2025-09-29 15:53:43 +02:00
|
|
|
.PP
|
|
|
|
|
To perform this analysis, SnapRAID needs a reference for the ambient
|
|
|
|
|
system temperature. It first attempts to read it from available
|
|
|
|
|
hardware sensors. If no system sensor can be accessed, it uses the
|
|
|
|
|
lowest disk temperature measured at the start of the run as a fallback
|
|
|
|
|
reference.
|
|
|
|
|
.PP
|
|
|
|
|
Normally, SnapRAID shows only the temperature of the hottest disk.
|
|
|
|
|
To display the temperature of all disks, use the \-A or \-\-stats option.
|
2025-09-21 19:54:10 +02:00
|
|
|
.SS temp_sleep TIME_IN_MINUTES
|
|
|
|
|
Sets the standby time, in minutes, when the temperature limit is
|
|
|
|
|
reached. During this period, the disks remain spun down. The default
|
2025-10-17 09:12:21 +02:00
|
|
|
is 5 minutes.
|
2013-02-22 22:17:54 +01:00
|
|
|
.SS pool DIR
|
|
|
|
|
Defines the pooling directory where the virtual view of the disk
|
2014-03-17 22:06:20 +01:00
|
|
|
array is created using the \[dq]pool\[dq] command.
|
2013-12-18 19:26:57 +01:00
|
|
|
.PP
|
2013-03-10 19:54:37 +01:00
|
|
|
The directory must already exist.
|
2013-12-18 19:26:57 +01:00
|
|
|
.SS share UNC_DIR
|
|
|
|
|
Defines the Windows UNC path required to access the disks remotely.
|
|
|
|
|
.PP
|
|
|
|
|
If this option is specified, the symbolic links created in the pool
|
|
|
|
|
directory use this UNC path to access the disks.
|
2025-10-02 18:36:40 +02:00
|
|
|
Without this option, the symbolic links generated use only local paths,
|
|
|
|
|
which does not allow sharing the pool directory over the network.
|
2013-12-18 19:26:57 +01:00
|
|
|
.PP
|
|
|
|
|
The symbolic links are formed using the specified UNC path, adding the
|
2025-10-02 18:36:40 +02:00
|
|
|
disk name as specified in the \[dq]data\[dq] option, and finally adding the
|
|
|
|
|
file directory and name.
|
2013-12-18 19:26:57 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This option is required only for Windows.
|
2015-04-08 22:56:44 +02:00
|
|
|
.SS smartctl DISK/PARITY OPTIONS...
|
2025-10-02 18:36:40 +02:00
|
|
|
Defines custom smartctl options to obtain the SMART attributes for
|
|
|
|
|
each disk. This may be required for RAID controllers and some USB
|
|
|
|
|
disks that cannot be auto\-detected. The %s placeholder is replaced by
|
|
|
|
|
the device name, but it is optional for fixed devices like RAID controllers.
|
2015-04-08 22:56:44 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
DISK is the same disk name specified in the \[dq]data\[dq] option.
|
|
|
|
|
PARITY is one of the parity names: \[dq]parity\[dq], \[dq]2\-parity\[dq], \[dq]3\-parity\[dq],
|
|
|
|
|
\[dq]4\-parity\[dq], \[dq]5\-parity\[dq], \[dq]6\-parity\[dq], or \[dq]z\-parity\[dq].
|
2015-04-08 22:56:44 +02:00
|
|
|
.PP
|
|
|
|
|
In the specified OPTIONS, the \[dq]%s\[dq] string is replaced by the
|
2025-10-02 18:36:40 +02:00
|
|
|
device name. For RAID controllers, the device is
|
|
|
|
|
likely fixed, and you may not need to use \[dq]%s\[dq].
|
2015-04-08 22:56:44 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
Refer to the smartmontools documentation for possible options:
|
2015-04-08 22:56:44 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
https://www.smartmontools.org/wiki/Supported_RAID\-Controllers
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
https://www.smartmontools.org/wiki/Supported_USB\-Devices
|
|
|
|
|
.PD 0
|
2025-09-15 23:48:53 +02:00
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
For example:
|
2015-04-08 22:56:44 +02:00
|
|
|
.PP
|
2025-09-15 23:48:53 +02:00
|
|
|
.RS 4
|
|
|
|
|
smartctl parity \-d sat %s
|
|
|
|
|
.PD 0
|
2015-04-08 22:56:44 +02:00
|
|
|
.PD
|
|
|
|
|
.RE
|
2025-09-15 16:56:09 +02:00
|
|
|
.SS smartignore DISK/PARITY ATTR [ATTR...]
|
|
|
|
|
Ignores the specified SMART attribute when computing the probability
|
|
|
|
|
of disk failure. This option is useful if a disk reports unusual or
|
|
|
|
|
misleading values for a particular attribute.
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
DISK is the same disk name specified in the \[dq]data\[dq] option.
|
|
|
|
|
PARITY is one of the parity names: \[dq]parity\[dq], \[dq]2\-parity\[dq], \[dq]3\-parity\[dq],
|
|
|
|
|
\[dq]4\-parity\[dq], \[dq]5\-parity\[dq], \[dq]6\-parity\[dq], or \[dq]z\-parity\[dq].
|
2025-09-15 16:56:09 +02:00
|
|
|
The special value * can be used to ignore the attribute on all disks.
|
|
|
|
|
.PP
|
2025-09-29 16:20:39 +02:00
|
|
|
For example, to ignore the \[dq]Current Pending Sector Count\[dq] attribute on
|
|
|
|
|
all disks:
|
2025-09-15 16:56:09 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2025-09-29 16:20:39 +02:00
|
|
|
smartignore * 197
|
2025-09-15 16:56:09 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
To ignore it only on the first parity disk:
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2025-09-29 16:20:39 +02:00
|
|
|
smartignore parity 197
|
2025-09-15 16:56:09 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
2011-09-03 11:17:25 +02:00
|
|
|
.SS Examples
|
2011-05-04 19:51:30 +02:00
|
|
|
An example of a typical configuration for Unix is:
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2014-03-18 19:34:18 +01:00
|
|
|
parity /mnt/diskp/snapraid.parity
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-18 19:34:18 +01:00
|
|
|
content /mnt/diskp/snapraid.content
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-18 19:34:18 +01:00
|
|
|
content /var/snapraid/snapraid.content
|
2011-04-25 13:43:51 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d1 /mnt/disk1/
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d2 /mnt/disk2/
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d3 /mnt/disk3/
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
exclude /lost+found/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2011-05-04 19:51:30 +02:00
|
|
|
exclude /tmp/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2015-04-08 22:56:44 +02:00
|
|
|
smartctl d1 \-d sat %s
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
smartctl d2 \-d usbjmicron %s
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
smartctl parity \-d areca,1/1 /dev/sg0
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2015-04-12 21:25:16 +02:00
|
|
|
smartctl 2\-parity \-d areca,2/1 /dev/sg0
|
|
|
|
|
.PD 0
|
2025-09-15 23:48:53 +02:00
|
|
|
.PD
|
2011-05-04 19:51:30 +02:00
|
|
|
.RE
|
|
|
|
|
.PP
|
|
|
|
|
An example of a typical configuration for Windows is:
|
|
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2014-03-18 19:34:18 +01:00
|
|
|
parity E:\\snapraid.parity
|
2011-05-04 19:51:30 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-18 19:34:18 +01:00
|
|
|
content E:\\snapraid.content
|
2011-05-04 19:51:30 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-18 19:34:18 +01:00
|
|
|
content C:\\snapraid\\snapraid.content
|
2011-05-04 19:51:30 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d1 G:\\array\\
|
2011-05-04 19:51:30 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d2 H:\\array\\
|
2011-05-04 19:51:30 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2016-01-10 21:19:20 +01:00
|
|
|
data d3 I:\\array\\
|
2011-05-04 19:51:30 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
exclude Thumbs.db
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-17 22:06:20 +01:00
|
|
|
exclude \\$RECYCLE.BIN
|
2011-05-04 19:51:30 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-17 22:06:20 +01:00
|
|
|
exclude \\System Volume Information
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2015-04-08 22:56:44 +02:00
|
|
|
smartctl d1 \-d sat %s
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
smartctl d2 \-d usbjmicron %s
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
smartctl parity \-d areca,1/1 /dev/arcmsr0
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2015-04-12 21:25:16 +02:00
|
|
|
smartctl 2\-parity \-d areca,2/1 /dev/arcmsr0
|
|
|
|
|
.PD 0
|
2025-09-15 23:48:53 +02:00
|
|
|
.PD
|
2011-03-22 23:22:18 +01:00
|
|
|
.RE
|
|
|
|
|
.SH PATTERN
|
2011-04-26 18:51:42 +02:00
|
|
|
Patterns are used to select a subset of files to exclude or include in
|
|
|
|
|
the process.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
|
|
|
|
There are four different types of patterns:
|
|
|
|
|
.TP
|
|
|
|
|
.B FILE
|
2025-10-02 18:36:40 +02:00
|
|
|
Selects any file named FILE. You can use any globbing
|
|
|
|
|
characters like * and ?, and character classes like [a\-z].
|
|
|
|
|
This pattern applies only to files, not directories.
|
2011-03-22 23:22:18 +01:00
|
|
|
.TP
|
|
|
|
|
.B DIR/
|
2014-01-18 16:42:56 +01:00
|
|
|
Selects any directory named DIR and everything inside.
|
2025-10-02 18:36:40 +02:00
|
|
|
You can use any globbing characters like * and ?.
|
|
|
|
|
This pattern applies only to directories, not files.
|
2011-03-22 23:22:18 +01:00
|
|
|
.TP
|
|
|
|
|
.B /PATH/FILE
|
2011-03-30 00:14:43 +02:00
|
|
|
Selects the exact specified file path. You can use any
|
2025-10-02 18:36:40 +02:00
|
|
|
globbing characters like * and ?, but they never match a
|
2011-03-22 23:22:18 +01:00
|
|
|
directory slash.
|
2025-10-02 18:36:40 +02:00
|
|
|
This pattern applies only to files, not directories.
|
2011-03-22 23:22:18 +01:00
|
|
|
.TP
|
|
|
|
|
.B /PATH/DIR/
|
2014-01-18 16:42:56 +01:00
|
|
|
Selects the exact specified directory path and everything
|
2025-10-02 18:36:40 +02:00
|
|
|
inside. You can use any globbing characters like * and ?, but
|
2014-01-18 16:42:56 +01:00
|
|
|
they never match a directory slash.
|
2025-10-02 18:36:40 +02:00
|
|
|
This pattern applies only to directories, not files.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
When you specify an absolute path starting with /, it is applied at
|
|
|
|
|
the array root directory, not the local file system root directory.
|
2011-03-30 00:14:43 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
In Windows, you can use the backslash \\ instead of the forward slash /.
|
|
|
|
|
Windows system directories, junctions, mount points, and other Windows
|
|
|
|
|
special directories are treated as files, meaning that to exclude
|
|
|
|
|
them, you must use a file rule, not a directory one.
|
2013-01-19 17:35:04 +01:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
If the file name contains a \'*\', \'?\', \'[\',
|
|
|
|
|
or \']\' character, you must escape it to avoid having it interpreted as a
|
|
|
|
|
globbing character. In Unix, the escape character is \'\\\'; in Windows, it is \'^\'.
|
|
|
|
|
When the pattern is on the command line, you must double the escape
|
|
|
|
|
character to avoid having it interpreted by the command shell.
|
2016-03-02 12:05:38 +01:00
|
|
|
.PP
|
2011-04-26 23:41:15 +02:00
|
|
|
In the configuration file, you can use different strategies to filter
|
2011-04-26 18:51:42 +02:00
|
|
|
the files to process.
|
2025-10-02 18:36:40 +02:00
|
|
|
The simplest approach is to use only \[dq]exclude\[dq] rules to remove all the
|
2011-04-26 18:51:42 +02:00
|
|
|
files and directories you do not want to process. For example:
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2014-03-17 22:06:20 +01:00
|
|
|
# Excludes any file named \[dq]*.unrecoverable\[dq]
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2013-08-20 12:23:46 +02:00
|
|
|
exclude *.unrecoverable
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-17 22:06:20 +01:00
|
|
|
# Excludes the root directory \[dq]/lost+found\[dq]
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
exclude /lost+found/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2025-10-02 18:36:40 +02:00
|
|
|
# Excludes any subdirectory named \[dq]tmp\[dq]
|
2011-03-22 23:22:18 +01:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
exclude tmp/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
2011-03-30 00:14:43 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The opposite approach is to define only the files you want to process, using
|
2014-03-17 22:06:20 +01:00
|
|
|
only \[dq]include\[dq] rules. For example:
|
2011-04-26 18:51:42 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
# Includes only some directories
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
include /movies/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
include /musics/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
include /pictures/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
The final approach is to mix \[dq]exclude\[dq] and \[dq]include\[dq] rules. In this case,
|
|
|
|
|
the order of rules is important. Earlier rules take
|
|
|
|
|
precedence over later ones.
|
|
|
|
|
To simplify, you can list all the \[dq]exclude\[dq] rules first and then
|
|
|
|
|
all the \[dq]include\[dq] rules. For example:
|
2011-04-26 18:51:42 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
2014-03-17 22:06:20 +01:00
|
|
|
# Excludes any file named \[dq]*.unrecoverable\[dq]
|
2011-04-26 18:51:42 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2013-08-20 12:23:46 +02:00
|
|
|
exclude *.unrecoverable
|
2011-04-26 18:51:42 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2025-10-02 18:36:40 +02:00
|
|
|
# Excludes any subdirectory named \[dq]tmp\[dq]
|
2011-04-26 18:51:42 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
exclude tmp/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
# Includes only some directories
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
include /movies/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
include /musics/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
|
|
|
|
include /pictures/
|
|
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
|
|
|
|
.PP
|
2014-03-17 22:06:20 +01:00
|
|
|
On the command line, using the \-f option, you can only use \[dq]include\[dq]
|
2011-04-26 18:51:42 +02:00
|
|
|
patterns. For example:
|
2011-03-30 00:14:43 +02:00
|
|
|
.PP
|
|
|
|
|
.RS 4
|
|
|
|
|
# Checks only the .mp3 files.
|
|
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2025-10-02 18:36:40 +02:00
|
|
|
# In Unix, use quotes to avoid globbing expansion by the shell.
|
2011-03-30 00:14:43 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PP
|
|
|
|
|
.PD
|
2014-03-17 22:06:20 +01:00
|
|
|
snapraid \-f \[dq]*.mp3\[dq] check
|
2011-03-30 00:14:43 +02:00
|
|
|
.PD 0
|
|
|
|
|
.PD
|
|
|
|
|
.RE
|
2011-05-03 23:28:03 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
In Unix, when using globbing characters on the command line, you must
|
|
|
|
|
quote them to prevent the shell from expanding them.
|
2011-03-22 23:22:18 +01:00
|
|
|
.SH CONTENT
|
2025-10-02 18:36:40 +02:00
|
|
|
SnapRAID stores the list and checksums of your files in the content file.
|
2011-03-22 23:22:18 +01:00
|
|
|
.PP
|
2025-10-06 15:43:51 +02:00
|
|
|
It is a binary file that lists all the files present in your disk array,
|
2025-10-02 18:36:40 +02:00
|
|
|
along with all the checksums to verify their integrity.
|
2011-04-29 23:21:27 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
This file is read and written by the \[dq]sync\[dq] and \[dq]scrub\[dq] commands and
|
|
|
|
|
read by the \[dq]fix\[dq], \[dq]check\[dq], and \[dq]status\[dq] commands.
|
2011-03-22 23:22:18 +01:00
|
|
|
.SH PARITY
|
2013-11-29 23:06:09 +01:00
|
|
|
SnapRAID stores the parity information of your array in the parity
|
2013-10-26 00:05:23 +02:00
|
|
|
files.
|
2011-03-29 18:57:13 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
These are binary files containing the computed parity of all the
|
2014-03-17 22:06:20 +01:00
|
|
|
blocks defined in the \[dq]content\[dq] file.
|
2011-04-29 23:21:27 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
These files are read and written by the \[dq]sync\[dq] and \[dq]fix\[dq] commands and
|
|
|
|
|
only read by the \[dq]scrub\[dq] and \[dq]check\[dq] commands.
|
2011-05-24 21:03:30 +02:00
|
|
|
.SH ENCODING
|
2013-11-29 23:06:09 +01:00
|
|
|
SnapRAID in Unix ignores any encoding. It reads and stores the
|
2025-10-02 18:36:40 +02:00
|
|
|
file names with the same encoding used by the file system.
|
2011-05-24 21:03:30 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
In Windows, all names read from the file system are converted and
|
|
|
|
|
processed in UTF\-8 format.
|
2011-05-24 21:03:30 +02:00
|
|
|
.PP
|
2025-10-02 18:36:40 +02:00
|
|
|
To have file names printed correctly, you must set the Windows
|
|
|
|
|
console to UTF\-8 mode with the command \[dq]chcp 65001\[dq] and use
|
|
|
|
|
a TrueType font like \[dq]Lucida Console\[dq] as the console font.
|
|
|
|
|
This affects only the printed file names; if you
|
2011-05-24 21:03:30 +02:00
|
|
|
redirect the console output to a file, the resulting file is always
|
2025-10-02 18:36:40 +02:00
|
|
|
in UTF\-8 format.
|
2011-03-22 23:22:18 +01:00
|
|
|
.SH COPYRIGHT
|
2025-10-02 18:36:40 +02:00
|
|
|
This file is Copyright (C) 2025 Andrea Mazzoleni
|
2011-03-22 23:22:18 +01:00
|
|
|
.SH SEE ALSO
|
|
|
|
|
rsync(1)
|