Klaus Knopper answers your Linux questions
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").
Listing 1
Output of TestDisk
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.
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.
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.
« Previous 1 2
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
The GNU Project Celebrates Its 40th Birthday
September 27 marks the 40th anniversary of the GNU Project, and it was celebrated with a hacker meeting in Biel/Bienne, Switzerland.
-
Linux Kernel Reducing Long-Term Support
LTS support for the Linux kernel is about to undergo some serious changes that will have a considerable impact on the future.
-
Fedora 39 Beta Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.
-
UbuntuDDE 23.04 Now Available
A new version of the UbuntuDDE remix has finally arrived with all the updates from the Deepin desktop and everything that comes with the Ubuntu 23.04 base.