Last time, we have seen how to rescue a partition. Let's go further and make an other mistake...

Crash your partition's FAT

The FAT (file allocation table) is a map : it tells the OS where all the files of your partition are. Thus, there is one FAT by partition, and the FAT is depending of the filesystem of your partition. It's the same analogy as the partition table : if you loose this map, the cities are still there but you don't know where.

There is several ways of crashing a file allocation table. Bad use of dd is one of them, and probably the most common, playing with Partition Magic is an other. But once again I'll give you the one I used. You are rescuing /dev/sdb. To do that, you bought an other hard disk. This hard disk is seen by the OS as /dev/sdc (you see my point ? ). You plan to play with LVM with this new hard disk.

Full of confidence, and at an advanced night time, you think "pvcreate /dev/sdc2" and you type : [root@home]# pvcreate /dev/sdb2 Just when pressing Enter, you realize that you should have slept before doing hard disk rescue, but it's too late : something wrong has been done.

You try to mount(8) /dev/sdb2, and you get that message : mount: unknown filesystem type 'LVM2_member'

Well, bad news : you are in trouble.

At this point, you know that your FAT has been altered, and just it, because the OS can see the partition, but can't read the files in it. It is the same under Windows (although I don't know how to only crash a partition table under Windows :) ) : if you can see the partitions but Windows says that it is not formatted, your are almost sure that your FAT is gone.

Maybe you noticed that pvcreate didn't take so much time that it destroyed all the datas (i.e. : all the allocated inodes/sectors of the partition). I mean : the guess is that only the file allocation table has been destroyed, not the allocated blocks (remember : you loose the map but the cities are still there)

If this supposition is true (spoiler : it is), there are two good news :

Good news #1 : it's possible to rescue your datas.

Good news #2 : there is (at least) two possibilities.

Rescue your files

The first possibility that comes into mind is photorec(1). Photorec comes with testdisk. Its purpose is to find deleted files by searching beyond the filesystem. I.e. : it can find deleted files even if your partitions and/or file allocation table is destroyed.

In other words :

• If your partition is deleted, photorec can help you rescuing your files (not the partition table)
• If your file allocation table is destroyed, photorec can help you in the same way (i.e.: rescuing the files, not the file allocation table)
• If you want to rescue a deleted file, photorec can help you again

photorec

Go on with photorec, which is the 'canonical' way of rescuing files.

[root@home]# photorec /dev/sdb2 Select a media (use Arrow keys, then press Enter): Disk /dev/sdb2 - 98 MB / 94 MiB (RO) - VBOX HARDDISK [Proceed ]  [  Quit  ] Press 'Proceed' Please select the partition table type, press Enter when done. [Intel  ]  Intel/PC partition [EFI GPT]  EFI GPT partition map (Mac i386, some x86_64...) [Mac    ]  Apple partition map [None   ]  Non partitioned media [Sun    ]  Sun Solaris partition [XBox   ]  XBox partition [Return ]  Return to disk selection You are rescuing a partition, not a whole hard disk. So validate on 'None' Partition                  Start        End    Size in sectors Unknown                  0   0  1    11 253 63     192717 [Whole disk] P Linux LVM2               0   0  1    11 253 63     192717 [ Search ]  [Options ]  [File Opt]  [  Quit  ] Validate on 'Linux LVM2'

P Linux LVM2               0   0  1    11 253 63     192717 To recover lost files, PhotoRec need to know the filesystem type where the file were stored: [ ext2/ext3 ]  ext2/ext3/ext4 filesystem [ Other     ]  FAT/NTFS/HFS+/ReiserFS/...

Make the good choice. For my case it was 'Other' (ntfs) Do you want to save recovered files in /root ? [Y/N] Do not choose to write the files to the same partition they were stored on. To select another directory, use the arrow keys. drwxr-xr-x     0     0      4096  7-Jul-2010 17:30 . drwxr-xr-x     0     0      4096  3-Mar-2010 17:01 .. drwxr-xr-x     0     0      4096 25-Sep-2009 15:50 Desktop drwxr-xr-x     0     0      4096 25-Sep-2009 15:50 Documents drwx------     0     0      4096 20-Apr-2010 16:05 Mail drwxr-xr-x     0     0      4096 25-Sep-2009 15:50 Music drwxr-xr-x     0     0      4096 25-Sep-2009 15:50 Pictures drwxr-xr-x     0     0      4096 25-Sep-2009 15:50 Public drwxr-xr-x     0     0      4096 25-Sep-2009 15:50 Templates drwxr-xr-x     0     0      4096 25-Sep-2009 15:50 Videos Here, select a directory to restore your files to. Photorec will create a directory named 'recup_dir.1' within the one you chose. Please do not select the directory where the partition your are rescuing is mounted (if so) or you'll probably lose all the datas you are trying to rescue. Once you have chosen the directory, press 'Y'.

Disk /dev/sdb1 - 98 MB / 94 MiB (RO) - VBOX HARDDISK Partition                  Start        End    Size in sectors P Linux LVM2               0   0  1    11 253 63     192717 1 files saved in /root/recup_dir directory. Recovery completed. txt: 1 recovered

After a (eventually awfully long) time, your files will be in (maybe a bunch of) 'recup_dir.*'. Press 'q' as often as necessary to quit photorec.

Let's see what has been done :

[root@home]# ls recup_dir.1 f0012290.f

Oumpf... the file is ill named (photorec can't guess what was the name of the file, as the partition table was probably destroyed), but it is there. If you have only a few files, it's ok, but if you have plenty, you are done for a Sherlock Homes' work...

This is an understandable limitation of photorec. As I'm lazy, I tried to find an other way of rescuing my files, a way that restores the file allocation table.

Other way

It's a bit tricky, so please put yourself in a quiet and gentle place.

First, I looked at pvcreate's man page. I saw this : -Z, --zero y|n Whether  or  not  the  first  4 sectors (2048 bytes) of the device should be wiped.  If this option is not given, the default is to wipe these sectors unless either or both of the --restorefile or --uuid options were specified.

This means that only the first 2k of /dev/sdb2 are modified by pvcreate (and this means the assertion that pvcreate didn't take so long that it wiped all the data is true). And this means that, maybe, the file allocation table of the partition has not been touched. So maybe it's possible to rescue your datas by only restoring the fist 2k of the partition. It's worth a try and, spoiler again, it works.

How to recreate those 2k ? By taking them from an other partition of the same type.

But, bad news, it's not so easy as it seems : if you wan to succeed, you have to take care of the filesystem you are playing with.

In other words : with ext2 you can fetch those 2k in a particular way, and this particular way doesn't work with ntfs...

I'll explain both : the way that work with ext2, and the way that work with ntfs.

Your filesystem is ext2 (or ext3, ext4, xfs)

Easy easy easy :

• You will create a file which will contain a partition of the given type
• And copy the first 2k of this file to the sick partition.

If you have enough free space, it's highly advisable to make a copy of your sick partition with 'dd if=/dev/sdb1 of=/some/where' and play with the copy. In that case do not forget to append 'conv=notrunc' to all the dd commands, or you'll lose time, and maybe data.

And if you still have free space, you should create a file of the same size of the sick partition. For fun, let's consider you don't enough space to create a file of the sick partition's size. So you'll create a file of 10MB

[root@home]# dd if=/dev/zero of=/tmp/rescue bs=1k count=10k 10240+0 records in 10240+0 records out 10485760 bytes (10 MB) copied, 0.0297014 s, 353 MB/s [root@home]# mke2fs /tmp/rescue mke2fs 1.41.11 (14-Mar-2010) /tmp/rescue is not a block special device. Proceed anyway? (y,n)

Say yes.

[root@home]# dd if=/tmp/rescue of=/dev/sdb1 bs=512 count=4 4+0 records in 4+0 records out 2048 bytes (2.0 kB) copied, 0.00195328 s, 1.0 MB/s

At this point, you can now mount /dev/sdb1 and you'll see you files, yeah :) Try to copy them in a safe place before continuing.

If you type 'df', you'll maybe see weird things :

Filesystem           1K-blocks      Used Available Use% Mounted on /dev/sdb1                 9911     -5437     14836   -  /mnt/sdb

It's because you have take the 2k from a filesystem with a different size, thus mke2fs has made different choices concerning the parameter with whom /dev/sdb1 and /tmp/rescue were made.

fsck -y will help us :

[root@home]# umount /dev/sdb1 ; e2fsck -y /dev/sdb1 e2fsck 1.41.11 (14-Mar-2010) /dev/sdb1 contains a file system with errors, check forced. Resize inode not valid.  Recreate? yes Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences:  -(42--202) -(204--258) -(421--511) -525 -(8234--8450) -(8613--8703) Fix? yes Free blocks count wrong for group #0 (7161, counted=7470). Fix? yes Free blocks count wrong for group #1 (7681, counted=1844). Fix? yes Free blocks count wrong (14842, counted=9314). Fix? yes Free inodes count wrong for group #0 (1896, counted=1168). Fix? yes Free inodes count wrong for group #1 (2008, counted=1280). Fix? yes Free inodes count wrong (3904, counted=2448). Fix? yes /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdb1: 112/2560 files (0.9% non-contiguous), 926/10240 blocks

If your filesystem is xfs, the command is not 'fsck -y' but 'xfs_repair-o force_geometry'

Your filesystem is ntfs

It's more difficult : ntfs behaves bad when mixing files seen as filesystem and filesystem on hard disk. I mean that you can test with 2 files : one that you crash with pvcreate, and the other one used to fix the first, and it will works. But you can't (at least, I didn't succeed) rescue a physical ntfs FAT with a file, as done with ext2.

So, your only hope, Obiwan, is to :

• Save your partition in a file. It is not an option !
• Make a ntfs filesystem on the partition,

From here, you can either :

• Put the first 2k of that partition in a safe place,
• Put your saved partition in its original place,
• Put the first 2k you have saved at the beginning of the partition.

Or :

• Reput your partition to its original place skipping the first 2k, leaving untouched the brand new first 2k of the hard disk.

As the second method is more elegant, I'll describe it :

Here, /dev/sdb2 contain a ntfs partition salvaged with pvcreate. [root@home]# cat /dev/sdb2 > /safe/place/sdb2.sick [root@home]# mkfs.ntfs /dev/sdb2 #if your partition is huge : mkfs.ntfs -f /dev/sdb2 [root@home]# dd if=/safe/place/sdb2.sick bs=512 seek=4 skip=4

Please note the two options of 'dd' : seek and skip. They tell dd to skip the first 4 (512b) blocks of the originating file, and to seek 4 (512b) blocks after the beginning of the destination file.

You can now mount your partition.

Et voilà :)

If I summarize : when you crash your file allocation table, photorec will help you find your lost files. It's the common way of doing it, but photorec can't guess the name of your lost files.

If you crash the file allocation table with a tool such as pvcreate, which erases the first 2k of a partition, you can recover your files by rebuilding those 2k, either by making an other filesystem aside, or by recreating the partition in place, it depends of the filesystem.

Conclusion

Crashing a FAT should not happen too often. Anyway, photorec can help you in much more occasions than a FAT crash : accidentally erasing data, partition corruption, ...

But photorec is slow. In some cases, you'd better use your brain and read man page to save time :)