update: extundelete works well on ext3 but kind of failed me on ext4.

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

get an overview:

what harddisk is what?

lsblk 
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sdd      8:48   0   3.7T  0 disk 
sdb      8:16   0   3.7T  0 disk 
└─sdb1   8:17   0   3.7T  0 part /run/media/user/MOVIES3
sdc      8:32   0 931.5G  0 disk 
└─sdc1   8:33   0 931.5G  0 part /run/media/user/SOFTWARE
sda      8:0    0 238.5G  0 disk 
├─sda4   8:4    0     1K  0 part 
├─sda2   8:2    0   100G  0 part /home
├─sda5   8:5    0   7.8G  0 part [SWAP]
├─sda3   8:3    0    50G  0 part /
├─sda1   8:1    0     1G  0 part /boot
└─sda6   8:6    0  79.7G  0 part /run/media/user/projects

lost partition table:

testdisk

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

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.

reiserfs
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
data.

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
warned.

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:

photorec

can only recover photos / picutre / jpg files, not word.doc.

foremost

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)

https://centos.pkgs.org/7/repoforge-x86_64/foremost-1.5.7-1.el7.rf.x86_64.rpm.html

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.

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.

extundelete: binaries for download:

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

sha512: 87fe3543d337d7db07891e28149ca303a9cf6143c93a9d20bbac602d46e3286ac7a36880735ab341a60870960a98e4dd8e397c47406a80b722d92416df1ccde1

64Bit: rpm centos / redhat / fedora

http://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/extundelete-0.2.4-6.el7.x86_64.rpm

https://centos.pkgs.org/7/epel-x86_64/extundelete-0.2.4-6.el7.x86_64.rpm.html

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

links:

https://wiki.archlinux.org/index.php/Foremost

http://extundelete.sourceforge.net/

admin