One important thing to know before doing anything else:
Every byte written to partitions in question will decrease chances to get data back since deletion of files and even partitions does not automatically mean actually deleting that data on disk. In most cases it only means deleting administrative entries in file or partition tables. But writing new files or partitions on the very same disk might actually overwrite data blocks containing pieces associated with files still intact! The second thing you might want to consider: If you mistakenly deleted single files or even a bunch of them look somewhere else but better not reboot until you really know why you have to do so as rebooting in those cases will sometimes also mess up chances to get back your data. Here I will only handle partition or hard drive errors.
So the very first step will be to get hold of extra storage (like USB drives), boot up some Live CD, e.g. your Ubuntu installation cd. If you have liability to paranoia you might even want to physically detach your hard drive and use some USB case to access it instead. First of all do something like
ddrescue -vr-1 /dev/sda recovered_data_blocks.img gddrescue.log
using gddrescue. Adjust parameters to your needs, especially /dev/sda (complete drive) or /dev/sda1 (partition in question). For Ubuntu you need to install gddrescue (= GNU ddrescue) package first. gddrescue will create an image trying hard to copy every data block still intact so you can, at any point, restore the drive stage where you first discovered you lost data. This, or course, can be used with any block-oriented medium such as CD-ROMs or DVDs. You might want to specify “-b 2048” for CDs. Also use -n to get the most data on first run. For subsequent attempts you might want -rX where X is the number of retries for erroneous areas. I recommend to use -vr-1 for verbose infinite retries. gddrescue first reads as many as possible intact blocks and then splits error areas with each subsequent run. Note though for partitions or even complete hard drives it will take hours so be patient and make sure to use gddrescue’s log file option! With other tools I tried it took even more time which makes sense since gddrescue reads only blocks that really need to be read.
Second you should — just in case — save your partition geometries with fdisk (output similar):
$ sudo fdisk -ls Password: Disk /dev/hda: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 9145 73457181 b W95 FAT32 /dev/hda2 9146 19106 80011732+ 83 Linux /dev/hda3 19107 19457 2819407+ 5 Extended /dev/hda5 19107 19457 2819376 82 Linux swap / Solaris Disk /dev/hdb: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System Disk /dev/hdc: 20.8 GB, 20847697920 bytes 255 heads, 63 sectors/track, 2534 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdc1 * 1 2427 19494846 83 Linux /dev/hdc2 2428 2534 859477+ 5 Extended /dev/hdc5 2428 2534 859446 82 Linux swap / Solaris
After ddrescue has finished try TestDisk for lost partitions which, among others, looks for back up partition tables, inode tables, and the like. To restore plain data there are heaps of tools. Most notably foremost and PhotoRec. Note though that for lost partitions there is no way to really know what file type found blocks belong to or even the name of associated files’ paths, at least as far as I can imagine. File names really are — in all file systems I know — only attributes of a data segment called file (or inode) such as access date, ownership and such. Sometimes file names are even stored in special files (directories or folders) which means there data blocks need to be intact and it has to be known where they are! The scenario I ran into was I mistakenly installed Ubuntu on top of Windows XP (NTFS partition) instead of resizing the partition as intended. TestDisk even though listing a NTFS partition (from it’s back-up MFT located at the end of NTFS partitions) couldn’t however restore the partition as such. Running Microsoft’s chkdsk stored a bunch of files with their filenames several folders into one called found.000 (I ran it inMicrosoft’s recovery command line from CD after manually through fdisk changed partition type to NTFS/HPFS, e.g. x07). Using the above mentioned tools I could restore some more but without there original path or file names. All together I recovered ~40 GB out of probably 60 GB data (which included system files).
Resources
- Tincho’s Debian Package of the Day: gddrescue
- Pat Patterson’s article on Ubuntu hard drive recovery (stating John Gilmore to suggest GNU shred instead of /dev/urandom to securely shred data on dead hard drives)
- Find deleted or lost partitions using testdisk
- Ubuntu Wiki on Data Recovery
- On toad.com: “Disk drive recovery“
- Heaps of info on filesystems and mounting (especially section about FS checking) as part of a larger site about Ubuntu/Windows dual-boot set-ups; has a section on TestDisk with illustrated walk-throughs
- hachoir-subfile is a tool based on hachoir-parser to find subfiles in any binary stream.
- About damaged Superblocks (extfs based), what superblocks are and how to use backups of them stored throughout the partition
- From German Ubuntu User Wiki: “Notfall“, “Festplatten Problembehebung“
- From German Linuxwiki: “verlorene Partition finden“
- man pages from ntfsprogs in Linux-NTFS Wiki (ntfsck is not ready, yet)
Further reading:
- On a side note: Why *nix FS don’t need defragmentation and on Fragmentation and Unix file systems
- Another side note: Ubuntu Forum entry on the various mount/fstab options
- Easiest Way To Restore Deleted FAT and NTFS Logical Drives
all posts
sysblogd 