mirror of
https://github.com/amadvance/snapraid.git
synced 2026-10-26 19:01:57 -04:00
1444 lines
41 KiB
Groff
1444 lines
41 KiB
Groff
.TH "SnapRAID Backup For Disk Arrays" 1
|
|
.SH NAME
|
|
snapraid \- SnapRAID Backup For Disk Arrays
|
|
.SH SYNOPSIS
|
|
snapraid [\-c, \-\-conf CONFIG]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
[\-f, \-\-filter PATTERN] [\-d, \-\-filter\-disk NAME]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
[\-m, \-\-filter\-missing] [\-e, \-\-filter\-error]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
[\-a, \-\-audit\-only] [\-h, \-\-pre\-hash] [\-i, \-\-import DIR]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
[\-p, \-\-percentage PERC] [\-o, \-\-older\-than DAYS]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
[\-Z, \-\-force\-zero] [\-E, \-\-force\-empty]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
[\-U, \-\-force\-uuid] [\-D, \-\-force\-device]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
[\-N, \-\-force\-nocopy] [\-F, \-\-force\-full]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
[\-v, \-\-verbose] [\-l, \-\-log FILE]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
[\-s, \-\-start BLKSTART] [\-t, \-\-count BLKCOUNT]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
status|sync|scrub|fix|check|list|diff|dup|pool|rehash
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.PP
|
|
snapraid [\-V, \-\-version] [\-H, \-\-help] [\-C, \-\-gen\-conf CONTENT]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.SH DESCRIPTION
|
|
SnapRAID is a backup program for disk arrays. It stores parity
|
|
information of your data and it\'s able to recover from up to six
|
|
disk failures.
|
|
.PP
|
|
SnapRAID is mainly targeted for a home media center, with a lot of
|
|
big files that rarely change.
|
|
.PP
|
|
Beside the ability to recover from disk failures, other
|
|
features of SnapRAID are:
|
|
.PD 0
|
|
.IP \(bu
|
|
All your data is hashed to ensure data integrity and to avoid
|
|
silent corruption.
|
|
.IP \(bu
|
|
If the failed disks are too many to allow a recovery,
|
|
you lose the data only on the failed disks.
|
|
All the data in the other disks is safe.
|
|
.IP \(bu
|
|
If you accidentally delete some files in a disk, you can
|
|
recover them.
|
|
.IP \(bu
|
|
You can start with already filled disks.
|
|
.IP \(bu
|
|
The disks can have different sizes.
|
|
.IP \(bu
|
|
You can add disks at any time.
|
|
.IP \(bu
|
|
It doesn\'t lock\-in your data. You can stop using SnapRAID at any
|
|
time without the need to reformat or move data.
|
|
.PD
|
|
.PP
|
|
The official site of SnapRAID is:
|
|
.PP
|
|
.RS 4
|
|
http://snapraid.sourceforge.net
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.SH LIMITATIONS
|
|
SnapRAID is in between a RAID and a Backup program trying to get the best
|
|
benefits of them. Although it also has some limitations that you should
|
|
consider before using it.
|
|
.PP
|
|
The main one is that if a disk fails, and you haven\'t recently synced,
|
|
you may not able to do a complete recover.
|
|
More specifically, you may be unable to recover up to the size of the
|
|
amount of the changed or deleted files from the last sync operation.
|
|
This happens even if the files changed or deleted are not in the
|
|
failed disk.
|
|
New added files don\'t prevent the recovering of the already existing
|
|
files. You may only lose the just added files, if they are on the failed
|
|
disk.
|
|
.PP
|
|
This is the reason because SnapRAID is better suited for data that
|
|
rarely change.
|
|
.PP
|
|
Other limitations are:
|
|
.PD 0
|
|
.IP \(bu
|
|
You have different file\-systems for each disk.
|
|
Using a RAID you have only a big file\-system.
|
|
.IP \(bu
|
|
It doesn\'t stripe data.
|
|
With RAID you get a speed boost with striping.
|
|
.IP \(bu
|
|
It doesn\'t support real\-time recovery.
|
|
With RAID you do not have to stop working when a disk fails.
|
|
.IP \(bu
|
|
It\'s able to recover damages only from a limited number of disks.
|
|
With a Backup you are able to recover from a complete
|
|
failure of the whole disk array.
|
|
.IP \(bu
|
|
Only file, timestamps, symlinks and hardlinks are saved.
|
|
Permissions, ownership and extended attributes are not saved.
|
|
.PD
|
|
.SH GETTING STARTED
|
|
To use SnapRAID you need to first select one disk of your disk array
|
|
to dedicate at the \[dq]parity\[dq] information. With one disk for parity you
|
|
will be able to recover from a single disk failure, like RAID5.
|
|
.PP
|
|
If you want to be able to recover from more disk failures, like RAID6,
|
|
you must reserve additional disks for parity. Any additional parity
|
|
disk allow to recover from one more disk failure.
|
|
.PP
|
|
As parity disks, you have to pick the biggest disks in the array,
|
|
as the parity information may grow in size as the biggest data
|
|
disk in the array.
|
|
.PP
|
|
These disks will be dedicated to store the \[dq]parity\[dq] files.
|
|
You should not store your data in them.
|
|
.PP
|
|
The list of files is saved in the \[dq]content\[dq] files, usually
|
|
stored in the data, parity or boot disks.
|
|
These files contain the details of your backup, with all the
|
|
checksums to verify its integrity.
|
|
The \[dq]content\[dq] file is stored in multiple copies, and each one must
|
|
be in a different disk, to ensure that in even in case of multiple
|
|
disk failures at least one copy is available.
|
|
.PP
|
|
For example, suppose that you are interested only at one parity level
|
|
of protection, and that your disks are present in:
|
|
.PP
|
|
.RS 4
|
|
/mnt/diskp <\- selected disk for parity
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
/mnt/disk1 <\- first disk to backup
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
/mnt/disk2 <\- second disk to backup
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
/mnt/disk3 <\- third disk to backup
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
you have to create the configuration file /etc/snapraid.conf with
|
|
the following options:
|
|
.PP
|
|
.RS 4
|
|
parity /mnt/diskp/snapraid.parity
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
content /var/snapraid/snapraid.content
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
content /mnt/disk1/snapraid.content
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
content /mnt/disk2/snapraid.content
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d1 /mnt/disk1/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d2 /mnt/disk2/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d3 /mnt/disk3/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
If you are in Windows, you should use drive letters and backslashes
|
|
instead of slashes, and if you like, also file extensions.
|
|
.PP
|
|
.RS 4
|
|
parity E:\\snapraid.parity
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
content C:\\snapraid\\snapraid.content
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
content F:\\array\\snapraid.content
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
content G:\\array\\snapraid.content
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d1 F:\\array\\
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d2 G:\\array\\
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d3 H:\\array\\
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
At this point you are ready to start the \[dq]sync\[dq] command to build the
|
|
parity information.
|
|
.PP
|
|
.RS 4
|
|
snapraid sync
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
This process may take some hours the first time, depending on the size
|
|
of the data already present in the disks. If the disks are empty
|
|
the process is immediate.
|
|
.PP
|
|
You can stop it at any time pressing Ctrl+C, and at the next run it
|
|
will start where interrupted.
|
|
.PP
|
|
When this command completes, your data is SAFE.
|
|
.PP
|
|
Now you can start using your array as you like, and periodically
|
|
update the parity information running the \[dq]sync\[dq] command.
|
|
.SS Restoring and Undeleting
|
|
In recovering, SnapRAID is more like a backup program than a RAID system,
|
|
and it can be used to restore or undelete a file or directory to its previous
|
|
state using the \-f, \-\-filter option :
|
|
.PP
|
|
.RS 4
|
|
snapraid fix \-f FILE
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
or for a directory:
|
|
.PP
|
|
.RS 4
|
|
snapraid fix \-f DIR/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
You can also use it to recover only accidentally deleted files inside
|
|
a directory using the \-m, \-\-filter\-missing option, that restores
|
|
only missing files, leaving untouched all the others.
|
|
.PP
|
|
.RS 4
|
|
snapraid fix \-m \-f DIR/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
Or to recover all the deleted files in all the drives with:
|
|
.PP
|
|
.RS 4
|
|
snapraid fix \-m
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
If instead you have lost an entire disk and you want to recover it,
|
|
please see the \'Recovering\' chapter.
|
|
.SS Scrubbing
|
|
To periodically check the data and parity for errors, you can
|
|
run the \[dq]scrub\[dq] command.
|
|
.PP
|
|
.RS 4
|
|
snapraid scrub
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
This command verifies only the oldest data in your array.
|
|
Every run of the command checks about 12% of the array,
|
|
but not newer than 10 days.
|
|
You can use the \-p, \-\-percentage option to specify a different amount,
|
|
and the \-o, \-\-older\-than option to specify a different age in days.
|
|
For example, to check 5% of the array older than 20 days use:
|
|
.PP
|
|
.RS 4
|
|
snapraid \-p 5 \-o 20 scrub
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
If a silent or input error is found, the corresponding block is marked
|
|
as bad in the \[dq]content\[dq] file, and listed in the \[dq]status\[dq] command.
|
|
.PP
|
|
.RS 4
|
|
snapraid status
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
To fix them, you can use the \[dq]fix\[dq] command filtering for files containing
|
|
bad blocks:
|
|
.PP
|
|
.RS 4
|
|
snapraid \-e fix
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
At the next \[dq]scrub\[dq] the errors will disappear from the \[dq]status\[dq] report
|
|
if really fixed. To make it fast, you can use \-p 0 to scrub only blocks
|
|
marked as bad.
|
|
.PP
|
|
.RS 4
|
|
snapraid \-p 0 scrub
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
Take care that running scrub on a not synced array may result in
|
|
errors caused by removed or modified files. These errors are reported
|
|
in the \[dq]scrub\[dq] result, but related blocks are not marked as bad.
|
|
.SS Pooling
|
|
To have all the files in your array shown in the same directory tree,
|
|
you can enable \[dq]pooling\[dq], that consists in creating a virtual view of all
|
|
the files in your array using symbolic links.
|
|
.PP
|
|
You can configure the \[dq]pooling\[dq] directory in the configuration file with:
|
|
.PP
|
|
.RS 4
|
|
pool /pool
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
or, if you are in Windows, with:
|
|
.PP
|
|
.RS 4
|
|
pool C:\\pool
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
and then run the \[dq]pool\[dq] command to create or update the virtual view.
|
|
.PP
|
|
.RS 4
|
|
snapraid pool
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
If you are using a Unix platform and you want to share such directory
|
|
in the network to either Windows or Unix machines, you should add
|
|
to your /etc/samba/smb.conf the following options:
|
|
.PP
|
|
.RS 4
|
|
# In the global section of smb.conf
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
unix extensions = no
|
|
.PD 0
|
|
.PP
|
|
.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
|
|
follow symlinks = yes
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
In Windows the same sharing operation is not so straightforward,
|
|
because Windows shares the symbolic links as they are, and that
|
|
requires the network clients to resolve them remotely.
|
|
.PP
|
|
To make it working, besides sharing in the network the pool directory,
|
|
you must also share all the disks independently, using as share points
|
|
the disk names as defined in the config file. You must also specify in
|
|
the \[dq]share\[dq] option of the configure file, the Windows UNC path that remote
|
|
clients needs to use to access such shared disks.
|
|
.PP
|
|
For example, operating from a server named \[dq]darkstar\[dq], you can use
|
|
the options:
|
|
.PP
|
|
.RS 4
|
|
disk d1 F:\\array\\
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d2 G:\\array\\
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d3 H:\\array\\
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
pool C:\\pool
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
share \\\\darkstar
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
and share the following dirs in the network:
|
|
.PP
|
|
.RS 4
|
|
\\\\darkstar\\pool \-> C:\\pool
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
\\\\darkstar\\d1 \-> F:\\array
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
\\\\darkstar\\d2 \-> G:\\array
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
\\\\darkstar\\d3 \-> H:\\array
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
to allow remote clients to access all the files at \\\\darkstar\\\\pool.
|
|
.PP
|
|
You may also need to configure remote clients, to enable the access at
|
|
remote symlinks with the command:
|
|
.PP
|
|
.RS 4
|
|
fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.SH COMMANDS
|
|
SnapRAID provides a few simple commands that allow to:
|
|
.PD 0
|
|
.IP \(bu
|
|
Prints a report of the status of the array \-> \[dq]status\[dq]
|
|
.IP \(bu
|
|
Makes a backup/snapshot \-> \[dq]sync\[dq]
|
|
.IP \(bu
|
|
Periodically checks data \-> \[dq]scrub\[dq]
|
|
.IP \(bu
|
|
Restore the last backup/snapshot \-> \[dq]fix\[dq].
|
|
.PD
|
|
.PP
|
|
Take care that the commands have to be written in lower case.
|
|
.SS status
|
|
Prints a summary of the state of the disk array.
|
|
.PP
|
|
It includes information about the parity fragmentation, how old
|
|
are the blocks without checking, and all the recorded silent
|
|
errors encountered while scrubbing.
|
|
.PP
|
|
Note that the information presented refers at the latest time you run \[dq]sync\[dq].
|
|
Later modifications are not taken into account.
|
|
.PP
|
|
Nothing is modified.
|
|
.SS sync
|
|
Updates the parity information. All the modified files
|
|
in the disk array are read, and the parity data is
|
|
recomputed.
|
|
.PP
|
|
Files are identified by path and/or inode and checked by
|
|
size and timestamp.
|
|
If the size or timestamp are different, the parity data is
|
|
recomputed for the whole file.
|
|
With inode you can move them on the disk without triggering
|
|
any parity recomputation.
|
|
.PP
|
|
You can stop this process at any time pressing Ctrl+C,
|
|
without losing the work already done.
|
|
At the next run the \[dq]sync\[dq] process will start where
|
|
interrupted.
|
|
.PP
|
|
The \[dq]content\[dq] and \[dq]parity\[dq] files are modified if necessary.
|
|
The files in the array are NOT modified.
|
|
.SS scrub
|
|
Scrubs the array, checking for silent errors in data or parity disks.
|
|
.PP
|
|
For each command invocation, the 12% of the array is checked, but
|
|
nothing that it\'s more recent than 10 days.
|
|
This means that scrubbing once a week, every bit of data is checked
|
|
at least one time every two months.
|
|
.PP
|
|
You can use the \-p, \-\-percentage option to specify a different amount,
|
|
and the \-o, \-\-older\-than option to specify a different age in days.
|
|
You can have a full scrub with \[dq]\-p100 \-o0\[dq].
|
|
.PP
|
|
Any silent error identified is recorded in the content file,
|
|
and it\'s listed in the \[dq]status\[dq] command until it\'s fixed calling
|
|
\[dq]fix\[dq] and then \[dq]scrub\[dq].
|
|
.PP
|
|
The oldest blocks are scrubbed first ensuring an optimal check.
|
|
Blocks already marked as bad are always checked, and if found
|
|
correct, they are automatically unmarked.
|
|
.PP
|
|
It\'s recommended to run \[dq]scrub\[dq] on a synced array, to avoid to have
|
|
reported error caused by unsynced data. These errors are recognized
|
|
as not being silent errors, and the blocks are not marked as bad,
|
|
but such errors are reported in the output of the command.
|
|
.PP
|
|
Files are identified only by path, and not by inode.
|
|
.PP
|
|
The \[dq]content\[dq] file is modified to update the time of the last check
|
|
of each block, and to mark bad blocks.
|
|
The \[dq]parity\[dq] files are NOT modified.
|
|
The files in the array are NOT modified.
|
|
.SS fix
|
|
Fix all the files and the parity data.
|
|
.PP
|
|
All the files and the parity data are compared with the snapshot
|
|
state saved in the last \[dq]sync\[dq] command.
|
|
If a difference is found, it\'s reverted at the stored snapshot.
|
|
.PP
|
|
Note that \[dq]fix\[dq] doesn\'t differentiate from errors or intentional
|
|
changes at files. It just reverts the state at the last \[dq]sync\[dq] command.
|
|
.PP
|
|
By default the full array is processed. Use the filter options
|
|
to select a subset of files or disks to operate on.
|
|
To know that file is checked, you can use the \-v, \-\-verbose option.
|
|
.PP
|
|
To only fix errors found with \[dq]scrub\[dq] and reported in \[dq]status\[dq],
|
|
you can use the \-e, \-\-filter\-error option.
|
|
.PP
|
|
All the files that cannot be fixed are renamed adding
|
|
the \[dq].unrecoverable\[dq] extension.
|
|
.PP
|
|
Files are identified only by path, and not by inode.
|
|
.PP
|
|
The \[dq]content\[dq] file is NOT modified.
|
|
The \[dq]parity\[dq] files are modified if necessary.
|
|
The files in the array are modified if necessary.
|
|
.SS check
|
|
Verify all the files and the parity data.
|
|
.PP
|
|
It works just like \[dq]fix\[dq], but it only simulates a recovery
|
|
and no change is written in the array.
|
|
.PP
|
|
This command is mostly intended for manual verifications,
|
|
like after a recovery process or in other special conditions.
|
|
For periodic and scheduled checks uses the \[dq]scrub\[dq] command.
|
|
.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
|
|
By default the full array is processed. Use the filter options
|
|
to select a subset of files or disks to operate on.
|
|
To know that file is checked, you can use the \-v, \-\-verbose option.
|
|
.PP
|
|
Files are identified only by path, and not by inode.
|
|
.PP
|
|
Nothing is modified.
|
|
.SS list
|
|
Lists all the files contained in the array at the time of the
|
|
last \[dq]sync\[dq] command.
|
|
.PP
|
|
Nothing is modified.
|
|
.SS diff
|
|
Lists all the files modified from the last \[dq]sync\[dq] command that
|
|
need to have their parity data recomputed.
|
|
.PP
|
|
This command doesn\'t check the file data, but only the file timestamp
|
|
size and inode.
|
|
.PP
|
|
Nothing is modified.
|
|
.SS dup
|
|
Lists all the duplicate files. Two files are assumed equal if their
|
|
hashes are matching. The file data is not read, but only the
|
|
precomputed hashes are used.
|
|
.PP
|
|
Nothing is modified.
|
|
.SS pool
|
|
Creates or updates in the \[dq]pooling\[dq] directory a virtual view of all
|
|
the files of your disk array.
|
|
.PP
|
|
The files are not really copied here, but just linked using
|
|
symbolic links.
|
|
.PP
|
|
When updating, all the present symbolic links and empty
|
|
subdirectories are deleted and replaced with the new
|
|
view of the array. Any other regular file is left in place.
|
|
.PP
|
|
Nothing is modified outside the pool directory.
|
|
.SS rehash
|
|
Schedules a rehash of the whole array.
|
|
.PP
|
|
This option can be used to change the hash kind used,
|
|
typically when upgrading from a 32 bits system to a 64
|
|
bits one, to switch from MurmurHash3 to the faster SpookyHash.
|
|
.PP
|
|
If you are already using the optimal hash, this command
|
|
do nothing and tells you that nothing has to be done.
|
|
.PP
|
|
The rehash isn\'t done immediately, but it takes place
|
|
progressively during the \[dq]sync\[dq] and \[dq]scrub\[dq] commands.
|
|
.PP
|
|
You can get the rehash state using the \[dq]status\[dq] command.
|
|
.PP
|
|
During the rehash, SnapRAID maintains full functionality,
|
|
with the only exception of the \[dq]dup\[dq] command not able to detect
|
|
duplicated files using a different hash.
|
|
.SH OPTIONS
|
|
SnapRAID provides the following options:
|
|
.TP
|
|
.B \-c, \-\-conf CONFIG
|
|
Selects the configuration file. If not specified it\'s assumed
|
|
the file \[dq]/etc/snapraid.conf\[dq] in Unix, and \[dq]snapraid.conf\[dq] in
|
|
the current directory in Windows.
|
|
.TP
|
|
.B \-f, \-\-filter PATTERN
|
|
Filters the files to process in the \[dq]check\[dq] and \[dq]fix\[dq]
|
|
commands.
|
|
Only the files matching the entered pattern are processed.
|
|
This option can be used many times.
|
|
See the PATTERN section for more details in the
|
|
pattern specifications.
|
|
In Unix, ensure to quote globbing chars if used.
|
|
This option can be used only with the \[dq]check\[dq] and \[dq]fix\[dq] commands.
|
|
Note that it cannot be used with \[dq]sync\[dq] and \[dq]scrub\[dq], because they always
|
|
process the whole array.
|
|
.TP
|
|
.B \-d, \-\-filter\-disk NAME
|
|
Filters the files to process in the \[dq]check\[dq] and \[dq]fix\[dq]
|
|
commands.
|
|
Only the files present in the specified disk are processed.
|
|
You must specify a disk name as named in the configuration
|
|
file.
|
|
In \[dq]check\[dq], you can make it faster, specifying also \-a, \-\-audit\-only
|
|
option, to avoid to access other disks to check parity data.
|
|
If you combine more \-\-filter, \-\-filter\-disk and \-\-filter\-missing options,
|
|
only files matching all the set of filters are selected.
|
|
This option can be used many times.
|
|
This option can be used only with the \[dq]check\[dq] and \[dq]fix\[dq] commands.
|
|
Note that it cannot be used with \[dq]sync\[dq] and \[dq]scrub\[dq], because they always
|
|
process the whole array.
|
|
.TP
|
|
.B \-m, \-\-filter\-missing
|
|
Filters the files to process in the \[dq]check\[dq] and \[dq]fix\[dq]
|
|
commands.
|
|
Only the files missing/deleted from the array are processed.
|
|
When used with \[dq]fix\[dq], this is a kind of \[dq]undelete\[dq] command.
|
|
If you combine more \-\-filter, \-\-filter\-disk and \-\-filter\-missing options,
|
|
only files matching all the set of filters are selected.
|
|
This option can be used only with the \[dq]check\[dq] and \[dq]fix\[dq] commands.
|
|
Note that it cannot be used with \[dq]sync\[dq] and \[dq]scrub\[dq], because they always
|
|
process the whole array.
|
|
.TP
|
|
.B \-e, \-\-filter\-error
|
|
Filters the files to process in the \[dq]check\[dq] and \[dq]fix\[dq]
|
|
commands.
|
|
It processes only the files containing blocks marked with silent
|
|
errors during the \[dq]sync\[dq] and \[dq]scrub\[dq] command, and listed in the
|
|
\[dq]status\[dq] command.
|
|
This option can be used only with the \[dq]check\[dq] and \[dq]fix\[dq] commands.
|
|
.TP
|
|
.B \-p, \-\-percentage PERC
|
|
Selects the part of the array to process in the \[dq]scrub\[dq] command.
|
|
PERC is a numeric value from 0 to 100, default is 12.
|
|
When specifying 0, only the blocks marked as bad are scrubbed.
|
|
This option can be used only with the \[dq]scrub\[dq] command.
|
|
.TP
|
|
.B \-o, \-\-older\-than DAYS
|
|
Selects the older the part of the array to process in the
|
|
\[dq]scrub\[dq] command.
|
|
DAYS is the minimum age in days for a block to be scrubbed,
|
|
default is 10.
|
|
Blocks marked as bad are always scrubbed despite this option.
|
|
This option can be used only with the \[dq]scrub\[dq] command.
|
|
.TP
|
|
.B \-a, \-\-audit\-only
|
|
In the \[dq]check\[dq] command verifies the hash of the files without
|
|
doing any kind of check on the parity data.
|
|
If you are interested in checking only the file data this
|
|
option can speedup a lot the checking process.
|
|
This option can be used only with the \[dq]check\[dq] command.
|
|
.TP
|
|
.B \-h, \-\-pre\-hash
|
|
In the \[dq]sync\[dq] command run a preliminary hashing phase of all
|
|
the new data to verify the data used in 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\'s read
|
|
for the first time,
|
|
Unfortunately, this process happens when the system is under
|
|
heavy load, with all disks spinning and a busy CPU.
|
|
This is an extreme condition for your machine, and if it has a
|
|
latent hardware problem, it\'s possible to encounter silent errors
|
|
what cannot be detected because the data is not yet hashed.
|
|
To avoid this risk, you can enable the \[dq]pre\-hash\[dq] mode and have
|
|
all the data hashed two times to ensure its integrity.
|
|
This option can be used only with the \[dq]sync\[dq] command.
|
|
.TP
|
|
.B \-i, \-\-import DIR
|
|
Imports from the specified directory any file that you deleted
|
|
from the array after the last \[dq]sync\[dq] command.
|
|
If you still have such files, they could be used by the \[dq]check\[dq]
|
|
and \[dq]fix\[dq] commands to improve the recover process.
|
|
The files are read also in subdirectories and they are
|
|
identified regardless of their name.
|
|
This option can be used only with the \[dq]check\[dq] and \[dq]fix\[dq] commands.
|
|
.TP
|
|
.B \-Z, \-\-force\-zero
|
|
Forces the insecure operation of syncing a file with zero
|
|
size that before was not.
|
|
If SnapRAID detects a such condition, it stops proceeding
|
|
unless you specify this option.
|
|
This allows to easily detect when after a system crash,
|
|
some accessed files were truncated.
|
|
This is a possible condition in Linux with the ext3/ext4
|
|
filesystems.
|
|
This option can be used only with the \[dq]sync\[dq] command.
|
|
.TP
|
|
.B \-E, \-\-force\-empty
|
|
Forces the insecure operation of syncing a disk with all
|
|
the original files missing.
|
|
If SnapRAID detects that all the files originally present
|
|
in the disk are missing or rewritten, it stops proceeding
|
|
unless you specify this option.
|
|
This allows to easily detect when a data file\-system is not
|
|
mounted.
|
|
This option can be used only with the \[dq]sync\[dq] command.
|
|
.TP
|
|
.B \-U, \-\-force\-uuid
|
|
Forces the insecure operation of syncing, checking and fixing
|
|
with disks that have changed their UUID.
|
|
If SnapRAID detects that some disks have changed UUID,
|
|
it stops proceeding unless you specify this option.
|
|
This allows to detect when your disks are mounted in the
|
|
wrong mount points.
|
|
It\'s anyway allowed to have a single UUID change with
|
|
single parity, and more with multiple parity, because it\'s
|
|
the normal case of replacing disks after a recovery.
|
|
This option can be used only with the \[dq]sync\[dq], \[dq]check\[dq] or
|
|
\[dq]fix\[dq] command.
|
|
.TP
|
|
.B \-D, \-\-force\-device
|
|
Forces the insecure operation of fixing with disks on the same
|
|
physical device.
|
|
If SnapRAID detects that some disks have the same device ID,
|
|
it stops proceeding, because it\'s not a supported configuration.
|
|
But it could happen that you want to temporarily restore a lost
|
|
disk in the free space left in an already used disk. and this
|
|
option allows you to continue anyway.
|
|
This option can be used only with the \[dq]fix\[dq] command.
|
|
.TP
|
|
.B \-N, \-\-force\-nocopy
|
|
In the \[dq]sync\[dq], \[dq]check and \[dq]fix\[dq] commands, disables the copy
|
|
detection heuristic.
|
|
Without this option SnapRAID assumes that files with same
|
|
attributes, like name, size and timestamp are copies with the
|
|
same data.
|
|
This allows to identify copied or moved files from one disk
|
|
to another, and to reuse the already computed hash information
|
|
to detect silent errors or to recover missing files.
|
|
This behavior, in some rare cases, may result in false positives,
|
|
or in a slow process due the many hash verifications, and this
|
|
option allows to resolve them.
|
|
This option can be used only with the \[dq]sync\[dq], \[dq]check\[dq] and \[dq]fix\[dq]
|
|
commands.
|
|
.TP
|
|
.B \-F, \-\-force\-full
|
|
In the \[dq]sync\[dq] command, forces a full rebuild of the parity.
|
|
This option can be used when you reverted back to an old content
|
|
file, and you still have the parity data.
|
|
Instead of recomputing the parity from scratch, this allows
|
|
to reuse the hashes present in the content file to validate data,
|
|
and to maintain data protection during the \[dq]sync\[dq] process using
|
|
the old content file and the parity data you have.
|
|
This option can be used only with the \[dq]sync\[dq] command.
|
|
.TP
|
|
.B \-l, \-\-log FILE
|
|
Write a detailed log of errors found in check and fix.
|
|
This log contains the exact specification of which block of
|
|
any file is not recoverable and why.
|
|
If this option is not specified, no detailed log is printed,
|
|
and you\'ll get only a summary at the end of the operations.
|
|
When checking and fixing this allows to keep separated
|
|
the possible huge list of errors from the human readable
|
|
output.
|
|
If the specified path starts with \'>>\' the file is opened
|
|
in append mode. Occurrences of \'%D\' and \'%T\' in the name are
|
|
replaced with the date and time in the format YYYYMMDD and
|
|
HHMMSS. Note that in Windows batch files, you\'ll have to double
|
|
the \'%\' char, like result\-%%D.log. And to use \'>>\' you\'ll have
|
|
to enclose the name in \[dq], like \[dq]>>result.log\[dq].
|
|
To output the log to standard output or standard error,
|
|
you can use respectively \[dq]>&1\[dq] and \[dq]>&2\[dq].
|
|
.TP
|
|
.B \-s, \-\-start BLKSTART
|
|
Starts the processing from the specified
|
|
block number. It could be useful to retry to check
|
|
or fix some specific block, in case of a damaged disk.
|
|
It\'s present mainly for advanced manual recovering.
|
|
.TP
|
|
.B \-t, \-\-count BLKCOUNT
|
|
Processes only the specified number of blocks.
|
|
It\'s present mainly for advanced manual recovering.
|
|
.TP
|
|
.B \-C, \-\-gen\-conf CONTENT_FILE
|
|
Generates a dummy configuration file from an existing
|
|
content file.
|
|
The configuration file is written in the standard output,
|
|
and it doesn\'t overwrite an existing one.
|
|
This configuration file also contains the information
|
|
needed to reconstruct the disk mount points, in case you
|
|
lose the entire system.
|
|
.TP
|
|
.B \-v, \-\-verbose
|
|
Prints more information in the processing.
|
|
.TP
|
|
.B \-H, \-\-help
|
|
Prints a short help screen.
|
|
.TP
|
|
.B \-V, \-\-version
|
|
Prints the program version.
|
|
.SH CONFIGURATION
|
|
SnapRAID requires a configuration file to know where your disk array
|
|
is located, and where storing the parity information.
|
|
.PP
|
|
This configuration file is located in /etc/snapraid.conf in Unix or
|
|
in the execution directory in Windows.
|
|
.PP
|
|
It should contain the following options (case sensitive):
|
|
.SS parity FILE
|
|
Defines the file to use to store the parity information.
|
|
The parity enables the protection from a single disk
|
|
failure, like RAID5.
|
|
.PP
|
|
It must be placed in a disk dedicated for this purpose with
|
|
as much free space as the biggest disk in the array.
|
|
Leaving the parity disk reserved for only this file ensures that
|
|
it doesn\'t get fragmented, improving the performance.
|
|
.PP
|
|
This option is mandatory and it can be used only one time.
|
|
.SS [2,3,4,5,6]\-parity FILE
|
|
Defines the files to use to store extra parity information.
|
|
For each parity file specified, one additional level of protection
|
|
is enabled:
|
|
.PD 0
|
|
.IP \(bu
|
|
2\-parity enables RAID6 double parity.
|
|
.IP \(bu
|
|
3\-parity enables triple parity
|
|
.IP \(bu
|
|
4\-parity enables quad parity
|
|
.IP \(bu
|
|
5\-parity enables penta (five) parity
|
|
.IP \(bu
|
|
6\-parity enables hexa (six) parity
|
|
.PD
|
|
.PP
|
|
Each parity level requires also all the files of the previous levels.
|
|
.PP
|
|
Each file must be placed in a disk dedicated for this purpose with
|
|
as much free space as the biggest disk in the array.
|
|
Leaving the parity disks reserved for only these files ensures that
|
|
they doesn\'t get fragmented, improving the performance.
|
|
.PP
|
|
These options are optional and they can be used only one time.
|
|
.SS z\-parity FILE
|
|
Defines an alternate file and format to store the triple parity.
|
|
.PP
|
|
This option is an alternative at \'3\-parity\' mainly intended for
|
|
low\-end CPUs like ARM or AMD Phenom, Athlon and Opteron that don\'t
|
|
support the SSSE3 instructions set, and in such case it provides
|
|
a better performance.
|
|
.PP
|
|
This format is similar, but faster, at the one used by the ZFS RAIDZ3,
|
|
but it doesn\'t work beyond triple parity.
|
|
.PP
|
|
When using \'3\-parity\' you will be warned if it\'s recommended to use
|
|
the \'z\-parity\' format for a performance improvement.
|
|
.PP
|
|
It\'s possible to convert from one format to another, adjusting
|
|
the configuration file with the wanted z\-parity or 3\-parity file,
|
|
and using \'fix\' to recreate it.
|
|
.SS content FILE
|
|
Defines the file to use to store the list and checksums of all the
|
|
files present in your disk array.
|
|
.PP
|
|
It can be placed in the disk used to store data, parity, or
|
|
any other disk available.
|
|
If you use a data disk, this file is automatically excluded
|
|
from the \[dq]sync\[dq] process.
|
|
.PP
|
|
This option is mandatory and it can be used more times to save
|
|
more copies of the same files.
|
|
.PP
|
|
You have to store at least one copy for each parity disk used
|
|
plus one. Using some more doesn\'t hurt.
|
|
.SS disk NAME DIR
|
|
Defines the name and the mount point of the disks of the array.
|
|
NAME is used to identify the disk, and it must be unique.
|
|
DIR is the mount point of the disk in the filesystem.
|
|
.PP
|
|
You can change the mount point as you like, as long you
|
|
keep the NAME fixed.
|
|
.PP
|
|
You should use one option for each disk of the array.
|
|
.SS nohidden
|
|
Excludes all the hidden files and directory.
|
|
In Unix hidden files are the ones starting with \[dq].\[dq].
|
|
In Windows they are the ones with the hidden attribute.
|
|
.SS exclude/include PATTERN
|
|
Defines the file or directory patterns to exclude and include
|
|
in the sync process.
|
|
All the patterns are processed in the specified order.
|
|
.PP
|
|
If the first pattern that matches is an \[dq]exclude\[dq] one, the file
|
|
is excluded. If it\'s an \[dq]include\[dq] one, the file is included.
|
|
If no pattern matches, the file is excluded if the last pattern
|
|
specified is an \[dq]include\[dq], or included if the last pattern
|
|
specified is an \[dq]exclude\[dq].
|
|
.PP
|
|
See the PATTERN section for more details in the pattern
|
|
specifications.
|
|
.PP
|
|
This option can be used many times.
|
|
.SS blocksize SIZE_IN_KIBIBYTES
|
|
Defines the basic block size in kibi bytes of the parity.
|
|
One kibi bytes is 1024 bytes. The default blocksize is 256
|
|
and it should work for most cases.
|
|
.PP
|
|
A reason to use a different blocksize is if your system has less
|
|
than 4 GiB of memory. As a rule of thumb, with 4 GiB or more memory
|
|
use the default 256, with 2 GiB use 512, and with 1 GiB use 1024.
|
|
.PP
|
|
In more details SnapRAID requires about TS*28/BS bytes
|
|
of RAM memory to run. Where TS is the total size in bytes of
|
|
your disk array, and BS is the block size in bytes.
|
|
.PP
|
|
For example with 4 disk of 3 TiB and a block size of 256 KiB
|
|
(1 KiB = 1024 bytes) you have:
|
|
.PP
|
|
RAM = (4 * 3 * 2^40) * 28 / (256 * 2^10) = 1.4 GiB
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.PP
|
|
Another reason to use a different blocksize is if you have a lot of small
|
|
files. In the order of many millions.
|
|
.PP
|
|
In details, for each file, even of few bytes, a whole block of parity is
|
|
always allocated, and with many files this may result in a lot of unused
|
|
parity space. And when you completely fill the parity disk, you are not
|
|
allowed to add more files in the data disks.
|
|
But note that wasted parity doesn\'t sum between data disk. Wasted space
|
|
resulting from a high number of files in a data disk, limits only
|
|
the amount of data in such data disk and not in others.
|
|
.PP
|
|
As approximation, you can assume that half of the block size is
|
|
wasted for each file. For example, with 100000 files and a 256 KiB
|
|
block size, you are going to waste 12 GiB of parity, that may result
|
|
in 12 GiB less space available in the data disk.
|
|
.PP
|
|
You can get the amount of wasted space in each disk using the \[dq]status\[dq]
|
|
command. This is the amount of space that you must leave free in the data
|
|
disks, or use for files not included in the array.
|
|
.PP
|
|
To avoid to problem, you can use a bigger partition for parity.
|
|
For example, if you have the parity partition bigger than 12 GiB
|
|
than data disks, you have enough extra space to handle up to 100000
|
|
files in each data disk.
|
|
.PP
|
|
A trick to get a bigger parity partition in Linux, is to format it
|
|
with the command:
|
|
.PP
|
|
.RS 4
|
|
mkfs.ext4 \-m 0 \-T largefile4 DEVICE
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
This results in about 1.5% of extra space. Meaning about 48 GiB for
|
|
a 3 TiB disk, that allows about 400000 files in each data disk without
|
|
any wasted space.
|
|
.SS autosave SIZE_IN_GIBIBYTES
|
|
Automatically save the state when syncing after the specified amount
|
|
of GiB processed.
|
|
This option is useful to avoid to restart from scratch long \[dq]sync\[dq]
|
|
commands interrupted by a machine crash, or any other event that
|
|
may interrupt SnapRAID.
|
|
The SIZE argument is specified in gibibytes. Where one gibi bytes
|
|
is 1073741824 bytes.
|
|
.SS pool DIR
|
|
Defines the pooling directory where the virtual view of the disk
|
|
array is created using the \[dq]pool\[dq] command.
|
|
.PP
|
|
The directory must already exist.
|
|
.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.
|
|
Without this option the symbolic links generated use only local paths,
|
|
not allowing to share the pool directory in the network.
|
|
.PP
|
|
The symbolic links are formed using the specified UNC path, adding the
|
|
disk name as specified in the \[dq]disk\[dq] option, and finally adding the
|
|
file dir and name.
|
|
.PP
|
|
This option is only required for Windows.
|
|
.SS Examples
|
|
An example of a typical configuration for Unix is:
|
|
.PP
|
|
.RS 4
|
|
parity /mnt/diskp/snapraid.parity
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
content /mnt/diskp/snapraid.content
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
content /var/snapraid/snapraid.content
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d1 /mnt/disk1/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d2 /mnt/disk2/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d3 /mnt/disk3/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
exclude /lost+found/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
exclude /tmp/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
An example of a typical configuration for Windows is:
|
|
.PP
|
|
.RS 4
|
|
parity E:\\snapraid.parity
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
content E:\\snapraid.content
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
content C:\\snapraid\\snapraid.content
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d1 G:\\array\\
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d2 H:\\array\\
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
disk d3 I:\\array\\
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
exclude Thumbs.db
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
exclude \\$RECYCLE.BIN
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
exclude \\System Volume Information
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.SH PATTERN
|
|
Patterns are used to select a subset of files to exclude or include in
|
|
the process.
|
|
.PP
|
|
There are four different types of patterns:
|
|
.TP
|
|
.B FILE
|
|
Selects any file named as FILE. You can use any globbing
|
|
character like * and ?.
|
|
This pattern is applied only to files and not to directories.
|
|
.TP
|
|
.B DIR/
|
|
Selects any directory named DIR and everything inside.
|
|
You can use any globbing character like * and ?.
|
|
This pattern is applied only to directories and not to files.
|
|
.TP
|
|
.B /PATH/FILE
|
|
Selects the exact specified file path. You can use any
|
|
globbing character like * and ? but they never match a
|
|
directory slash.
|
|
This pattern is applied only to files and not to directories.
|
|
.TP
|
|
.B /PATH/DIR/
|
|
Selects the exact specified directory path and everything
|
|
inside. You can use any globbing character like * and ? but
|
|
they never match a directory slash.
|
|
This pattern is applied only to directories and not to files.
|
|
.PP
|
|
Note that when you specify an absolute path starting with /, it\'s
|
|
applied at the array root dir and not at the local filesystem root dir.
|
|
.PP
|
|
In Windows you can use the backslash \\ instead of the forward slash /.
|
|
Note that Windows system directories, junctions, mount points, and any
|
|
other Windows special directory are treated just as files, meaning that
|
|
to exclude them you must use a file rule, and not a directory one.
|
|
.PP
|
|
In the configuration file, you can use different strategies to filter
|
|
the files to process.
|
|
The simplest one is to use only \[dq]exclude\[dq] rules to remove all the
|
|
files and directories you do not want to process. For example:
|
|
.PP
|
|
.RS 4
|
|
# Excludes any file named \[dq]*.unrecoverable\[dq]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
exclude *.unrecoverable
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
# Excludes the root directory \[dq]/lost+found\[dq]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
exclude /lost+found/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
# Excludes any sub\-directory named \[dq]tmp\[dq]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
exclude tmp/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
The opposite way is to define only the file you want to process, using
|
|
only \[dq]include\[dq] rules. For example:
|
|
.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
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
The final way, is to mix \[dq]exclude\[dq] and \[dq]include\[dq] rules. In this case take
|
|
care that the order of rules is important. Previous rules have the
|
|
precedence over the later ones.
|
|
To get things simpler you can first have all the \[dq]exclude\[dq] rules and then
|
|
all the \[dq]include\[dq] ones. For example:
|
|
.PP
|
|
.RS 4
|
|
# Excludes any file named \[dq]*.unrecoverable\[dq]
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
exclude *.unrecoverable
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
# Excludes any sub\-directory named \[dq]tmp\[dq]
|
|
.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
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
On the command line, using the \-f option, you can only use \[dq]include\[dq]
|
|
patterns. For example:
|
|
.PP
|
|
.RS 4
|
|
# Checks only the .mp3 files.
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
# Note the \[dq]\[dq] use to avoid globbing expansion by the shell in Unix.
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
snapraid \-f \[dq]*.mp3\[dq] check
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
In Unix, when using globbing chars in the command line, you have to
|
|
quote them. Otherwise the shell will try to expand them.
|
|
.SH RECOVERING
|
|
The worst happened, and you lost a disk!
|
|
.PP
|
|
DO NOT PANIC! You will be able to recover it!
|
|
.PP
|
|
The first thing you have to do is to avoid further changes at you disk array.
|
|
Disable any remote connection to it, any scheduled process, including any
|
|
scheduled SnapRAID nightly sync.
|
|
.PP
|
|
Then proceed with the following steps.
|
|
.SS STEP 1 \-> Reconfigure
|
|
You need some space to recover, even better if you already have an additional
|
|
disk, but in case, also an external USB or remote disk is enough.
|
|
.PP
|
|
Change the SnapRAID configuration file and make the \[dq]disk\[dq] option
|
|
of the failed disk to point to the place where you have enough empty
|
|
space to recover the files.
|
|
.PP
|
|
For example, if you have that disk \[dq]d1\[dq] failed, you can change:
|
|
.PP
|
|
.RS 4
|
|
disk d1 /mnt/disk1/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
to:
|
|
.PP
|
|
.RS 4
|
|
disk d1 /mnt/new_spare_disk/
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.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
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
Where NAME is the name of the disk, like \[dq]d1\[dq] as in our previous example.
|
|
.PP
|
|
This command will take a long time.
|
|
.PP
|
|
Take care that you need also few gigabytes free to store the fix.log file.
|
|
Run it from a disk with some free space.
|
|
.PP
|
|
Now you have recovered all the recoverable. If some file is partially or totally
|
|
unrecoverable, it will be renamed adding the \[dq].unrecoverable\[dq] extension.
|
|
.PP
|
|
You can get a detailed list of all the unrecoverable blocks in the fix.log file
|
|
checking all the lines starting with \[dq]unrecoverable:\[dq]
|
|
.PP
|
|
If you are not satisfied of the recovering, you can retry it as many time you wish.
|
|
For example, if you have remove some files after the last \[dq]sync\[dq], you can retry
|
|
to put them inplace, and retry the \[dq]fix\[dq].
|
|
.PP
|
|
If you are satisfied of the recovering, you can now proceed further,
|
|
but take care that after syncing you will be no more able to retry the
|
|
\[dq]fix\[dq] command!
|
|
.SS STEP 3 \-> Check
|
|
As paranoid check, you can now run a \[dq]check\[dq] command to ensure that everything
|
|
is OK on the recovered disk.
|
|
.PP
|
|
.RS 4
|
|
snapraid \-d NAME \-a check
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
Where NAME is the name of the disk, like \[dq]d1\[dq] as in our previous example.
|
|
.PP
|
|
The options \-d and \-a tell SnapRAID to check only the specified disk,
|
|
and ignore all the parity data.
|
|
.PP
|
|
This command will take a long time.
|
|
.SS STEP 4 \-> Sync
|
|
Run the \[dq]sync\[dq] command to resynchronize the array with the new disk.
|
|
.PP
|
|
.RS 4
|
|
snapraid sync
|
|
.PD 0
|
|
.PP
|
|
.PD
|
|
.RE
|
|
.PP
|
|
If everything is recovered, this command is immediate.
|
|
.SH CONTENT
|
|
SnapRAID stores the list and checksums of your files in the content file.
|
|
.PP
|
|
It\'s a binary file, listing all the files present in your disk array,
|
|
with all the checksums to verify their integrity.
|
|
.PP
|
|
This file is read and written by the \[dq]sync\[dq] and \[dq]scrub\[dq] commands, and
|
|
read by \[dq]fix\[dq], \[dq]check\[dq] and \[dq]status\[dq].
|
|
.SH PARITY
|
|
SnapRAID stores the parity information of your array in the parity
|
|
files.
|
|
.PP
|
|
They are binary files, containing the computed parity of all the
|
|
blocks defined in the \[dq]content\[dq] file.
|
|
.PP
|
|
These files are read and written by the \[dq]sync\[dq] and \[dq]fix\[dq] commands, and
|
|
only read by \[dq]scrub\[dq] and \[dq]check\[dq].
|
|
.SH ENCODING
|
|
SnapRAID in Unix ignores any encoding. It reads and stores the
|
|
file names with the same encoding used by the filesystem.
|
|
.PP
|
|
In Windows all the names read from the filesystem are converted and
|
|
processed in the UTF\-8 format.
|
|
.PP
|
|
To have the file names printed correctly you have to set the Windows
|
|
console in the UTF\-8 mode, with the command \[dq]chcp 65001\[dq], and use
|
|
a TrueType font like \[dq]Lucida Console\[dq] as console font.
|
|
Note that it has effect only on the printed file names, if you
|
|
redirect the console output to a file, the resulting file is always
|
|
in the UTF\-8 format.
|
|
.SH COPYRIGHT
|
|
This file is Copyright (C) 2011 Andrea Mazzoleni
|
|
.SH SEE ALSO
|
|
rsync(1)
|