Newsgroups: gmane.linux.debian.user Date: Fri, 4 Mar 2005 20:40:06 +0000
stop in your tracks, do as little as possible with your files
let's assume you deleted some files from /home/myaccount/source
find out which partition the deleted file is on. For example, run df, and see that /home is a directory under /, which lives on /dev/hda5 (all examples, your case may be different)
su to root
for safety, umount /dev/hda5 (this may not be possible though)
change to a directory on a different partition (/boot for example), and create a temp directory there
run debugfs /dev/hda5
at the prompt, run lsdel. It will list inode, owner, mode, size, blocks & time of all deleted files on that partition. This list could be long. Near the bottom are your recently deleted files. You'll recognize them by the id (run id to find out your account's id number), filesize, deletion time. Note the inodes of the files you want to recover.
run dump < inode > /boot/temp/filename for each file you want to recover. Note: you need the angled brackets around the inode number!
A program which has a more sophisticated interface for doing this is e2undel. (I'll write some info on this program here later).
Newsgroups: gmane.linux.debian.user Date: Fri, 4 Mar 2005 20:40:06 +0000
> A harddisc partition died on me without prior warnings. (ext3 filesystem) > The fsck command during boot suddenly reported: > > [...] > > I tried to read some data with the dd command and the first couple of > blocks work ok but later it complains:
I've had exactly this problem occur at work yesterday. I thought I would explain the full process for any other interested parties.
What you need to do is get the disk to a machine with sufficient space to hold the entire contents of the disk (or partition) that you are concerned about.
You then need to ensure that you are able to write a file that is bigger than 2GB - this is the real problem that I have been having!!!
Then what you do is NOT MOUNT you're dodgy disk but do make sure that your donor machine can see it.
If I presume that your bad disk is /dev/hda3 and that your good disk can be written to the current directory, then you should then be able to copy the contents to another disk by using the following command:
dd if=/dev/hda3 of=./recover.dat conv=noerror,sync.
The "noerror" bit says ignore errors and the "sync" option says to replace any bad bits read with zero data instead.
You can then mount the resultant file loop.
As an aside: my problem has been the combination of a Promise FastTrak 100 controller which had one disk die in a mirrored pair and the fact that neither DamnSmallLinux nor SystemRescueCD has allowed me to write a file bigger than 2GB on an ext2 partition!!
Eventually I found that SystemRescueCD would allow me to create and mount a ReiserFS partition where I can create a 20GB file!! Hurrah!
(I checked this by doing "dd if=/dev/zero of=/mnt/tmpdisk/blank_file bs=1k count=30720000")
But SystemRescueCD is not able to see the blasted disk on the blasted FastTrak controler!!!!!! AAAAAAAGGGGGGHHHHHH!!!!!!
Anyway - I hope this is of use to you.
TreeBoy
October 24, 2006 by Admin
Like dd, dd_rescue does copy data from one file or block device to another.dd_rescue is a tool to help you to save data from crashed partition. It tries to read and if it fails, it will go on with the next sectors where tools like dd will fail. If the copying process is interrupted by the user it is possible to continue at any position later. It can copy backwards.
[…] the whole article ignored because the author didn't even know that 'dd_rescue' and 'ddrescue' are different programs.
Moreover, jack Said on February 28th, 2007:
I think /dev/sda1 and /dev/sda2 are two partitions of the same hard disk. If you want to save a backup of the crashed sda1, you shouldn't place it onto the same physical disk.
/dev/sda2 is a device file, so the "/dev/sda2/backup.img" reference is invalid. You should mount the partition first, and then - if it has a writeable filesystem on it - you can create the backup file (the next example assumes that neither sda1 nor sda2 is mounted):
# mkdir /root/rescue # mount /dev/sda2 /root/rescue # dd_rescue /dev/sda1 /root/rescue/backup.img
I think when you try to mount a regular file as a partition you can only do it through a kernel loop device. It goes like this:
# mount -o loop /root/rescue/backup.img
Actually, there are two programs with similar names, 'dd_rescue' and 'ddrescue' (my preference)……The difference is 'ddrescue' is also known as gnu ddrescue, which can automate the whole process by specifying the log file option, and can resume where it left off if interrupted…….dd_rescue requires a separate wrapper script to automate it…
So you should make sure to use the correct name throughout the entire article, and not interchange dd_rescue with ddrescue….
documented on: November 4th, 2006, thegeekster
The big difference is that ddrescue can keep track of the bad sectors, and go back and try to do a slow read of that data. dd_rescue will slow down and read more carefully, yeah, but ddrescue is more thorough. Personal experience tells me that dd_rescue is ok for slightly wonky drives/removable media, but ddrescue is better for the slowly-dying-hard-drive variety of problem.
documented on: 10/25/06, regeya
The program described in this article is Garloff's original dd_rescue.
The program which I very much prefer is Diaz's newer GNU ddrescue.
Both are mature, well-respected tools. However, Diaz's ddrescue maintains a logfile so that it always knows what has been recovered, and what has not. So if you stop it (or your computer crashes) in the middle of a recovery operation, you can just run it again and it'll pick up where it left off.
Also, you can try again with different options (e.g., after disabling readahead or dma on the drive, or reading smaller chunks), or you can retry while reading from a raw device bound to the /dev/hdx instead of to the drive itself, to read individual sectors. It just works: if you put the drive in the freezer overnight, then hook it up and re-run GNU ddrescue with "-r 1" (retry bad sectors 1 time), it'll only try to read the unrecovered sectors, and won't waste time re-reading the parts that have already been recovered.
What's more, the logfile is plain ASCII and well-documented, so it serves as a record that you can use for other purposes. E.g., I've written a Perl script which reads the ddrescue logfile and spits out a Windows .bat file of 'nfi' commands, to determine which files on an NTFS file system are damaged.
documented on: February 3rd, 2007, Dave Burton
Yet another disk recovery blog that fails to point out some very important information. While the rest of the blog is quite helpful, hard drive failures can occur for many varied reasons. Just listening to the drive will often tell you.
Does it spin up? No - it's beyond mere mortals.
Does it make a clicking noise? Yes - ddrescue as in the blog will probably help.
No clicking and it might just be a partial electronics failure. In such cases, hdparam will allow you to turn off some advanced drive features that will get around the part of the electronic component that has failed.
I've had 100% recovery of a few failed drives simply by turning off DMA access. (hdparam -d 0 /dev/hda) Other hdparam options can also help. Man hdparam for more information! Note however, that hdparam is most useful on IDE PATA devices. YMMV for SATA. For USB & SCSI, hdparam is next to useless.
documented on: 10/25/06, digg0t
by ido50 on Tue 18 Jul 2006
Tags: corruption, file system, filesystems, recovery, restoration
We've all been there. We press the wrong key, we do some silly mistake, and suddenly, one or more of our file systems refuse to work. Whenever this happens, the first thing we hear is "You should have made a backup", the dreaded sentence that we'll never listen to. Let's face it, we're stupid, and we don't backup.
Fortunately, we have several powerful, open source tools that can help us save our data. The first thing you should do after having such a problem - to quote Douglas Adams - Don't Panic!
In this article, we'll use the amazing 'TestDisk' program to try and recover our damaged/lost partitions. The 'testdisk' package is available in all Debian releases (From stable to unstable) and can be installed easily.
So, after getting over the panic phase, we need to buckle up and get going. I suggest the following steps:
Classify the type of hardware where data has been lost: Hard Drive, USB Storage Device, CD, DVD, Compact Flash, etc. This is important because we are assuming the corrupted file system is not the one where the operating system resides, so it's still up and running. If that's not the situation, then the best way is to use a Live distribution. Knoppix is recommended, since it's based on Debian, containes all the tools we're gonna talk about, and every Debian user should feel comfortable with it. If you don't have a copy of Knoppix yet, you should get one now (See external links).
Note that when dealing with CDs and DVDs, these could be scratched or fast erased discs.
Backup the damaged partition(s): You may raise an eyebrow, but this step is actually very important. After suffering a corruption, we can still save our file system. This step assumes that if we were stupid enough to corrupt a file system and not make a backup, we're stupid enough to make another mistake while trying to save it, and destroy our chances of saving it completely.
This step might be difficult, depending on the size of the partition, but do your best to avoid skipping it. Basically, you'd want to backup to a larger device, and always, ALWAYS, to a DIFFERENT device. We'll do this using the 'ddrescue' program, available in the 'gddrescue' package:
$ apt-get install gddrescue
Then, we can create our backup:
$ ddrescue -B -n /dev/old_disk /dev/new_disk rescued.log $ ddrescue -B -r 1 /dev/old_disk /dev/new_disk rescued.log
Replace old_disk and new_disk with your source and destination devices, respectively (We're backing up the whole device, not just a partition). Note that the first command backs up error-free areas, while the other tries to backup damaged areas.
Unfortunately, stable doesn't have the 'gddrescue' package yet, so you will need to use 'dd' instead.
$ dd if=/dev/old_disk of=/dev/new_disk
Which is a pretty basic command. You might wanna try 'man dd' to learn about dd's arguments and use a command more suitable for your hardware.
If you prefer not to use 'dd', you can also try Kurt Garloff's 'dd_rescue'.
Install TestDisk: 'TestDisk' is a powerful program designed to recover damaged or lost partitions. To install it, simply type:
$ apt-get install testdisk
'TestDisk' works with Ext2/Ext3, ReiserFS 3.6, ReiserFS 4, XFS, JFS, VFAT, NTFS, Linux Swap, etc. It also comes bundled with another program, 'PhotoRec', which started as a program for recovering photographs from digital cameras, but developed into a general data recovery program from different storage devices, even hard disks. For a list of file systems 'TestDisk' can work with and file types 'PhotoRec' can work with, use apt-cache:
$ apt-cache show testdisk
Run TestDisk: We're now ready to run 'TestDisk':
$ testdisk
After a few seconds, 'TestDisk' will list the storage devices connected to your computer. Highlight your device and choose "Proceed". 'TestDisk' will then ask you the type of your partition. Usually, this would be Intel. After that, first thing to do is use "Analyze". 'TestDisk' will then analyze the device and try to find all of the partitions in it.
If you can't find your partition, try a more thorough search using "Search!". If you still can't find your partition, move to step 5.
If you have found your partition, highlight it and press Enter. Next, press 'p' to view the files in the partition. I call this step the "Phew, my files are still there step".
Right now, you might wanna try using "Write" to write the changes to the device. We haven't really done any changes, but 'TestDisk' might have done them itself, if it has identified a damaged boot sector.
After quitting 'TestDisk', you can try to access the partition. If you still can't do that, don't despair. Possibly, the boot sector is damaged. Run 'TestDisk' again, but this time use "Advanced". Select your partition, and choose "Boot".
If the NTFS or FAT boot sector has been found using the backup boot sector, 'TestDisk' will let you choose between "Rebuild BS" and "Backup BS". Choose "Backup BS" to replace the damaged boot sector by its backup.
Also, 'TestDisk' lets you dump the boot sector content ("Dump"). If it's a FAT partition, you can try to "Repair FAT". If it's an Ext2/Ext3 partition, you can try "Superblock".
Hopefully, 'TestDisk' has managed to repair the boot sector and the partition can now be mounted.
If 'TestDisk' found your partition, but doesn't know its type, use "Advanced" and select "Type". 'TestDisk' will then ask you for the fs type.
You are now ready to try mounting the partition again. If you can't do so, check if the disk is in use. If it is, you may have to reboot to be able to mount the partition. If you still can't mount, we might as well give up on trying to get the partition working, and try to recover the data inside it instead.
Run PhotoRec: 'PhotoRec' is your best choice when trying to recover data from damaged partitions. Basically, it doesn't care about the file system. It simply ignores it. To run 'PhotoRec', just type:
$ photorec
I will remind you that 'PhotoRec' has been automatically installed with 'TestDisk'.
The program's interface is just like 'TestDisk'. Select your device, the partition type (Intel, Mac, etc.), and use "Search". 'PhotoRec' will then make a thorough search of the partition to find files in it and recover them to your home directory (Into numbered "recup_dir" directories, like "recup_dir.1", "recup_dir.2", etc.). This may take some minutes, or hours, if the partition is very big.
Note that if you are recovering from an Ext2/Ext3 partition, you have to activate the ext2/ext3 mode in "Options".
After search has been completed, quit, take a look at your restored files, and use the command
$ hip hip hooray
which may or may not work.
If you need a more general program for recovering files, you can try the 'recover' and 'e2undel' packages, but these only work with ext2 partitions, and we are assuming that the partitions are not damaged. Basically, you can use these tools after you have used 'TestDisk' to repair a damaged partition or recover a lost one, but some of your files are still lost.
Remember: At any point of the above process, if somehow you make a mistake and damage your partition even more badly, just grab your backup device and start over.
I have managed to use 'TestDisk' to recover a damaged ext2 partition, back in the days when I was dual booting Debian and Windows. I used Partition Magic to resize some partitions, and it completely screwed them up.
I have also managed to use 'PhotoRec' to recover photographs from a CompactFlash card, after it failed mysteriously. I was taking pictures with my camera, when suddenly I got a "CF Error" message. I couldn't mount the card on my computer, and 'TestDisk' didn't manage to recover it. Fortunately, 'PhotoRec' restored all of the files with no problems, and I was able to format the card and start using it again.
Good Luck!
I would be happy to recieve any comments, suggestions, etc.
External Links:
Knoppix.
TestDisk - The program's home page, contains a Wiki with a lot of useful information and documentation. Be sure to check out Data recovery examples.
PhotoRec.
ddrescue
In case this article hasn't made this clear enough for everyone, TestDisk and PhotoRec are extremely useful tools in situations where partition meta-information may have been lost, but the data held on the partition has not yet been overwritten with new data.
This would be the case, for example, if you mistakenly used a 'format' command on a filesystem. Thus, for example, I was able to recover my mom's 'lost' pictures off a CF card that she had 'formatted' by mistake using her camera. The picture files did not show up with an ls command, but were nonetheless recovered in full after a PhotoRec run.
The important detail to remember here is that when you make this kind of mistake with a filesystem, you should unmount it right away and proceed to use Grenier's recovery tools immediately, so as not to allow the existing (hidden) data to be overwritten with new data.
Finally, it should be noted that the tools in question are also available for the Windows platform, so they are still useable even if you don't have access to a proper PC.
by Anonymous (216.46.xx.xx)
> would it work on CDR too? > > I have a CDR full of tools that I collected. It was burnt ok, but I can't > mount it any more (due to alignment problem of the original burnner?).
Yes, it works with CD-R and CD-RW as well.
More information in the program's wiki http://www.cgsecurity.org/wiki/CDRW
ido50
PhotoRec 6.5, Data Recovery Utility, October 2006
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org[]
Disk /dev/sdb - 1029 MB / 982 MiB (RO)
Partition Start End Size in sectors
D empty 0 0 1 981 63 32 2011136 [Whole disk]
Pass 0 - Reading sector 161745/2011136, 0/10 headers found
Elapsed time 1h04m51s - Estimated time for achievement 12h21m29
documented on: 2007.06.21
I did a lot of system recovery recently on a Windows XP system with a bad disk, and SystemRescueCD was invaluable - it has a great set of tools and is easy to use for Linux people, and has some graphical tools for those who don't know Linux.
The basic approach I used to copy as many good disk blocks over to a new disk, using GNU ddrescue - I also used SpinRite as a quicker alternative just to make data available before the new disk arrived.
Rather than using the included dd_rescue, use GNU ddrescue, which is much faster as it doesn't involve a shell script when trying to extract the maximum good data from a disk. It would be good if SystemRescueCD included this as an option (or ultimately a replacement as it does the same thing). See http://www.gnu.org/software/ddrescue/ddrescue.html
To recover more data from the disks, I used SpinRite, an inexpensive commercial tool that recovers failing hard disks (and improves health of disks that are near failure). It boots from its own disk, can be used with any hard disk whether it has a Windows or Linux filesystem, and the boot disk can be created under Wine. It worked really well at salvaging the maximum data possible, and is worth getting if you need urgently to recover data and don't have a spare disk of the right size to use with GNU ddrescue. It can also recover some bad data blocks if used before ddrescue, though I would always just use ddrescue first, then do a second pass with SpinRite once the good data is backed up. I don't think there's an open source equivalent. See http://en.wikipedia.org/wiki/SpinRite for more details.
Posted Jun 5, 2007 6:27 UTC (Tue) by guest Cato
documented on: May 23, 2007 by ris
Newsgroups: comp.os.linux.misc Date: 19 Mar 2003 21:15:41 GMT
> I need an *ignore* option in a cp of large files from a CD to disk.
Lowlevel reading of a device and ignoring all read errors is always possible by using "dd if=$INPUT of=$OUTPUT bs=$BLOCKSIZE conv=noerror". This will, as is implied, ignore all read errors. Any blocks that dd is unable to read successfully will be replaced with blocks filled with 0x00. There's another, possibly more useful, program called dd_rescue that works like dd, except it reads a large block to start with, if it finds an error in that large block, it attempts to read smaller blocks, and it recurses that process until the block size goes down to 512 bytes and it's received a certain number of read errors on a particular 512-byte block. dd_rescue is *damned* useful if you have a partially dead hard disk with important data on it.
Matt G
It is correct that you can either dd the block device, or dd individual files with the conv=noerror option. I have had mixed results. I think we have to distinguish between physical and logical read errors. The conv=noerror option can succeed when a checksum error has been found, meaning that some data have been read but it is known that the results are not what was originally written. A physical error on the device can result in a loss of track/sector locations and, I think, prevent a seek around the (localized) damage. In my case, there is physical damage. The dd conv=noerror just hung after the first Input/output error message.
Then I turned to myrescue, which operates on a file basis. myrescue has a slick little display that gives you hope. Alas, it too just hung.
Finally, after the suggestion of Dancing With Crows, I turned to dd_rescue. It did not hang, but it ran so slowly that I left the machine running and went to bed. After 8 hours or so dd_rescue had advanced only a few Mb.
Here is a follow up of my experience. The situation is that I have a CD with iso9660 file system containing a number of valuable files. I can mount the CD and examine the directory, but a number of the files are unreadable, part of the file can be accessed, but at some point there is a read error. I hoped to be able to recover what I could from the file regardless of the content of unreadable sectors.
Treating the CD as a block device is a bad idea. None of the "rescue" resources are able to get past the first read-error, so the bulk of the CD is inaccessible.
Since the directory of the CD is readable, I can mount it and try to access the files individually. The no-brain rescue method is to try to cp the files to disk. Here is the kicker: in *every* case cp got more of the file than:
dd with conv=noerrror
myrescue
dd_rescue
Newsgroups: comp.os.linux.misc Date: 30 Jan 2003 19:58:34 GMT
> How do I delete this file? I have tried chattr, etc. without > success. It appears to be viewed as a device. It is not in > the /dev directory!! > > c---rw--wx 29816 1937012594 1914725664 47, 118 Jan 20 > 1995 screensaver-properties.desktop
umount the partition, then run e2fsck or reiserfsck on it, making sure to use the -f option if the fsck says "filesystem is clean." This points to a problem with your filesystem, and fsck is the best hope of getting rid of this weird problem. fsck will probably complain about a number of other things. Scan your logs in /var/log/messages for mentions of disk errors. If you're using a pre-2.4.5 kernel and you have a VIA IDE chipset, upgrade your kernel *NOW*.
Matt G
>>>c---rw--wx 29816 1937012594 1914725664 47, 118 Jan 20 1995 > >>So this file is referenced 29816 times. Also, the owner of the file >>is 1937012594, and the group owner is 1914725664. I would check the >>consistency of the filesystem since these are fairly strange values. > It's a broken file system, but so what. His best bet is probably to wipe the > inode with debugfs then pull the plug and see if fsck > fixes it on reboot. > I.e. the FS isn't broken _enough_ yet. He needs to break it a bit more > before the tools will notice.
Things like this are most commonly from a failing disk (maybe only 1 sector) or bad memory. Less common are controller or motherboard problems (less common in the sense that they would usually cause more wide spread problems).
The inode is junk, and need to be wiped. In addition to fsck though, I'd also run non-destructive disk analysis and any other hardware diagnostics available. Better to know sooner than later: this could of course be a rogue accidental write, but unless the owner plays with drivers or regularly is running dd etc. as root, there's probably hardware going south somewhere.
Tony Lawrence
> I had just run e2fsck and it found a small number of items, less then a > dozen. Half of those were bad time stamp on free inodes. I will check the > disk. > How can I identify the inode? > This is an ext3 fs. Will debugfs work?
The 'second' run of e2fsck fixed it. It found a dozen or so things it did not like all within a 4 inodes range. The file actually had device attributes.
Thanks, Dan
Newsgroups: alt.os.linux.mandrake Date: 2001-04-24 07:04:02 PST
> Please help me. During instalation of Mandrake 8.0 one of the most > important partition was formated. It is formated, thus it mean that > partition table was deleted but data are still there, please can anybody > tell how to get disk working. Please help me. > I am using Linux from 1995, and it happen first time in my life.
I had a similar problem with a RH installation and was able to recover everything. The problem appeared to be caused by lilo. Here are a few tips.
Do not let scandisk 'fix' anything or you may loose all your data.
Boot to DOS using a boot floppy. Are the directories and files in tact?
If they are you will probably be able to recover everything.
Try restoring the disk to its original condition by:
A. FDISK /MBR (will restore your MBR to pre lilo (or grub)
B. Run SYS on your disk partition (usually SYS C:) to restore the FAT
boot sector. It is very important that you use the sys command that was on
original windows partition.
In the unlikely event that this does not work, I will give you a few more tips about FAT32 files system that might help.
Good luck
Bill
> Did you do an expert install? > > I'm sorry for the anguish that you are suffering. > > Just exactly how did this happen? Normally it wouldn't happen.
Yes I instaled in expert mode, when I choosed partition to instal Linux, and than I choosed swap, it asked me if I want to format, I thought it will format only linux and swap. But it formated linux and one of the windows partition.
I was working long time to try to recover it, but without any result. Fat tables are all zeros "0", but all data are on disk, but if I am using norton disk doctor it could not find the names for the files, all files recover as the text files, but this way I will work all life to find the names of the files on my 12 GB fat32 partition.
Newsgroups: alt.os.linux,comp.os.linux.x Date: Sat, 11 Jan 2003 22:34:11 +0100
Thanks so much everyone for the huge response. You guys were a great help, you saved my system, and I learned a lot beyound that.
Here's what I did:
First I scanned my harddisc with gpart. The output looked very much like it could be my partition table, with the first two partitions missing (which is not surprising, since the beginning of the disc was overwritten). Then I called gpart -W /dev/hda /dev/hda to write the guessed partition table to the disc.
Then I called fdisc to create the two missing partitions at the beginning of the disc. This resulted in the partition table being not in disc order. But fdisc has a function to fix the partition order (x for expert, then f). I wrote the partition table to the disc, removed the first partition from /etc/fstab and rebooted using the boot disc:
Everything worked! Next, I recreated the first partition (/boot), updated /etc/fstab, rebooted again, and happily saw that everything was good.
With the gpart output for comparison, the content of /proc/partitions also made sense: It lists the size of each partition in kilobytes. Just for curiosity, I tried to create a partition table with fdisk by putting in the exact numbers in kilobytes. However, this resulted in the partition table NOT having the correct boundaries, thus this wouldn't have worked.
Also thanks for the hint that tar does store file ownership information and special files like devices and fifos.
Jannik
22 0 9873360 hdc 22 1 9871911 hdc1 3 0 40021632 hda 3 1 30712 hda1 3 2 2468592 hda2 3 3 6963264 hda3 3 4 1 hda4 3 5 614848 hda5 3 6 5734480 hda6 3 7 24209608 hda7
./gpart.linux /dev/hda
Begin scan...
Possible partition(Linux ext2), size(6800mb), offset(2440mb)
Possible extended partition at offset(9240mb)
Possible partition(Linux swap), size(600mb), offset(9240mb)
Possible partition(Linux ext2), size(5600mb), offset(9841mb)
Possible partition(Linux ext2), size(23642mb), offset(15441mb)
End scan.
Checking partitions...
Partition(Linux ext2 filesystem): primary
Partition(Linux swap or Solaris/x86): logical
Partition(Linux ext2 filesystem): logical
Partition(Linux ext2 filesystem): logical
Ok.
Guessed primary partition table:
Primary partition(1)
type: 131(0x83)(Linux ext2 filesystem)
size: 6800mb #s(13926528) s(4998672-18925199)
chs: (1023/15/63)-(1023/15/63)d (4959/0/1)-(18774/15/63)r
Primary partition(2)
type: 005(0x05)(Extended DOS)
size: 29842mb #s(61118064) s(18925200-80043263)
chs: (1023/15/63)-(1023/15/63)d (18775/0/1)-(79407/15/63)r
Primary partition(3)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
Primary partition(4)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
> I have a Linux SuSE 7.2 with two hard discs (hda and hdc). Everything > important resides on hda. I wanted to do a "badblocks -wv /dev/hdc" (a > destructive surface test), but instead I typed "badblocks -wv /dev/hda", > which immediately started to write to the beginning of /dev/hda. > I noticed the error immediately, but the boot sector, partition table and > partition hda1 (which is only a too big /boot volume and not important, I > have kernel, map and menu on a boot disc) are overwritten. > Now I have the situation of a system that is running perfectly at the moment > (I can still post messages in newsgroups...), but I know that upon reboot > everything will be lost. Of course I backup important stuff at the moment > (writing one CD after another), but hda is 40GB and the installation is > valuable also since I installed and configured loads of stuff manually. > Since I can even mount and unmount partitions on hda, it seems the > kernel/system still knows where the partitions are. There must be a copy of > the partition table, at least in memory. Is there any way to restore this > partition table? > Is there a program that creates a partiton table by looking at the hard dis > and partition sizes? > The second option is to copy everything to the second hard disk. But it is > only 10GB. It would fit if things are zipped (a 3GB /usr zips to 1GB), but > then the file ownership data and special files (fifos, devices) are > lost. Does anyone know of a backup procedure that keeps all this stuff? > A million thanks for any answer that comes before the next power failure...
Jannik Meyer