diff --git a/TODO b/TODO index f953f4e0..43634a75 100644 --- a/TODO +++ b/TODO @@ -13,13 +13,6 @@ This is the list of TODO items for SnapRAID. https://github.com/linuxhw/SMART https://github.com/linuxhw/EnterpriseDrive -* Implement the use Shadow Copy in Windows for creating snapshots. -See Jens's Windows script at: -http://sourceforge.net/p/snapraid/discussion/1677233/thread/a1707211/ -https://sourceforge.net/p/snapraid/discussion/1677233/thread/5c9e670c/ -Note that a difference between Windows and Unix is that in Windows old snapshots -are automatically deleted. - * A "dependents" output option to [--test-fmt file|disk|path|dependents] for LIST. Example, snapraid LIST --test-fmt dependents >FileList_with_dependents.txt The goal is a filelist that, for every file, includes full paths to the dependent files @@ -60,9 +53,6 @@ See: https://sourceforge.net/p/snapraid/discussion/1677233/thread/a1683dd9/?limi * Add markdown support for output See: https://sourceforge.net/p/snapraid/discussion/1677233/thread/661cce8b/ -* Add ZFS support for SMART and UUID. -See latest messages at: https://sourceforge.net/p/snapraid/discussion/1677233/thread/42defa3b/ - * Change all the paths printed in the terminal as relative and not absolute. https://sourceforge.net/p/snapraid/discussion/1677233/thread/648955ec/ (Leifi in diff) https://sourceforge.net/p/snapraid/discussion/1677233/thread/5b6ef1b9/ (Miles in check + filter) diff --git a/doc/snapraid.1 b/doc/snapraid.1 index b8e260b2..b48162df 100644 --- a/doc/snapraid.1 +++ b/doc/snapraid.1 @@ -122,17 +122,29 @@ SnapRAID is a hybrid between a RAID and a backup program, aiming to combine the best benefits of both. However, it has some limitations that you should consider before using it. .PP -The main limitation is that if a disk fails and you haven\'t recently synced, -you may not be able to fully recover. -More specifically, you may be unable to recover up to the size of -the changed or deleted files since the last sync operation. -This occurs even if the changed or deleted files are not on the -failed disk. This is why SnapRAID is better suited for -data that rarely changes. +The main limitation is that if a disk fails, you can only recover data up to +the state of the last \`sync\` operation. Any data added or modifications made +since the last sync that are located on the failed disk will be lost. +Consequently, SnapRAID is primarily suited for data that rarely changes. .PP -On the other hand, newly added files don\'t prevent recovery of already -existing files. You will only lose the recently added files if they -are on the failed disk. +For data that already existed at the last sync, recovery reliability depends +on whether the \`snapshot\` option is used: +.PD 0 +.IP \(bu +With snapshot support (available on Btrfs, ZFS, Bcachefs, and NTFS), +SnapRAID can automatically maintain a frozen reference of your data disks. +This ensures that even if you modify or delete files on your live +filesystem during or after a sync, the recovery process remains +consistent and reliable. +.PD +.PD 0 +.IP \(bu +Without snapshot support, deleting or changing files after a \`sync\` +can prevent the full recovery of other failed disks. This occurs +because the parity no longer matches the modified files, even if +those files are not on the failed disk. On the other hand, newly added +files don\'t prevent recovery of already existing files. +.PD .PP Other SnapRAID limitations are: .PD 0 @@ -1434,16 +1446,16 @@ When enabled, SnapRAID creates a read\-only snapshot of your data at the start of a \'sync\'. This ensures a consistent, point\-in\-time view of your files, preventing errors caused by concurrent file modifications. .PP -This option applies exclusively to data disks formatted with the -Btrfs, Bcachefs or ZFS filesystems in Linux and NTFS in Windows. -Parity disks, or data disks using other filesystems, will always use -the live version of the filesystem. -.PP This significantly improves recovery: if a file is deleted from the live filesystem, it remains preserved in the snapshot. This prevents the parity from becoming \[dq]broken\[dq] for that block, ensuring you can still successfully recover data if another disk fails. .PP +This option applies exclusively to data disks formatted with the +Btrfs, Bcachefs or ZFS filesystems in Linux and NTFS in Windows. +Parity disks, or data disks using other filesystems, will always use +the live version of the filesystem. +.PP Snapshot creation and deletion require administrative privileges. Ensure SnapRAID is run with the necessary permissions (e.g., sudo) when this option is enabled. @@ -1814,7 +1826,7 @@ in the snapshot to reconstruct the failed disk. In case of a disk failure during an active sync process, SnapRAID is also able to read automatically from both the snapshot of the previous parity computation and the current one. -This maximizes the probability of a full recovery by +This maximizes the probability of a full recovery by providing access to the exact data blocks required to solve the parity equations, even if those blocks were modified or deleted between syncs. @@ -1876,8 +1888,8 @@ All other commands operate exclusively on the live filesystem. .SH SNAPSHOTS LIFECYCLE SnapRAID manages two specific snapshots, \`stable\` and \`pending\`, within a hidden directory at the root of each data subvolume. -In Btrfs an Bcachefs it\'s used the \`.snapraid/\` directory, in ZFS -the standard \`.zfs/snapshot/\`. +In Btrfs, Bcachefs, and NTFS it\'s used the \`.snapraid/\` directory, +in ZFS the standard \`.zfs/snapshot/\`. .PP The \`stable\` snapshot represents the state of the last successfully completed \`sync\`, containing the exact data used to @@ -1886,8 +1898,8 @@ for \`scrub\`, \`check\`, and \`fix\` commands. .PP The \`pending\` snapshot is a temporary image created at the start of a \`sync\` to provide a frozen state for parity computation. -Upon successful completion of the operation, the previous stable -snapshot is deleted, and the pending snapshot is promoted to +Upon successful completion of the operation, the previous \`stable\` +snapshot is deleted, and the \`pending\` snapshot is promoted to take its place as the new stable reference. .PP If a \`sync\` is interrupted, the \`pending\` snapshot is preserved. @@ -1896,7 +1908,7 @@ pending snapshot as it matches the filesystem state recorded in the .content file, even if the parity is only partially synchronized. .PP In the event of a \`sync\` interruption, \`check\` and \`fix\` commands -can also read from the \`stable\` snapshot to retrieve data blocks +also read from the \`stable\` snapshot to retrieve data blocks from files that were updated or deleted during the sync. This is possible because the .content file retains metadata for all modified or deleted files throughout the sync process. diff --git a/doc/snapraid.d b/doc/snapraid.d index 5dc7927f..b02b3d3b 100644 --- a/doc/snapraid.d +++ b/doc/snapraid.d @@ -56,17 +56,25 @@ Limitations the best benefits of both. However, it has some limitations that you should consider before using it. - The main limitation is that if a disk fails and you haven't recently synced, - you may not be able to fully recover. - More specifically, you may be unable to recover up to the size of - the changed or deleted files since the last sync operation. - This occurs even if the changed or deleted files are not on the - failed disk. This is why SnapRAID is better suited for - data that rarely changes. + The main limitation is that if a disk fails, you can only recover data up to + the state of the last `sync` operation. Any data added or modifications made + since the last sync that are located on the failed disk will be lost. + Consequently, SnapRAID is primarily suited for data that rarely changes. - On the other hand, newly added files don't prevent recovery of already - existing files. You will only lose the recently added files if they - are on the failed disk. + For data that already existed at the last sync, recovery reliability depends + on whether the `snapshot` option is used: + + * With snapshot support (available on Btrfs, ZFS, Bcachefs, and NTFS), + SnapRAID can automatically maintain a frozen reference of your data disks. + This ensures that even if you modify or delete files on your live + filesystem during or after a sync, the recovery process remains + consistent and reliable. + + * Without snapshot support, deleting or changing files after a `sync` + can prevent the full recovery of other failed disks. This occurs + because the parity no longer matches the modified files, even if + those files are not on the failed disk. On the other hand, newly added + files don't prevent recovery of already existing files. Other SnapRAID limitations are: @@ -1154,16 +1162,16 @@ Configuration start of a 'sync'. This ensures a consistent, point-in-time view of your files, preventing errors caused by concurrent file modifications. - This option applies exclusively to data disks formatted with the - Btrfs, Bcachefs or ZFS filesystems in Linux and NTFS in Windows. - Parity disks, or data disks using other filesystems, will always use - the live version of the filesystem. - This significantly improves recovery: if a file is deleted from the live filesystem, it remains preserved in the snapshot. This prevents the parity from becoming "broken" for that block, ensuring you can still successfully recover data if another disk fails. + This option applies exclusively to data disks formatted with the + Btrfs, Bcachefs or ZFS filesystems in Linux and NTFS in Windows. + Parity disks, or data disks using other filesystems, will always use + the live version of the filesystem. + Snapshot creation and deletion require administrative privileges. Ensure SnapRAID is run with the necessary permissions (e.g., sudo) when this option is enabled. @@ -1431,7 +1439,7 @@ Snapshots In case of a disk failure during an active sync process, SnapRAID is also able to read automatically from both the snapshot of the previous parity computation and the current one. - This maximizes the probability of a full recovery by + This maximizes the probability of a full recovery by providing access to the exact data blocks required to solve the parity equations, even if those blocks were modified or deleted between syncs. @@ -1490,8 +1498,8 @@ Snapshots Snapshots Lifecycle SnapRAID manages two specific snapshots, `stable` and `pending`, within a hidden directory at the root of each data subvolume. - In Btrfs an Bcachefs it's used the `.snapraid/` directory, in ZFS - the standard `.zfs/snapshot/`. + In Btrfs, Bcachefs, and NTFS it's used the `.snapraid/` directory, + in ZFS the standard `.zfs/snapshot/`. The `stable` snapshot represents the state of the last successfully completed `sync`, containing the exact data used to @@ -1500,8 +1508,8 @@ Snapshots Lifecycle The `pending` snapshot is a temporary image created at the start of a `sync` to provide a frozen state for parity computation. - Upon successful completion of the operation, the previous stable - snapshot is deleted, and the pending snapshot is promoted to + Upon successful completion of the operation, the previous `stable` + snapshot is deleted, and the `pending` snapshot is promoted to take its place as the new stable reference. If a `sync` is interrupted, the `pending` snapshot is preserved. @@ -1510,7 +1518,7 @@ Snapshots Lifecycle the .content file, even if the parity is only partially synchronized. In the event of a `sync` interruption, `check` and `fix` commands - can also read from the `stable` snapshot to retrieve data blocks + also read from the `stable` snapshot to retrieve data blocks from files that were updated or deleted during the sync. This is possible because the .content file retains metadata for all modified or deleted files throughout the sync process. diff --git a/doc/snapraid.txt b/doc/snapraid.txt index 043a85c8..d46e89da 100644 --- a/doc/snapraid.txt +++ b/doc/snapraid.txt @@ -66,17 +66,25 @@ SnapRAID is a hybrid between a RAID and a backup program, aiming to combine the best benefits of both. However, it has some limitations that you should consider before using it. -The main limitation is that if a disk fails and you haven't recently synced, -you may not be able to fully recover. -More specifically, you may be unable to recover up to the size of -the changed or deleted files since the last sync operation. -This occurs even if the changed or deleted files are not on the -failed disk. This is why SnapRAID is better suited for -data that rarely changes. +The main limitation is that if a disk fails, you can only recover data up to +the state of the last `sync` operation. Any data added or modifications made +since the last sync that are located on the failed disk will be lost. +Consequently, SnapRAID is primarily suited for data that rarely changes. -On the other hand, newly added files don't prevent recovery of already -existing files. You will only lose the recently added files if they -are on the failed disk. +For data that already existed at the last sync, recovery reliability depends +on whether the `snapshot` option is used: + +* With snapshot support (available on Btrfs, ZFS, Bcachefs, and NTFS), + SnapRAID can automatically maintain a frozen reference of your data disks. + This ensures that even if you modify or delete files on your live + filesystem during or after a sync, the recovery process remains + consistent and reliable. + +* Without snapshot support, deleting or changing files after a `sync` + can prevent the full recovery of other failed disks. This occurs + because the parity no longer matches the modified files, even if + those files are not on the failed disk. On the other hand, newly added + files don't prevent recovery of already existing files. Other SnapRAID limitations are: @@ -1232,16 +1240,16 @@ When enabled, SnapRAID creates a read-only snapshot of your data at the start of a 'sync'. This ensures a consistent, point-in-time view of your files, preventing errors caused by concurrent file modifications. -This option applies exclusively to data disks formatted with the -Btrfs, Bcachefs or ZFS filesystems in Linux and NTFS in Windows. -Parity disks, or data disks using other filesystems, will always use -the live version of the filesystem. - This significantly improves recovery: if a file is deleted from the live filesystem, it remains preserved in the snapshot. This prevents the parity from becoming "broken" for that block, ensuring you can still successfully recover data if another disk fails. +This option applies exclusively to data disks formatted with the +Btrfs, Bcachefs or ZFS filesystems in Linux and NTFS in Windows. +Parity disks, or data disks using other filesystems, will always use +the live version of the filesystem. + Snapshot creation and deletion require administrative privileges. Ensure SnapRAID is run with the necessary permissions (e.g., sudo) when this option is enabled. @@ -1536,7 +1544,7 @@ Recovery - If a file is updated or deleted from the live filesystem, In case of a disk failure during an active sync process, SnapRAID is also able to read automatically from both the snapshot of the previous parity computation and the current one. - This maximizes the probability of a full recovery by + This maximizes the probability of a full recovery by providing access to the exact data blocks required to solve the parity equations, even if those blocks were modified or deleted between syncs. @@ -1600,8 +1608,8 @@ All other commands operate exclusively on the live filesystem. SnapRAID manages two specific snapshots, `stable` and `pending`, within a hidden directory at the root of each data subvolume. -In Btrfs an Bcachefs it's used the `.snapraid/` directory, in ZFS -the standard `.zfs/snapshot/`. +In Btrfs, Bcachefs, and NTFS it's used the `.snapraid/` directory, +in ZFS the standard `.zfs/snapshot/`. The `stable` snapshot represents the state of the last successfully completed `sync`, containing the exact data used to @@ -1610,8 +1618,8 @@ for `scrub`, `check`, and `fix` commands. The `pending` snapshot is a temporary image created at the start of a `sync` to provide a frozen state for parity computation. -Upon successful completion of the operation, the previous stable -snapshot is deleted, and the pending snapshot is promoted to +Upon successful completion of the operation, the previous `stable` +snapshot is deleted, and the `pending` snapshot is promoted to take its place as the new stable reference. If a `sync` is interrupted, the `pending` snapshot is preserved. @@ -1620,7 +1628,7 @@ pending snapshot as it matches the filesystem state recorded in the .content file, even if the parity is only partially synchronized. In the event of a `sync` interruption, `check` and `fix` commands -can also read from the `stable` snapshot to retrieve data blocks +also read from the `stable` snapshot to retrieve data blocks from files that were updated or deleted during the sync. This is possible because the .content file retains metadata for all modified or deleted files throughout the sync process.