xfs
[Top] [All Lists]

Re: Problem restoring destroyed, important XFS filesystem from tape back

To: Jason Hlady <hlady@xxxxxxxxxxx>
Subject: Re: Problem restoring destroyed, important XFS filesystem from tape backup using xfsrestore
From: Tim Shimmin <tes@xxxxxxx>
Date: Thu, 27 Jan 2005 10:34:05 +1100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <C59B0EAD-6FEA-11D9-9D2E-000A958655F0@xxxxxxxxxxx>; from hlady@xxxxxxxxxxx on Wed, Jan 26, 2005 at 04:36:51PM -0600
References: <C59B0EAD-6FEA-11D9-9D2E-000A958655F0@xxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5.1i
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.

> 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 ;-)

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. 

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 ;-)

BTW, how come your dumps are always interrupted?

--Tim


<Prev in Thread] Current Thread [Next in Thread>