Linux File Recovery from rm -rf

2017/02/08

I managed to do a "rm -rf *" in a home directory of my slackware virtual machine. Ouch!!

I did not have a lot on the machine but there was a couple scripts and Minimal Linux notes I would like to have.

So, the adventure begins on the road file recovery......

The quick summary of steps:

Step One -- Convert to Raw Disk Image

To convert the Virtual Box VDI disk into something useable on a linux command line we can use the VBox utilities.

$ VBoxManage clonemedium disk ~/VirtualBox\ VMs/slackware/slackware.vdi \
    --format RAW  disk.img

Step Two -- Check Filesystem

The slackware VM was using a ext4 filesystem so we should be able to mount this raw disk image. The only question is where does the first partition start. The fdisk command is helpful here.

$ fdisk disk.img 
    Command (m for help): p

    Disk disk.img: 21.5 GB, 21474836480 bytes
    213 heads, 34 sectors/track, 5791 cylinders, total 41943040 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x311e4f2a

       Device Boot      Start         End      Blocks   Id  System
    disk.img1            2048    41943039    20970496   83  Linux

    Command (m for help): q

We can see from this the first partition starts 2048 data blocks into the image. That would be 2048 X 512 bytes/block = 1048576 bytes.

$ mkdir mnt
$ sudo mount -t ext4 -o loop -o offset=1048576  disk.img mnt/
..... ls around the mnt directory to make sure you can see a filesystem
$ sudo umount mnt

Step Three -- Recover Files

First we create a directory to recovery file into then check which loop device is available to use. If my case loop0 was the first one available.

$ mkdir slackfiles
$ sudo losetup -f
/dev/loop0

...
Next we connect the disk image to the loop device at the correct offset.

$ sudo losetup -o 1048576 /dev/loop0 disk.img

 ... or as root
# losetup -o 1048576 /dev/loop0 disk.img

...
First thing I did was check if we could read things correctly.

$ sudo extundelete --journal  /dev/loop0
    No action specified; implying --superblock.

    WARNING: Extended attributes are not restored.
    Journal Super Block:
    Signature: 0xc03b3998
    Block type: Superblock version 2
    Sequence Number: 0
    Journal block size: 4096
    Number of journal blocks: 32768
    Journal block where the journal actually starts: 1
    Sequence number of first transaction: 133712
    Journal block of first transaction: 0
    Error number: 0
    Compatible Features: 0
    Incompatible features: 1
    Read only compatible features: 0
    Journal UUID: 0x52ec480cc754495fa767604efa25f1c6
    Number of file systems using journal: 1
    Location of superblock copy: 0
    Max journal blocks per transaction: 0
    Max file system blocks per transaction: 0
    IDs of all file systems using the journal:
    1. 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

...
Wonderful, we can read the disk. Now we can recovery file/directories into the output directory.

...To Restore Files
$ sudo extundelete --restore-file "/home/john/src/sboup/sbcheck" \
    --output-dir slackfiles/  /dev/loop0

....To Restore Directories
$ sudo extundelete --restore-directory "/home/john/src" --output-dir slackfiles/ \
     /dev/loop0

$ sudo extundelete --restore-directory "/home/john/tiny/" --output-dir slackfiles/ \
     /dev/loop0

$ sudo extundelete --restore-directory "/home/john/src/sboup/" \
     --output-dir slackfiles/  /dev/loop0

....To Restore Everything
$ sudo extundelete --restore-all  --output-dir slackfiles/  /dev/loop0

...
The last step is to release the loop device.

 $ sudo losetup -d /dev/loop0

Home