AJ524
asked on
Recover Data from FreeBSD Software RAID1
Hi there, my apologies in advance if this is the wrong mailing list for
this type of question. I have a problem with a previously-RAID1'd
FreeBSD filesystem I was hoping someone could help me with. The
background is this:
The disks originally belong to a client of a friend running an old
obsolete (as in, the company doesn't exist any more) home NAS device by
Fastora (model NAS-T2, two 200GB IDE disks in a RAID1 configuration,
unknown version of FreeBSD). The NAS gave up the ghost when the OS
(stored on a CF card) recently melted down, rendering the device
unbootable. The IDE drives seem unharmed, after sticking them in a USB
drive cage they present themselves to both Linux and FreeBSD operating
systems and both OSes can see partition tables, disklabels, etc.
Unfortunately, because of what appears to be a previously-configured
software RAID1 scheme I can't seem to simply mount the slices under *nix
or *BSD and copy the data off.
Currently one of the drives is attached via USB cradle to a freshly
installed FreeBSD 8.2 VM. I was able to get a good chunk of the data
back off of it with a tool called "photorec", which (to be brief) scans
the block device looking for file-header signatures and makes educated
guesses as to whether it's $file_type_x, $file_type_y and so forth,
copying to a separate recovery directory without the benefit of the
original file name or previous directory structure. It's cool, the guy
technically has his data back (or will, after a couple of hours of
manual sorting), but I've got enough time into this that, by $deity, I
Have To Win(™) by being able to mount the (by all accounts happy and
uncorrupted) filesystem. I was hoping this might be the proper mailing
list for insight into ccd/geom/vinum.
What I think needs to happen at some level (and please feel free to
correct me if I'm wrong) is one of two things:
1. Using CCD or one of the other utilities, I need to add this USB-caged
disk into a temporary RAID-1 array in a 'degraded' state so FreeBSD sees
the disklabels as something other than type "raid". This will allow me
to mount the preexisting partitions as normal, and copy the data off the
disk. If there's some way I can positively identify a given
partition/slice as having been created by either ccd/geom/vinum, that
would be awesome.
2. Using dd or something similar, I need to image the existing disk to a
file and strip the first N bytes that (presumably) hold the software
RAID headers. My hope is that if I get the offset right, the mount
command will pick up on the partition/slice data it needs and allow me
to mount the image via loopback, copying the data off as above.
Does anyone have any insight that could help me accomplish the above, or
a better way to approach the problem?
Here's some information about the disk itself (all commands run from the
FreeBSD 8.2 VM):
ls -l /dev/da0*
http://pastebin.com/6Sv8T4Mg
fdisk /dev/da0 output
http://pastebin.com/ZzPKUXDL
bsdlabel /dev/da0*
http://pastebin.com/3BPKbYZ6
newfs -N "dry run" data (possible superblock locations, blocksize
defaults, etc for /dev/da0s3a, the 'important' one)
http://pastebin.com/b9nLFsjK
incomplete "scan_ffs /dev/da0" run:
http://pastebin.com/28T8Fr67
I hope this helps, any assistance folks could provide would be MOST
helpful! Please don't hesitate to let me know if you need more
information, I'm happy to respond as quick as I possibly can.
Many thanks in advance,
Andrew
this type of question. I have a problem with a previously-RAID1'd
FreeBSD filesystem I was hoping someone could help me with. The
background is this:
The disks originally belong to a client of a friend running an old
obsolete (as in, the company doesn't exist any more) home NAS device by
Fastora (model NAS-T2, two 200GB IDE disks in a RAID1 configuration,
unknown version of FreeBSD). The NAS gave up the ghost when the OS
(stored on a CF card) recently melted down, rendering the device
unbootable. The IDE drives seem unharmed, after sticking them in a USB
drive cage they present themselves to both Linux and FreeBSD operating
systems and both OSes can see partition tables, disklabels, etc.
Unfortunately, because of what appears to be a previously-configured
software RAID1 scheme I can't seem to simply mount the slices under *nix
or *BSD and copy the data off.
Currently one of the drives is attached via USB cradle to a freshly
installed FreeBSD 8.2 VM. I was able to get a good chunk of the data
back off of it with a tool called "photorec", which (to be brief) scans
the block device looking for file-header signatures and makes educated
guesses as to whether it's $file_type_x, $file_type_y and so forth,
copying to a separate recovery directory without the benefit of the
original file name or previous directory structure. It's cool, the guy
technically has his data back (or will, after a couple of hours of
manual sorting), but I've got enough time into this that, by $deity, I
Have To Win(™) by being able to mount the (by all accounts happy and
uncorrupted) filesystem. I was hoping this might be the proper mailing
list for insight into ccd/geom/vinum.
What I think needs to happen at some level (and please feel free to
correct me if I'm wrong) is one of two things:
1. Using CCD or one of the other utilities, I need to add this USB-caged
disk into a temporary RAID-1 array in a 'degraded' state so FreeBSD sees
the disklabels as something other than type "raid". This will allow me
to mount the preexisting partitions as normal, and copy the data off the
disk. If there's some way I can positively identify a given
partition/slice as having been created by either ccd/geom/vinum, that
would be awesome.
2. Using dd or something similar, I need to image the existing disk to a
file and strip the first N bytes that (presumably) hold the software
RAID headers. My hope is that if I get the offset right, the mount
command will pick up on the partition/slice data it needs and allow me
to mount the image via loopback, copying the data off as above.
Does anyone have any insight that could help me accomplish the above, or
a better way to approach the problem?
Here's some information about the disk itself (all commands run from the
FreeBSD 8.2 VM):
ls -l /dev/da0*
http://pastebin.com/6Sv8T4Mg
fdisk /dev/da0 output
http://pastebin.com/ZzPKUXDL
bsdlabel /dev/da0*
http://pastebin.com/3BPKbYZ6
newfs -N "dry run" data (possible superblock locations, blocksize
defaults, etc for /dev/da0s3a, the 'important' one)
http://pastebin.com/b9nLFsjK
incomplete "scan_ffs /dev/da0" run:
http://pastebin.com/28T8Fr67
I hope this helps, any assistance folks could provide would be MOST
helpful! Please don't hesitate to let me know if you need more
information, I'm happy to respond as quick as I possibly can.
Many thanks in advance,
Andrew
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
gheist
He sort of says he sees disklabel and mbr partitions.
oups, i missed the pastebin part
i guess the NAS uses slices as LUNs and builds several raids in there
in this case the exact procedure i gave above is likely to work, except for :
- it should be performed on each /dev/da0sXa partition
- you may look for a partition table or a disk superblock depending on the way the NAS was setup
to look for a superblock, the file command should help. pipe one block at a time to it's stdin, and it should be able to detect a raw filesystem
i guess the NAS uses slices as LUNs and builds several raids in there
in this case the exact procedure i gave above is likely to work, except for :
- it should be performed on each /dev/da0sXa partition
- you may look for a partition table or a disk superblock depending on the way the NAS was setup
to look for a superblock, the file command should help. pipe one block at a time to it's stdin, and it should be able to detect a raw filesystem
If it is RAID1 mirrored partitions it could be 2 copies of UFS, hopefully with very little damage...
ASKER
Thanks for your thoughts on this guys. No one... not even data recovery companies... has been able to get the data off of these drives. They're basically restoring from their last good backup (a YEAR ago! Who does that??) and taking the loss.
ASKER
Thanks anyway guys!
Strange, the viertual machine was showing good FFS data.
ASKER
I agree! Very strange! One company said they could do it but it would cost about $5k and then the data would be in a very raw state... no folders, no file names... and even then only about 75% of the files would work. Not sure what they were doing there. I'm h oping that next time this client will listen when I beg them to do backups rather than rely on an unknown company's NAS.
Do you have a dd image of that disk?
I'd try to mount the partitions seen by fdisk, if any files in there then tar cvf /some/nfs/share *
i can extract raw data for 5k dollars too (or for free)
I'd try to mount the partitions seen by fdisk, if any files in there then tar cvf /some/nfs/share *
i can extract raw data for 5k dollars too (or for free)
ASKER
I am completely open to any idea other than spending thousandS of dollars on a recovery, including shipping out drives, having someone sign a non-disclosure contract, etc. It's a job that will certainly pay for results, if you know anyone interested.
PS your initial approach was completely correct
Do you have a disk space to keep all the data from your broken disk? Twice?
You can use g4u boot disk to make exact image copy from the disk. (the $5k thing)
run fdisk, run fsck against all partitions found, mount them, ls -lR. If it makes sense tar cf...
You can use g4u boot disk to make exact image copy from the disk. (the $5k thing)
run fdisk, run fsck against all partitions found, mount them, ls -lR. If it makes sense tar cf...
use dd to image the target and work with the copy. The drive is ancient and in stress. Once you have a copy you can try things all day long w/o risking data destruction.