Amitai Schlair writes:
> Greg Oster wrote:
> 
> > Amitai Schlair writes:
> > 
> > > When I swap in a drive that was part of the RAID set two weeks ago,
> > > how can I be sure that RAIDframe will reconstruct _onto_ it, not
> > > _from_ it?
> > 
> > The "old" component will have correct component numbers, correct ID's, 
> > and correct "everything but the modification counter".  In that case, 
> > RAIDframe will identify the old component as being part of the set, 
> > but will realize that there is a component out of sync (due to it's 
> > modification counter being lower) and will mark that old component as 
> > "failed".  You can just then use "raidctl -R" to rebuild the 
> > old-component in place (and re-sync to the good component).
> 
> That sounds hard for me to screw up, which is a desirable property of a 
> backup regimen.
> 
> Speaking of screwing up, another rather important question comes to 
> mind: what happens when I need to restore data? I usually won't want to 
> roll back the whole filesystem to the way it was two weeks ago. How can 
> I safely mount the "old" component's filesystem in order to copy backups 
> of just the affected files onto the active (and temporarily degraded) 
> RAID set?

That will be a little bit trickier, since RAIDframe is going to 
incorporate that "old component" into the RAID set...  The easiest 
solution is probably to create another partition on that disk...  So 
if you have something like:

#        size    offset     fstype [fsize bsize cpg/sgs]
  e:  24117248   2048319       RAID                     # (Cyl.   2032*-  25957*)

for the RAID component, just add

  f:  24117184   2048383       4.2BSD   1024  8192 46376 # (Cyl.   2032*-  25957*)

(i.e. reduce the size by 64 and increase the offset by 64, and make 
the other parameters the same as the parameters in the disklabel for 
the raid set) to the disklabel, and you should be able to mount 'f' directly. 
(This works for only RAID 1 sets, of course :) ).

Later...

Greg Oster