I am planning a 14 data and 2 parity drive storage server using SR, but want to maintain an offsite backup in case of flood, fire etc. I can't afford to duplicate the full server offsite, but got the crazy idea that maybe, if I just keep a copy of one or both of the parity drives updated remotely, that this might be enough for me to reassemble the data drives if a disaster hits. (The offsite backup would be at a relative's house in a distant area.)
1) Is this even possible? If so, what do I need to rebuild the data files if I lose the primary server completely?
2) Is the parity drive information in a single file or in multiple smaller files? This would affect how long an update of the remote backup would take, assuming only changed files would be sent (can't hog someone else' bandwidth).
3) In theory would only one of the two parity drives need to be backed up remotely? (Realizing two is probably better that one in this scenario.)
4) If the array can be rebuilt using the one or two remote parity drives, do I have a security issue in maintaining this parity data remotely? (I can think of ways around this of course, but if it requires having the same MB and drives to rebuild I'm not too concerned.)
If you gather I haven't yet built a SR system you'd be right, hope the answers aren't too obvious.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For recovery, all the good disks in the system are required. Data and parity.
Parity is one large file, not many small ones. It will be as large as the data content on the largest disk.
Could you do an incremental backup scheme? Do a complete backup of the data disks once when your backup system is on site, then incrementals thereafter? The "diff" command will show you the changes to the array before the next "sync", or the standard rsync utility will do network incremental backups.
-Bill
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-08-31
Thanks Bill. Yes that would work, but it requires having a full 3RU server at the relatives house. Much harder to 'sell' to them, as compared to a little 4bay cube, plus requires double the cash outlay. Was hoping for a 'magic' fix, but now I understand better how SR works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-09-01
After pondering this further, it's clear that my original hope to minimize backup bandwidth won't work, since a 4TB drive file is still a lot of data to push over a relative's network. But I'm not sure why all the good disks are required; is something written to the data disks above the actual data? It seems like the parity info, if it actually captures the integrity of the data disks sufficiently to rebuild them, would be enough by itself to re-create the data disks without the original data - else what would be the point? What am I missing??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The parity by itself cannot rebuild lost data. Let's say you have 1 parity disk and 5 data disks, all full. There is no way for the parity disk alone to contain the info needed to rebuild each of the 5 data disks.
Instead, when parity is created ALL the data disks are read in parallel to calculate a parity value for each byte. If one disk is lost, ALL the remaining discs must be scanned in parallel to recreate it.
1 parity disk protects you against the loss of 1 disk at a time. If you want to guard against the loss of 2 discs simultaneously, you need 2 parity drives, etc.
-Bill
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I feel like rsync is actually smart enough to transfer only the parts of
a file that have changed. If so, that would reduce the bandwidth
requirement significantly.
But you're still just guessing that the parity file will be the one that
needs the additional redundancy.
mitch
On 9/1/2014 9:42 AM, Bill McClain wrote:
The parity by itself cannot rebuild lost data. Let's say you have 1 parity disk and 5 data disks, all full. There is no way for the parity disk alone to contain the info needed to rebuild each of the 5 data disks.
Instead, when parity is created ALL the data disks are read in parallel to calculate a parity value for each byte. If one disk is lost, ALL the remaining discs must be scanned in parallel to recreate it.
1 parity disk protects you against the loss of 1 disk at a time. If you want to guard against the loss of 2 discs simultaneously, you need 2 parity drives, etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-09-04
I think I get it now. I was originally thinking that a parity file was generated for each disk in the array and that each parity file was stored on each parity drive, so the array could be rebuilt just from the parity files. That would have made it possible to backup the array with just the parity files, and would have made for a sweet way to keep a remote backup without duplicating the entire array.
Thanks for the feedback. If anyone has any brilliant ideas on how to accomplish what I'm trying to do please let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Clearly you can't restore the data for 14 disks from 1 or 2 disks (of course, assuming the disks are reasonably close size-wise).
As far as snapraid goes I think having at least (or even MORE) parity disks than data disks is supported (up to 6 or whatever the maximum number of parity disks is). In other words if you have let's say 2 data disks and 2 parity disks you can restore the data only from the parity disks. But that's rather stupid and not something the regular user would do.
The simple way for you would be just to get one (or a few) big disks, as big as you can justify and backup there (at your relative or whatever) what is more important, up to the capacity of those drives.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am planning a 14 data and 2 parity drive storage server using SR, but want to maintain an offsite backup in case of flood, fire etc. I can't afford to duplicate the full server offsite, but got the crazy idea that maybe, if I just keep a copy of one or both of the parity drives updated remotely, that this might be enough for me to reassemble the data drives if a disaster hits. (The offsite backup would be at a relative's house in a distant area.)
1) Is this even possible? If so, what do I need to rebuild the data files if I lose the primary server completely?
2) Is the parity drive information in a single file or in multiple smaller files? This would affect how long an update of the remote backup would take, assuming only changed files would be sent (can't hog someone else' bandwidth).
3) In theory would only one of the two parity drives need to be backed up remotely? (Realizing two is probably better that one in this scenario.)
4) If the array can be rebuilt using the one or two remote parity drives, do I have a security issue in maintaining this parity data remotely? (I can think of ways around this of course, but if it requires having the same MB and drives to rebuild I'm not too concerned.)
If you gather I haven't yet built a SR system you'd be right, hope the answers aren't too obvious.
No, this won't work.
For recovery, all the good disks in the system are required. Data and parity.
Parity is one large file, not many small ones. It will be as large as the data content on the largest disk.
Could you do an incremental backup scheme? Do a complete backup of the data disks once when your backup system is on site, then incrementals thereafter? The "diff" command will show you the changes to the array before the next "sync", or the standard rsync utility will do network incremental backups.
-Bill
Thanks Bill. Yes that would work, but it requires having a full 3RU server at the relatives house. Much harder to 'sell' to them, as compared to a little 4bay cube, plus requires double the cash outlay. Was hoping for a 'magic' fix, but now I understand better how SR works.
After pondering this further, it's clear that my original hope to minimize backup bandwidth won't work, since a 4TB drive file is still a lot of data to push over a relative's network. But I'm not sure why all the good disks are required; is something written to the data disks above the actual data? It seems like the parity info, if it actually captures the integrity of the data disks sufficiently to rebuild them, would be enough by itself to re-create the data disks without the original data - else what would be the point? What am I missing??
The parity by itself cannot rebuild lost data. Let's say you have 1 parity disk and 5 data disks, all full. There is no way for the parity disk alone to contain the info needed to rebuild each of the 5 data disks.
Instead, when parity is created ALL the data disks are read in parallel to calculate a parity value for each byte. If one disk is lost, ALL the remaining discs must be scanned in parallel to recreate it.
Here is an illustration of how it works in general: http://en.wikipedia.org/wiki/Parity_bit#RAID
1 parity disk protects you against the loss of 1 disk at a time. If you want to guard against the loss of 2 discs simultaneously, you need 2 parity drives, etc.
-Bill
I feel like rsync is actually smart enough to transfer only the parts of
a file that have changed. If so, that would reduce the bandwidth
requirement significantly.
But you're still just guessing that the parity file will be the one that
needs the additional redundancy.
mitch
On 9/1/2014 9:42 AM, Bill McClain wrote:
I think I get it now. I was originally thinking that a parity file was generated for each disk in the array and that each parity file was stored on each parity drive, so the array could be rebuilt just from the parity files. That would have made it possible to backup the array with just the parity files, and would have made for a sweet way to keep a remote backup without duplicating the entire array.
Thanks for the feedback. If anyone has any brilliant ideas on how to accomplish what I'm trying to do please let me know.
Clearly you can't restore the data for 14 disks from 1 or 2 disks (of course, assuming the disks are reasonably close size-wise).
As far as snapraid goes I think having at least (or even MORE) parity disks than data disks is supported (up to 6 or whatever the maximum number of parity disks is). In other words if you have let's say 2 data disks and 2 parity disks you can restore the data only from the parity disks. But that's rather stupid and not something the regular user would do.
The simple way for you would be just to get one (or a few) big disks, as big as you can justify and backup there (at your relative or whatever) what is more important, up to the capacity of those drives.