----- Original Message -----
From: "Tim Shimmin" <tes@xxxxxxx>
To: "Jason Hlady" <hlady@xxxxxxxxxxx>
Cc: <linux-xfs@xxxxxxxxxxx>
Sent: Wednesday, January 26, 2005 5:34 PM
Subject: Re: Problem restoring destroyed, important XFS filesystem from tape
backup using xfsrestore
> Hi Jason,
>
> On Wed, Jan 26, 2005 at 04:36:51PM -0600, Jason Hlady wrote:
> > Hi there,
> >
> > I'm not even sure if this is the right mailing list for my problem, but
> > I was hoping that someone here could at least point me to the correct
> > set of people who might help me get the data back off the tapes.
>
> You've asked at the right place.
Thank goodness!
>
> > I
> > have graduate students facing the loss of months and years of work, and
> > I would appreciate any help that could be ferried my way.
> >
> > I have had a catastrophic RAID failure on a 700GB XFS filesystem (OS =
> > Mandrake 9.1 on IBM x340) and am looking to try and restore from tape.
> > I have had backups running on my Ultrium LTO tape drive. All of the
> > dumps that we have done in the past two years seem to have this same
> > restoring problem. We hadn't checked whether we could restore from the
> > tapes recently, since we had successfully managed to dump and resture
> > using xfsdump and xfsrestore years earlier :( .
> >
> > I apologize in advance for the length/verbosity of this email. I just
> > wanted to provide some information in advance.
> >
>
> I understand your concern with such large data.
> But as it says on the back of The Hitch Hikers Guide to the Galaxy,
> DON'T PANIC :-) And don't destroy those tapes ;-)
>
Ok. :-) I wish I had a towel--it would be really useful. :-)
The tapes are safe, and there are lots of them.
> Looking thru your email, it really looks like a block size problem on
> reading of the tapes. I have seen similar problems in the past.
>
> My first suggestion is to use the same strategy and blocksize in the
> restore as you did in the dump. That is use "-m -b 245760".
> You said you tried "-b 245760" but you should also use the same
> strategy "-m".
> The minrmt strategy doesn't rely on all the status info from the drive.
Right. We have tried the -m -b 245760 option, and that doesn't work either
(I can get a verbose printout of what that's doing when I get to work
tomorrow.)
>
> >From memory, the "-b" option shouldn't be ignored as you suspected.
>
> If this doesn't work don't despair.
> In the worst case, I can find an old program which I have somewhere,
> which hunts for headers and extracts data which I used a while ago
> on a blocksize problem on an IRIX dump (have no idea how that IRIX one
> happened - od(1)'ing on that dump it was in a strange format).
> I also have something which looks at the headers to confirm the
> blocksize that was used. It has been a while...
> (We know the dump format, so if the data is there, we should be able
> to extract it ;-)
Oh, this is making me feel much better. :-) We have write protected the
tapes, compiled the xfsrestore source and tried to hack the source, to no
success yet. Someone who actually knows what is going on would be much
appreciated right now.
>
> BTW, how come your dumps are always interrupted?
These are level 0s of a 700GB system, so they don't all fit on one tape, and
must be resumed on multiple tapes.
Jason
>
> --Tim
>
|