I've been trying to figure what exactly is involved in a recovery and I'm not 100% confident about my understanding. I saw in the FAQ that I can rebuild a disk at the point it was on the last sync before it failed. As per the FAQ, if I added files, those would be lost on the failed disk but all other data is safe (as per "What happen if I add files and a disk breaks before I have updated the redundancy data?".
That's the part I'm not 100% certain as I'm seeing the "sync" as a snapshot of the whole. As such, it seems that doing a "fix" to recover a disk may either mean I'll go back in time on all the disks (not likely as we don't have all the data to rebuild all the drives at once) or some part of the recovered disks may be corrupted.
This hypothesis is based on the theory behind a standard RAID where the parity is based on a calculation of a stripe on each disk. So if you loose a disk, the missing data is rebuild from all the remaining disks. If I apply this to snapraid, it would means that I can only recover a disks if nothing has changed on any of the other disks since the last sync. If something changed (modified/added/removed files) on the remaining disks, I can't see how the missing disk could be rebuild without corruption if it is using part of the data on the other disks.
Can somebody explain how exactly work Snapraid when it create the parity and why it doesn't matter that some files are changed here and there on the disks if we need to recover a file, a folder or a complete disk?
Thank you!
ehfortin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is good to think about recovery BEFORE you NEED to do it.
The most important point I can offer you is this:
*NEVER* delete files from your snapraid array (ie, files that are actually part of the array ) until just prior to a "snapraid sync". Ie, minimize your "window of vulnerability."
You will find mention of the possible consequences, in the FAQ, but this point needs more emphasis.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just added files don't damage the array because the "content" file describes the state without them. In standard RAID you don't have this state description before the file addition, and you cannot recover.
With file deletion or modification, it's instead impossible to recover, because you have lost some necessary data. But at least SnapRAID is able to detect exactly which file is not correctly recovered, and it will mark them as unrecoverable.
A solution for this problem, it's to use double parity. With double parity, it's possible to recover from two missing blocks. You can have a failed block, and a changed/delete one, and still be able to fully recover.
Another workaround, is to recover in some way the deleted files. For example, you can rip again a ISO just deleted.
Also what uhclem suggest is OK. I also do it before deleting a lot of stuff. I first move files to a directory outside the SnapRAID tree, but inside the same disk. Then I run "sync", and only after I really delete files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've been trying to figure what exactly is involved in a recovery and I'm not 100% confident about my understanding. I saw in the FAQ that I can rebuild a disk at the point it was on the last sync before it failed. As per the FAQ, if I added files, those would be lost on the failed disk but all other data is safe (as per "What happen if I add files and a disk breaks before I have updated the redundancy data?".
That's the part I'm not 100% certain as I'm seeing the "sync" as a snapshot of the whole. As such, it seems that doing a "fix" to recover a disk may either mean I'll go back in time on all the disks (not likely as we don't have all the data to rebuild all the drives at once) or some part of the recovered disks may be corrupted.
This hypothesis is based on the theory behind a standard RAID where the parity is based on a calculation of a stripe on each disk. So if you loose a disk, the missing data is rebuild from all the remaining disks. If I apply this to snapraid, it would means that I can only recover a disks if nothing has changed on any of the other disks since the last sync. If something changed (modified/added/removed files) on the remaining disks, I can't see how the missing disk could be rebuild without corruption if it is using part of the data on the other disks.
Can somebody explain how exactly work Snapraid when it create the parity and why it doesn't matter that some files are changed here and there on the disks if we need to recover a file, a folder or a complete disk?
Thank you!
ehfortin
It is good to think about recovery BEFORE you NEED to do it.
The most important point I can offer you is this:
*NEVER* delete files from your snapraid array (ie, files that are actually part of the array ) until just prior to a "snapraid sync". Ie, minimize your "window of vulnerability."
You will find mention of the possible consequences, in the FAQ, but this point needs more emphasis.
Just added files don't damage the array because the "content" file describes the state without them. In standard RAID you don't have this state description before the file addition, and you cannot recover.
With file deletion or modification, it's instead impossible to recover, because you have lost some necessary data. But at least SnapRAID is able to detect exactly which file is not correctly recovered, and it will mark them as unrecoverable.
A solution for this problem, it's to use double parity. With double parity, it's possible to recover from two missing blocks. You can have a failed block, and a changed/delete one, and still be able to fully recover.
Another workaround, is to recover in some way the deleted files. For example, you can rip again a ISO just deleted.
Also what uhclem suggest is OK. I also do it before deleting a lot of stuff. I first move files to a directory outside the SnapRAID tree, but inside the same disk. Then I run "sync", and only after I really delete files.