update: extundelete works well on ext3 but kind of failed me on ext4.
get an overview:
what harddisk/partition is what?
lsblk; # more detailed lsblk -o "NAME,MAJ:MIN,RM,SIZE,RO,FSTYPE,MOUNTPOINT,UUID" alias harddisk='lsblk -o "NAME,MAJ:MIN,RM,SIZE,RO,FSTYPE,MOUNTPOINT,UUID"' harddisk 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:
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
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.
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
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)
“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)
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.
extundelete: 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 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!) 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?