• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Snapraid query

PliotronX

2[H]4U
Joined
Aug 8, 2000
Messages
2,070
Hey gang, I've done a lot of Googling and read the documentation but am still trying to understand and was just wondering about the logistics of a recovery with Snapraid. Since it's taking snapshots at basically a filesystem level, say a drive in an array craps out and the controller cannot see any of the data, how does Snapraid gather the data striped across the remaining drives and "inject" the backed up data? Must the snapshot drive be then included in the array to recover data? Do you boot to a live Linux disc or something? Just wondering how involved the process is. MTIA
 
Last edited:
Must the snapshot drive be then included in the array to recover data?

It's not really a snapshot drive. You have 1 or more parity drives. Parity raid is done in chunks across each disk and your parity disks. The chunks are created by allocation of a block of files on each disk. The content file contains this mapping (make sure you keep several copies of this content file - I put it on every data disk). On top of this unlike traditional raid5.. each block on each disk has a checksum.

Do you boot to a live Linux disc or something?

Not needed. The recovery is done while the filesystems are up.

Just wondering how involved the process is

I say its very easy. However I have been a programmer since the early 1980s.
 
It's not really a snapshot drive. You have 1 or more parity drives. Parity raid is done in chunks across each disk and your parity disks. The chunks are created by allocation of a block of files on each disk. The content file contains this mapping (make sure you keep several copies of this content file - I put it on every data disk). On top of this unlike traditional raid5.. each block on each disk has a checksum.



Not needed. The recovery is done while the filesystems are up.



I say its very easy. However I have been a programmer since the early 1980s.

Ah, thanks. Conceptually these chunks are taken at either automated or manual intervals which is why "snapshot" or "saved state" could be synonyms for chunks, but I digress. What I am not getting is visualizing how, if the array is dropped from being visible to the OS (at least in Windows' case), that Snapraid can use the parity drive to reconstruct from the drives. Must the array be broken so that Snapraid can pull from each drive while supplementing the parity data? What I mean is the RAID configuration removed so that each drive is just a raw disk.
 
if the array is dropped from being visible to the OS

The array is never dropped from being visible to the OS. To the OS, SnapRAID presents individual drives in OS native filesystems. For example my 6 data disks show up as 6 different filesystems on linux. Most of these I use the zfs filesystem but 1 or 2 are still ext4.

Edit:
Actually with SnapRAID there is no array to the OS. You can enable a pool feature but that is virtual using symbolic links. I do not use that since my pvr software allows for more than 1 storage folder and automatically balances recordings using the storage devices I give it.

manual intervals which is why "snapshot"

The "snapshot" is mainly caused by the raid sync not being real time. You manually run sync some time after files are added. If you have just synchronized this represents a snapshot in time. After a sync if you deleted a bunch of files and you have enough parity you can issue a command to put the deleted files back (provided you did not sync again after / during the delete).
 
Last edited:
Back
Top