Hi, Just following up to myself. I have a bit more info. I used vnconfig like so to attach my dd "image":
vnconfig -s labels -c vn0 xena-home.dd And while fsck and disklable both refuse to believe it's at all valid, I can do the following: mount -o ro -f /dev/vn0c /mnt/tmp And for the most part I can move around the filesystem, read files, etc. But it is in a very inconsistent state. How can I make fsck work on this? There's data there, but looking into certain dirs panics the box (it is just a junker set aside for this task at the moment). Here's what fsck says: [EMAIL PROTECTED]/mnt/tmp/vpopmail/domains]# fsck /dev/vn0c ** /dev/vn0c BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE ioctl (GCINFO): Invalid argument fsck: /dev/vn0c: can't read disk label Any hints? Thanks, Charles On Mon, 19 Jul 2004, Charles Sprickman wrote: > Hi, > > I'm sorry for hitting this list, but I'm trying to target people with some > good old-fashioned recovery procedures in their toolboxes, and people that > have a better understanding of UFS than I do. > > I'll try to keep this brief. We are looking for either some "here you go" > help, or if there's someone who's really a whiz at this, paid help... > > The story, in brief, and what we're looking for: > > We have a mail server that had it's RAID array trashed by a typo. No > backups (perhaps this will make the budget for that appear). There are > four disks running in RAID 1+0 on an Adaptec 2110s. While replacing a > failed drive I screwed the pooch with a typo. I meant "raidutil -a > rebuild" but I typed "raidutil -a build". That command ran for about 45 > seconds before I realized what had happened and cut power to the box. > > fsck was able to fix / with no problems, and most other partitions. We > reinstalled the base OS and rebuilt all our local additions (ports + > vpopmail/qmail/courier-imap-pop) in case there was any corrupted gunk left > on the drive. However the partition holding all the mail (in Maildir > format, working with vpopmail/qmail) seemed quite screwed. We let fsck > try for about 12 hours and had to cancel out of it. While working on > other things, I dd'd off this partition via ssh to another machine (ssh > borked.box dd if=/dev/da1s1h bs=1024 > dd.img) hoping that we could do > something with it later. Once that was done, we newfs'd that partition > and let vpopmail recreate mailboxes as mail came in. So we're done on > that front, but missing all old mail. > > I now have the disk image on a spare box. It's 26GB (about 20GB of actual > data). My initial plan is just to see what happens if I mount it > read-only, and then try to fsck without any time pressure and see what > we've got left. Since I wasn't able to figure out how to dd this back to > a pre-partitioned drive, I was going to try vnconfig to attach the dd > image to vn0, then mount and fsck that. Should that work? > > I have little faith that all this will work though... If anyone has some > tips/pointers/prayers, let me know. Again, we can probably dig up some > cash if someone with experience in this would like to help. > > I'm still waiting for some info from Adaptec to see exactly what the > "build" option does, and where it starts from and how far it might have > got in that period of time. Oddly, the last tech that called for more > info said he was going to ask DriveSavers (as they know that stuff???). > > Please email me directly with any other questions. I wanted to keep this > as brief as possible since it's fairly OT. > > Thanks, > > Charles > _______________________________________________ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
