-SnapRAID is an application able to make a partial backup of your disk array. -If some of the disks of your array fail, even if they are completely broken, you will be able to recover their content. -It's only a partial backup, because it doesn't allow to recover from a failure of the whole array, -but only if the number of failed disks are under a predefined limit. +SnapRAID is an application that creates a partial backup of your disk array. +If some disks in your array fail, even if they are completely broken, you can recover their contents. +It provides only a partial backup because it does not allow recovery from a failure of the entire array, +but only if the number of failed disks is below a predefined limit.
--RAIDs are mirroring solutions that propagate changes immediately to the parity data. -In this sense, RAIDs are not backups, because they don't allow to restore an old state of the array. +RAID solutions mirror data and propagate changes immediately to the parity data. +In this sense, RAID systems are not backups because they do not allow restoration of an earlier state of the array.
-SnapRAID is instead more similar at a backup solution, and you can restore the state of the last backup. -For example, with SnapRAID, if you delete by accident a file, you can easily restore it. +SnapRAID, however, is more akin to a backup solution, allowing you to restore the state of the last backup. +For example, with SnapRAID, if you accidentally delete a file, you can easily recover it.
-Others advantages over traditional RAID5/6 solutions are: +Other advantages over traditional RAID5/6 solutions include:
-Obviously RAID has other advantages, like having a better speed due data striping. -What is best for you, depends on your specific use case. +RAID has advantages, such as better speed due to data striping. +The best choice depends on your specific use case.
--SnapRAID creates a file-system snapshot conceptually similar at other snapshot solutions. -The difference is that the purpose of SnapRAID is to be able to recover a disk to the saved state -after a complete disk failure. +SnapRAID creates a file-system snapshot conceptually similar to other snapshot solutions. +However, its primary purpose is to recover a disk to its saved state after a complete disk failure.
-SnapRAID is more similar at the RAID-Z/RAID functionality of ZFS/Btrfs. -Compared to them, SnapRAID has the following advantages: +SnapRAID is more akin to the RAID-Z/RAID functionality of ZFS/Btrfs. +Compared to them, SnapRAID offers the following advantages:
-Obviously ZFS/Btrfs have other advantages, like being real-time solutions. -What is best for you, depends on your specific use case. +ZFS and Btrfs have advantages, such as being real-time solutions. +The best choice depends on your specific use case.
--With a normal backup solution you always need as much space as the full disk array for the backup. -With SnapRAID you need only one additional parity disk to be able to recover the most common case of a single disk failure. -Adding more parity disks, you can recover from more disk failures. +With a typical backup solution, you need as much space as the entire disk array for the backup. +With SnapRAID, you need only one additional parity disk to recover from the most common case of a single disk failure. +Adding more parity disks allows recovery from additional disk failures.
-Note that only a full backup allows to recover from a complete failure of the disk array and -it's surely the preferred solution if you can afford it. -SnapRAID is a good option if a full backup is not a possible solution. +Note that only a full backup allows recovery from a complete failure of the disk array, +making it the preferred solution if you can afford it. +SnapRAID is a good option when a full backup is not feasible.
--You can see the Compare page to see it compared to other similar solutions. +Visit the Compare page to see a comparison with other similar solutions.
-A strong advantage of SnapRAID is the integrity and silent error management that is at the same level (if not better) -of the ZFS and Btrfs file-systems. Instead, unRAID and Storage Space have no integrity check at all! -FlexRAID is at least able to report silent errors, but not to fix them. +A key advantage of SnapRAID is its integrity and silent error management, which is at the same level as (or better than) +ZFS and Btrfs file systems. In contrast, unRAID and Windows Storage Spaces lack integrity checks.
-Nothing. It's a FreeSoftware application released with the GPLv3 license. +Nothing. SnapRAID is a free software application released under the GPLv3 license.
--Go to the Forum. +Visit the Forum.
--No. SnapRAID is a command line application. -But there is the Elucidate external GUI, -and a plugin for OpenMediaVault. +No, SnapRAID is a command-line application. +However, there is an external GUI called Elucidate, +and a plugin for OpenMediaVault.
--SnapRAID provides a basic virtual views/storage pooling solution, but it's also compatible -with any other pooling solutions. +SnapRAID provides a basic virtual views/storage pooling solution but is also compatible with other pooling solutions.
-For encryption, SMART monitoring, Power control and Data Recovery you can use other tools. -Here some suggestions: +For encryption, SMART monitoring, power control, and data recovery, you can use other tools. +Here are some suggestions:
| Linux | Windows | Mac OS X | ||
|---|---|---|---|---|
| Encryption |
-dmcrypt/LUKS +dm-crypt/LUKS (tutorial) |
VeraCrypt | - | |
| SMART monitor | +SMART monitoring | smartmontools, GSmartControl | @@ -326,13 +313,13 @@ Discontinued? 28/5/2014||
| Power Control | +Power control | hdparm | hdparm | |
| Data recovering | +Data recovery | ddrescue, safecopy, @@ -343,84 +330,81 @@ Discontinued? 28/5/2014 |
-No. If you have a limited amount of data that can be easily saved in an external USB HD, -or in online backup services, it doesn't make sense to use SnapRAID. -SnapRAID should be used when you have to backup a very large amount of data, -many Tera bytes, and a full backup copy of a such amount of data is not possible -in any other way. +No. If you have a limited amount of data that can be easily saved to an external USB drive +or an online backup service, using SnapRAID is unnecessary. +SnapRAID is best suited for backing up a very large amount of data, +such as many terabytes, where a full backup copy is not feasible.
--No. For the disk used for booting your machine and containing the OS files, -it's better to use another solution, like RAID1 or a mirror copy. -SnapRAID needs an OS to run, and then it cannot recover the OS if the OS is missing. +No. For the disk used to boot your machine and containing the OS files, +it’s better to use another solution, such as RAID1 or a mirror copy. +SnapRAID requires an operating system to run and cannot recover the OS if it is missing.
- --No. It's not possible to use SnapRAID to only hash files. The hashing used by SnapRAID is meant to be used -in combination of parity computation, and it's not the best implementation for a hash only solution. +No, SnapRAID cannot be used solely to hash files. Its hashing is designed to work in combination with parity computation +and is not optimized for hashing alone.
-You can find a list of file verification tools at: -Wikipedia: Comparison_of_file_verification_software. +For a list of file verification tools, see: +Wikipedia: Comparison of file verification software.
+For a setup example in Ubuntu 14.04, see Zack's SnapRAID tutorial. +
-As a rule of thumb you can stay with one parity disk (RAID5) with up to four data disks, -and then using one parity disk for each group of seven data disks, like in the table: +As a rule of thumb, use one parity disk (RAID5) for up to four data disks, +and then add one parity disk for each group of seven data disks, as shown in the table:
| Parities | Data disks | |
|---|---|---|
| 1/Single Parity/RAID5 | -2 - 4 | +2–4 |
| 2/Double Parity/RAID6 | -5 - 14 | +5–14 |
| 3/Triple Parity | -15 - 21 | +15–21 |
| 4/Quad Parity | -22 - 28 | +22–28 |
| 5/Penta Parity | -29 - 35 | +29–35 |
| 6/Hexa Parity | -36 - 42 | +36–42 |
-This table takes into account that more parity levels also help to recover from unsynced array, -and that likely you are running all the disks in the same box and environment, meaning that -their failures could be correlated. +This table accounts for the fact that more parity levels help recover from an unsynced array +and that disk failures may be correlated if all disks are in the same environment.
--Take care that multiple failures happen. At now the worst case reported in the SnapRAID history, -is a four disks failure, successfully recovered using four parities. +Multiple failures can occur. The worst case reported in SnapRAID’s history +is a four-disk failure, successfully recovered using four parities.
--Some interesting articles about number of parity levels and failure rate of disks are: +For more information on parity levels and disk failure rates, see: Why RAID 5 stops working in 2009, Why RAID 6 stops working in 2019, Does RAID 6 stop working in 2019?, @@ -428,51 +412,49 @@ Some interesting articles about number of parity levels and failure rate of disk How long do disk drives last?.
--For the data disks, follow these suggestions: +For data disks, consider these suggestions:
| Data | Result | |
|---|---|---|
| Any | -OK. In general you can use whatever file-sytem you like. Just see the following notes for some exceptions. | +OK. You can generally use any file system you prefer, with some exceptions noted below. |
| Btrfs | -OK. Ensure to build SnapRAID with the libblkid library to get UUID support. -You will be warned at every run if this doesn't happen. -Note that multiple Btrfs snapshots are not supported. - | +OK. Ensure SnapRAID is built with the libblkid library for UUID support. +You will be warned at each run if this is not the case. +Note that multiple Btrfs snapshots are not supported. |
| ZFS | -Partial. You won't get UUID support, but this doesn't prevent the use of the core SnapRAID functionalities. -Note that multiple ZFS snapshots are not supported. - | +Partial. UUID support is unavailable, but core SnapRAID functionalities remain usable. +Note that multiple ZFS snapshots are not supported. |
| FAT | -Unsure. There are reports -of duplicate inodes cases. NTFS is anyway a lot faster. Use it instead. | +Uncertain. There are reports +of duplicate inode cases. NTFS is significantly faster and recommended instead. |
| ReFS | -No. ReFS uses 128 bit inodes, -and SnapRAID doesn't support them yet. - | +No. ReFS uses 128-bit inodes, +which SnapRAID does not yet support. |
-For the parity disks, follow these suggestions: +For parity disks, consider these suggestions:
| Parity | Result | |
|---|---|---|
| ext4 | -OK if the disks are NOT bigger than 16 TB. The parity is stored in a single big file, and ext4 has a upper limit of 16 TB for file size. | +OK if disks are not larger than 16 TB. The parity is stored in a single large file, and ext4 has a 16 TB file size limit. |
| XFS | @@ -480,24 +462,22 @@ For the parity disks, follow these suggestions:||
| Btrfs | -OK. But ensure to build SnapRAID with the libblkid library to get UUID support. -You will be warned at every run if this doesn't happen. | +OK. Ensure SnapRAID is built with the libblkid library for UUID support. +You will be warned at each run if this is not the case. |
| JFS | -No. It doesn't support the fallocate() command needed to allocated the parity files.
- -It also doesn't seem to implement at the best the posix_fadvise() command. |
+No. It does not support the fallocate() command needed to allocate parity files. +It also does not optimally implement the posix_fadvise() command. |
| NTFS | -OK in Windows. No in Linux, as it doesn't support fallocate() command needed to allocated the parity files. -You can anyway use it if you limit the use of the parity disk to contain only the parity file. - | +OK in Windows. Not supported in Linux, as it does not support the fallocate() command needed to allocate parity files. +You can use it if the parity disk contains only the parity file. |
| FAT | -No. You cannot store files bigger than 4 GB. It's also not journaled. Use NTFS instead. | +No. Files larger than 4 GB cannot be stored. It is also not journaled. Use NTFS instead. |
| HFS+ | @@ -506,135 +486,129 @@ You can anyway use it if you limit the use of the parity disk to contain only th
-In Linux, to get more space for the parity, it's recommended to format the parity file-system with the -m 0 -T largefile4 options. -Like: +In Linux, to maximize space for the parity file system, format it with the -m 0 -T largefile4 options, like:
mkfs.ext4 -m 0 -T largefile4 DEVICE
-On a 8 TB disk you can save about 400 GB. This is also expected to be as fast as the default, if not faster. +On an 8 TB disk, this can save about 400 GB. It is also expected to be as fast as, or faster than, the default.
-For best performance it's recommended to have all the disks connected with SATA and not with USB. +For optimal performance, connect all disks via SATA, not USB.
-Check Raj's Prototype Builds -for some examples of hardware setups. +See Raj's Prototype Builds +for examples of hardware setups.
-For choosing harddisk, you can check Backblaze's What Hard Drive Should I Buy?, +For choosing hard drives, refer to Backblaze's What Hard Drive Should I Buy? and Backblaze's Enterprise Drives: Fact or Fiction?.
-No. SnapRAID is usually not CPU bound. The limiting factor is the read performance from disks. -So, also a single core CPU should be enough. +No. SnapRAID is typically not CPU-bound; the limiting factor is disk read performance. +A single-core CPU is usually sufficient.
-For example, in my system I get a combined read speed of 400 MiB/s, -but SnapRAID is able to hash at 12000 MiB/s in a single core. +For example, in my system, I achieve a combined read speed of 400 MiB/s, +but SnapRAID can hash at 12,000 MiB/s on a single core.
--Yes. SnapRAID works better in a 64 bit operating system. It can access more than 4 GiB of memory, +Yes. SnapRAID performs better on a 64-bit operating system, as it can access more than 4 GiB of memory and use faster hashing and parity algorithms. -Anyway, if you have less than 30 TB of data, it performs very well also using a 32 bit -operating system. +However, for less than 30 TB of data, it performs well on a 32-bit operating system too.
--Approximatively, SnapRAID requires 1 GiB of memory for 16 TB of data. +Approximately, SnapRAID requires 1 GiB of memory for every 16 TB of data.
-If you have less memory than required, the recommended option is to install more memory in the machine. +If you have insufficient memory, the recommended solution is to install more memory.
-Otherwise you have to increase the blocksize option in the configuration file. -The memory occupation is inversely proportional at the select block_size. -For example, using "blocksize 512", instead of the default 256, halves the memory occupation. -But take care that using a bigger block size will also increase the amount of wasted space -in the parity files. +Alternatively, increase the blocksize option in the configuration file. +Memory usage is inversely proportional to the selected block size. +For example, using "blocksize 512" instead of the default 256 halves memory usage. +However, a larger block size increases wasted space in parity files.
-Note that running with memory swapped to disk is not recommended because it will be a huge slowdown. +Running with memory swapped to disk is not recommended, as it significantly slows performance.
--Yes! 20% of the disks die before 4 years of life, as +Yes. Approximately 20% of disks fail within four years, as reported by Backblaze's How long do disk drives last?. -Monitoring SMART attributes you can anticipate the failures and avoid to lose data! +Monitoring SMART attributes can help anticipate failures and prevent data loss.
-If you see one of the SMART attributes +If any of the SMART attributes Reallocated_Sector_Ct (5), Reported_Uncorrect (187), Command_Timeout (188), Current_Pending_Sector (197), -and Offline_Uncorrectable (198) -different than zero, replace the disk as recommended by +or Offline_Uncorrectable (198) +are non-zero, replace the disk, as recommended by Backblaze's Hard Drive SMART Stats.
-Check also Google's Failure trends in a large disk drive population -where is found that: +See also Google's Failure trends in a large disk drive population, +which found:
-after the first reallocation, drives are +After the first reallocation, drives are over 14 times more likely to fail within 60 days than drives without reallocation counts.-after the first probational event, drives +After the first probational event, drives are 16 times more likely to fail within 60 days than drives with zero probational counts.-after the first offline reallocation, drives have over +After the first offline reallocation, drives have over 21 times higher chances of failure within 60 days than drives without offline reallocations.-that also recommens to replace the disk after the first error in the SMART attributes Reallocated_Sector_Ct (5), -Current_Pending_Sector (197) and Offline_Uncorrectable (198). +These findings recommend replacing a disk after the first error in the SMART attributes Reallocated_Sector_Ct (5), +Current_Pending_Sector (197), or Offline_Uncorrectable (198).
-Is it possible to use SnapRAID in a dual boot configuration, like Windows and Linux?
+Is it possible to use SnapRAID in a dual-boot configuration, such as Windows and Linux?
-Yes. It's possible to use SnapRAID in a dual boot configuration. Doesn't matter the OS combination used. +Yes, SnapRAID can be used in a dual-boot configuration, regardless of the OS combination.
-In such case it's recommended to run SnapRAID only from one OS. -In theory, it should also work if run in both OS. -But it's a scenario not really tested, and there is always the risk to mess-up things, -like using different SnapRAID version, configuration, content files, and so on. +It is recommended to run SnapRAID from only one OS. +While it may work if run from both OSes, this scenario is not thoroughly tested and risks issues +due to different SnapRAID versions, configurations, or content files.
Configuration
-What's the SnapRAID 'content' file?
+What is the SnapRAID 'content' file?
-It's the file used by SnapRAID to save the list of all files present in your array with -all the checksum, timestamp and any other information needed. +The content file stores the list of all files in your array, including their checksums, timestamps, and other necessary information.
-These file will be of about few GiB depending of how big is your array. -Approximatively for 10 TB of data, you'll need 500 MiB of content file. +This file will be approximately a few GiB in size, depending on the array’s size. +For 10 TB of data, the content file will be about 500 MiB.
What are the SnapRAID 'parity' and 'N-parity' files?
-They are the files used by SnapRAID to store the parity data used in recovering. +These files store the parity data used for recovery.
-These files will grow in size as the biggest amount of data stored in a single disk -of the array. +Their size grows to match the largest amount of data stored on any single disk in the array.
-How to configure SAMBA to share the Pool directory
+How do I configure SAMBA to share the pool directory?
-To configure SAMBA to share the pool directory, for example /pool, you should add to -your /etc/samba/smb.conf the following options: +To configure SAMBA to share the pool directory (e.g., /pool), add the following options to +your /etc/samba/smb.conf:
# In the global section of smb.conf @@ -649,143 +623,135 @@ guest ok = yes wide links = yes-How to use more disks than drive letters in Windows?
+How can I use more disks than available drive letters in Windows?
-You can use Volume Mount points. You can mount a disk in a directory without -using a drive letter. Just like in Linux. +Use Volume Mount Points to mount a disk in a directory without +using a drive letter, similar to Linux.
Use
-What are the most important things to do to prevent damages?
+What are the most important steps to prevent data loss?
-If you want to minimize the probability to lose data, do this: +To minimize the risk of data loss, follow these steps:
-To add a new data disk at the array, add the new "disk" option in the configuration file, -and then run a "sync" command. +To add a new data disk to the array, add the new "disk" option in the configuration file, +then run a "sync" command:
snapraid sync
-If the disk is empty, the "sync" command will be immediate. +If the disk is empty, the "sync" command will complete immediately.
-To remove a data disk from the array do: +To remove a data disk from the array, follow these steps:
snapraid sync -E-The "-E" option tells at SnapRAID to proceed even when detecting an empty disk.
-Your array is now without any reference to the removed disk. +The array will then have no reference to the removed disk.
--To add a new parity level, add the proper "N-parity" option in the configuration file, and then run the "sync" command, -using the "-F, --force-full" option: +To add a new parity level, add the appropriate "N-parity" option in the configuration file, then run the "sync" command +with the "-F, --force-full" option:
snapraid -F sync
-The "-F" option tells at SnapRAID to recompute the full parity. +The "-F" option instructs SnapRAID to recompute the full parity.
-During the process you will be always protected because the existing parity is not modified -(note that this happens only from version 11.0). +During this process, your existing parity remains unmodified, ensuring continued protection +(note that this applies only from version 11.0).
-If you wish to remove a parity, you can simply remove the highest -"N-parity" option from the configuration and then delete the parity file. +To remove a parity level, remove the highest "N-parity" option from the configuration file and delete the parity file.
-Take care that after removing a parity file, you cannot reuse it anymore, -because it gets outdated after the next "sync" command. +Note that after removing a parity file, it cannot be reused, as it becomes outdated after the next "sync" command.
-The "scrub" command verifies all the content of the array, -and it's not possible to limit the verification to a single data disk. -To verify only a data disk, you can run a "check" audit -command limited to the disk you want to verify. +The "scrub" command verifies the entire array and cannot be limited to a single data disk. +To verify only one data disk, use the "check" audit command with the disk specified:
snapraid check -a -d DISK_NAME
-This command will verify all the check-sums of the files in the disk specified. -The other data and parity disks won't be read and they won't be verified. +This command verifies the checksums of all files on the specified disk. +Other data and parity disks are not read or verified.
-If you lost the disk, see the recovering section in the manual. -Otherwise, copy all the files in the new disk, -maintaining the same directory structure and names. +If the disk is lost, refer to the recovery section in the manual. +Otherwise, copy all files to the new disk, maintaining the same directory structure and names.
-In Linux use the command: +In Linux, use the command:
cp -av /from_dir/. /to_dir
-WARNING! If you want to use the 'rsync' or 'mc' commands, ensure that they are recent ones. +WARNING: If using 'rsync' or 'mc' commands, ensure they are recent versions. 'rsync' must be at least version 3.1.0 (2013), and 'mc' at least version 4.8.19 (2017). -Older versions are not able to copy the sub-second timestamps. +Older versions may not copy sub-second timestamps.
-In Windows use the command: +In Windows, use the command:
robocopy F:\from_dir T:\to_dir /e /copyall
-Then change the SnapRAID configuration to point the disk at the new mount point and run a "diff" -command to ensure that everything is placed correctly. +Update the SnapRAID configuration to point to the new mount point, then run a "diff" command to ensure everything is correct:
snapraid diff
-If "diff" reports some "added" or "removed" files likely you have copied files -with a different directory structure. -In such case you have to fix it, until "diff" reports only "equal", "restored" or "copied" files. +If "diff" reports "added" or "removed" files, you may have copied files with a different directory structure. +Correct this until "diff" reports only "equal", "restored", or "copied" files.
-Now you can check that the files were really copied correctly, you can run a "check" audit command -limited to the replaced disk to check the check-sum of all the files. +To verify that files were copied correctly, run a "check" audit command on the replaced disk to verify checksums:
snapraid check -a -d DISK_NAME
-Finally you can run "sync" to update the SnapRAID state. This command will be almost immediate. +Finally, run "sync" to update the SnapRAID state. This command will complete almost immediately:
snapraid sync @@ -793,41 +759,35 @@ snapraid syncHow can I replace a parity disk?
-If the disk is still accessible, first ensure to have a synced array running a sync command: +If the disk is still accessible, ensure the array is synced by running:
snapraid sync-Then you can copy the big parity file to the new disk, -and configure the new parity location in the configuration file. +Copy the parity file to the new disk and update the parity location in the configuration file.
-Then run sync again to make snapraid to recognize the new disk. This command will be almost immediate. +Run "sync" again to make SnapRAID recognize the new disk. This command will complete almost immediately:
snapraid sync-In Linux a good copy command is ddrescue. -You can use: +In Linux, a good copy command is ddrescue. For example:
ddrescue /OLD_DISK/parity /NEW_DISK/parity /tmp/copy.log-This will copy the parity file from the old to new location, and in case of errors, -it will continue copying what can be copied. -To retry to copy the problematic sections, you can just retry the same copy -command. +This copies the parity file from the old to the new location, continuing despite errors. +To retry problematic sections, repeat the same command.
-Having a partial parity file, is still beneficial, as it will still allow to recover -data as long it uses the valid part. +A partial parity file is still useful, as it allows recovery using the valid parts.
-If you have a partially damaged or totally lost parity file, you can run the "fix" command to recreate it, -but ensure to use the -d option to fix only the interested parity and not the other disks. +If the parity file is partially damaged or lost, use the "fix" command with the -d option to recreate it, targeting only the affected parity:
snapraid fix -d PARITY_NAME @@ -835,112 +795,101 @@ snapraid fix -d PARITY_NAMEHow can I safely move files from one disk to another?
-In case you need to move files from one data disk of the array to another disk -also in the array, the 100% safe way to proceed is: +To safely move files between data disks in the array, follow these steps:
-
-This process gives the guarantee that even if disks die during the sync process, -you will be able to recover everything. It also verifies that the hashes of all the -moved files are matching the original ones. +This process ensures that, even if disks fail during the sync process, +you can recover all data. It also verifies that the hashes of moved files match the originals.
--Yes, you can defragment data and parity disks. Defragmentation doesn't affect SnapRAID. +Yes, defragmentation does not affect SnapRAID.
--In Linux, you can use the ionice command with Idle priority. Like: +In Linux, use the ionice command with idle priority, like: +
ionice -c 3 snapraid sync- -
-To upgrade SnapRAID to a new version, just replace the old SnapRAID executable with the new one. -The new SnapRAID will use your existing configuration, content and parity files. +To upgrade, replace the old SnapRAID executable with the new one. +The new version will use your existing configuration, content, and parity files.
-By time to time the format of the content file changes, but a newer SnapRAID -is always able to read all old formats. So, it's always possible to upgrade. -If necessary, the content file format is updated the next time it's written. +Occasionally, the content file format changes, but newer SnapRAID versions can read all older formats. +The content file is updated to the new format the next time it is written, if necessary.
-Instead, it's in general not possible to downgrade to an old SnapRAID. -You can anyway try, and if the old SnapRAID is not able to read the new content file, -you will be advised by a proper message. +Downgrading to an older SnapRAID version is generally not possible. +If the old version cannot read the new content file, you will receive an appropriate message.
-Simply run the "fix" command using a filter for the specified file. Like: +Run the "fix" command with a filter for the specified file, like:
snapraid fix -f my_just_deleted_file
-To undelete a directory use: +To undelete a directory, use:
snapraid fix -f my_just_deleted_dir/
-To undelete all the missing files use: +To undelete all missing files, use:
snapraid fix -m-
-All the files added in the broken disk after the last "sync" command are lost. -All the other data is safe and it can be recovered. +Files added to the failed disk after the last "sync" command are lost. +All other data is safe and can be recovered.
--In the worst case, any file deleted or modified in not broken disks may prevent to recover the same amount of data in the broken disk. -For example, if you deleted 10GB of data, you may not be able to recover 10GB of data from the broken disk. -The exact amount of data lost depends on how much the deleted and broken data overlaps in the parity. +In the worst case, files deleted or modified on non-failed disks may prevent recovery of an equivalent amount of data on the failed disk. +For example, deleting 10 GB of data may prevent recovery of 10 GB from the failed disk. +The exact data loss depends on how much the deleted and failed data overlap in the parity.
-To reduce this problem you can use two parity disks. This improves a lot the chances to recover the data. +Using two parity disks significantly improves recovery chances.
-A way to be always safe, is to don't delete files, but move them to another directory in the same disk, -but outside the directory tree checked by SnapRAID. Then you can run the "sync" command and only after -its completion really delete the files. -In case you get a disk failure during the "sync", you have to just run the "fix" command specifying where -the deleted files are stored: +To ensure safety, avoid deleting files directly. Instead, move them to another directory on the same disk, +outside the SnapRAID-checked directory tree. Run the "sync" command, then delete the files. +If a disk fails during the "sync", run the "fix" command, specifying the location of the deleted files:
snapraid fix -i dir_of_deleted_files-
-You are still able to recover data. In the worst case, you will be able to recover as much data as if the -disk would have broken before the "sync". -But if the "sync" process already run for some time, SnapRAID is able to use the partially synced data -to recover more. -To improve the recovering you can also use the "autosave" configuration option to save the intermediate -content file during the sync process. +You can still recover data. In the worst case, you can recover as much data as if the disk failed before the "sync". +If the "sync" process has progressed, SnapRAID uses the partially synced data to recover more. +Using the "autosave" configuration option saves intermediate content files during the sync process, improving recovery.
-Syncing... 309505: Data error for file d4/data/index.db at position 40960 @@ -948,30 +897,26 @@ WARNING! Unexpected data error in a data disk! The block is now marked as bad! Try with 'snapraid -e fix' to recover!
-Data errors happen when SnapRAID detects that the content of a file changed but the write time of the file didn't. -This is a condition that normally should never happen and it may be the result of a silent error in the disk, -or the signal that something got wrong at the file-system level, like when you poweroff the machine without a -proper shutdown. -
-If a data error is found, the "sync" process continues, and erroneous blocks are marked as bad -and fixed at the next "fix" command. -To just fix the silent errors and not the whole array, you can use the "-e fix" command -that usually takes only few seconds. +Data errors occur when SnapRAID detects that a file’s content has changed without an updated write timestamp. +This should not happen and may indicate a silent disk error or a file system issue, such as an improper shutdown.
-If you have errors in more than on file, it's also possible that something is not working at hardware level. -The first thing to try is to check your PC memory with an automated tool like memtest86. -Another thing to check is the disk cabling and the CPU heat. +If a data error is found, the "sync" process continues, marking erroneous blocks as bad. +These can be fixed with the "-e fix" command, which typically takes only a few seconds: +
++snapraid -e fix ++
+If errors occur in multiple files, check for hardware issues. +Test your PC’s memory with a tool like MemTest86. +Also, check disk cabling and CPU temperature.
-Another possibility is that you are using programs that change files without modifying the time-stamp of the file itself.
-
-In Linux this is almost guaranteed by the operating system. The only exception is for memory mapped files
-not yet closed.
-
-In Windows it's a bit trickier. Even using normal writes, you have the guarantee of an updated time-stamp
-only after closing it.
-See the MSDN WriteFile():
+Another possibility is that a program modified files without updating their timestamps.
+In Linux, this is rare, except for memory-mapped files not yet closed.
+In Windows, timestamps are guaranteed to update only after closing a file.
+See MSDN WriteFile():
When writing to a file, the last write time is not fully updated until @@ -980,38 +925,36 @@ accurate last write time, close the file handle immediately after writing to the file.
-When using memory mapped file, the program must ensure to update the time-stamp manually, -because Windows doesn't do it automatically. -See the MSDN CreateFileMapping(): +For memory-mapped files in Windows, the program must manually update the timestamp, +as Windows does not do so automatically. +See MSDN CreateFileMapping():
-When modifying a file through a mapped view, the last modification time-stamp +When modifying a file through a mapped view, the last modification timestamp may not be updated automatically. If required, the caller should use SetFileTime -to set the time-stamp. +to set the timestamp.
-To avoid all these Windows problems, simply ensure to run "sync" when no program is using the files into the array. +To avoid these issues in Windows, run "sync" when no programs are accessing files in the array.
--To generate a log file you can use the "-l" option. +Use the "-l" option to generate a log file:
snapraid check -l mylog.log-
-These log files could be really big, many GB. If they are too big to be opened for your editor, -you can use HxD. +These log files can be large, potentially several GB. If too large for your editor, +use HxD.
--There is the dedicated -C, --gen-conf command that writes a template configuration file +Use the "-C, --gen-conf" command to generate a template configuration file compatible with your content file. -Note that this configuration requires some manual adjustments to set the disk mount points, -but in the comments you'll find the required information to do so. +Manual adjustments are needed to set disk mount points, but comments in the file provide guidance:
snapraid -C snapraid.content > snapraid.conf.new @@ -1019,25 +962,29 @@ snapraid -C snapraid.content > snapraid.conf.newTech
-If the SnapRAID "check" command says it's all OK. Is it really OK?
-Yes. SnapRAID checks all your files with a 128 bit check-sum. -If it says that they are correct, they really are. - -What integrity checksum is used?
-SnapRAID uses Murmur3 and SpookyHash 128 bit hashes. -Murmur3 is the default in 32 bit platforms, SpookyHash in the default for 64 bit ones. - -Why integrity checksum are important?
-Integrity check-sum are important to detect silent errors, -when the HD is returning garbage without reporting any error. - +If the SnapRAID "check" command reports everything is OK, is it really OK?
-An introduction to this problem is in this article: -Data corruption is worse than you know +Yes. SnapRAID verifies all files with a 128-bit checksum. +If it reports they are correct, they are. +
+ +What integrity checksum does SnapRAID use?
++SnapRAID uses Murmur3 and SpookyHash 128-bit hashes. +Murmur3 is the default on 32-bit platforms, and SpookyHash is the default on 64-bit platforms. +
+ +Why are integrity checksums important?
++Integrity checksums detect silent errors when a hard drive returns corrupt data without reporting an error.
-A good analysis of this risk is in the paper: -An Analysis of Data Corruption in the Storage Stack +For an introduction to this issue, see: +Data corruption is worse than you know. +
++For a detailed analysis, see: +An Analysis of Data Corruption in the Storage Stack:
A significant number (8% on average) of corruptions @@ -1046,147 +993,129 @@ possibility of data loss. In this case, protection against double disk failures is necessary to prevent data loss.-How can SnapRAID recover also if a disk break during a 'sync'?
+How can SnapRAID recover if a disk fails during a 'sync'?
-Before the sync process start, SnapRAID saves a special content file that contains -a description of both the states before and after the sync. -This allows SnapRAID to try two different recovery strategies. +Before starting a sync, SnapRAID saves a special content file describing both the pre- and post-sync states. +This allows SnapRAID to attempt two recovery strategies.
-For each block to recover, it first assumes that the parity was correctly computed, -just like if "sync" was completed successfully. -If this recovering fails, it then assumes that parity was not yet updated, -ignoring any new file added in the array. +For each block to recover, it first assumes the parity was correctly computed, as if the "sync" completed successfully. +If this fails, it assumes the parity was not yet updated, ignoring any new files added to the array.
-Also in this case, using a double parity helps to recover when there are overlapping changes in the array. +Using double parity improves recovery when there are overlapping changes in the array.
-Does SnapRAID allow to access data disks during a 'sync'?
+Can I access data disks during a 'sync'?
-Yes. You can safely read from data disks while a 'sync' is running. +Yes, you can safely read from data disks during a 'sync'.
-You can also write, and if this interferes with the SnapRAID 'sync', -the process will continue anyway, just skipping that written part. +You can also write, and if this interferes with the 'sync', +the process continues, skipping the written part.
-This obviously could affect a potential recovery, but it's just like if you wrote -just after the 'sync' completed. +This may affect potential recovery, but it is equivalent to writing just after the 'sync' completes.
-Does SnapRAID retry reads or writes if a disk is not working?
+Does SnapRAID retry reads or writes if a disk fails?
-No. SnapRAID never retries disk operations. It reports the error and then it tries -to continue anyway. After a limit of 100 errors, it then stops the execution. +No, SnapRAID does not retry disk operations. It reports errors and attempts to continue. +After 100 errors, it stops execution.
-In these conditions, it's better to allow the user to try to save manually as much as data possible -before the disk dies definitively. -Trying an automatic long sequence of retries, will likely kill the disk. -If you want to retry, you have to just repeat the command. +In such cases, it’s better to allow manual data recovery before the disk fails completely. +Automatic retries could further damage the disk. +To retry, repeat the command manually.
-You can control the 100 errors limit using the "-L, --error-limit" option. +You can adjust the 100-error limit using the "-L, --error-limit" option.
-In the case of "fix" and "check" commands you can restart from the interrupted point using the "-s, --start" -option specifying the block number that generated the error. +For "fix" and "check" commands, you can resume from the point of interruption using the "-s, --start" option, specifying the block number that caused the error.
-In the case of "sync" command, the latest state is anyway saved before termination. -So, just restarting it will continue where stopped. +For the "sync" command, the latest state is saved before termination, so restarting it will continue from where it stopped.
-What's the snapraid.content.lock file?
+What is the snapraid.content.lock file?
-It's a file used by SnapRAID to check if another SnapRAID instance is already running. -It's created where the first content file is placed. +This file is used by SnapRAID to check if another instance is running. +It is created where the first content file is stored.
-What's the notice about zero sub-second timestamp?
+What does the notice about zero sub-second timestamps mean?
-In the 'status' command you may now get a notice like: +In the 'status' command, you may see:
You have XXXXX files with zero sub-second timestamp. -Run the 'touch' command to set it to a not zero value. +Run the 'touch' command to set it to a non-zero value.-It means that a number of your files have a timestamp approximated at the second value, -when instead your filesystem can store a more precise timestamp, with a sub-second precision. +This indicates that some files have timestamps rounded to the nearest second, +even though your file system supports sub-second precision.
-This is not a problem by itself, but it could limit the SnapRAID effectiviness to detect -moved or copied files between different disks. +While not a problem, this may limit SnapRAID’s ability to detect moved or copied files between disks.
-You have the option to set that subsecond timestamp to a random value using the new 'touch' command. -Note that the second part of the timestamp is not modified. +You can set sub-second timestamps to a random value using the 'touch' command, which does not modify the second part of the timestamp.
Performance
-Which is the optimal hardware configuration to get the best performance?
+What is the optimal hardware configuration for the best performance?
-The most important factor is to connect all the disks using (E)SATA connections, -to avoid slowdown caused by the controller. Avoid any kind of USB disks. +The most critical factor is using (E)SATA connections for all disks to avoid controller slowdowns. +Avoid USB disks.
-The second important factor is use disks with similar performance, because the read/write -speed is limited by the slowest disk of the array. -After a sync operation, it's printed a short stats with the wait times for each disk, -that could help to identify a bottleneck caused by a slow disk. +The second factor is using disks with similar performance, as the array’s read/write speed is limited by the slowest disk. +After a sync, SnapRAID displays statistics with wait times for each disk, helping identify bottlenecks.
-As last, a fast CPU could improve the speed when having a lot of disks. -You can detect if the CPU is a limiting factor, checking the CPU usage during sync operations. +Finally, a fast CPU can improve performance with many disks. +Check CPU usage during sync operations to determine if it’s a limiting factor.
-Which is the optimal blocksize to get the best performance?
+What is the optimal block size for the best performance?
-The default blocksize should be already the best one. +The default block size is typically optimal.
-Note that increasing it doesn't necessarily improve the performance. -In some cases, it could decrease it. +Increasing it may not improve performance and could reduce it in some cases.
-Which is the optimal Linux read-ahead size to get the best performance?
+What is the optimal Linux read-ahead size for the best performance?
-The default Linux read-ahead size of 128 KiB already ensures the best performance -for the default SnapRAID block size of 256 KiB. -If you use a bigger block size, you should configure the read-ahead size to be at least equal -to half of the SnapRAID block size. +The default Linux read-ahead size of 128 KiB is optimal for SnapRAID’s default block size of 256 KiB. +If using a larger block size, set the read-ahead size to at least half the SnapRAID block size.
-For example, if you want to use a SnapRAID block size of 512 KiB, -it's recommended to configure a read-ahead size of 256 KiB for sdX using: +For example, with a SnapRAID block size of 512 KiB, configure a read-ahead size of 256 KiB for sdX using:
echo 256 > /sys/block/sdX/queue/read_ahead_kb-Note that if you want to use a SnapRAID block size smaller than 256 KiB, it's recommended to don't configure a specific -read-ahead size, and just use the default value. +For a SnapRAID block size smaller than 256 KiB, use the default read-ahead size.
-How fast are the hash and parity computation?
+How fast are the hash and parity computations?
-Murmur3 hash is very fast on 32 bits, SpookyHash is even faster on 64 bits. -The speed of parity computation is always good up to double parity, -even in architectures without SSE support. -Beyond double parity having a CPU with SSSE3 support is recommended. -For low end CPUs without SSE, there is a special, but incompatible, triple parity -support working well also without SSE. -See 'z-parity' in the manual for more info. +Murmur3 hash is very fast on 32-bit systems, and SpookyHash is even faster on 64-bit systems. +Parity computation is efficient up to double parity, even without SSE support. +Beyond double parity, a CPU with SSSE3 support is recommended. +For low-end CPUs without SSE, a special, incompatible triple-parity option is available. +See 'z-parity' in the manual for details.
-The following are the result on a Core i5-4670K @ 3.4 GHz. -You can check your values with the -T option. +The following results are from a Core i5-4670K @ 3.4 GHz. +Check your values with the -T option:
-root@redstar:/root# snapraid -T +root@redstar:/root# snapraid -T snapraid v7.0 by Andrea Mazzoleni, http://www.snapraid.it Compiler gcc 4.8.1 CPU GenuineIntel, family 6, model 60, flags mmx sse2 ssse3 sse42 avx2 @@ -1231,112 +1160,94 @@ RAID functions used for recovering with 'fix':Known Problems
-Why does my machine reboots or crashes while SnapRAID is running?
+Why does my machine reboot or crash while SnapRAID is running?
-SnapRAID pushes the system to extreme conditions, and if the machine has a latent problem, -it could result in an unexpected system crash or reboot. +SnapRAID pushes the system to extreme conditions, which may expose latent hardware or driver issues, +resulting in a system crash or reboot.
-Even if the problem happens only when SnapRAID is running, it's without any doubt a hardware -or driver issue because SnapRAID is just a standard user application that cannot reboot or -crash the system. +Although the issue occurs only when SnapRAID is running, it is undoubtedly a hardware or driver problem, +as SnapRAID is a standard user application that cannot crash or reboot the system.
-Possible thing to checks are: +Check the following:
-Likely you have too few free memory, and the Linux OOM (out-of-memory) killer -terminates SnapRAID because it's using too much memory. -You can use the Linux 'free' command to check how much free memory you have. +This is likely due to insufficient free memory, causing the Linux out-of-memory (OOM) killer +to terminate SnapRAID for using too much memory. +Check available memory with:
free -m
-If it's too small, you have to install more memory in the machine. +If memory is low, install more memory in the machine.
--This means that SnapRAID needs to grow the parity file to a size that cannot be contained in the -parity disk. +This error indicates that SnapRAID needs to expand the parity file to a size that exceeds the available space on the parity disk.
-The first thing to check is to ensure that no other data is stored in the parity disk. -Leave if only for the parity file. -Otherwise you have to move the files mentioned in the output to another data disk -to reduce the size of the needed parity. +Ensure no other data is stored on the parity disk, reserving it exclusively for the parity file. +Alternatively, move files mentioned in the output to another data disk to reduce the required parity size.
-If you are using Linux, an alternate approach is to reformat the parity disk using -specific options to increase the available space, like: +In Linux, you can reformat the parity disk to increase available space using:
mkfs.ext4 -m 0 -T largefile4 DEVICE
-The '-T largefile4' and '-m 0' options should give more space available for the parity file. +The '-T largefile4' and '-m 0' options provide more space for the parity file.
-This means that SnapRAID found two different files using the same inode. -This is theoretically something that should never happen, -but in some specific conditions is instead possible. +This error occurs when SnapRAID detects two different files using the same inode, +a condition that should theoretically never happen but can occur in specific cases.
-First ensure that the mentioned files were not modified while SnapRAID was running. -If files are renamed, deleted or recreated while SnapRAID is running, it's possible -that inodes are reused, causing this condition. +Ensure the mentioned files were not modified while SnapRAID was running. +Renaming, deleting, or recreating files during SnapRAID operation can cause inode reuse, triggering this error.
-If you are using a FAT file-system in Windows, try to convert it to NTFS. -Theoretically inodes (FileIndex) are -unique even in FAT, -but this condition was already seen in the field. +If using a FAT file system in Windows, convert to NTFS. +Although inodes (FileIndex) are theoretically unique in FAT, +this issue has been observed in practice.
--Unfortunately the Excel application does dirty tricks when handling .xls files, -that may cause the followings data error: +Excel modifies .xls files upon opening, even without saving, to store the name of the last user who accessed the file. +This allows it to warn if another user tries to open the file simultaneously. +Excel restores the original timestamp, but SnapRAID detects the modification, reporting a data error:
-Data change at file '/xxx/xxx.xls' at position '0' WARNING! Unexpected data modification of a file without parity!-
-This happens because Excel modifies the files after opening them, even if you don't press 'Save'. -It stores the name of the last user that opened it to be able to report if another user tries -to open the same file at the same time. -To avoid to have the file triggered as modified, it restores the time-stamp to its original value. -But the file was modified, and SnapRAID reports it. -
- --To workaround the problem you can see -How to prevent Excel from modifying the file on exit?, -or you can switch to the .xlsx format. +To work around this, see +How to prevent Excel from modifying the file on exit?, +or switch to the .xlsx format.
-VeraCrypt (a fork of TrueCrypt) by default has enabled the option Preserve modification time-stamp of file containers -that makes impossible at SnapRAID, and at other backup programs, to detect that a file container is changed. -Ensure to disable this option in VeraCrypt. +VeraCrypt (a fork of TrueCrypt) has a default option, Preserve modification timestamp of file containers, +that prevents SnapRAID and other backup programs from detecting changes to file containers. +Disable this option in VeraCrypt.
@@ -1368,4 +1279,3 @@ Ensure to disable this option in VeraCrypt.