Backup Repair

Hi Klaus: I think it's awesome the help you give people in your Linux Magazine column; I've read it each month since you started. Now it seems it's my turn to ask for your advice.

My backup disk (an external USB disk; Maxtor, 320GB) happened to be mounted on my PC when I wanted to write a boot image to a USB stick. Unfortunately, I used the wrong device when running dd. Thus, the boot image got written over the external USB disk. One would think that it wouldn't be such a problem since it was just my backup disk; however, I'd actually like to get data back from my backups. I would guess that only the first few megabytes were overwritten (the boot image is roughly 14MB), and thus basically everything is intact, and it's just a matter of writing a new partition table and telling it that the start of the disk is actually a few megabytes along from where it normally would be.

Unfortunately, I haven't been able to repair the system. I don't want to use PhotoRec or similar tools because working my way through thousands of files sorted by file type isn't going to help me find what I'm looking for. At best, I'd like to get the files with directory structure back (as much as possible), and given that the hard drive itself isn't broken, this should be theoretically possible.

I'm hoping that you can give me some pointers as to what I could do to recover my data. So far, I've created an image of the disk with ddrescue so that I can test various recovery scenarios before doing the actual recovery. At present, TestDisk has been most helpful; however, it hasn't been able to reconstruct the partition structure, although it has given me some information.

Starting TestDisk and selecting Intel and then Analyse gives the output in Analyse.txt. This doesn't seem to help much further, so running the next option, which is Quick Search, gives the output in QuickSearch.txt (both files attached).

I'm almost 100% certain that I formatted the disk ext3; however, it could be the case that I just left the disk FAT/NTFS-formatted and used it as-is. It's been several years ago since I set the disk up. I also tried:

e2fsck -nv maxtor.img

to see the extra locations for the superblocks. This information then could be fed back into e2fsck as an alternative superblock to get it to repair the disk (with the -b option). Unfortunately, this didn't work either.

Do you have any ideas as to what I could do to get most of the files with the directory structure back? Or is it all gone? If you need any more info from me, please don't hesitate to ask.

Note that the image used to copy to create the USB boot disk was this file:

ftp://ftp.rrzn.uni-hannover.de/pub/mirror/linux/scientific/58/x86_64/images/diskboot.img

Many thanks in advance for your help! Kind regards, Paul

Hello Paul, I think you are right, 14MB of data could not really damage too many files on a large disk. However, if the filesystem structure were damaged in a way that nodes close to the root node have been overwritten, and you were using a btree+ filesystem, it may be difficult to find the directories and their contents again. Listing 1 shows your TestDisk output ("Deeper search").

Because only NTFS and ext* are likely candidates in this case, you can start a hex editor and have a quick look on the data, starting at about the place where the 14MB of overwritten data ends. Ctrl+G and entering the address in hexadecimal gets you there.

An NTFS filesystem looks similar to Figure 1. Note that there are indicators like FILE0 found in the file node headers. Also file names (as opposed to file contents) are written in 16-bit characters (i.e., every second byte of an ASCII file name is a zero byte), and the presence of a file called $MFT is also a hint that NTFS metadata is present. You may want to search the ASCII part of HexEdit (Ctrl+S) for these indicators.

Figure 1: An NTFS filesystem.

If you see "normal" text and a lot of binary data, you are already in the data section of a file, which will then look the same on ext3 and NTFS.

Figure 2 shows an ext3 filesystem. File names are written as ISO Latin-1 or UTF-8 strings, and there should always be a lost+found directory present, which you can search for.

Figure 2: An ext3 filesystem.

Once you have identified the most likely kind of filesystem in use, you can try to recover by undeleting the corresponding partition in TestDisk and then retry the file browser/recovery by pressing P.

Using e2fsck with a backup superblock will probably not be very helpful, because the superblock does not contain all the information needed to reconstruct the filesystem tree, which was cut off in the first 14MB. Filesystems with "file allocation table style" often store their first directory indexes in the very first blocks of the partition, which is of course a problem in this case, because these were overwritten. TestDisk may pick up parts of the tree at a later block, once it knows the partition's limits.

The following recipe assumes you found an ext2 filesystem, but it should work the same way for the NTFS tools (ntfsck, ntfs-3g, …)

If you are very lucky and the filesystem was quite large, the overwritten part may lie in a section that wasn't used yet, so e2fsck -b and mounting may work if you add an offset to the commands indicating the filesystem's position inside the image. In the case of a Linux-type partition, your TestDisk output said that the start of the partition is at C/H/S 0/1/1, which indicates that the actual partition data starts at byte 512 × 63 = 32,256, so you need to add an offset of 32,256 bytes to e2fsck or mount when working with the image.

Try this command with mount (possibly after a repair attempt):

sudo mount -o ro,offset=32256,loop maxtor.img /mnt

Unfortunately, e2fsck does not have an "offset" parameter, so you need to use a free block loopback device to let e2fsck start from the beginning of the partition (rather than from the beginning of the disk), repair the filesystem, or attempt another mount:

sudo losetup -o 32256 /dev/loop1 maxtor.img
sudo e2fsck -nv /dev/loop1
sudo e2fsck -b 32768 /dev/loop1
sudo mount -o ro /dev/loop1 /mnt
...

Instead of the 32256 offset, which would count from disk track 1 instead of 0, you could also try 512, which would just skip the MBR and assume the first partition starts right after this.

If you still can't get your data back, PhotoRec may still be able to recover some of the files – unfortunately, without the matching file names.