Q0: Someone accidentally deleted files on an ext3 partition?

Yes -> Q2: You have a working backup of some sort?

No -> POWEROFF your PC / Laptop / Server IMMEDIATELY or remount the affected partition read only and get access to the extundelete binaries WIHTOUT writing to the affected partition.

E.g. boot some sort of rescue/Live-CD-USB-Stick system such as KNOPPIX.

find –delete is a great way to kill a lot of important files.

If your backup is not working and you are NOT using ext3. You are 99% screwed.

If you are using ext3 and your backup wasn’t working as the mistake happened – you are only 1-10% screwed.

Because usually extundelete can recover most if not ALL of the deleted files from an ext3  partition PLUS 90% of the filenames and directories they used to be in. (when i think about getdatabackntfs… you get a lot of files… but no filenames and no directories… which SUCKS MASSIVELY… you will have to analyize each and every file BY HAND in order to find out is it a *.jpg is it a *.pdf or what is it?)

In my case – extundelete put all the files that it could not determine in which directory they used to be in – in lost+found folder… but with the correct filenames at least.

So yes – there is still some manual work to do after recovering from a find –delete disaster 😀

It takes time – but it can be done.

It took me about 3 days 😀 and there are still some files of this blog missing… so i would say a week.

As we all know… if you accidentally deleted a file… you better have a working backup of some sort.

If not: turn off PC IMMEDIATELY and boot from Live-CD-USB-Stick such as KNOPPIX.

UNMOUNT / UNPLUG HARDDISK / PARTITION IMMEDIATELY 😀 and boot from knoppix live-CD

extundelete.man.txt

let us take a picture of Mr Stallmann for a test delete and restore drive.

binaries for download:

32Bit knoppix version(?): (i hope it works for you)
http://dwaves.de/software/recovery/extundelete.tar.gz

sha512: 87fe3543d337d7db07891e28149ca303a9cf6143c93a9d20bbac602d46e3286ac7a36880735ab341a60870960a98e4dd8e397c47406a80b722d92416df1ccde1

64Bit:

extundelete -v
extundelete version 0.2.4
libext2fs version 1.43.4
Processor is little endian.

extundelete_64Bit_debian9.tar.gz

sha512: 2e424c5c70107c3e36a4d3453c0deb5ef643b9f453e22ad8987152c637e4eca383de62e59c6debd434ca3dc7f817728840bc0b4e1cb8c81167569b68919fda42

i want to demonstrate that extundelete actually works well with ext3 but miserable with ext4:

hostnamectl; # testing was done with
   Static hostname: debian9
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 532eabca552b4075a8679094397c8dba
           Boot ID: c51ea5627e7a4e9dae150aaeea9e29a2
    Virtualization: microsoft
  Operating System: Debian GNU/Linux 9 (stretch)
            Kernel: Linux 4.12.0cuztom
      Architecture: x86-64

apt-get install extundelete;

lsblk -fs; # as you can see there are thwo partitions sdb5 with ext4 and sdb6 with ext3
NAME  FSTYPE LABEL UUID                                 MOUNTPOINT
sdb3
└─sdb
sdb5  ext4   ext4  e8926fbe-b937-4576-b5b8-70a115fce795
└─sdb
sdb6  ext3   ext3  5f06baec-02be-4ed8-8e85-a7eb7fc87b6e
└─sdb

mkdir /mnt/ext4;
mkdir /mnt/ext3;

mount /dev/sdb5 /mnt/ext4;
mount /dev/sdb6 /mnt/ext3;

# let's create some sample content
echo "this is a very important file with important content of which no backup exists" > /mnt/ext3/very_important_file.txt

echo "this is a very important file with important content of which no backup exists" > /mnt/ext4/very_important_file.txt

wget -P /mnt/ext4 http://dwaves.de/wp-content/uploads/2017/06/Richard-Stallman.jpg;
wget -P /mnt/ext3 http://dwaves.de/wp-content/uploads/2017/06/Richard-Stallman.jpg;

# checksum those files
md5sum /mnt/ext4/*
d41d8cd98f00b204e9800998ecf8427e  /mnt/ext4/fschk
md5sum: /mnt/ext4/lost+found: Is a directory
fab9d3e592942c468365a97c6e620f35  /mnt/ext4/Richard-Stallman.jpg
ecb25c87f02bb0874246a166432bd3c4  /mnt/ext4/very_important_file.txt

md5sum /mnt/ext3/*
fab9d3e592942c468365a97c6e620f35  /mnt/ext3/Richard-Stallman.jpg
ecb25c87f02bb0874246a166432bd3c4  /mnt/ext3/very_important_file.txt

# now delete
rm -rf /mnt/ext3/*
rm -rf /mnt/ext4/*

# now unmount
umount /mnt/ext3 /mnt/ext4

# create directory where to restore the files
mkdir /mnt/restored/;
cd /mnt/restored/;

# let's start with ext4 partition
extundelete --restore-all /dev/sdb5
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... 80 groups loaded.
Loading journal descriptors ... 26 descriptors loaded.
Searching for recoverable inodes in directory / ...
0 recoverable inodes found.
Looking through the directory structure for deleted files ...
0 recoverable inodes still lost.
No files were undeleted.

# let's give ext3 a try
extundelete --restore-all /dev/sdb6
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ... 80 groups loaded.
Loading journal descriptors ... 40 descriptors loaded.
Searching for recoverable inodes in directory / ...
3 recoverable inodes found.
Looking through the directory structure for deleted files ...
0 recoverable inodes still lost.

root@debian9:/mnt/restored# ll RECOVERED_FILES/
total 68K
drwxr-xr-x 2 root root 4.0K Jul  6 15:41 .
drwxr-xr-x 3 root root 4.0K Jul  6 15:26 ..
-rw-r--r-- 1 root root   45 Jul  6 15:41 important.txt
-rw-r--r-- 1 root root  50K Jul  6 15:41 Richard-Stallman.jpg
-rw-r--r-- 1 root root   79 Jul  6 15:41 very_important_file.txt

 md5sum ./RECOVERED_FILES/*
244b5d8e29526a0f9cff08174ac4433b  ./RECOVERED_FILES/important.txt
fab9d3e592942c468365a97c6e620f35  ./RECOVERED_FILES/Richard-Stallman.jpg
ecb25c87f02bb0874246a166432bd3c4  ./RECOVERED_FILES/very_important_file.txt

this alone let’s me say – STAY AWAY FROM EXT4! 😀

what is all the speed in the world… if you can not recover your lost files?

admin