[Novalug] [OT] recovery tools

Anthony Soucek monkeywrenchit@gmail.com
Sun Oct 28 11:28:33 EDT 2007


excerpt from show notes on security now episode 112, from author of
spinrite on use with raid systems:

Andy in Iowa - another Iowan - had a common question about SpinRite
and RAID:  I love SpinRite.  I love RAID.  I'd like to use SpinRite on
RAID.  Is that okay?

STEVE:  We get the question a lot.  And so I don't want to take a lot
of time about this, but I want to explain that there are, in our mind,
sort of two types of RAID controllers, what we call "thin RAID" and
full-on industrial strength "thick RAID," the distinction being that a
thick RAID controller is a controller with a coprocessor, probably has
got some caching memory on it, and it's really decoupled the drives in
the RAID array from the machine.  So the machine dumps a bunch of data
on the controller, which the controller caches.  And then the
controller independently turns around and writes that data in
so-called "lazy writing" to the drives of the RAID array.

Now, this is as distinct from motherboards that now often will have a
RAID controller on them, but it's a little Promise Technology chip.
And all it's really doing is basically allowing that to be a bootable
RAID.  So there's some BIOS support that allows a couple drives to be
booted.  And then you still need a software driver in your OS in order
to essentially implement the RAID in software.

LEO:  People often think that these motherboard RAIDs are hardware
RAIDs.  They're not.  They're software RAIDs.

STEVE:  Yes, they are.  They're just sort of hardware assists that
just gets the RAID and allows it to be bootable.  But once it gets
going, the OS has a driver which does this in software.  So, relative
to SpinRite, it is generally okay to run SpinRite on a RAID 0, which
is...

LEO:  A hardware RAID.  Or even a BIOS RAID.

STEVE:  No, in fact you would not want to run it on a so-called thick
RAID controller ever because, well, at least not on the controller.
That is, what we tell people to do is just temporarily take the drive
off of the RAID...

LEO:  Ah, do individual drives.

STEVE:  Exactly.  Stick it onto a regular motherboard connection,
which you probably have right there on the motherboard, and SpinRite
will see it and run on it just�fine.

LEO:  And that works because you don't need a file system; you don't
need to know that the files are all there.  You're looking at such a
low level, you're not looking at how it's written or anything like
that.

STEVE:  At just the raw physical sector level, right.  And so we won't
break - SpinRite will never break the RAID.  It won't cause it to be
nonfunctional.  It doesn't matter if you've got RAID 5 or 6 or 27 or
whatever you're using.  SpinRite will work on it just fine as long as
it's talking just to the bare drive, not through the controller.  But
in the case of the thin RAID, because when you're running SpinRite
there's no operating system with its own software drivers, it will see
the drives separately in the normal case.  However, you still, in a
mirroring configuration where you are writing to both drives - but
you're only reading from one typically in a mirror.  You're not
redundantly reading from the drives.  So the point is, it does not
make sense to run SpinRite on mirrored drives behind a thin RAID
controller.  Even there you would want to unplug them from that
connector and plug them into a regular motherboard controller.

But in the case of striping, where you've RAIDed them to expand the
size - so, for example, you've got two 100-gig drives, and you're
running in RAID 0, which is where essentially you've created a virtual
200-gig drive, there you could run SpinRite in place with the drives
just like they are because essentially the queries are being split
between drives, but there's no redundancy of data.  It's the
redundancy of data, or in the case of a thick RAID it's the caching,
which is sort of decoupling SpinRite from the drive.  And that's what
you want to avoid.  You want SpinRite to actually have the full and
undivided attention of the drive.

LEO:  Makes sense.  And actually I'm glad you addressed this notion of
software RAID because I've said it for a long time, but nobody
believes me.

On 10/27/07, John <jpwarren00@gmail.com> wrote:
> Actually, GRC "Spinrite" runs just fine in Linux, the standalone live CD
> runs on FreeDOS.  It's a pretty low level application, programed in
> assembler that is pretty OS agnostic.  I tested a copy, and although it
> is a great tool I couldn't conclude that it is any better than "dd" or
> "ddrescue" + free tools, although I'm still using it to see if there is
> a long term benefit to using it for it's "disk conditioning".
>
> -John
>
> On Sat, 2007-10-27 at 13:54 -0400, Anthony Soucek wrote:
> > premature exclamaition...If it's a raid system, you may have trouble
> > getting it to see the drives since it runs on freeDos.  I doubt you
> > could use it on a raid array.  Check the details on the site.
> >
> > On 10/27/07, Anthony Soucek <monkeywrenchit@gmail.com> wrote:
> > > SPINRITE!
> > >
> > > go to www.grc.com
> > >
> > > for $100, if your hard drive still spins, this software will recover
> > > the data, linux, microsoft, tivo, whatever.
> > >
> > > On 10/26/07, Miguel Gonzalez Castaños <miguel_3_gonzalez@yahoo.es> wrote:
> > > > Hi,
> > > >
> > > >   Sorry for the off-topic. Our All-in-One Storage 600 server has been
> > > > doing weird things after a cache module replacement and two partitions
> > > > are showing as unallocate. We are looking for tools that would helps us
> > > > to recover as much as we can. We are currently runnig disk internals
> > > > tools, and we get some data, but seems to be old (from July).
> > > >
> > > >   If you know of any tool, please let me know back channel (or online,
> > > > whatever you think is the best but i don't want to upset anyone).
> > > >
> > > >   I also have tried rescuecd, and testdisk shows that recognizes the
> > > > partition, but we can't get any file when we try. We haven't tried the
> > > > advanced options yet.
> > > >
> > > >   Thanks,
> > > >
> > > >    Miguel
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Novalug mailing list
> > > > Novalug@calypso.tux.org
> > > > http://calypso.tux.org/cgi-bin/mailman/listinfo/novalug
> > > >
> > >
> > >
> > > --
> > > Anthony Soucek
> > >
> >
> >
>
>


-- 
Anthony Soucek


More information about the Novalug mailing list