On Mon, 2004-11-29 at 23:17, Benjamin Scott wrote: > On 29 Nov 2004, at 9:43am, [EMAIL PROTECTED] wrote: > > I carelessly hit 'Enter' when I shouldn't have and now have a hard drive ( > > hdb ) formatted reiserfs that *did* contain all my backup data when it was > > an ext2 partition. > > Ouch. Got backups?
This *was* my backups. :-( Thanks for the tips Ben, I'll see what I can do with it. This is on my home PC and all that really is lost is some personal stuff and various things I've been saving. I'll live. > Clarification/FYI: "hdb" refers to an entire hard disk (the slave disk on > the first IDE bus, in particular). Typically, filesystems are created on > partitions, such as "hdb1" (first primary partition). Do you know which way > your original filesystem was created? > > > I chose 'quick' format when I formatted it. Is there any way for me to > > get the data off this drive? > > Before I even get into doing things, if the data on this filesystem had > significant value, you may want to consider a professional data recovery > outfit, such as CBL Technologies (http://www.cbltech.com). While expensive > (several hundred to a few thousand dollars), it can be less expensive then > re-creating all your data. > > Assuming that is is not the option you want... > > Before you do anything else, you might want to consider making an "image > copy" of the filesystem partition (or what's left of it, anyway). You can > then later restore the same image back to the partition if a recovery > attempt makes things worse rather then better. > > This requires an existing filesystem with at least as much free space as > the size of the damaged filesystem. For example: > > dd if=/dev/foo of=/path/to/bar.img > > In the above, "/dev/foo" is the device to read from, and > "/path/to/bar.img" is the path and file name of a file (to be created) that > will be an exact image copy of the partition. You can also image a whole > disk this way. > > You could try using "e2fsck" with the "-b" switch, which allows you to > specify an alternate superblock. Use one of the backup superblocks, which > ResierFS might have left untouched. For example: > > e2fsck -b 32768 /dev/foo > > If you don't know where any of the backup superblocks might be, you can > use the "-n" switch to "mke2fs" to find out. The "-n" switch causes mke2fs > to not actually write any changes; it just prints information. For example: > > mke2fs -n /dev/foo > > CAUTION: If you leave out the "-n" switch. mke2fs will create a brand new > (empty) filesystem instead! > > If all your backup superblocks are toast, you can try the "-S" switch to > "mke2fs", which will cause mke2fs to write out new superblocks and block > descriptors, but leaves the inode table intact. Then immediately run > "e2fsck" on the same filesystem. The results can resemble swiss cheese more > then your original data, but can be better then nothing. > > WARNING: The "-S" switch to "mke2fs" is a last-ditch, semi-destructive > option. Use with great care! > > In all of the above "mke2fs" commands, if you specified any special > options when you first created the filesystem (e.g., a journal, or a > non-default block size), you will need to specify those same options again, > or you will end up making things a lot worse. > > Hope this helps, -- Charles Farinella Appropriate Solutions, Inc. (www.AppropriateSolutions.com) [EMAIL PROTECTED] 603.924.6079 _______________________________________________ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
