recovering data on a failed raid-0 installation

recovering data on a failed raid-0 installation

[Technomage]

ok,
here's the situation in a nutshell.

one of the 2 HD's in a linux raid-0 installation has failed.

Fortunately, or otherwise, it was NOT the primary HD.

problem is, I need to recover data from the first drive but appear to be 
unable to do so because the raid is not complete. the second drive only had 
193 MB written to it and I am fairly certain that the data I would like to 
recover is NOT on that drive.

can anyone offer any solutions to this?

the second HD is not usable (heat related failure issues). 

The filesystem used on the md0 partition (under mdadm) was xfs. now I have 
tried the xfs_check and xfs_repair tools and they are not helpful at this 
point.

The developer (of mdadm) suggested I use the following commands in an attempt 
to recover:

  mdadm -C /dev/md0 -l0 -n2 /dev/......
  fsck -n /dev/md0

However, the second one was a no go.

I am stumped as to how to proceed here. I need the data off the first drive, 
but do not appear to have any way (other than using cat to see it) to get at 
it.

some help would be greatly appreciated.

technomage

p. here is the original response sent back to me from the developer of mdadm:
***************************
Re: should have been more explicit here -> Re: need some help <URGENT!>
From: Neil Brown <neilb@suse.de>
To: Technomage <technomage-hawke@cox.net>
Date: Sunday 22:01:45
On Sunday March 26, technomage-hawke@cox.net wrote:
> ok,
> 
> you gave me more info than some local to that mentioned e-mail list.
> 
> ok, the vast majority of the data I need to recover is on /dev/hda 
> and /dev/hdb only has 193 MB and is probably irrelevant.
> 
> can you help me with this?
> can you baby me through this. I really need to recover this data (if at all 
> possible). 

Not really, and certainly not now (I have to go out).
I have already make 2 suggestions
  mail linux-raid@vger.kernel.org
and
  mdadm -C /dev/md0 -l0 -n2 /dev/......
  fsck -n /dev/md0

try one of those.

NeilBrown

> 
> the friend of mine that this actually happened to is on the phone, begging 
me 
> and grovelling before the gods of linux in order to have this fixed. I have 
> setup an identical test situation here.
> 
> the important data is on drive 1 and drive 2 is mostly irrelevant.
> is there any way to convince raid-0 to truncate to the end of drive 1 and 
> allow me to get whatever data I can off. btw, the filesystem that was 
> formatted was xfs (for linux) on md0.
> 
> if you have questions, please do not hesitate to ask.
> 
> thank you.
> 
> p. real name here is Eric.
> 
> 
> On Sunday 26 March 2006 21:33, you wrote:
> > On Sunday March 26, technomage-hawke@cox.net wrote:
> >
> > With a name like "Technomage" and a vague subject "need some help
> > <URGENT>", I very really discarded your email assuming it was spam!
> >
> > Questions like this are best sent to linux-raid@vger.kernel.org.
> >
> > If one drive in a raid0 has failed non-recoverably, then half your
> > data is gone, so you are out of luck.
> >
> > Your best bet would be to recreate the raid0 in exactly the same
> > configuration as before, and see if you can find the data there.
> > e.g.
> >    mdadm -C /dev/md0 -l0 -n2 /dev/hda2 /dev/hdb2
> >   fsck -n /dev/md0
> >
> > or something like that.
> >
> > NeilBrown
> >
> > > I recently ran into a problem after an install using mdadm. the software
> > > raid-0 environment suffered a failure after a HD in the system failed 
due
> > > to thermal run-away.
> > >
> > > the setup goes like this:
> > >
> > > /dev/hda has:
> > > /dev/hda1 -> boot (512 MN)
> > > /dev/hda2 -> partition 1 (linux raid autodetect)
> > >
> > > /dev/hdb has:
> > > /dev/hdb1 -> swap (512 MB)
> > > /dev/hdb2 -> partition 2 (linux raid autodetect)
> > >
> > > /dev/hdb is the drive that failed. according to a drive imager, only 129
> > > MB of data was actually written to the second raid partition (in 
serial).
> > > unfortunately, without it, I cannot recover any data off of the first HD
> > > and I would like very much to do so. Some of this data is for my work as
> > > a forensics examiner.
> > >
> > > I am fairly certain that the data I need to recover is on /dev/hda but 
so
> > > far, I have been unable to read the data in any meaningful way (except
> > > the use of cat piped through less to see if the data is, in fact,
> > > readable).
> > >
> > > can you help?
> > >
> > > thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: recovering data on a failed raid-0 installation

[Guy]

RAID0 uses all disks evenly (all 2 in your case).  I don’t see how you can
recover from a drive failure with a RAID0.  Never use RAID0 unless you are
willing to lose all the data!

Are you sure the second disk is dead?  Have you done a read test on the
disk?  dd works well for read testing.  Try this:
dd if=/dev/hdb2 of=/dev/null bs=64k
or
dd if=/dev/hdb of=/dev/null bs=64k

Guy

} -----Original Message-----
} From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
} owner@vger.kernel.org] On Behalf Of Technomage
} Sent: Wednesday, March 29, 2006 12:09 AM
} To: linux-raid@vger.kernel.org
} Subject: recovering data on a failed raid-0 installation
} 
} ok,
} here's the situation in a nutshell.
} 
} one of the 2 HD's in a linux raid-0 installation has failed.
} 
} Fortunately, or otherwise, it was NOT the primary HD.
} 
} problem is, I need to recover data from the first drive but appear to be
} unable to do so because the raid is not complete. the second drive only
} had
} 193 MB written to it and I am fairly certain that the data I would like to
} recover is NOT on that drive.
} 
} can anyone offer any solutions to this?
} 
} the second HD is not usable (heat related failure issues).
} 
} The filesystem used on the md0 partition (under mdadm) was xfs. now I have
} tried the xfs_check and xfs_repair tools and they are not helpful at this
} point.
} 
} The developer (of mdadm) suggested I use the following commands in an
} attempt
} to recover:
} 
}   mdadm -C /dev/md0 -l0 -n2 /dev/......
}   fsck -n /dev/md0
} 
} However, the second one was a no go.
} 
} I am stumped as to how to proceed here. I need the data off the first
} drive,
} but do not appear to have any way (other than using cat to see it) to get
} at
} it.
} 
} some help would be greatly appreciated.
} 
} technomage
} 
} p. here is the original response sent back to me from the developer of
} mdadm:
} ***************************
} Re: should have been more explicit here -> Re: need some help <URGENT!>
} From: Neil Brown <neilb@suse.de>
} To: Technomage <technomage-hawke@cox.net>
} Date: Sunday 22:01:45
} On Sunday March 26, technomage-hawke@cox.net wrote:
} > ok,
} >
} > you gave me more info than some local to that mentioned e-mail list.
} >
} > ok, the vast majority of the data I need to recover is on /dev/hda
} > and /dev/hdb only has 193 MB and is probably irrelevant.
} >
} > can you help me with this?
} > can you baby me through this. I really need to recover this data (if at
} all
} > possible).
} 
} Not really, and certainly not now (I have to go out).
} I have already make 2 suggestions
}   mail linux-raid@vger.kernel.org
} and
}   mdadm -C /dev/md0 -l0 -n2 /dev/......
}   fsck -n /dev/md0
} 
} try one of those.
} 
} NeilBrown
} 
} >
} > the friend of mine that this actually happened to is on the phone,
} begging
} me
} > and grovelling before the gods of linux in order to have this fixed. I
} have
} > setup an identical test situation here.
} >
} > the important data is on drive 1 and drive 2 is mostly irrelevant.
} > is there any way to convince raid-0 to truncate to the end of drive 1
} and
} > allow me to get whatever data I can off. btw, the filesystem that was
} > formatted was xfs (for linux) on md0.
} >
} > if you have questions, please do not hesitate to ask.
} >
} > thank you.
} >
} > p. real name here is Eric.
} >
} >
} > On Sunday 26 March 2006 21:33, you wrote:
} > > On Sunday March 26, technomage-hawke@cox.net wrote:
} > >
} > > With a name like "Technomage" and a vague subject "need some help
} > > <URGENT>", I very really discarded your email assuming it was spam!
} > >
} > > Questions like this are best sent to linux-raid@vger.kernel.org.
} > >
} > > If one drive in a raid0 has failed non-recoverably, then half your
} > > data is gone, so you are out of luck.
} > >
} > > Your best bet would be to recreate the raid0 in exactly the same
} > > configuration as before, and see if you can find the data there.
} > > e.g.
} > >    mdadm -C /dev/md0 -l0 -n2 /dev/hda2 /dev/hdb2
} > >   fsck -n /dev/md0
} > >
} > > or something like that.
} > >
} > > NeilBrown
} > >
} > > > I recently ran into a problem after an install using mdadm. the
} software
} > > > raid-0 environment suffered a failure after a HD in the system
} failed
} due
} > > > to thermal run-away.
} > > >
} > > > the setup goes like this:
} > > >
} > > > /dev/hda has:
} > > > /dev/hda1 -> boot (512 MN)
} > > > /dev/hda2 -> partition 1 (linux raid autodetect)
} > > >
} > > > /dev/hdb has:
} > > > /dev/hdb1 -> swap (512 MB)
} > > > /dev/hdb2 -> partition 2 (linux raid autodetect)
} > > >
} > > > /dev/hdb is the drive that failed. according to a drive imager, only
} 129
} > > > MB of data was actually written to the second raid partition (in
} serial).
} > > > unfortunately, without it, I cannot recover any data off of the
} first HD
} > > > and I would like very much to do so. Some of this data is for my
} work as
} > > > a forensics examiner.
} > > >
} > > > I am fairly certain that the data I need to recover is on /dev/hda
} but
} so
} > > > far, I have been unable to read the data in any meaningful way
} (except
} > > > the use of cat piped through less to see if the data is, in fact,
} > > > readable).
} > > >
} > > > can you help?
} > > >
} > > > thank you.
} -
} To unsubscribe from this list: send the line "unsubscribe linux-raid" in
} the body of a message to majordomo@vger.kernel.org
} More majordomo info at  http://vger.kernel.org/majordomo-info.html

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recovering data on a failed raid-0 installation

[Neil Brown]

On Tuesday March 28, technomage-hawke@cox.net wrote:
> ok,
> here's the situation in a nutshell.
> 
> one of the 2 HD's in a linux raid-0 installation has failed.
> 
> Fortunately, or otherwise, it was NOT the primary HD.

What do you mean by "primary HD".  All drives in a raid-0 are equal.

> 
> problem is, I need to recover data from the first drive but appear to be 
> unable to do so because the raid is not complete. the second drive only had 
> 193 MB written to it and I am fairly certain that the data I would like to 
> recover is NOT on that drive.

Why do you think only 193MB was written to the second drive?  raid0
will normally write equal amounts to all drives.

> 
> can anyone offer any solutions to this?
> 
> the second HD is not usable (heat related failure issues). 
> 
> The filesystem used on the md0 partition (under mdadm) was xfs. now I have 
> tried the xfs_check and xfs_repair tools and they are not helpful at this 
> point.
> 
> The developer (of mdadm) suggested I use the following commands in an attempt 
> to recover:
> 
>   mdadm -C /dev/md0 -l0 -n2 /dev/......
>   fsck -n /dev/md0
> 
> However, the second one was a no go.

Exactly how was it a "no go"?
However if the second drive is really not usable, then your data is
gone.

> 
> I am stumped as to how to proceed here. I need the data off the first drive, 
> but do not appear to have any way (other than using cat to see it) to get at 
> it.

Your data isn't on the first drive.  It is half on the first drive and
half on the second drive.
However if you really really think most of the data is on the first
drive, you could try getting another blank drive, combining it with
the working drive in a raid0, and xfs_check/xfs_repair that.

Sorry we cannot be more helpful, but raid0 provide zero protection
against device failure.

> 
> some help would be greatly appreciated.
> 
> technomage
> 
> p. here is the original response sent back to me from the developer
> of mdadm:

For future reference, it is generally considered bad form to post a
privately received mail message to a public list.  Not that I have
particular problems with it in this case, but it is best to avoid
things that are considered "bad form".

NeilBrown

addendum: was Re: recovering data on a failed raid-0 installation

[Technomage]

ok, guy and others.

this is a followup to the case I am currently trying (still) to solve.

synopsis:
the general consensus is that raid0 writes in a striping fashion.

However, the test case I have here doesn't appear to operate in the above 
described manner. what was observed was this: on /dev/mdo (while observing 
drive activity for both hda and hdb) hda was active until filled at which 
point data was spanned to hdb.  In other words, the data was written in a 
linear, not striped, manner. 

given this behavior (as observed), it stands to reason that the data on the 
first of the 2 members of this "raid" should be recoverable, if only we could 
"trick" the raid into allowing us to mount it without its second member. at 
this point, we are assuming that the data on drive 2 (hdb) is not 
recoverable. 

In a scientific fashion, assuming that the observed behavior is correct, how 
would one go about recovering data from the first member without the second 
being present? I assume that we are going to have to use mdadm in such a way 
as to trick it into thinking it is doing something that it is not. I invite 
anyone here to setup a similar testing environment to confirm these results.

drives: 2 identical IDE drives (same make/model)
suse 9.3 os.

p.s. I have heard all the "naysayer commentary" so please, keep it to USEFUL 
information only. thanks....

On Tuesday 28 March 2006 22:26, you wrote:
> RAID0 uses all disks evenly (all 2 in your case).  I don’t see how you can
> recover from a drive failure with a RAID0.  Never use RAID0 unless you are
> willing to lose all the data!
>
> Are you sure the second disk is dead?  Have you done a read test on the
> disk?  dd works well for read testing.  Try this:
> dd if=/dev/hdb2 of=/dev/null bs=64k
> or
> dd if=/dev/hdb of=/dev/null bs=64k
>
> Guy
>
> } -----Original Message-----
> } From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> } owner@vger.kernel.org] On Behalf Of Technomage
> } Sent: Wednesday, March 29, 2006 12:09 AM
> } To: linux-raid@vger.kernel.org
> } Subject: recovering data on a failed raid-0 installation
> }
> } ok,
> } here's the situation in a nutshell.
> }
> } one of the 2 HD's in a linux raid-0 installation has failed.
> }
> } Fortunately, or otherwise, it was NOT the primary HD.
> }
> } problem is, I need to recover data from the first drive but appear to be
> } unable to do so because the raid is not complete. the second drive only
> } had
> } 193 MB written to it and I am fairly certain that the data I would like
> to } recover is NOT on that drive.
> }
> } can anyone offer any solutions to this?
> }
> } the second HD is not usable (heat related failure issues).
> }
> } The filesystem used on the md0 partition (under mdadm) was xfs. now I
> have } tried the xfs_check and xfs_repair tools and they are not helpful at
> this } point.
> }
> } The developer (of mdadm) suggested I use the following commands in an
> } attempt
> } to recover:
> }
> }   mdadm -C /dev/md0 -l0 -n2 /dev/......
> }   fsck -n /dev/md0
> }
> } However, the second one was a no go.
> }
> } I am stumped as to how to proceed here. I need the data off the first
> } drive,
> } but do not appear to have any way (other than using cat to see it) to get
> } at
> } it.
> }
> } some help would be greatly appreciated.
> }
> } technomage
> }
> } p. here is the original response sent back to me from the developer of
> } mdadm:
> } ***************************
> } Re: should have been more explicit here -> Re: need some help <URGENT!>
> } From: Neil Brown <neilb@suse.de>
> } To: Technomage <technomage-hawke@cox.net>
> } Date: Sunday 22:01:45
> } On Sunday March 26, technomage-hawke@cox.net wrote:
> } > ok,
> } >
> } > you gave me more info than some local to that mentioned e-mail list.
> } >
> } > ok, the vast majority of the data I need to recover is on /dev/hda
> } > and /dev/hdb only has 193 MB and is probably irrelevant.
> } >
> } > can you help me with this?
> } > can you baby me through this. I really need to recover this data (if at
> } all
> } > possible).
> }
> } Not really, and certainly not now (I have to go out).
> } I have already make 2 suggestions
> }   mail linux-raid@vger.kernel.org
> } and
> }   mdadm -C /dev/md0 -l0 -n2 /dev/......
> }   fsck -n /dev/md0
> }
> } try one of those.
> }
> } NeilBrown
> }
> } >
> } > the friend of mine that this actually happened to is on the phone,
> } begging
> } me
> } > and grovelling before the gods of linux in order to have this fixed. I
> } have
> } > setup an identical test situation here.
> } >
> } > the important data is on drive 1 and drive 2 is mostly irrelevant.
> } > is there any way to convince raid-0 to truncate to the end of drive 1
> } and
> } > allow me to get whatever data I can off. btw, the filesystem that was
> } > formatted was xfs (for linux) on md0.
> } >
> } > if you have questions, please do not hesitate to ask.
> } >
> } > thank you.
> } >
> } > p. real name here is Eric.
> } >
> } >
> } > On Sunday 26 March 2006 21:33, you wrote:
> } > > On Sunday March 26, technomage-hawke@cox.net wrote:
> } > >
> } > > With a name like "Technomage" and a vague subject "need some help
> } > > <URGENT>", I very really discarded your email assuming it was spam!
> } > >
> } > > Questions like this are best sent to linux-raid@vger.kernel.org.
> } > >
> } > > If one drive in a raid0 has failed non-recoverably, then half your
> } > > data is gone, so you are out of luck.
> } > >
> } > > Your best bet would be to recreate the raid0 in exactly the same
> } > > configuration as before, and see if you can find the data there.
> } > > e.g.
> } > >    mdadm -C /dev/md0 -l0 -n2 /dev/hda2 /dev/hdb2
> } > >   fsck -n /dev/md0
> } > >
> } > > or something like that.
> } > >
> } > > NeilBrown
> } > >
> } > > > I recently ran into a problem after an install using mdadm. the
> } software
> } > > > raid-0 environment suffered a failure after a HD in the system
> } failed
> } due
> } > > > to thermal run-away.
> } > > >
> } > > > the setup goes like this:
> } > > >
> } > > > /dev/hda has:
> } > > > /dev/hda1 -> boot (512 MN)
> } > > > /dev/hda2 -> partition 1 (linux raid autodetect)
> } > > >
> } > > > /dev/hdb has:
> } > > > /dev/hdb1 -> swap (512 MB)
> } > > > /dev/hdb2 -> partition 2 (linux raid autodetect)
> } > > >
> } > > > /dev/hdb is the drive that failed. according to a drive imager,
> only } 129
> } > > > MB of data was actually written to the second raid partition (in
> } serial).
> } > > > unfortunately, without it, I cannot recover any data off of the
> } first HD
> } > > > and I would like very much to do so. Some of this data is for my
> } work as
> } > > > a forensics examiner.
> } > > >
> } > > > I am fairly certain that the data I need to recover is on /dev/hda
> } but
> } so
> } > > > far, I have been unable to read the data in any meaningful way
> } (except
> } > > > the use of cat piped through less to see if the data is, in fact,
> } > > > readable).
> } > > >
> } > > > can you help?
> } > > >
> } > > > thank you.
> } -
> } To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> } the body of a message to majordomo@vger.kernel.org
> } More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: addendum: was Re: recovering data on a failed raid-0 installation

[Guy]

If what you say is true, then it was not a RAID0.  It sounds like LINEAR.
Do you have the original command used to create the array?
Or the output from mdadm before you tried any recovery methods.
The output must be from before you re-created the array.
Output from commands like "mdadm -D /dev/md0" or "mdadm -E /dev/hda2".
Or the output from "cat /proc/mdstat", from before you re-created the array.

Guy


} -----Original Message-----
} From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
} owner@vger.kernel.org] On Behalf Of Technomage
} Sent: Wednesday, March 29, 2006 11:15 PM
} To: Guy
} Cc: linux-raid@vger.kernel.org
} Subject: addendum: was Re: recovering data on a failed raid-0 installation
} 
} ok, guy and others.
} 
} this is a followup to the case I am currently trying (still) to solve.
} 
} synopsis:
} the general consensus is that raid0 writes in a striping fashion.
} 
} However, the test case I have here doesn't appear to operate in the above
} described manner. what was observed was this: on /dev/mdo (while observing
} drive activity for both hda and hdb) hda was active until filled at which
} point data was spanned to hdb.  In other words, the data was written in a
} linear, not striped, manner.
} 
} given this behavior (as observed), it stands to reason that the data on
} the
} first of the 2 members of this "raid" should be recoverable, if only we
} could
} "trick" the raid into allowing us to mount it without its second member.
} at
} this point, we are assuming that the data on drive 2 (hdb) is not
} recoverable.
} 
} In a scientific fashion, assuming that the observed behavior is correct,
} how
} would one go about recovering data from the first member without the
} second
} being present? I assume that we are going to have to use mdadm in such a
} way
} as to trick it into thinking it is doing something that it is not. I
} invite
} anyone here to setup a similar testing environment to confirm these
} results.
} 
} drives: 2 identical IDE drives (same make/model)
} suse 9.3 os.
} 
} p.s. I have heard all the "naysayer commentary" so please, keep it to
} USEFUL
} information only. thanks....
} 
} On Tuesday 28 March 2006 22:26, you wrote:
} > RAID0 uses all disks evenly (all 2 in your case).  I don’t see how you
} can
} > recover from a drive failure with a RAID0.  Never use RAID0 unless you
} are
} > willing to lose all the data!
} >
} > Are you sure the second disk is dead?  Have you done a read test on the
} > disk?  dd works well for read testing.  Try this:
} > dd if=/dev/hdb2 of=/dev/null bs=64k
} > or
} > dd if=/dev/hdb of=/dev/null bs=64k
} >
} > Guy
} >
} > } -----Original Message-----
} > } From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
} > } owner@vger.kernel.org] On Behalf Of Technomage
} > } Sent: Wednesday, March 29, 2006 12:09 AM
} > } To: linux-raid@vger.kernel.org
} > } Subject: recovering data on a failed raid-0 installation
} > }
} > } ok,
} > } here's the situation in a nutshell.
} > }
} > } one of the 2 HD's in a linux raid-0 installation has failed.
} > }
} > } Fortunately, or otherwise, it was NOT the primary HD.
} > }
} > } problem is, I need to recover data from the first drive but appear to
} be
} > } unable to do so because the raid is not complete. the second drive
} only
} > } had
} > } 193 MB written to it and I am fairly certain that the data I would
} like
} > to } recover is NOT on that drive.
} > }
} > } can anyone offer any solutions to this?
} > }
} > } the second HD is not usable (heat related failure issues).
} > }
} > } The filesystem used on the md0 partition (under mdadm) was xfs. now I
} > have } tried the xfs_check and xfs_repair tools and they are not helpful
} at
} > this } point.
} > }
} > } The developer (of mdadm) suggested I use the following commands in an
} > } attempt
} > } to recover:
} > }
} > }   mdadm -C /dev/md0 -l0 -n2 /dev/......
} > }   fsck -n /dev/md0
} > }
} > } However, the second one was a no go.
} > }
} > } I am stumped as to how to proceed here. I need the data off the first
} > } drive,
} > } but do not appear to have any way (other than using cat to see it) to
} get
} > } at
} > } it.
} > }
} > } some help would be greatly appreciated.
} > }
} > } technomage
} > }
} > } p. here is the original response sent back to me from the developer of
} > } mdadm:
} > } ***************************
} > } Re: should have been more explicit here -> Re: need some help
} <URGENT!>
} > } From: Neil Brown <neilb@suse.de>
} > } To: Technomage <technomage-hawke@cox.net>
} > } Date: Sunday 22:01:45
} > } On Sunday March 26, technomage-hawke@cox.net wrote:
} > } > ok,
} > } >
} > } > you gave me more info than some local to that mentioned e-mail list.
} > } >
} > } > ok, the vast majority of the data I need to recover is on /dev/hda
} > } > and /dev/hdb only has 193 MB and is probably irrelevant.
} > } >
} > } > can you help me with this?
} > } > can you baby me through this. I really need to recover this data (if
} at
} > } all
} > } > possible).
} > }
} > } Not really, and certainly not now (I have to go out).
} > } I have already make 2 suggestions
} > }   mail linux-raid@vger.kernel.org
} > } and
} > }   mdadm -C /dev/md0 -l0 -n2 /dev/......
} > }   fsck -n /dev/md0
} > }
} > } try one of those.
} > }
} > } NeilBrown
} > }
} > } >
} > } > the friend of mine that this actually happened to is on the phone,
} > } begging
} > } me
} > } > and grovelling before the gods of linux in order to have this fixed.
} I
} > } have
} > } > setup an identical test situation here.
} > } >
} > } > the important data is on drive 1 and drive 2 is mostly irrelevant.
} > } > is there any way to convince raid-0 to truncate to the end of drive
} 1
} > } and
} > } > allow me to get whatever data I can off. btw, the filesystem that
} was
} > } > formatted was xfs (for linux) on md0.
} > } >
} > } > if you have questions, please do not hesitate to ask.
} > } >
} > } > thank you.
} > } >
} > } > p. real name here is Eric.
} > } >
} > } >
} > } > On Sunday 26 March 2006 21:33, you wrote:
} > } > > On Sunday March 26, technomage-hawke@cox.net wrote:
} > } > >
} > } > > With a name like "Technomage" and a vague subject "need some help
} > } > > <URGENT>", I very really discarded your email assuming it was
} spam!
} > } > >
} > } > > Questions like this are best sent to linux-raid@vger.kernel.org.
} > } > >
} > } > > If one drive in a raid0 has failed non-recoverably, then half your
} > } > > data is gone, so you are out of luck.
} > } > >
} > } > > Your best bet would be to recreate the raid0 in exactly the same
} > } > > configuration as before, and see if you can find the data there.
} > } > > e.g.
} > } > >    mdadm -C /dev/md0 -l0 -n2 /dev/hda2 /dev/hdb2
} > } > >   fsck -n /dev/md0
} > } > >
} > } > > or something like that.
} > } > >
} > } > > NeilBrown
} > } > >
} > } > > > I recently ran into a problem after an install using mdadm. the
} > } software
} > } > > > raid-0 environment suffered a failure after a HD in the system
} > } failed
} > } due
} > } > > > to thermal run-away.
} > } > > >
} > } > > > the setup goes like this:
} > } > > >
} > } > > > /dev/hda has:
} > } > > > /dev/hda1 -> boot (512 MN)
} > } > > > /dev/hda2 -> partition 1 (linux raid autodetect)
} > } > > >
} > } > > > /dev/hdb has:
} > } > > > /dev/hdb1 -> swap (512 MB)
} > } > > > /dev/hdb2 -> partition 2 (linux raid autodetect)
} > } > > >
} > } > > > /dev/hdb is the drive that failed. according to a drive imager,
} > only } 129
} > } > > > MB of data was actually written to the second raid partition (in
} > } serial).
} > } > > > unfortunately, without it, I cannot recover any data off of the
} > } first HD
} > } > > > and I would like very much to do so. Some of this data is for my
} > } work as
} > } > > > a forensics examiner.
} > } > > >
} > } > > > I am fairly certain that the data I need to recover is on
} /dev/hda
} > } but
} > } so
} > } > > > far, I have been unable to read the data in any meaningful way
} > } (except
} > } > > > the use of cat piped through less to see if the data is, in
} fact,
} > } > > > readable).
} > } > > >
} > } > > > can you help?
} > } > > >
} > } > > > thank you.
} > } -
} > } To unsubscribe from this list: send the line "unsubscribe linux-raid"
} in
} > } the body of a message to majordomo@vger.kernel.org
} > } More majordomo info at  http://vger.kernel.org/majordomo-info.html
} -
} To unsubscribe from this list: send the line "unsubscribe linux-raid" in
} the body of a message to majordomo@vger.kernel.org
} More majordomo info at  http://vger.kernel.org/majordomo-info.html

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: addendum: was Re: recovering data on a failed raid-0 installation

[Technomage]

well? are you guys tapped out on this or should I be looking elsewhere?

The *was* the recommended place to seek out help.

still waiting........

Re: addendum: was Re: recovering data on a failed raid-0 installation

[Technomage]

Jeff,
I would if I could. but I live on a rather limited income here . :(

also, my chances for employment (other than self-contracted services) in 
phoenix are slim and none (being disabled in a market with a very soft tech 
sector can lead to that).

now, I don't mean to be abrasive, but, so far, I haven't seen much other than:
1. it can't be done or
2. hire a paid consultant.

as for 1, if a pro can do it, it stands to reason that someone, somewhere (not 
a pro) found the way and made his millions on it.

as for 2, not going to be possible on $600.00 a month.

On Friday 31 March 2006 15:10, Jeff Breidenbach wrote:
> Technomage, I recommend hiring a paid consultant; your attitude is a
> little too abrasive for a communal support channel.

Re: addendum: was Re: recovering data on a failed raid-0 installation

[Technomage]

mike,
yeah.... coaxing the FS into trying to recover seems to be the sticky bit. :(

I have tried all that I know, which is not much considering that this is not 
my specialty (I am a unix security admin <unemployed on disability>).

we still have the original drives and we have a drive imaging device arriving 
(should have been here today). I can only hope that it will be able to 
overcome the problems I have seen with that particular laptop and its "flaky" 
IDE subsystem.

only problem with the backups, there were none (no spare drives and the person 
that did the setup hadn't realized until too late that there was an incipient 
problem with the hardware. :(

if the drive imager is successful in recovering the entire contents of the 
drive (he is a forensics specialist and I am retraining to be one) then we 
are in business. however, if not. call it a write off and move on I guess. :(

thanks for responding though.....


On Friday 31 March 2006 15:55, you wrote:
> You were in the right spot, I think raid-0 is just a data-lossy format
> and my first impression of your post was "well, don't pick raid-0, duh"
> - not in a rude way just that you got the defined behavior of the
> system, data loss on any failure
>
> I can't imagine how to coax a filesystem to work when it's missing half
> it's contents, but maybe a combination of forcing a start on the raid
> and read-only FS mounts could make it hobble along.
>
> I'd restore from backup and be done with it though
>
> -Mike
>
> Technomage wrote:
> > well? are you guys tapped out on this or should I be looking elsewhere?
> >
> > The *was* the recommended place to seek out help.
> >
> > still waiting........
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: addendum: was Re: recovering data on a failed raid-0 installation

[Technomage]

ok,
seems I made a mistake in how this silly mail client is configured.

so, in that, I do apologize for having this show up on the list (doh!)

this was meant to be private and should have remained that way.


On Friday 31 March 2006 19:01, Technomage wrote:
> Jeff,
> I would if I could. but I live on a rather limited income here . :(
>
> also, my chances for employment (other than self-contracted services) in
> phoenix are slim and none (being disabled in a market with a very soft tech
> sector can lead to that).
>
> now, I don't mean to be abrasive, but, so far, I haven't seen much other
> than: 1. it can't be done or
> 2. hire a paid consultant.
>
> as for 1, if a pro can do it, it stands to reason that someone, somewhere
> (not a pro) found the way and made his millions on it.
>
> as for 2, not going to be possible on $600.00 a month.
>
> On Friday 31 March 2006 15:10, Jeff Breidenbach wrote:
> > Technomage, I recommend hiring a paid consultant; your attitude is a
> > little too abrasive for a communal support channel.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: addendum: was Re: recovering data on a failed raid-0 installation

[Technomage]

mike.

given the problem, I have a request.


On Friday 31 March 2006 15:55, Mike Hardy wrote:
>
> I can't imagine how to coax a filesystem to work when it's missing half
> it's contents, but maybe a combination of forcing a start on the raid
> and read-only FS mounts could make it hobble along.

we will test any well laid out plan. 

lay out for us (from beginning to end) all the steps required, in your test. 
do not be afraid to detail the obvious. it is better that we be in good 
communication than to be working on assumptions. it will save you a lot of 
frustration trying to correct for our assumptions, if there are none. 

tmh

Re: addendum: was Re: recovering data on a failed raid-0 installation

[Mike Hardy]

Well, honestly I'm not really sure. I've never done this as I only use
the redundant raid levels, and when they're gone, things are a complete
hash and there's no hope. In fact, with raid-0 (striping, right? not
linear/append?) I believe you are in the same boat. Each large file will
have half its contents on the disk that died. So really, there's very
little hope.

Anyway, I'll try to give you pointers to what I would try anyway, with
as much detail as I can.

First, you just need to get the raid device up. It sounds like you are
actually already doing that, but who knows. If you have one drive but
not the other, you could make a sparse file that is the same size as the
disk you lost. I know this is possible, but haven't done it so you'll
have to see for yourself - I think there are examples in linux-raid
archives in reference to testing very large raid arrays. Loopback mount
the file as a device (losetup is he command to use here) and now you
have a "virtual" device of the same size as the drive you lost.

Recreate the raid array using the drive you have, and the new "virtual"
drive in place of the one you lost. It's probably best to do this with
non-persistent superblocks and just generally as read-only as possible
for data preservation on the drive you have.

So now you have a raid array.

For the filesystem, well, I don't know. That's a mess. I assume it's
possible to mount the filesystem with some degree of force (probably a
literally -force argument) as well as read-only. You may need to point
at a different superblock, who knows?

You just want to get the filesystem to mount somehow, any way you need
to, but hopefully in a read-only mode.

I would not even attempt to fsck it.

At this point, you have a mostly busted filesystem on a fairly broken
raid setup, but it might be possible to pull some data out of it, who
knows? You could pull what looks like data but is instead garbage to
though - if you don't have md5sums of the files you get (if you get any)
it'll be hard to tell without checking them all.

Honestly, that's as much as I can think of.

I know I'm just repeating myself when I say this, but raid is no
replacement for backups. They have different purposes, and backups are
no less necessary. I was sorry to hear you didn't have any, because that
probably seals the coffin on your data.

With regard to people recommending you get a pro. In this field (data
recovery) there are software guys (most of the people on this list) that
can do a lot while the platters are spinning and there are hardware guys
(the pros I think most people are talking about). They have physical
tools that can get data out of platters that wouldn't spin otherwise.

There's nothing the folks on the list can do really other than recommend
seeing someone (or shipping the drive to) one of those dudes. When you
get the replacement drive back from them with your data on it, then
we're back in software land and you may have half a chance.

That said, it sounded like you had already tried to fsck the filesystem
on this thing, so you may have hashed the remaining drive. It's hard to
say. Truly bleak though...

-Mike

Technomage wrote:
> mike.
> 
> given the problem, I have a request.
> 
> 
> On Friday 31 March 2006 15:55, Mike Hardy wrote:
> 
>>I can't imagine how to coax a filesystem to work when it's missing half
>>it's contents, but maybe a combination of forcing a start on the raid
>>and read-only FS mounts could make it hobble along.
> 
> 
> we will test any well laid out plan. 
> 
> lay out for us (from beginning to end) all the steps required, in your test. 
> do not be afraid to detail the obvious. it is better that we be in good 
> communication than to be working on assumptions. it will save you a lot of 
> frustration trying to correct for our assumptions, if there are none. 
> 
> tmh
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: addendum: was Re: recovering data on a failed raid-0 installation

[Technomage]

On Friday 31 March 2006 22:27, Mike Hardy wrote:
> Well, honestly I'm not really sure. I've never done this as I only use
> the redundant raid levels, and when they're gone, things are a complete
> hash and there's no hope. In fact, with raid-0 (striping, right? not
> linear/append?) I believe you are in the same boat. Each large file will
> have half its contents on the disk that died. So really, there's very
> little hope.

ok. in one of the tests we did, it has proved to have  written in a linear 
fashion. so, at least 1 disk may have most of the data (with mdadm v. 1.6.0).

But this was not the version of mdadm that was in dispute (mdadm v.1.9.0-3). 
we have not been able to prove that the version of mdadm that is in dispute 
writes in a linear mode, but that is the consensus at this point. The issue 
here is how the yast installer for suse creates the array, which is what we 
cannot confirm at this point. 



>
> Anyway, I'll try to give you pointers to what I would try anyway, with
> as much detail as I can.
>
> First, you just need to get the raid device up. It sounds like you are
> actually already doing that, but who knows. If you have one drive but
> not the other, you could make a sparse file that is the same size as the
> disk you lost. I know this is possible, but haven't done it so you'll
> have to see for yourself - I think there are examples in linux-raid
> archives in reference to testing very large raid arrays. Loopback mount
> the file as a device (losetup is he command to use here) and now you
> have a "virtual" device of the same size as the drive you lost.

it appears from the errors as detailed to me, the raid array does come up, but 
as soon as xfs tries to check the array is when the trouble starts. The 
errors for this have been posted here in another thread. 

as for the last sentence above, when we tried something similar, we 
encountered superblock problems. additionally, no valid or verifiable 
secondary superblocks could be found on the test array given the conditions 
to mimic the original problem.

>
> Recreate the raid array using the drive you have, and the new "virtual"
> drive in place of the one you lost. It's probably best to do this with
> non-persistent superblocks and just generally as read-only as possible
> for data preservation on the drive you have.

one small problem in the suse yast installer, "persistant superblocks" is 
usually defaulted to on. and that was not changed in the original install. 

>
> So now you have a raid array.
>
> For the filesystem, well, I don't know. That's a mess. I assume it's
> possible to mount the filesystem with some degree of force (probably a
> literally -force argument) as well as read-only. You may need to point
> at a different superblock, who knows?

This is xfs, it has a pretty good reputation at maintaining and retrieving 
data. However, as stated above, secondary superblocks could not be found to 
enable this operation.

>
> You just want to get the filesystem to mount somehow, any way you need
> to, but hopefully in a read-only mode.
>
> I would not even attempt to fsck it.
>
> At this point, you have a mostly busted filesystem on a fairly broken
> raid setup, but it might be possible to pull some data out of it, who
> knows? You could pull what looks like data but is instead garbage to
> though - if you don't have md5sums of the files you get (if you get any)
> it'll be hard to tell without checking them all.
>
> Honestly, that's as much as I can think of.
>
> I know I'm just repeating myself when I say this, but raid is no
> replacement for backups. They have different purposes, and backups are
> no less necessary. I was sorry to hear you didn't have any, because that
> probably seals the coffin on your data.

let us hope not. we still have several other options to try, including a 
partially functional drive that we can "possibly" retrieve data off of.

there is also the possibility that this is related to a kernel bug (as stated 
in another thread recently) and that there may not actually be anything wrong 
with the drive at all. 

>
> That said, it sounded like you had already tried to fsck the filesystem
> on this thing, so you may have hashed the remaining drive. It's hard to
> say. Truly bleak though...

actually, we have done nothing to the original other that to duplicate it. 
same goes for the secondary drive, though there were some problems on the 
laptop in question. IOW, my friend is so paranoid about the data that he 
treats the drives with tender loving care (IOW no destructive tests have 
been, or will be, run on the originals). 

on another front, because of the aforementioned kernel bug with XFS and mdadm, 
what are your thoughts on using LVM?

Re: addendum: was Re: recovering data on a failed raid-0 installation

[Mark Hahn]

> well? are you guys tapped out on this or should I be looking elsewhere?
> The *was* the recommended place to seek out help.
> still waiting........

netiquette hint: if you don't get a reply, you need to first verify
that you provided all possible diagnostic info in a clear, succinct message,
and _send_it_again_.  this sort of "well, why haven't you fixed my problem
yet" message is going to discourage any response, since you're asserting 
that readers should spend the time to go back, find your message, and do 
free work for you.

in short, make yourself easy to help.

regards, mark hahn.