update: extundelete works well on ext3 but not on ext4.


WHILE STILL POWERED ON IMMEDIATELY backup the ext4 journal to file on usb stick:

debugfs -R "dump <8> /mount/usb-stick/sda.journal" /dev/sda

(assuming sda is the drive where the deletion happened)

then “hard reset” unplug the system.

then checkout this guide

and the Debian packages: ext4magic

tools to try: http://trinityhome.org/Home/index.php?wpid=61&front_id=12

ext3undelete ext4undelete extundelete linux undelete recover deleted files – extundelete Bad magic number in super-block when trying to open filesystem – DO NOT ATTACH EXTERNAL USB-SATA HARDDISK DIRECTLY TO SATA

get an overview:

what harddisk/partition is what?

# more detailed

NAME                   MAJ:MIN RM   SIZE RO FSTYPE      MOUNTPOINT                       UUID
sda                      8:0    0 465.8G  0                                              
├─sda1                   8:1    0   243M  0 ext2        /boot                            423f9db5-5ca6-4c20-8343-abb46ea59343
├─sda2                   8:2    0     1K  0                                              
└─sda5                   8:5    0 465.5G  0 crypto_LUKS                                  694a3c8c-ec09-40a9-a78d-fe9ccf73491f
  └─sda5_crypt         254:0    0 465.5G  0 LVM2_member                                  JURsVK-XzG0-RP6e-x0R0-z8Q5-3uXb-tcjxn7
    ├─giada--vg-root   254:1    0    28G  0 ext4        /                                73d90e72-9a4f-4b5b-b44b-95dc3a8f4a53
    ├─giada--vg-swap_1 254:2    0   7.9G  0 swap        [SWAP]                           0c15e2b2-4ffd-4d02-9da4-5a3cf7f87b6f
    └─giada--vg-home   254:3    0 429.6G  0 ext4        /home                            26d6d09a-7dca-4404-8ec0-2b791f673447
sdc                      8:32   0 232.9G  0                                              
└─sdc1                   8:33   0 232.9G  0 ntfs        /media/user/722CC7CA2CC78815 722CC7CA2CC78815

# is harddisk full?/usage of filesystem
df -h
Filesystem                  Size  Used Avail Use% Mounted on
udev                        3.9G     0  3.9G   0% /dev
tmpfs                       788M  9.2M  779M   2% /run
/dev/mapper/giada--vg-root   28G  7.5G   19G  29% /
tmpfs                       3.9G  182M  3.7G   5% /dev/shm
tmpfs                       5.0M  4.0K  5.0M   1% /run/lock
tmpfs                       3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda1                   236M  106M  119M  48% /boot
/dev/mapper/giada--vg-home  422G  299G  102G  75% /home
tmpfs                       788M   72K  788M   1% /run/user/1000
/dev/sdc1                   233G   94M  233G   1% /media/user/722CC7CA2CC78815

recover lost partitions / partition table:


debian package testdisk includes photorec

give testdisk a shot with it’s deep search feature:


su - root; # become root
apt update;
apt install testdisk;

TestDisk checks the partition and boot sectors of your disks. It is very useful in forensics, recovering lost partitions. It works with :

 * DOS/Windows FAT12, FAT16 and FAT32
 * NTFS ( Windows NT/2K/XP )
 * Linux Ext2 and Ext3
 * BeFS ( BeOS )
 * BSD disklabel ( FreeBSD/OpenBSD/NetBSD )
 * CramFS (Compressed File System)
 * HFS and HFS+, Hierarchical File System
 * JFS, IBM's Journaled File System
 * Linux Raid
 * Linux Swap (versions 1 and 2)
 * LVM and LVM2, Linux Logical Volume Manager
 * Netware NSS
 * ReiserFS 3.5 and 3.6
 * Sun Solaris i386 disklabel
 * UFS and UFS2 (Sun/BSD/...)
 * XFS, SGI's Journaled File System

src: https://packages.debian.org/sid/admin/testdisk

note: processing of USB connected large harddisks x>2TB will take DAYS!

when done the user is left with millions of files and folders: a script that at least helps a bit with the sorting

cat /scripts/sort_photorec_pictures.sh


# settings

echo "=== sort out pictures after photorec restore ==="
echo "this script is intended to help with the sorting, after a photorec restore"
echo "photorec can not restore filenames but content"
echo "so it is up to the user to sort, which file has valuable content and which not"
echo "what this script does is create subfolders for jpg bmp tiff png mp4 avi doc docx xls xlsx of filesize > $MINIMUM_FILESIZE"
echo "then go through all files photorec restored and find then move according to fileending in those subfolders"

mkdir $SORT_TO/jpg
mkdir $SORT_TO/bmp
mkdir $SORT_TO/tiff
mkdir $SORT_TO/png
mkdir $SORT_TO/mp4
mkdir $SORT_TO/avi

find $PHOTOREC_FOLDER -type f -size $MINIMUM_FILESIZE -iname *.jpg -exec mv -v {} $SORT_TO/jpg/ \;
find $PHOTOREC_FOLDER -type f -size $MINIMUM_FILESIZE -iname *.bmp -exec mv -v {} $SORT_TO/bmp/ \;
find $PHOTOREC_FOLDER -type f -size $MINIMUM_FILESIZE -iname *.tiff -exec mv -v {} $SORT_TO/tiff/ \;
find $PHOTOREC_FOLDER -type f -size $MINIMUM_FILESIZE -iname *.png -exec mv -v {} $SORT_TO/png/ \;
find $PHOTOREC_FOLDER -type f -size $MINIMUM_FILESIZE -iname *.mp4 -exec mv -v {} $SORT_TO/mp4/ \;
find $PHOTOREC_FOLDER -type f -size $MINIMUM_FILESIZE -iname *.avi -exec mv -v {} $SORT_TO/avi/ \;

# if those are needed just uncomment
# mkdir $SORT_TO/doc
# mkdir $SORT_TO/docx
# mkdir $SORT_TO/xls
# mkdir $SORT_TO/xlsx
# mkdir $SORT_TO/txt

# find . -type f -size $MINIMUM_FILESIZE -iname *.doc -exec mv -v {} $SORT_TO/doc/ \;
# find . -type f -size $MINIMUM_FILESIZE -iname *.docx -exec mv -v {} $SORT_TO/docx/ \;
# find . -type f -size $MINIMUM_FILESIZE -iname *.xls -exec mv -v {} $SORT_TO/xls/ \;
# find . -type f -size $MINIMUM_FILESIZE -iname *.xlsx -exec mv -v {} $SORT_TO/xlsx/ \;
# find . -type f -size $MINIMUM_FILESIZE -iname *.txt -exec mv -v {} $SORT_TO/txt/ \;

gparted -> gpart

you can give it a shot – you will need to install gparted and gpart

gpart is a tool used by gparted to rescue partitions.

howto: https://ubuntuforums.org/showthread.php?t=370121

gpart /dev/hda

here is the manpage: gpart.man.txt
“gpart – guess PC-type hard disk partitions”

DESCRIPTION: gpart tries to guess which partitions are on a hard disk.

If the primary partition table has been lost, overwritten or destroyed the partitions still exist on the disk but the operating system cannot access them.

gpart ignores the primary partition table and scans the disk (or disk image, file) sector after sector for several filesystem/partition types.

It does so by “asking” filesystem recognition modules if they think a given sequence of sectors resembles the beginning of a filesystem or partition type.

Currently the following filesystem types are known to gpart (listed by module names):

beos BeOS filesystem type.

bsddl FreeBSD/NetBSD/386BSD disklabel sub-partitioning scheme used on
Intel platforms.

ext2 Linux second extended filesystem.

fat MS-DOS FAT12/16/32 “filesystems”.

hpfs IBM OS/2 High Performance filesystem.

hmlvm Linux LVM physical volumes (LVM by Heinz Mauelshagen).

lswap Linux swap partitions (versions 0 and 1).

minix The Minix operating system filesystem type.

ntfs MS Windows NT/2000 filesystem.

qnx4 QNX 4.x filesystem.

The Reiser filesystem (version 3.5.X, X > 11, 3.6.X).

s86dl Sun Solaris on Intel platforms uses a sub-partitioning scheme on
PC hard disks similar to the BSD disklabels.

xfs Silicon Graphic’s journalling filesystem for Linux.

More filesystem guessing modules can be added at runtime (see the -t
option). Please consult the gpart README file for detailed explanations
on how to create guessing modules. All modules are accompanied by a
guessing weight factor which denotes how “educated” their guesses are
compared to other modules. This weight can be changed if a certain mod‐
ule keeps on mis-identifying a partition.

Naturally only partitions which have been formatted in some way can be
recognized. If the type of a partition entry in the primary partition
table is changed from x to y while the filesystem is still of type x,
gpart will also still guess a type x.

No checks are performed whether a found filesystem is clean or even
consistent/mountable, so it is quite possible that gpart may identify
partitions which existed prior to the current partitioning scheme of
the disk. Especially on large disks old file system headers/superblocks
may be present a long time until they are finally overwritten with user

It should be stressed that gpart does a very heuristic job, never
believe its output without any plausability checks. It can be easily
right in its guesswork but it can also be terribly wrong. You have been

After having found a list of possible partition types, the list is
checked for consistency. For example, a partition which overlaps with
the previous one will be discarded. All remaining partitions are
labelled with one of the following attributes: “primary”, “logical”,
“orphaned” or “invalid”.

A partition labelled “orphaned” is a logical partition which seems ok
but is missed in the chain of logical partitions. This may occur if a
logical partition is deleted from the extended partition table without
overwriting the actual disk space.

An “invalid” partition is one that cannot be accepted because of vari‐
ous reasons. If a consistent primary partition table was created in
this process it is printed and can be written to a file or device.

recover files / lost deleted files folders:


is specialized on recovery of certain file formats most famously of course “photos” = pictures = jpg files

the great feature of photorec will store the status of the recovery in a file called “photorec.ses”

if the user starts photorec from the directory where photorec.ses is in, it will resume the recovery

in this example the recovery of files Windows-deleted from an NTFS harddisk is tried and it works quiet well, it was possible to restore a lot of pictures and other files

filenames: what photorec is unable to do: restore the proper filename

so without reviewing the file, the user will have no clue what the content of the file might be (even mp3 meta information is lost?)

so restore of content works – restore of filename not – of course it is kind of a pain to go through 24000 pictures and decide which ones are worth keeping, but at least, the user was able to perform the recovery of the content-data – thank you US AirForce.

here is the photorec manpage: photorec.man.txt

it is included in the debian testdisk package


su - root; # become root
apt update;
apt install testdisk;

PhotoRec is file data recovery software designed to recover lost pictures from digital camera memory or even Hard Disks. It has been extended to search also for non audio/video headers. It searches for following files and is able to undelete them:

 * Sun/NeXT audio data (.au)
 * RIFF audio/video (.avi/.wav)
 * BMP bitmap (.bmp)
 * bzip2 compressed data (.bz2)
 * Source code written in C (.c)
 * Canon Raw picture (.crw)
 * Canon catalog (.ctg)
 * FAT subdirectory
 * Microsoft Office Document (.doc)
 * Nikon dsc (.dsc)
 * HTML page (.html)
 * JPEG picture (.jpg)
 * MOV video (.mov)
 * MP3 audio (MPEG ADTS, layer III, v1) (.mp3)
 * Moving Picture Experts Group video (.mpg)
 * Minolta Raw picture (.mrw)
 * Olympus Raw Format picture (.orf)
 * Portable Document Format (.pdf)
 * Perl script (.pl)
 * Portable Network Graphics (.png)
 * Raw Fujifilm picture (.raf)
 * Contax picture (.raw)
 * Rollei picture (.rdc)
 * Rich Text Format (.rtf)
 * Shell script (.sh)
 * Tar archive (.tar )
 * Tag Image File Format (.tiff)
 * Microsoft ASF (.wma)
 * Sigma/Foveon X3 raw picture (.x3f)
 * zip archive (.zip)

src: https://packages.debian.org/sid/admin/testdisk


“Foremost is a console program to recover files based on their headers, footers, and internal data structures.

This process is commonly referred to as data carving.

Foremost can work on (disk.img or disk.iso) image files, such as those generated by dd, Safeback, Encase, etc, or directly on a drive.

The headers and footers can be specified by a configuration file or you can use command line switches to specify built-in file types.

These built-in types look at the data structures of a given file format allowing for a more reliable and faster recovery.” (src)

tried: foremost http://foremost.sourceforge.net/

which seems to work better with ext4 and large volumes, BUT it seems it (just as photorec) also is unable to 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)


wget http://ftp.tu-chemnitz.de/pub/linux/dag/redhat/el7/en/x86_64/rpmforge/RPMS/foremost-1.5.7-1.el7.rf.x86_64.rpm

sha512sum foremost-1.5.7-1.el7.rf.x86_64.rpm
71f9b2b2e6f6443006e937637cd18ecde8e1f07c2df8dfbb4de97d397f7c6176a74a4bd06e9c31cb61e9dc4333af74ee6b1477f3f9e6a0594b45bc2967b89dd7 foremost-1.5.7-1.el7.rf.x86_64.rpm

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.



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

extundelete: binaries for download:

32Bit knoppix version(?): (i hope it works for you)

sha512: 87fe3543d337d7db07891e28149ca303a9cf6143c93a9d20bbac602d46e3286ac7a36880735ab341a60870960a98e4dd8e397c47406a80b722d92416df1ccde1

64Bit: rpm centos / redhat / fedora



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


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
sdb5  ext4   ext4  e8926fbe-b937-4576-b5b8-70a115fce795
sdb6  ext3   ext3  5f06baec-02be-4ed8-8e85-a7eb7fc87b6e

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 https://dwaves.de/wp-content/uploads/2017/06/Richard-Stallman.jpg;
wget -P /mnt/ext3 https://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!)
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: =========
======= 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

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?




liked this article?

  • only together we can create a truly free world
  • plz support dwaves to keep it up & running!
  • (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
  • really really hate advertisement
  • contribute: whenever a solution was found, blog about it for others to find!
  • talk about, recommend & link to this blog and articles
  • thanks to all who contribute!