SNAPRAID(1)

📦
version 14.9 · 7 versions
, in ubuntu stonking

💾 snapraid — SnapRAID Backup for Disk Arrays ✨

okay bestie, so this is the manual page for snapraid, and it lives in the General Commands Manual as section 1 (the title up top is "SnapRAID B...Disk Arrays(1)"). yeah the name is literally abbreviated with dots in the header, that's not a typo, that's just how the page was born. 💅 anyway, sit down, grab a snack, this one's a long one — but it's SO worth it, i promise.

🌸 NAME 🌸

snapraid — SnapRAID Backup for Disk Arrays

🎀 SYNOPSIS 🎀

snapraid [-c, --conf CONFIG]
     [-f, --filter PATTERN] [-d, --filter-disk NAME]
     [-m, --filter-missing] [-e, --filter-error]
     [-a, --audit-only] [-h, --pre-hash] [-i, --import DIR]
     [-p, --plan PERC|bad|new|full]
     [-o, --older-than DAYS] [-l, --log FILE]
     [-s, --spin-down-on-error] [-w, --bw-limit RATE]
     [-t, --tail]
     [-Z, --force-zero] [-E, --force-empty]
     [-U, --force-uuid] [-D, --force-device]
     [-N, --force-nocopy] [-F, --force-full]
     [-R, --force-realloc] [-W, --force-realloc-tail]
     [-S, --start BLKSTART] [-B, --count BLKCOUNT]
     [-L, --error-limit NUMBER]
     [-A, --stats]
     [-v, --verbose] [-q, --quiet]
     status|smart|probe|up|down|diff|sync|scrub|fix|check
     |list|dup|pool|devices|touch|rehash|locate

snapraid [-V, --version] [-H, --help] [-C, --gen-conf CONTENT]

like yes, that's a LOT of flags, and no, you don't need all of them at once. the second form is the lil' short one — just --version, --help, or --gen-conf. 🫶

🦋 DESCRIPTION 🦋

SnapRAID is a backup program made specifically for disk arrays, and here's the serve: it stores parity information so you can recover your data even if up to six disks fail. six!! 👑

It's primarily intended for home media centers with big, infrequently-changing files, and it's stacked with features, no cap:

  • You can use disks that are already full of files — no reformatting required, just use them like normal. iconic behavior honestly. 💅
  • All your data gets hashed, so data integrity is checked and silent corruption can't sneak past you. 🕵️
  • If the number of failed disks exceeds the parity count, data loss stays confined to the affected disks — everything on the other disks is still accessible. 🫶
  • If you accidentally delete files on a disk, you can recover them. the "oops" is survivable, bestie. 😭
  • Disks can be different sizes. yes, a mixed-size harem, it's fine. 🌈
  • You can add disks at any time. no drama. ✨
  • SnapRAID does not lock in your data — you can stop using it whenever, with no reformatting and no moving files around. freedom, periodt.
  • To access a file, only a single disk has to spin up, which saves power and keeps things quiet. your electricity bill is thriving. 💸

want more tea? the official SnapRAID site is right here:

https://www.snapraid.it/

💀 LIMITATIONS 💀

okay so real talk time, because SnapRAID is a hybrid between a RAID and a backup program, trying to combine the best of both worlds. but bestie, there's some stuff you NEED to know before you commit. 🙈

The main limitation is that if a disk fails and you haven't recently synced, you may not be able to fully recover. More precisely: you may be unable to recover up to the size of the changed or deleted files since the last sync operation. and here's the sneaky part — this happens even if the changed or deleted files aren't on the failed disk. which is exactly why SnapRAID is better suited for data that rarely changes. 💀

On the other hand (and this is the good news 🫶), newly added files don't block recovery of files that already existed. You'll only lose the recently added files if they happen to be on the failed disk.

the rest of the limitations, in a cute lil' list because i love you:

  • With SnapRAID, you still have separate file systems for each disk. With RAID, you get a single large file system.
  • SnapRAID does not stripe data. With RAID, striping gives you a speed boost.
  • SnapRAID does not support real-time recovery. With RAID, you don't have to stop working when a disk fails.
  • SnapRAID can only recover data from a limited number of disk failures. With a backup, you can recover from a complete failure of the entire disk array.
  • Only file names, timestamps, symlinks, and hardlinks are saved. Permissions, ownership, and extended attributes are NOT saved. so don't come crying about your chmods, bestie. 😭

✨ GETTING STARTED ✨

okay bestie, first things first 💖 To use SnapRAID, you're gonna pick one disk in your disk array and dedicate it to parity info. With just one parity disk, you can recover from a single disk failure — literally the RAID5 of it all. Iconic.

Wanna survive more disk failures? That's giving RAID6 energy. You reserve additional disks for parity, and each extra parity disk lets you recover from one more disk failure. More parity, more slay. 👑

As parity disks, you need the biggest disks in the array, because the parity info can grow all the way up to the size of the largest data disk in the array. Big disk energy required fr.

These disks are getting dedicated to storing the parity files. Do not put your data on them. That's not their job. 🙅‍♀️

Then you define the data disks you want to protect with SnapRAID. Protection works best when the data on them rarely changes, so it's lowkey better to NOT include the Windows C:\ disk, or the Unix /home, /var, and /tmp directories. Those change constantly, and SnapRAID is not about that chaotic life.

The list of files is saved in the content files, usually stored on the data, parity, or boot disks. This file has every detail of your backup, including all the checksums to verify its integrity. The content file is stored in multiple copies, and each copy has to live on a different disk — that way, even if multiple disks fail, at least one copy is still available. Redundancy queen. 🎀

For example, pretend you want just one parity level of protection and your disks are at:

/mnt/diskp <- selected disk for parity
/mnt/disk1 <- first disk to protect
/mnt/disk2 <- second disk to protect
/mnt/disk3 <- third disk to protect

You create the configuration file /etc/snapraid.conf with these options:

parity /mnt/diskp/snapraid.parity
content /var/lib/snapraid/snapraid.content
content /mnt/disk1/snapraid.content
content /mnt/disk2/snapraid.content
data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/

If you're on Windows, use the Windows path format instead — drive letters and backslashes, not slashes:

parity E:\snapraid.parity
content C:\snapraid\snapraid.content
content F:\array\snapraid.content
content G:\array\snapraid.content
data d1 F:\array\
data d2 G:\array\
data d3 H:\array\

If you have sooo many disks that you run out of drive letters, you can mount disks directly in subfolders. See:

https://www.google.com/search?q=Windows+mount+point

At this point you're ready to run the sync command and build your parity info 🦋

snapraid sync

The first time, this may take several hours, depending on how much data is already on the disks. If the disks are empty, it's immediate — no biggie. ✨

You can stop it anytime by pressing Ctrl+C, and on the next run it picks up right where it got interrupted. The resume feature is the main character fr.

When this command finishes, your data is SAFE. Periodt. 💅

Now you can use your array however you want, and periodically update the parity info by running sync again.

🧼 Scrubbing 🧼

To periodically check the data and parity for errors, run the scrub command:

snapraid scrub

This command compares the data in your array against the hash computed during the sync command to verify integrity. Vibe check for your bytes. 😌

Each run checks approximately 8% of the array, excluding data that was already scrubbed in the previous 10 days. You can use the -p, --plan option to pick a different amount, and the -o, --older-than option to pick a different age in days. Example: check 5% of the array for blocks older than 20 days — say it with me:

snapraid -p 5 -o 20 scrub

If silent or input/output errors show up during the process, the corresponding blocks get marked as bad in the content file and listed in the status command:

snapraid status

To fix them, use the fix command and filter for bad blocks with the -e, --filter-error option:

snapraid -e fix

At the next scrub, the errors vanish from the status report if they're truly fixed. Wanna make it faster? Use -p bad to scrub only the blocks marked bad:

snapraid -p bad scrub
Running scrub on an unsynced array may report errors caused by removed or modified files. These errors show up in the scrub output, but the related blocks are not marked as bad. Don't panic, it's not that deep. 😭

🌈 Pooling 🌈

Note: The pooling feature described below has been superseded by the mergerfs tool, which is now the recommended option for Linux users in the SnapRAID community. Maison 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.

To have all the files in your array show up in one directory tree, you can enable the pooling feature. It creates a read-only virtual view of all the files in your array using symbolic links. Cute little shortcuts everywhere 🫶

You configure the pooling directory in the configuration file with:

pool /pool

or, if you're on Windows, with:

pool C:\pool

and then run the pool command to create or update that virtual view:

snapraid pool

If you're on a Unix platform and want to share this directory over the network to Windows or Unix machines, add these options to your /etc/samba/smb.conf:

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

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

On Windows, sharing symbolic links over a network means clients have to resolve them remotely. To enable that, besides sharing the pool directory, you also have to share all the disks independently, using the disk names defined in the configuration file as share points. You also need to specify, in the share option of the configuration file, the Windows UNC path that remote clients must use to reach those shared disks.

For example, operating from a server named darkstar, you can use these options:

data d1 F:\array\
data d2 G:\array\
data d3 H:\array\
pool C:\pool
share \\darkstar

and share these directories over the network:

\\darkstar\pool -> C:\pool
\\darkstar\d1 -> F:\array
\\darkstar\d2 -> G:\array
\\darkstar\d3 -> H:\array

so remote clients can reach all the files at \\darkstar\pool.

You may also need to configure remote clients to enable access to remote symlinks with this command:

fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1

🙈 Undeleting 🙈

SnapRAID functions more like a backup program than a RAID system, and it can restore or undelete files back to their previous state using the -f, --filter option:

snapraid fix -f FILE

or, for a whole directory:

snapraid fix -f DIR/

You can also use it to recover only the files you accidentally deleted inside a directory, using the -m, --filter-missing option — it restores only missing files and leaves all the others totally untouched:

snapraid fix -m -f DIR/

Or, to recover all the deleted files on all drives:

snapraid fix -m

😭 Recovering 😭

The worst has happened. You lost one or more disks. 😱

DO NOT PANIC! You will be able to recover them! You got this bestie, SnapRAID has you. 💖

First thing you must do: avoid any further changes to your disk array. Disable every remote connection to it and every scheduled process — including any scheduled SnapRAID nightly sync or scrub. Lock it down, no cap. 🔒

Then proceed with the following steps.

🛠️ STEP 1 -> Reconfigure 🛠️

You need some space to recover into — ideally on additional spare disks, but an external USB disk or a remote disk will totally suffice.

Modify the SnapRAID configuration file so the data or parity option of the failed disk points to a location with enough empty space to recover the files.

For example, if disk d1 failed, change from:

data d1 /mnt/disk1/

to:

data d1 /mnt/new_spare_disk/

If the disk you're recovering is a parity disk, update the appropriate parity option. If you have multiple failed disks, update all of their configuration options.

🔧 STEP 2 -> Fix 🔧

Run the fix command, storing the log in an external file, with:

snapraid -d NAME -l fix.log fix

Where NAME is the name of the disk, such as d1 in our previous example. If the disk you're recovering is a parity disk, use the names parity, 2-parity, etc. If you have multiple failed disks, use multiple -d options to specify all of them.

This command will take a long time. Like, a long time. Go touch grass, come back. 🌱

Make sure you have a few gigabytes free to store the fix.log file. Run it from a disk with sufficient free space.

Now you've recovered everything that's recoverable. If some files are partially or totally unrecoverable, they get renamed by adding the .unrecoverable extension.

You can find a detailed list of all unrecoverable blocks in the fix.log file by checking all the lines starting with unrecoverable:.

If you're not satisfied with the recovery, you can retry it as many times as you want — no limit, go off. 💅

For example, if you removed files from the array after the last sync, that may result in some files not being recovered. In that case, you can retry the fix using the -i, --import option, specifying where those files are now so they get included in the recovery process again.

If you are satisfied with the recovery, you can proceed further — but note that after syncing, you cannot retry the fix command anymore! 🚨

🔍 STEP 3 -> Check 🔍

As a cautious lil check, you can now run a check command to make sure everything is correct on the recovered disk:

snapraid -d NAME -a check

Where NAME is the name of the disk, such as d1 in our previous example.

The -d and -a options tell SnapRAID to check only the specified disk and ignore all parity data.

This command will also take a long time — but if you're not overly cautious, you can skip it. Your call, bestie. 🤷‍♀️

🔄 STEP 4 -> Sync 🔄

Run the sync command to resynchronize the array with the new disk:

snapraid sync

If everything is recovered, this command is immediate. Instantly back on our bullshit. ✨

👑 COMMANDS 👑

SnapRAID gives you a few simple commands that let you:

  • Print the status of the array -> status
  • Control the disks -> smart, probe, up, down
  • Make a backup/snapshot -> sync
  • Periodically check data -> scrub
  • Restore the last backup/snapshot -> fix.

Commands must be written in lowercase. lowercase only, bestie — it's giving sensitive. 👑

📊 status 📊

Prints a summary of the state of the disk array.

Like, it also spills the tea on parity fragmentation, how old your blocks are going completely unchecked, and every single silent error it's ever clocked while scrubbing. 📊✨

And bestie, all of this is only from the last time you ran sync. Anything you changed after that? Not in the receipts, not counted. 🙈

If bad blocks got caught, their block numbers are listed right there. Wanna fix 'em? That's the fix -e command, go off. 💅

It also serves you a whole graph of the last time each block was scrubbed or synced. Scrubbed blocks show up as *, and blocks that got synced but not scrubbed yet get an o. Iconic little data portrait honestly. 👑

Nothing is modified. Periodt. 🫶

🌈 smart

Prints a SMART report of, like, every disk in the system. Total health checkup energy. 🩺✨

It throws in an estimation of the probability of failure in the next year, so you can actually plan out maintenance replacements for any disks acting suspicious. Being proactive is main character behavior, fr fr.

That probability estimation comes from correlating the SMART attributes of your disks with the Backblaze data available at:

https://www.backblaze.com/hard-drive-test-data.html

If SMART says a disk is failing, it prints FAIL or PREFAIL for that disk and SnapRAID bounces out with an error. In that case?? Immediately replace the disk. Like, do not pass go. ⚠️

Other possible status strings are:

logfail In the past, some attributes were lower than the threshold.

logerr The device error log contains errors.
selferr The device self-test log contains errors.

If you pass the -v, --verbose option, you get a deeper statistical analysis. That analysis can legitimately help you figure out if you need more or less parity. 🧠

This command uses the smartctl tool and is equivalent to running smartctl -a on all devices.

If your devices aren't auto-detected correctly, you can specify a custom command using the smartctl option in the configuration file.

Nothing is modified. 💜

🦋 probe

Prints the POWER state of all disks in the system.

Standby means the disk isn't spinning. Active means the disk is spinning. That's the whole vibe check. ⚡

This command uses the smartctl tool and is equivalent to running smartctl -n standby -i on all devices.

If your devices aren't auto-detected correctly, you can specify a custom command using the smartctl option in the configuration file.

Nothing is modified. 🌸

⭐ up

Spins up all the disks of the array. Waking everybody up. ☀️

You can spin up only specific disks using the -d, --filter-disk option.

Real talk: spinning up all the disks at the same time requires a LOT of power. Make sure your power supply can actually sustain it, bestie. No crispy fried PSUs please. 🔥

Nothing is modified.

💤 down

Spins down all the disks of the array. Nap time for the whole squad. 😴

This command uses the smartctl tool and is equivalent to running smartctl -s standby,now on all devices.

You can spin down only specific disks using the -d, --filter-disk option.

To automatically spin down on error, you can use the -s, --spin-down-on-error option with any other command — it's equivalent to running down manually when an error occurs.

Nothing is modified. 🎀

🔍 diff

Lists all the files modified since the last sync that need their parity data recomputed.

Ngl, this command doesn't check the actual file data — only the file timestamp, size, and inode.

After listing all changed files, you get a summary of the changes, grouped by:

equal Files unchanged from before.
added Files added that were not present before.
removed Files removed.
updated Files with a different size or timestamp, meaning they were
    modified.
moved 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.
copied Files copied on the same or a different disk where the
    original file still exists. They are identified by having the
    same name, size, and timestamp. If the sub-second timestamp is
    zero, the full path must match to be identified, not just the
    name.
relocated Files moved on the same or a different disk where the
    original has disappeared. They are identified by having the same
    name, size, and timestamp. If the sub-second timestamp is zero,
    the full path must match to be identified. Unlike ´moved´ files
    on the same disk, relocated files have a different inode.
restored Files with a different inode but matching directory, name,
    size, and timestamp.  These are usually files restored after
    being deleted.

If a sync is required, the process return code is 2, instead of the default 0. The return code 1 is used for a generic error condition.

Nothing is modified. ✨

🔄 sync

Updates the parity information. All modified files in the disk array get read, and the corresponding parity data is updated. The main event, honestly.

You can stop this process at any time by pressing Ctrl+C, without losing the work already done. At the next run, the sync process will resume right where it was interrupted. No wasted effort, we love a comeback queen. 💅

If silent or input/output errors are found during the process, the corresponding blocks are marked as bad.

Files are identified by path and/or inode and checked by 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 same inode, the parity is not recomputed. If the file is moved to another disk, the parity is recomputed, but the previously computed hash information is retained.

The content and parity files are modified if necessary. The files in the array are NOT modified. 🫶

🧼 scrub

Scrubs the array, checking for silent or input/output errors in data and parity disks.

Each invocation checks approximately 8% of the array, excluding data already scrubbed in the last 10 days. Which means scrubbing once a week ensures every bit of data is checked at least once every three months. Consistent queen behavior. 👑

You can define a different scrub plan or amount using the -p, --plan option, which accepts: bad - Scrub blocks marked bad. new - Scrub just-synced blocks not yet scrubbed. full - Scrub everything. 0-100 - Scrub the specified percentage of blocks.

If you specify a percentage amount, you can also use the -o, --older-than option to define how old the block should be. 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 -p new option.

To get details of the scrub status, use the status command.

For any silent or input/output error found, the corresponding blocks are marked as bad in the content file. These bad blocks are listed in status and can be fixed with fix -e. After the fix, at the next scrub, they'll be rechecked, and if found corrected, the bad mark gets removed. To scrub only the bad blocks, you can use the scrub -p bad command.

It's recommended to run scrub only on a synced array — otherwise you get reported errors caused by unsynced data. Those errors are recognized as not being silent errors, and the blocks are not marked as bad, but such errors do show up in the output of the command. So like, sync first, bestie. 😭

The content file is modified to update the time of the last check for each block and to mark bad blocks. The parity files are NOT modified. The files in the array are NOT modified.

🛠️ fix

Fixes all the files and the parity data.

All files and parity data are compared with the snapshot state saved in the last sync. If a difference is found, it's reverted to the stored snapshot.

WARNING! The fix command does not differentiate between errors and intentional modifications. It unconditionally reverts the file state to the last sync. Like, it will absolutely body your changes with zero remorse. 💀

If no other option is specified, the entire array is processed. Use the filter options to select a subset of files or disks to operate on.

To fix only the blocks marked bad during sync and scrub, use the -e, --filter-error option. Unlike other filter options, this one applies fixes only to files that are unchanged since the latest sync.

SnapRAID renames all files that cannot be fixed by adding the .unrecoverable extension.

Before fixing, the entire array is scanned to find any files moved since the last sync operation. These files are identified by their timestamp, ignoring their name and directory, and are used in the recovery process if necessary. If you moved some of them outside the array, you can use the -i, --import option to specify additional directories to scan.

Files are identified only by path, not by inode.

The content file is NOT modified. The parity files are modified if necessary. The files in the array are modified if necessary. 🎀

✅ check

Verifies all the files and the parity data.

It works like fix, but it only simulates a recovery and no changes are written to the array. Fake it till you make it, but make it harmless. ✨

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 scrub.

If you use the -a, --audit-only option, only the file data is checked, and the parity data is ignored for a faster run. Speedrun strats fr. 🏃‍♀️💨

Files are identified only by path, not by inode.

Nothing is modified.

📋 list

Lists all the files contained in the array at the time of the last sync.

With -v or --verbose, the subsecond time is also shown. Extra detail, no notes. 🔍

Nothing is modified. 💜

👯 dup

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.

Nothing is modified. 🍓

🌊 pool

Creates or updates a virtual view of all the files in your disk array in the pooling directory.

The files are not copied but linked using symbolic links. Clean, cheap, iconic. 🎀

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. She's respectful like that. 🫶

Nothing is modified outside the pool directory.

💾 devices

Prints the low-level devices used by the array.

This command displays the device associations in the array and is mainly intended as a script interface.

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.

In most cases, you have one low-level device for each disk in the array, but in some more complex configurations, you may have multiple low-level devices used by a single disk in the array.

Nothing is modified. ⭐

🫰 touch

Sets an arbitrary sub-second timestamp for all files that have it set to zero.

This improves SnapRAID's ability to recognize moved and copied files, since it makes the timestamp almost unique, reducing possible duplicates. Sneaky little glow-up for your metadata. ✨🌈

More specifically, if the sub-second timestamp is not zero, a moved-or-copied file gets ID'd as such when it matches the name, the size, and the timestamp. But if the sub-second timestamp is zero, then it only counts as a copy when the full path, the size, and the timestamp all match. 💅

And the second-precision timestamp? Untouched, bestie. So every single date and time on your files stays exactly as it was. Bestie behavior, no cap. 🫶

🌀 rehash

Schedules a rehash of the entire array. Okay iconic.

This command switches up the hash kind being used — typically when you're upgrading from a 32-bit system to a 64-bit one, so you can go from MurmurHash3 to the faster SpookyHash. ✨

And if you're already on the optimal hash? It literally does nothing and just tells you no action is needed. Slay, efficient. 💅

Heads up: the rehash doesn't happen immediately — it goes down progressively during sync and scrub. 🐌✨

You can peek at the rehash state with status. 👑

During the rehash, SnapRAID keeps full functionality — the one exception being that dup can't detect duplicated files that use a different hash. Noted. 💀

🌸 locate

Finds files stored in the parity disks. For each matching file it prints its location inside the parity file plus the number of fragments it occupies. Iconic little detective moment. 🔍

You can use the -t, --tail option to restrict the operation to files occupying the specified tail portion of the parity.

And if you want to reallocate those files, you can then reach for -W, --force-realloc-tail. But be aware — bestie, listen — those files will not be protected by parity during the reallocation process. 🙈

✨ OPTIONS ✨

SnapRAID provides the following options. Buckle up, there's a whole lot of them. 🎀

  • -c, --conf CONFIG — Picks which configuration file to use. If you don't specify one, on Unix it uses /usr/local/etc/snapraid.conf if that file exists, otherwise it falls back to /etc/snapraid.conf. On Windows, it uses snapraid.conf in the same directory as snapraid.exe. 💖
  • -f, --filter PATTERN — Filters which files get processed in check and fix. Only files matching the pattern you gave it get processed. You can use this option multiple times. Peep the PATTERN section for all the deets on how patterns work. On Unix, make sure you quote those globbing characters if you use any. This option can only be used with check and fix. It cannot be used with sync and scrub, because those always process the entire array. No shortcuts, periodt. 🌈
  • -d, --filter-disk NAME — Filters which disks get processed in check, fix, up, and down. You have to give it a disk name as defined in the configuration file. You can also name parity disks with parity, 2-parity, 3-parity, etc., to limit the operation to a specific parity disk. If you combine multiple --filter, --filter-disk, and --filter-missing options, only the files matching all the filters get selected. This option can be used multiple times. It can only be used with check, fix, up, and down. It cannot be used with sync and scrub, because those always process the entire array. 🔥
  • -m, --filter-missing — Filters which files get processed in check and fix. Only files that are missing or deleted from the array get processed. When you use it with fix, it acts like an undelete command. 👻 If you combine multiple --filter, --filter-disk, and --filter-missing options, only the files matching all the filters get selected. This option can only be used with check and fix. It cannot be used with sync and scrub, because those always process the entire array. 💅
  • -e, --filter-error — Processes the files with errors in check and fix. It only processes files that have blocks marked with silent or input/output errors during sync and scrub, as listed in status. This option can only be used with check and fix. 💀
  • -p, --plan PERC|bad|new|full — Selects the scrub plan. If PERC is a numeric value from 0 to 100, it's interpreted as the percentage of blocks to scrub. Instead of a percentage you can name a plan: bad scrubs bad blocks, new scrubs blocks not yet scrubbed, and full scrubs everything. This option can only be used with scrub. 🧹✨
  • -o, --older-than DAYS — Selects the oldest part of the array to process in scrub. 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. This option can only be used with scrub. 🕰️
  • -a, --audit-only — In check, verifies the hash of the files without checking the parity data. If you're only interested in checking the file data, this option can significantly speed up the checking process. This option can only be used with check. ⚡
  • -h, --pre-hash — In sync, runs a preliminary hashing phase over all new data for additional verification before the parity computation. Normally in sync no preliminary hashing is done, and the new data gets hashed right before the parity computation, the first time it's read. That whole process happens when the system is under heavy load, with all disks spinning and the CPU busy. That's an extreme condition for the machine, and if it's got a latent hardware problem, silent errors may go undetected because the data hasn't been hashed yet. To dodge that risk, you can turn on pre-hash mode so all the data gets read twice to guarantee its integrity. This option also verifies files moved within the array, to make sure the move actually worked and — if needed — lets you run a fix operation before carrying on. This option can only be used with sync. 😭🔥
  • -i, --import DIR — Imports from the given directory any files deleted from the array after the last sync. If you still have those files, check and fix can use them to improve the recovery process. The files get read, subdirectories included, and are identified no matter what their name is. This option can only be used with check and fix. 📥🫶
  • -s, --spin-down-on-error — On any error, spins down all managed disks before exiting with a non-zero status code. This stops the drives from staying active and spinning after an aborted operation, which helps dodge unnecessary heat buildup and power consumption. Use this option to make sure disks are safely stopped even when a command fails. 😴💤
  • -w, --bw-limit RATE — Applies a global bandwidth limit across all disks. RATE is the number of bytes per second. You can use a multiplier like K, M, G, or T (e.g., --bw-limit 1G). 🚦
  • -t, --tail SIZE — Limits the file listing to files using no more than the specified tail size of the parity disks. You can use multipliers like K, M, G, or T (e.g. --tail 1G). This option is only valid when used together with the locate command. 🐾
  • -A, --stats — Turns on an extended status view with extra info. The screen shows two graphs: 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. Usually the slowest disk will have no buffer available, and that's what determines the maximum achievable bandwidth. The second graph shows the percentage of time spent waiting over the past 100 seconds. The slowest disk is expected to cause most of the wait time, while the other disks should have little or no wait time since they can use their buffered stripes. This graph also shows the time spent waiting on hash calculations and RAID computations. All computations run in parallel with disk operations. So as long as there's measurable wait time on at least one disk, that means the CPU is fast enough to keep up with the workload. 📊👑
  • -Z, --force-zero — Forces the insecure operation of syncing a file with zero size that was previously non-zero. If SnapRAID spots that condition, it stops proceeding unless you specify this option. This makes it easy to detect when — after a system crash — some accessed files got truncated. That's a possible condition in Linux with the ext3/ext4 file systems. This option can only be used with sync. ⚠️
  • -E, --force-empty — Forces the insecure operation of syncing a disk with all the original files missing. If SnapRAID detects that every file originally present on the disk is missing or rewritten, it stops proceeding unless you specify this option. This makes it easy to detect when a data file system isn't mounted. This option can only be used with sync. 🚨
  • -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 changed UUID, it stops proceeding unless you specify this option. This lets you detect when your disks are mounted at the wrong mount points. It is, however, allowed to have a single UUID change with single parity, and more with multiple parity, because that's the normal case when replacing disks after a recovery. This option can only be used with sync, check, or fix. 🌈💀
  • -D, --force-device — Forces the insecure operation of fixing with inaccessible disks, or with disks on the same physical device. 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 into the free space left on an already used disk, sharing the same physical device. This option can only be used with fix. 🩹
  • -N, --force-nocopy — In sync, check, and fix, disables the copy detection heuristic. Without this option, SnapRAID assumes that files with the same attributes — name, size, timestamp — are copies with the same data. That's what lets it identify copied or moved files from one disk to another and reuse the already-computed hash info to detect silent errors or recover missing files. In some rare cases this behavior can cause false positives, or a slow process because of tons of hash verifications, and this option lets you fix those issues. This option can only be used with sync, check, and fix. 🙈✨
  • -F, --force-full — in sync, this one makes it redo all the parity from the ground up, no shortcuts 💪. Reach for it when you add a new parity level, or when you reverted to an old content file but your parity data is like, newer. Instead of building parity from absolute scratch, it lets you reuse the hashes already sitting in the content file to validate data — so you keep data protection alive during the sync using the parity you already have. Only works with sync, no cap.
  • -R, --force-realloc — in sync, forces a full reallocation of your files and a rebuild of the parity. Use it to reallocate literally every file and shake off fragmentation, while still reusing the hashes in the content file to validate data. Only with sync.
⚠️ WARNING! This is for experts only, and it is highly recommended that you do not use it. You DO NOT have data protection during the sync operation. Like bestie I am begging you 😭
  • -W, --force-realloc-tail SIZE — same energy as -R, --force-realloc, except it only touches the tail portion you name — the last SIZE bytes of each parity file. It forces reallocation (aka movement) of any file fragments/blocks currently chillin' in that tail, letting them land anywhere in the parity file(s) where there's free space (yes, including existing holes 🕳️). The whole point? Shrinking the on-disk size of the parity file. If the reallocation clears the entire tail section (no blocks left using it), the parity file gets truncated and that unused tail space comes back to you, iconic. You can use multipliers like K, M, G, or T (e.g. --force-realloc-tail 1G). You can use locate -t, --tail to know in advance which files get affected.
⚠️ WARNING! Experts only, and it is highly recommended not to use it. You DO NOT have data protection during the sync operation for the affected files.
  • -l, --log FILE — writes a detailed log to the file you pick 📝. Skip this option and unexpected errors get printed straight to your screen, which can get real loud real fast if there's a ton of them. When -l, --log is set, only fatal errors — the ones that make SnapRAID stop — hit the screen. If the path starts with >>, the file opens in append mode. Every %D and %T in the name gets swapped for the date and time in the format YYYYMMDD and HHMMSS. In Windows batch files you gotta double the % character, e.g., result-%%D.log. And to use >>, you must wrap the name in quotes, e.g., ">>result.log". Want the log going to standard output or standard error? Use ">&1" and ">&2". See the snapraid_log.txt file or man page for log tag descriptions.
  • -L, --error-limit NUMBER — sets a fresh error limit before execution just stops. Default behavior: SnapRAID bails if it hits more than 100 input/output errors, which is basically the universe telling you a disk is likely failing 💀. This option affects sync and scrub, the two that are allowed to keep going after the first batch of disk errors so they can try to finish what they started. But check and fix always stop at the very first error, no exceptions.
  • -S, --start BLKSTART — starts processing from the block number you specify. Handy for retrying a check or fix on specific blocks when a disk is damaged. Mostly for advanced manual recovery, iykyk.
  • -B, --count BLKCOUNT — processes only the number of blocks you tell it to. Again, mostly for advanced manual recovery.
  • -C, --gen-conf CONTENT — generates a dummy configuration file straight from an existing content file ✨. It writes the config to standard output and will not overwrite one that already exists. Bonus: this config file also carries the info you need to reconstruct the disk mount points if you lose the entire system. Disaster prep queen 👑
  • -v, --verbose — prints more info to the screen. Specify it once and it prints excluded files plus extra statistics. Heads up: this option has no effect on the log files.
  • -q, --quiet — prints less to the screen 🤫. Once removes the progress bar; twice removes the running operations; three times the info messages; four times the status messages. Fatal errors are always printed no matter what. Also no effect on the log files.
  • -H, --help — prints a short help screen.
  • -V, --version — prints the program version.

🎀 CONFIGURATION 🎀

SnapRAID needs a configuration file so it knows where your disk array lives and where to stash the parity information.

On Unix, it uses the file /usr/local/etc/snapraid.conf if it exists — otherwise it falls back to /etc/snapraid.conf. On Windows, it uses the file snapraid.conf in the same directory as snapraid.exe.

It must contain the following options (case-sensitive — do not play with the caps 🔤):

💖 parity FILE [,FILE] ...

Defines the files used to store the parity information. Parity is what gives you protection from a single disk failure, similar to RAID5. 🛡️

You can specify multiple files, and they must be on different disks. When one file cannot grow anymore, the next one gets used. The total space available must be at least as large as the largest data disk in the array.

You can add more parity files later, but you cannot reorder or remove them.

Keeping the parity disks reserved for parity is the move — that way they don't become fragmented, and performance stays nice.

On Windows, 256 MB is left unused on each disk so you don't get the warning about full disks.

This option is mandatory and can be used only once.

💖 (2,3,4,5,6)-parity FILE [,FILE] ...

Defines the files used to store extra parity information.

For each parity level you specify, one additional level of protection switches on:

  • 2-parity enables RAID6 dual parity.
  • 3-parity enables triple parity.
  • 4-parity enables quad (four) parity.
  • 5-parity enables penta (five) parity.
  • 6-parity enables hexa (six) parity.

Each parity level requires the presence of all previous parity levels. Chain 'em, don't skip 'em 🔗

The same considerations as for the parity option apply.

These options are optional and can be used only once.

💖 z-parity FILE [,FILE] ...

Defines an alternate file and format to store triple parity.

This one is an alternative to 3-parity, primarily made for low-end CPUs like ARM or AMD Phenom, Athlon, and Opteron that don't support the SSSE3 instruction set. In those cases it gives you better performance.

This format is similar to but faster than the one used by ZFS RAIDZ3. Like ZFS, it does not work beyond triple parity.

When you use 3-parity, you'll get warned if it's recommended to switch to the z-parity format for a performance boost.

You can convert from one format to another by adjusting the configuration file with whatever z-parity or 3-parity file you want, then using fix to recreate it 🔄

💖 content FILE

Defines the file used to store the list and checksums of every file present in your disk array.

It can go on a disk used for data, parity, or any other disk you have available. If you put it on a data disk, this file is automatically excluded from the sync process.

This option is mandatory and can be used multiple times to save multiple copies of the same file.

You must store at least one copy for each parity disk used, plus one. Extra copies do not hurt. Backups on backups bestie 💾

💖 data NAME DIR

Defines the name and mount point of the data disks in the array. NAME identifies the disk and must be unique. DIR is the mount point of the disk in the file system.

You can change the mount point whenever you need, as long as you keep the NAME fixed.

Use one of these options for each data disk in the array.

You can rename a disk later by changing the NAME directly in the configuration file and then running a sync command. When it's a rename, the association gets made using the stored UUID of the disks. Glow-up without the data loss 💅

💖 extra NAME DIR

Defines the name and mount point of additional disks you want to monitor with the smart and probe commands.

Super useful for keeping an eye on disks that aren't part of the array but are still required for the system to work — like the boot disk.

Note that these disks are not affected by the up and down commands, because they're expected to be always spinning.

💖 nohidden

Excludes all hidden files and directories. On Unix, hidden files are the ones starting with .. On Windows, they're the ones with the hidden attribute. Sneaky little things 🫣

💖 exclude/include PATTERN

Defines the file or directory patterns to exclude or include in the sync process. All patterns get processed in the order you specified them.

If the first pattern that matches is an exclude one, the file is excluded. If it's an include one, the file is included. If no pattern matches, the file is excluded when the last pattern specified is an include, or included when the last pattern specified is an exclude.

See the PATTERN section for more details on pattern specifications.

This option can be used multiple times.

💖 blocksize SIZE_IN_KIBIBYTES

Defines the basic block size in kibibytes for the parity. One kibibyte is 1024 bytes.

The default blocksize is 256, which should work for most cases.

⚠️ WARNING! This option is for experts only, and it is highly recommended not to change this value. If you ever want to change it down the line, you will need to recreate the entire parity! No take-backsies.

One reason to use a different blocksize is if you have a lot of small files — like, on the order of millions.

For each file, even if it's only a few bytes, an entire block of parity gets allocated. With many files, that can add up to a significant amount of unused parity space. When you completely fill the parity disk, you are not allowed to add more files to the data disks. But here's the thing — the wasted parity does not accumulate across data disks. Wasted space from a high number of files on one data disk limits only the amount of data on that data disk, not the others.

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.

You can check the amount of wasted space on each disk using status. 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're close to filling the parity, and it represents the space you can still waste. 👀

okay so to dodge that whole mess, you can just give parity a bigger partition, bestie 💅 for real, if your parity partition is 12.8 GB larger than your data disks, you've got enough extra room to handle up to 100,000 files on every data disk with zero wasted space. iconic.

A lil trick to score a bigger parity partition on Linux is to format it with this:

mkfs.ext4 -m 0 -T largefile4 DEVICE

The way that gives you like about 1.5% extra space, which is roughly 60 GB for a 4 TB disk, and that's enough for about 460,000 files on each data disk with no wasted space. slay. ✨

hashsize SIZE_IN_BYTES 🧠

Bestie, this one sets the hash size in bytes for the saved blocks.

The default hashsize is <yellow>16 bytes</yellow> (128 bits`), and ngl that's gonna work for basically everybody.

WARNING! This option is for experts only, and it is highly recommended not to change this value. And like, if you do wanna change it in the future, you will need to recreate the entire parity! no cap. 💀

A legit reason to reach for a different hashsize is if your system is working with limited memory. Rule of thumb: SnapRAID typically needs 1 GiB of RAM for each 16 TB of data in the array. wild, ik.

Specifically, to store the hashes of the data, SnapRAID needs approximately TS*(1+HS)/BS bytes of RAM, where TS is the total size in bytes of your disk array, BS is the block size in bytes, and HS is the hash size in bytes. let that marinate. 🫶

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:

  • RAM = (8 * 4 * 10^12) * (1+16) / (256 * 2^10) = 1.93 GiB

Switching to a hash size of 8, you get:

  • RAM = (8 * 4 * 10^12) * (1+8) / (256 * 2^10) = 1.02 GiB

Switching to a block size of 512, you get:

  • RAM = (8 * 4 * 10^12) * (1+16) / (512 * 2^10) = 0.96 GiB

Switching to both a hash size of 8 and a block size of 512, you get:

  • RAM = (8 * 4 * 10^12) * (1+8) / (512 * 2^10) = 0.51 GiB

math ate, fr fr. 🎀

autosave SIZE_IN_GIGABYTES 💾

This one auto-saves the state when syncing or scrubbing, once it's chewed through the specified amount of GB processed.

Why do you care? Because it saves you from restarting long sync commands from scratch if your machine crashes or literally anything else interrupts you. main character energy tbh 🌸

temp_limit TEMPERATURE_CELSIUS 🌡️

Sets the max allowed disk temperature, in Celsius. When you set this, SnapRAID periodically checks the temperature of all the disks using the smartctl tool. And while it's operating, the current disk temps get shown to you. 👀

If any disk goes over the limit, all operations stop, and the disks get spun down (put into standby) for however long temp_sleep says. After the sleep period, operations resume — and yes, it can absolutely pause again if the temperature limit is hit once more. 😭

During operation, SnapRAID also analyzes the heating curve of each disk and estimates the long-term steady temperature they're expected to reach if activity keeps going. The estimation is only done after the disk temperature has increased four times — that way there are enough data points to establish a reliable trend. That predicted steady temperature shows up in parentheses next to the current value and helps you figure out if your system's cooling is actually serving. 💅

That estimated temperature is for informational purposes only and has no effect on how SnapRAID behaves. The program's actions are based solely on the actual measured disk temperatures. periodt.

To do that analysis, SnapRAID needs a reference for the system temperature. It first tries to read it from available hardware sensors. If no system sensor can be accessed, it falls back to using the lowest disk temperature measured at the start of the run as the reference.

Normally, SnapRAID shows you only the temperature of the hottest disk. Wanna see all of them? Use the -A or --stats option. bestie certified. 🔥

temp_sleep TIME_IN_MINUTES 😴

Sets the standby time, in minutes, for when the temperature limit is reached. During that period, the disks stay spun down. The default is 5 minutes.

pool DIR 🗂️

Defines the pooling directory, aka where the virtual view of the disk array gets created using the pool command.

The directory must already exist. SnapRAID is not your dad, it won't make it for you. 🙈

share UNC_DIR 🌐

Defines the Windows UNC path you need to access the disks remotely.

If you specify this option, the symbolic links created in the pool directory use this UNC path to reach the disks. Without it, the symlinks generated use only local paths — which means you can't share the pool directory over the network. tragic, but that's just how it is. 🦋

The symbolic links are formed using the UNC path you specified, adding the disk name as specified in the data option, and finally adding the file directory and name.

This option is required only for Windows.

smartctl DISK/PARITY OPTIONS... 🔍

Defines custom smartctl options to grab the SMART attributes for each disk. You might need this for RAID controllers and some USB disks that just refuse to be auto-detected. rude. 😤

The %s placeholder gets replaced by the device name, but it's optional for fixed devices like RAID controllers.

DISK is the same disk name you specified in the data option.

PARITY is one of the parity names: parity, 2-parity, 3-parity, 4-parity, 5-parity, 6-parity, or z-parity.

In the specified OPTIONS, the %s string is replaced by the device name. For RAID controllers, the device is likely fixed, and you may not need to use %s.

Refer to the smartmontools documentation for possible options:

https://www.smartmontools.org/wiki/Supported_RAID-Controllers
https://www.smartmontools.org/wiki/Supported_USB-Devices

For example:

smartctl parity -d sat %s

smartignore DISK/PARITY ATTR [ATTR...] 🙈

Ignores the specified SMART attribute when SnapRAID is computing the probability of disk failure. This one's your bestie if a disk is reporting unusual or straight-up misleading values for a particular attribute.

DISK is the same disk name you specified in the data option.

PARITY is one of the parity names: parity, 2-parity, 3-parity, 4-parity, 5-parity, 6-parity, or z-parity. The special value * can be used to ignore the attribute on all disks. 🌈

For example, to ignore the Current Pending Sector Count attribute on all disks:

smartignore * 197

To ignore it only on the first parity disk:

smartignore parity 197

Examples 📝

An example of a typical configuration for Unix is:

parity /mnt/diskp/snapraid.parity
content /mnt/diskp/snapraid.content
content /var/lib/snapraid/snapraid.content
data d1 /mnt/disk1/
data d2 /mnt/disk2/
data d3 /mnt/disk3/
exclude /lost+found/
exclude /tmp/
smartctl d1 -d sat %s
smartctl d2 -d usbjmicron %s
smartctl parity -d areca,1/1 /dev/sg0
smartctl 2-parity -d areca,2/1 /dev/sg0

An example of a typical configuration for Windows is:

parity E:\snapraid.parity
content E:\snapraid.content
content C:\snapraid\snapraid.content
data d1 G:\array\
data d2 H:\array\
data d3 I:\array\
exclude Thumbs.db
exclude \$RECYCLE.BIN
exclude \System Volume Information
smartctl d1 -d sat %s
smartctl d2 -d usbjmicron %s
smartctl parity -d areca,1/1 /dev/arcmsr0
smartctl 2-parity -d areca,2/1 /dev/arcmsr0

copy one of these, tweak the paths to match your setup, and you're literally ready to go. you got this 🫶👑

✨ PATTERN ✨

Okay bestie, so patterns are how you tell SnapRAID which files to keep and which ones to yeet out of the process. You can use globbing characters to match files and paths all flexibly, iykyk. 💅

The question mark ? matches any single character, but not the directory separator. So it's giving "variable filename characters, but stay in your own lane, one directory level only." 🎀

The single star * matches any sequence of characters, but like the question mark, it never crosses directory boundaries. It stops dead at the forward slash, so it only vibes within a single path component. This is the classic wildcard behaviour you already know from shell globbing. ✨

The double star ** is the powerful one — it matches any sequence of characters including directory separators, so patterns can reach across multiple directory levels. When ** is embedded directly in a pattern, it can match zero or more characters including slashes between the surrounding literal text. 👑

The most iconic use of ** is the special form /**/. This matches zero or more complete directory levels, which means you can match files at any depth in a directory tree without knowing the exact path structure. For example, the pattern src/**/main.js matches:

  • src/main.js (skipping zero directories)
  • src/ui/main.js (skipping one directory)
  • src/ui/components/main.js (skipping two directories)

Character classes using square brackets match a single character from a specified set or range. Like the other single-character patterns, they do not match directory separators. Classes support ranges and negation using an exclamation mark.

The fundamental distinction to remember, and this is the main character moment of the whole section: *, ?, and character classes all respect directory boundaries and only match within a single path component, while ** is the only pattern that can match across directory separators. Periodt. 💀

There are four different types of patterns:

  • FILE — selects any file named FILE. This pattern applies only to files, not directories.
  • DIR/ — selects any directory named DIR and everything inside. This pattern applies only to directories, not files.
  • /PATH/FILE — selects the exact specified file path. This pattern applies only to files, not directories.
  • /PATH/DIR/ — selects the exact specified directory path and everything inside. This pattern applies only to directories, not files.

When you specify an absolute path starting with /, it is applied at the array root directory, not the local file system root directory. Not me almost getting that wrong 🙈

On 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.

If the file name contains a *, ?, [, or ] character, you must escape it so it doesn't get interpreted as a globbing character. In Unix the escape character is \; in Windows it's ^. When the pattern is on the command line, you must double the escape character so the command shell doesn't eat it first. 🫶

In the configuration file, you can use different strategies to filter the files to process. The simplest approach is to use only exclude rules to remove all the files and directories you don't want to process. For example:

# Excludes any file named `*.unrecoverable`
exclude *.unrecoverable
# Excludes the root directory `/lost+found`
exclude /lost+found/
# Excludes any subdirectory named `tmp`
exclude tmp/

The opposite approach is to define only the files you want to process, using only include rules. For example:

# Includes only some directories
include /movies/
include /musics/
include /pictures/

The final approach is to mix exclude and include rules. In this case, the order of rules is important — earlier rules take precedence over later ones. To simplify, you can list all the exclude rules first and then all the include rules. For example:

# Excludes any file named `*.unrecoverable`
exclude *.unrecoverable
# Excludes any subdirectory named `tmp`
exclude tmp/
# Includes only some directories
include /movies/
include /musics/
include /pictures/

On the command line, using the -f option, you can only use include patterns. For example:

# Checks only the .mp3 files.
# In Unix, use quotes to avoid globbing expansion by the shell.
snapraid -f "*.mp3" check

In Unix, when using globbing characters on the command line, you must quote them to prevent the shell from expanding them. Otherwise your shell is gonna do the most and ruin your whole vibe. 😭

🦋 IGNORE FILE 🦋

In addition to the global rules in the configuration file, you can drop .snapraidignore files in any directory within the array to define decentralized exclusion rules. It's giving local girlboss energy. 💖

Rules defined in .snapraidignore are applied after the rules in the configuration file. This means they have a higher priority and can be used to exclude files that were previously included by the global configuration. Effectively, if a local rule matches, the file is excluded regardless of the global include settings.

The pattern logic in .snapraidignore mirrors the global configuration, but anchors patterns to the directory where the file is located:

  • FILE — selects any file named FILE in this directory or below. This follows the same globbing rules as the global pattern.
  • DIR/ — selects any directory named DIR and everything inside, residing in this directory or below.
  • /PATH/FILE — selects the exact specified file relative to the location of the .snapraidignore file.
  • /PATH/DIR/ — selects the exact specified directory and everything inside, relative to the location of the .snapraidignore file.

Unlike the global configuration, .snapraidignore files only support exclusion rules — you cannot use include patterns or negation (!). No exceptions bestie, that's just the rules. 🚫

For example, if you have a .snapraidignore in /mnt/disk1/projects/:

# Excludes ONLY /mnt/disk1/projects/output.bin
/output.bin
# Excludes any directory named `build` inside projects/
build/
# Excludes any .tmp file inside projects/ or its subfolders
*.tmp

🌸 CONTENT 🌸

SnapRAID stores the list and checksums of your files in the content file.

It's a binary file that lists all the files present in your disk array, along with all the checksums to verify their integrity. Iconic little database, honestly. ⭐

This file is read and written by the sync and scrub commands, and read by the fix, check, and status commands.

🌈 PARITY 🌈

SnapRAID stores the parity information of your array in the parity files.

These are binary files containing the computed parity of all the blocks defined in the content file.

These files are read and written by the sync and fix commands, and only read by the scrub and check commands. No writing, just vibes. ✨

💜 ENCODING 💜

SnapRAID in Unix ignores any encoding. It reads and stores the file names with the same encoding used by the file system.

In Windows, all names read from the file system are converted and processed in UTF-8 format.

To have file names printed correctly, you must set the Windows console to UTF-8 mode with the command chcp 65001 and use a TrueType font like Lucida Console as the console font. This affects only the printed file names — if you redirect the console output to a file, the resulting file is always in UTF-8 format. Slay. 🎀

🔥 EXIT CODE 🔥

SnapRAID terminates with the following error codes:

  • 0 — Everything OK.
  • 1 — The command encountered some errors.
  • 2 — The diff command found everything is OK, but a sync is needed.

This file is Copyright (C) 2026 Andrea Mazzoleni

🫶 SEE ALSO 🫶

snapraid_log(1), snapraidd(1), rsync(1)

And that's the whole page bestie, we made it 💖 the footer's source is SnapRAID B...Disk Arrays(1) (date stamp included up in the corner), and I'm obsessed with the fact that you read the entire thing. Go forth and sync responsibly. ✨💅🌙

📦 where this page comes from