update: extundelete works well on ext3 but kind of failed me on ext4.
so i tried: foremost http://foremost.sourceforge.net/
which seems to work better with ext4 and large volumes, BUT it seems it can NOT recover filenames. (extundelete on ext3 can do that)
Also: IMHO foremost does pretty well on pictures (especially jpg) but it did not find the test.txt file i just deleted!?.
what is GREAT about foremost is, that it does not care about your filesystem. it can even recover Pictures from an NTFS partition! (the less fragmented the files are the better it works)
foremost is what is as known as a data-carving utility.
It operates by examining data, bit by bit, and extracting sets of data that meet a defined pattern.
foremost references its configuration file for a set of file headers, footers and other information that it uses to determine whether a set of data actually is a file or not.
Since foremost just looks at the file data, and not at any table entries, inodes, or anything similar, it can be used on virtually any image, whether it be of a hard drive, swap file, hibernation file, or RAM dump.
It also makes no distinction between existing and deleted files, as long as the deleted files’ headers have not been overwritten.
By default foremost can search for the following file types: jpg, gif, png, bmp, avi, exe, mpg, wav, riff, wmv, mov, pdf, ole, doc, zip, rar, htm, and cpp.
Other file types can be searched for by adding a custom definition to the configuration file.
foremost finds files by examining the image file for file headers.
Most types of files begin and end with a set string of bytes that indicates what type of file it is, and optionally also contain metadata about the file.
For example, .jpg files can contain information in them regarding what type of camera created the image.
foremost only looks at the header and footer;
again, in the case of a .jpg, the header and footer are 0xffd8 and 0xffd9, respectively.
When it finds a header that appears in its list, it searches for a set number of bytes for the footer;
if it does not find the footer after this number of bytes, it stops searching and moves on to the next header.
If it finds a matching footer, it carves out all the data between the header and footer and saves it as a file of the corresponding type.
As a result, foremost can only find contiguous files; therefore, if the image is heavily fragmented, it will not find many files.
The command that will invoke foremost is given below:
foremost -v -i -t a /dev/sda -o /save/recovered/files/here Output directory: /recovered Configuration file: /usr/local/etc/foremost.conf Processing: /dev/md0 |------------------------------------------------------------------ File: /dev/md0 Start: Sun Mar 4 23:02:16 2018 Length: 5 TB (6000790732800 bytes) Num Name (bs=512) Size File Offset Comment *0: 00276992.jpg 49 KB 141819904 ********************************************** # after 3 minutes it found the Stallman.jpg but without it's filename # but the test.txt file did not show up... # you can also use it on disk images/dd-image saved from disk, which is the preferable method for a failing disk: foremost -v -i -t a /media/disk/test_image.dd -o /media/disk/foremost
-v = verbose mode, which means it displays information about its progress to the screen.
All that information can be found in an audit file that foremost creates, so -v can be omitted if the user desires.
The next two flags, -i and -o are the input image file and the output directory, respectively.
As entered above, this command will have foremost extract all file types that it recognizes;
if the user wants to limit the search to a single file type, for example .jpg, adding the -t jpg flag would extract only files of type .jpg but you can also pass -t a (recover all known file types).
If the user has created a custom configuration file with additional file signature definitions, foremost can be directed to use that file with the -c flag followed by the path to the configuration file.
Like nearly all Linux programs, more information about foremost’s syntax and usage can be found by typing man foremost.
Once foremost starts to run, and the -v flag has been added, it will display on the screen each file that it recovers, showing the name it has given it (since this type of analysis has no way of determining the original filename), the size, the file offset, and a comments section, which can display information such as image dimensions. (src)
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
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)
64Bit: rpm centos / redhat / fedora
extundelete version 0.2.4
libext2fs version 1.43.4
Processor is little endian.
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. # i retried this with a ext4 formatted 5TB md0 raid10 device # and it crash flunked # while it worked well with the same 5TB device ext3 formatted # (recovered all deleted files and filenames!) hostnamectl Operating System: CentOS Linux 7 (Core) Kernel: Linux 4.15.7 Architecture: x86-64 mkfs.ext4 -V mke2fs 1.42.9 (28-Dec-2013) Using EXT2FS Library version 1.42.9 extundelete --restore-all /dev/md0 NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 44710 groups loaded. Loading journal descriptors ... 6266 descriptors loaded. *** Error in `extundelete': double free or corruption (!prev): 0x0000000000ae0fa0 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7c619)[0x7fb64b5e5619] extundelete[0x40d5b1] extundelete[0x41040f] extundelete[0x4047de] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fb64b58ac05] extundelete[0x404ca1] ======= Memory map: ======== 00400000-0041d000 r-xp 00000000 08:03 142289 /usr/bin/extundelete 0061c000-0061d000 r--p 0001c000 08:03 142289 /usr/bin/extundelete 0061d000-0061e000 rw-p 0001d000 08:03 142289 /usr/bin/extundelete 0061e000-0061f000 rw-p 00000000 00:00 0 00ad8000-00b71000 rw-p 00000000 00:00 0 [heap] 7fb638000000-7fb638021000 rw-p 00000000 00:00 0 7fb638021000-7fb63c000000 ---p 00000000 00:00 0 7fb63ec15000-7fb64b34d000 rw-p 00000000 00:00 0 7fb64b34d000-7fb64b364000 r-xp 00000000 08:03 3261078 /usr/lib64/libpthread-2.17.so 7fb64b364000-7fb64b563000 ---p 00017000 08:03 3261078 /usr/lib64/libpthread-2.17.so 7fb64b563000-7fb64b564000 r--p 00016000 08:03 3261078 /usr/lib64/libpthread-2.17.so 7fb64b564000-7fb64b565000 rw-p 00017000 08:03 3261078 /usr/lib64/libpthread-2.17.so 7fb64b565000-7fb64b569000 rw-p 00000000 00:00 0 7fb64b569000-7fb64b721000 r-xp 00000000 08:03 3261052 /usr/lib64/libc-2.17.so 7fb64b721000-7fb64b921000 ---p 001b8000 08:03 3261052 /usr/lib64/libc-2.17.so 7fb64b921000-7fb64b925000 r--p 001b8000 08:03 3261052 /usr/lib64/libc-2.17.so 7fb64b925000-7fb64b927000 rw-p 001bc000 08:03 3261052 /usr/lib64/libc-2.17.so 7fb64b927000-7fb64b92c000 rw-p 00000000 00:00 0 7fb64b92c000-7fb64b941000 r-xp 00000000 08:03 3263793 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7fb64b941000-7fb64bb40000 ---p 00015000 08:03 3263793 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7fb64bb40000-7fb64bb41000 r--p 00014000 08:03 3263793 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7fb64bb41000-7fb64bb42000 rw-p 00015000 08:03 3263793 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7fb64bb42000-7fb64bc43000 r-xp 00000000 08:03 3261060 /usr/lib64/libm-2.17.so 7fb64bc43000-7fb64be42000 ---p 00101000 08:03 3261060 /usr/lib64/libm-2.17.so 7fb64be42000-7fb64be43000 r--p 00100000 08:03 3261060 /usr/lib64/libm-2.17.so 7fb64be43000-7fb64be44000 rw-p 00101000 08:03 3261060 /usr/lib64/libm-2.17.so 7fb64be44000-7fb64bf2d000 r-xp 00000000 08:03 3261095 /usr/lib64/libstdc++.so.6.0.19 7fb64bf2d000-7fb64c12d000 ---p 000e9000 08:03 3261095 /usr/lib64/libstdc++.so.6.0.19 7fb64c12d000-7fb64c135000 r--p 000e9000 08:03 3261095 /usr/lib64/libstdc++.so.6.0.19 7fb64c135000-7fb64c137000 rw-p 000f1000 08:03 3261095 /usr/lib64/libstdc++.so.6.0.19 7fb64c137000-7fb64c14c000 rw-p 00000000 00:00 0 7fb64c14c000-7fb64c18e000 r-xp 00000000 08:03 3261585 /usr/lib64/libext2fs.so.2.4 7fb64c18e000-7fb64c38e000 ---p 00042000 08:03 3261585 /usr/lib64/libext2fs.so.2.4 7fb64c38e000-7fb64c38f000 r--p 00042000 08:03 3261585 /usr/lib64/libext2fs.so.2.4 7fb64c38f000-7fb64c391000 rw-p 00043000 08:03 3261585 /usr/lib64/libext2fs.so.2.4 7fb64c391000-7fb64c394000 r-xp 00000000 08:03 3261226 /usr/lib64/libcom_err.so.2.1 7fb64c394000-7fb64c593000 ---p 00003000 08:03 3261226 /usr/lib64/libcom_err.so.2.1 7fb64c593000-7fb64c594000 r--p 00002000 08:03 3261226 /usr/lib64/libcom_err.so.2.1 7fb64c594000-7fb64c595000 rw-p 00003000 08:03 3261226 /usr/lib64/libcom_err.so.2.1 7fb64c595000-7fb64c5b6000 r-xp 00000000 08:03 3261041 /usr/lib64/ld-2.17.so 7fb64c72a000-7fb64c7a2000 rw-p 00000000 00:00 0 7fb64c7b3000-7fb64c7b6000 rw-p 00000000 00:00 0 7fb64c7b6000-7fb64c7b7000 r--p 00021000 08:03 3261041 /usr/lib64/ld-2.17.so 7fb64c7b7000-7fb64c7b8000 rw-p 00022000 08:03 3261041 /usr/lib64/ld-2.17.so 7fb64c7b8000-7fb64c7b9000 rw-p 00000000 00:00 0 7ffc0019f000-7ffc001c0000 rw-p 00000000 00:00 0 [stack] 7ffc001c7000-7ffc001ca000 r--p 00000000 00:00 0 [vvar] 7ffc001ca000-7ffc001cc000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted (core dumped) # 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?