This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: Restoring Partition Information From: "Jeff Hogg" <tastin@catchnet.net> Date: Thu, 21 Sep 2000 15:45:58 -0500 Original Message----- From: Ward William E PHDN <wardwe@nswcphdn.navy.mil> To: Redhat-List (E-mail) <redhat-list@redhat.com> Date: Thursday, September 21, 2000 3:38 PM Subject: Restoring Partition Information >Guys, I need help. Last Friday, one of my wife's hard drives went >down in her machine. The drive is defective, but I can still detect >that it's there. I need to get the information off the drive, or >at least what is salvageable, as she hasn't made a backup in months. > >This seems like a natural for Linux; I've taken her drive, and inserted >it into my machine as hdb. However, the partition information is wiped. >The drive was partitioned as FAT32; I'm aware that there are techniques >that could be used (for example, I could look at the raw disk and >locate text files) but none of the techniques seem to be enough. Yeeouch :) That does not sound fun. Well, heres a my shot at helping you out o the dog house. If the drive in question isn't too big, you could just try using dd to grab everything from the disk and plop that into a file on your own hd. You could then mount that file as a "disk image" via mount -t vfat -o loop /directory/filename /mountpoint You could check to see if the data is relatively intact within the disk image. If so, then you could replace the old disk with a new one of the same type and size and dd the data back onto the drive. If not, you might mount the new drive up as well and try copying what data can be seen from the "image" to the new drive. You'd have to format the new drive first as fat32 of course. Undoubtedly there are a few dozen other solutions out there, and hopefully one of them will help you out. Goof luck. === Subject: Re: Restoring Partition Information From: rpjday <rpjday@mindspring.com> Date: Thu, 21 Sep 2000 17:41:33 -0400 (EDT) On Thu, 21 Sep 2000, Jeff Hogg wrote: > > -----Original Message----- > From: Ward William E PHDN <wardwe@nswcphdn.navy.mil> > To: Redhat-List (E-mail) <redhat-list@redhat.com> > Date: Thursday, September 21, 2000 3:38 PM > Subject: Restoring Partition Information > > > >Guys, I need help. Last Friday, one of my wife's hard drives went > >down in her machine. The drive is defective, but I can still detect > >that it's there. I need to get the information off the drive, or > >at least what is salvageable, as she hasn't made a backup in months. > > > >This seems like a natural for Linux; I've taken her drive, and inserted > >it into my machine as hdb. However, the partition information is wiped. > >The drive was partitioned as FAT32; I'm aware that there are techniques > >that could be used (for example, I could look at the raw disk and > >locate text files) but none of the techniques seem to be enough. as i recall, the original poster suggested the partition table was toast. i salvaged a drive like this years ago, when i was still young, stupid and didn't know how hard it should be. it was on a SCO box, and all i did was write a small C program that read blocks off of a device and looked for the superblock "fingerprint" (can't remember exactly what that was, but i think i looked for the boot block for each partition, and assumed the superblock started immediately thereafter, which it did.) this requires nothing more than using the "read" C library call, and figuring out what is distinctive about an ext2fs filesystem. using this trick, i did in fact locate the superblocks, hence the filesystems, and just ran fdisk to replace the partition table. voila. so, who wants to suggest how to identify the filesystem? note that this should work on windows boxes as well, again given some distinct pattern that identifies the start of a partition. === Subject: Re: Reiser FS From: John Summerfield <summer@OS2.ami.com.au> Date: Fri, 22 Sep 2000 02:02:02 +0800 Whither backups? A journaled filesystem will NOT protect against: 1) > failed hard drive; 2) hacker damage; 3) virus/worm damage; 4) accidental That's all true. However, those backups are no substitute for a fixup program that works well and does NOT require a lot of technical knowledge to use. I've just been through the backup/restore caper for my primary disk. It's no joke, and most people here would not be able to do it at all. I filled my Travan 4 (4/8 Gbyte tape) - that alone took two hours on the good run. I then exchanged the failed HDD, installed its replacement and restored. Because of tar's communication impediment, I then found it necessary to run a 'tar -d' to find what it complained about. Including travel to exchange disks, it took a good day's work, and that excludes much of the preparation (eliminating stuff that would not fit on the tape, preparing a recovery disk that would drive my tape drive and do everything else I thought I might need). Most home users, judging from the systems I see on sale in shops, cannot backup their systems; I couldn't have made a simple backup either, if the disk had been anywhere near capacity. On this computer I had a luxury - a MO drive where I could prepare a fairly complete Linux system. ===