rt/snapraid
1
0
Fork 0
mirror of https://github.com/amadvance/snapraid.git synced 2026-10-25 18:40:19 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update documentation about snapshots

Browse source
This commit is contained in:
Andrea Mazzoleni 2026-05-14 14:44:54 +02:00
parent 9b8e4a8845
commit d3ce39c8bd
4 changed files with 91 additions and 73 deletions
Download patch file Download diff file Expand all files Collapse all files

10
TODO
View file

@ -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)

54
doc/snapraid.1
View file

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

50
doc/snapraid.d
View file

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

50
doc/snapraid.txt
View file

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