update:
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
and:
scrounge-ntfs/oldstable 0.9-9 amd64
Data recovery program for NTFS filesystems
in one’s example, the server was shutdown immediately, but without taking above backup of the live journal, no magic could restore the data & the filenames (photorec can only do the files without the names (better than nothing, but 10 years of hand sorting will follow X-D)
ext4magic /dev/sda -f name-of-deleted-folder -j /path/to/sda.journal -r -d /recover/to/different/drive/
"/recover/to/different/drive/" accept for recoverdir
Filesystem in use: /dev/sda
Using external Journal at File /path/to/sda.journal
Inode found "name-of-deleted-folder" 202113025
No undeled inode 202113025 in journal found
ext4magic : EXIT_SUCCESS; # <- this can be hardly called a success
this user was luckier “ext4magic saved my life”, this actually, again, makes the case for ext3 or: not zeroing out
Warning!
if the user wants to do it like a forensic pro, always: make a backup of the backup before proceeding
- unmount whatever filesystem has problems
- make a 1:1 bit-wise-copy with dd of it on a harddisk same size or (better) larger
- detach the copy from the computer and put it in a double-metal casing (EMP protection)
- then the user can safely proceed to mess with the filesystem
what the problem could be:
- never rush, when the user is in a rush, errors happen
- “one fine day” example:
- needed to rebuild an ext3raid1 that kept failing after boot (was not the fault of ext3.. rather harddisk manufacturer (only ENTERPRISE graded harddisk are suitable for raid))
- the good thing about raid1 with two disks:
- both disks contain the same data (not chunks or parts of it or checksums like in raid5 or raid6)
- so both disks can be mounted simply like mount /dev/sda1 /mnt/sda1 and /dev/sdb1 /mnt/sdb1 (also checkout mount single single raid1 disk) so did that then, backuped all data via rsync via usb (PC had only USB 2.0 = 35MBytes/S = SUPER SLOW!) to external harddisk (4TB) (took like 3 days)
- then was rebuild the raid as ext4raid1
- during the backup restore (another 3 days) phase one was in a rush and paused the restore because needed the USB-SATA-external harddisk casing for something important and thought “hey… maybe one can simply attach the external USB-SATA disk (ext4) internal directly to SATA and have much faster restore speeds”
- well… NO! WRONG! it does not work that way… (might also depend on the USB-SATA adapter) because somehow the “layout” is different and it will not mount with “wrong superblock” problem… also restoring any backup superblocks won’t help here because the other superblocks also contain the wrong layout… so simply put it back in the USB-SATA-external-harddisk adapter and everything mounts fine 🙂
- “one fine day” example:
pretty amazing 😀 BUT ONLY WORKS PROPERLY WITH EXT3! NOT EXT4 🙁
might want to scroll down to “usage”.
managed to recover *.aac files that accidentally deleted with rm -rf ‘*\(1\)*’ (! NEED TO ESCAPE THOSE \( \) OR YOU WILL STAND THERE WITH AN EMPTY DIRECTORY)
IF A BUNCH OF FILES GOT DELETED THAT NEED TO BE RECOVER (ON EXT3)! (that’s breeze, but ext4: it’s a nightmare)
POWER-OFF YOUR MACHINE IMMEDIATELY!!
DO AS LITTLE WRITING TO DISK AS POSSIBLE!
1. SAVE ABSOLUTELY NECESSARY CHANGES THEN
2. PULL THE PLUG
3. plugin your KNOPPIX CD/DVD/USB STICK (USB-Stick prefered, because changes stay there)
you can create a bootable KNOPPIX USB STICK from a running CD/DVD-KNOPPIX, find the “KNOPPIX Flash-Disk install” entry in the menu or desktop and hit it.
there is a pretty good guide here: http://www.linux-magazine.com/Online/Features/Getting-Started-with-Knoppix-7.3
forget about installing extundelete under KNOPPIX with apt-get or aptitude: (i really wonder why it is not included per default, maybe it is on the DVD version)
init 0; # immediate shutdown without saving any files # 1. boot from live cd like knoppix # 2. attach a usb harddisk where to store recovered files apt-get install extundelete; # (fails with a mouth full of dependencies) aptitude install extundelete; # (takes ages to sort out things, then kind of fails too)
but you can manually download and put the binaries in place: (remember those are compiled for i386 version of KNOPPIX so they will probably not work with x64-Bit-KNOPPIX.
Also: It is most convenient to install KNOPPIX on a 8GByte Stick instead of CD/DVD, because then your binary will actually stay there 😀 after you reboot.
# open up a terminal su; # become root wget https://dwaves.de/software/recovery/extundelete.tar.gz; # download 32Bit version compiled for older version of debian tar fxvz extundelete.tar.gz; # unpack cp extundelete /usr/bin; # copy binary in place extundelete; # give it a test run, you should get a output like this extundelete No action specified; implying --superblock. extundelete: Missing device name. Usage: extundelete [options] [--] device-file Options: --version, -[vV] Print version and exit successfully. --help, Print this help and exit successfully. --superblock Print contents of superblock in addition to the rest. If no action is specified then this option is implied. --journal Show content of journal. --after dtime Only process entries deleted on or after 'dtime'. --before dtime Only process entries deleted before 'dtime'. Actions: --inode ino Show info on inode 'ino'. --block blk Show info on block 'blk'. --restore-inode ino[,ino,...] Restore the file(s) with known inode number 'ino'. The restored files are created in ./RECOVERED_FILES with their inode number as extension (ie, file.12345). --restore-file 'path' Will restore file 'path'. 'path' is relative to root of the partition and does not start with a '/' The restored file is created in the current directory as 'RECOVERED_FILES/path'. --restore-files 'path' Will restore files which are listed in the file 'path'. Each filename should be in the same format as an option to --restore-file, and there should be one per line. --restore-directory 'path' Will restore directory 'path'. 'path' is relative to the root directory of the file system. The restored directory is created in the output directory as 'path'. --restore-all Attempts to restore everything. -j journal Reads an external journal from the named file. -b blocknumber Uses the backup superblock at blocknumber when opening the file system. -B blocksize Uses blocksize as the block size when opening the file system. The number should be the number of bytes. --log 0 Make the program silent. --log filename Logs all messages to filename. --log D1=0,D2=filename Custom control of log messages with comma-separated Examples below: list of options. Dn must be one of info, warn, or --log info,error error. Omission of the '=name' results in messages --log warn=0 with the specified level to be logged to the console. --log error=filename If the parameter is '=0', logging for the specified level will be turned off. If the parameter is '=filename', messages with that level will be written to filename. -o directory Save the recovered files to the named directory. The restored files are created in a directory named 'RECOVERED_FILES/' by default. extundelete: Error parsing command-line options.
extundelete downloads:
32Bit knoppix version(?): (i hope it works for you)
https://dwaves.de/software/recovery/extundelete.tar.gz
sha512:
87fe3543d337d7db07891e28149ca303a9cf614
3c93a9d20bbac602d46e3286ac7a36880735ab3
41a60870960a98e4dd8e397c47406a80b722d92
416df1ccde1
64Bit:
extundelete -v
extundelete version 0.2.4
libext2fs version 1.43.4
Processor is little endian.
extundelete_64Bit_debian9.tar.gz
sha512: 2e424c5c70107c3e36a4d3453c0deb5
ef643b9f453e22ad8987152c637e4eca383de62
e59c6debd434ca3dc7f817728840bc0b4e1cb8c
81167569b68919fda42
when the user still has partition table / superblock
extundelete can not only recover deleted files but also directory structures.
1. umount the partition (let’s say /dev/sda5) containing the accidentally deleted files
2. navigate to a folder where to put the recovered files (can be on the same hard disk, but should be at least a different partition)
mkdir /mnt/sda4; # create mountpoint for external usb harddisk mount /dev/sda4 /mnt/sda4; # mount (yours might be not sda) cd /mnt/sda4/; # nav extundelete --restore-all /dev/sda5; # start recovery process # this is pretty fast ll; # when it finished, checkout what we got # had a folder called cd RESTORED; # where actually found the deleted *.aac files.
GOOD JOB EXTUNDELETE GUYS! 🙂
GOOD LUCK RECOVERING YOUR FILES! 🙂
LET ME KNOW IF IT WORKED FOR YOU IN THE COMMENTS SECTION.
scream off.
when partition table / superblock is lost:
when extundelete gives you: “bad magic number” “bad superblock” “extundelete Bad magic number in super-block when trying to open filesystem”
you can try: https://help.ubuntu.com/community/DataRecovery
foremost.man.txt is a brilliant tool that can work on partitions/whole harddisk
as always:
apt-get install foremost; # under debian and ubuntu
manual rpm download for Centos/redhat/fedora:
https://centos.pkgs.org/7/forensics-x86_64/foremost-1.5.7-13.1.el7.x86_64.rpm.html
unlike extundelete it will recover files even with filenames from ext3 but not the directory structure.
it will sort all files found by filetype and put them in a directory like:
ls --format=single-column
audit.txt
avi
bmp
dll
doc
docx
exe
gif
htm
jar
jpg
mbd
mov
mp4
mpg
ole
pdf
png
ppt
pptx
rar
rif
sdw
sx
sxc
sxi
sxw
vis
wav
wmv
xls
xlsx
zip
… better than nothing let’s get started:
recover all files of sdc and put them into /mnt/sda4
foremost -i /dev/sdc -o /mnt/sda4
good luck!
About extundelete
extundelete is a utility that can recover deleted files from an ext3 or ext4 partition. The ext3 and ext4 file systems are the most common default file systems in Linux distributions like Mint, Mageia, or Ubuntu. extundelete uses information stored in the partition’s journal to attempt to recover a file that has been deleted from the partition. There is no guarantee that any particular file will be able to be undeleted, so always try to have a good backup system in place, or at least put one in place after recovering your files!
Download the latest version
The latest version of extundelete is 0.2.4, which was released in January 2013. Download extundelete from its sourceforge project site. For brief descriptions of the various options the program understands, see the extundelete command-line options summary. Binary packages are available for some distibutions, but may not have the latest version, which could contain improvements to make it more likely to recover a deleted file. To take advantage of the latest features and bug fixes, read the notes on compiling and using the program below. extundelete has been recovering deleted files since April 2009, when the first version was released.
Why use extundelete?
extundelete is a complex program that makes data recovery from an ext3 or ext4 partition simple. Most people are able to recover their files by running one command from the terminal, as explained in the next section. extundelete was the first program able to restore both the contents and the file name of a deleted file on an ext4 partition. ext3grep was the first program to use the filesystem’s journal to recover data, and much of its code is shared by extundelete, but ext3grep only worked for ext3 partitions and could take hours to start recovering files if the files were on a large partition. extundelete, by contrast, starts recovering files immediately after parsing the filesystem’s journal, usually within a minute or two after starting the program. ext4magic is a program to recover files that was based on extundelete, and has a slightly different set of features and limitations. extundelete makes heavy use of the ext2fs library, which allows it to automatically support many features of ext3 and ext4 file systems.
Documentation
How to compile and install extundelete
To compile and install this program, you must first install the binary and development packages for e2fsprogs (called libext2fs-devel on Mageia, or e2fslibs-dev on Ubuntu, or e2fsprogs-devel on Fedora). extundelete requires libext2fs version 1.39 or newer to run, but for ext4 support, ensure you have e2fsprogs version 1.41 or newer (which may be found by running the command ‘dumpe2fs’ and noting the version it outputs). You must have g++ and GNU make to compile the program. You can install those with the package called build-essential on Ubuntu, or gcc-c++ and make on Fedora, or gcc-c++ and make on Mageia.
To compile the program, simply enter the command “./configure” from the directory the tar.bz2 file was extracted to. The configure step ensures all the necessary programs to install and run extundelete have been installed. Then, run “make” from the same directory to compile the program. The command will generate an executable file called “extundelete” in the “src” directory. You can the run “make install” to install the program in the /usr/bin directory, or it could be run from the “src” directory without this step.
How to use extundelete
extundelete is designed to undelete files from an unmounted partition to a separate (mounted) partition. extundelete will restore any files it finds to a subdirectory of the current directory named “RECOVERED_FILES”. To run the program, type “extundelete –help” to see various options available to you.
Typical usage to restore all deleted files from a partition looks like this:
$ extundelete /dev/sda4 --restore-all
For an example of running the program, see the file “README” included with the program. It is normal for extundelete to appear to pause (while taking up a lot of cpu cycles) for a minute or longer; during this time, the program is reading the directory structure and looking for a recoverable file within it. To restore important files quickly, you may use the –restore-file, –restore-files, or –restore-directory options.
If you have questions or comments about using extundelete or how to recover your lost files, or to report a success/failure of your recovery efforts with this utility, send a note to the extundelete mailing list.
What to do if you’ve deleted a file (or multiple files)
Do not save any more data to the partition with the deleted file for any reason! Doing so may overwrite your deleted data and sabotage any recovery effort. Many background processes will periodically write to disk, so work quickly until the partition is unmounted.
If you think the file may be still open by some program (for example, if it is a movie file currently being played by a movie player), and you know the filename, then first follow this procedure:
$ lsof|grep "/path/to/file"
progname 5559 user 22r REG 8,5 1282410 1294349 /path/to/file
Notice the number in the second column is 5559 and the number in the fourth column is 22. The command to restore that file is:
$ cp /proc/5559/fd/22 restored.file
If lsof doesn’t find your file, then immediately remount the partition read-only:
$ mount -o remount,ro /dev/partition
or unmount the partition:
$ umount /dev/partition
Typically, you would replace “partition” in the above examples by a device name like “sda4” or “hdb7”. When either of those commands successfully completes, you can now take the next steps leisurely – you will no longer make anything worse by waiting. If you would like to make a backup of your partition, you may do so by a command such as:
$ dd bs=4M if=/dev/partition of=partition.backup
Now is the time to run extundelete, which you may safely run on either the backup you may have made above or the raw device, as long as it is not mounted (or mounted read-only). See the section above for details on how to use this program. If extundelete was unable to recover your files, then you may try to recover your files with debugfs, a tool included with the e2fsprogs package. If you unmounted the partition before the file system got a chance to fully delete the files you are interested in, running debugfs may allow you to recover the files before the file system deletes them (which it may do the next time the partition is mounted). The ‘dump’ and ‘rdump’ commands in debugfs may be useful to you for these purposes. If you were unable to recover your files using extundelete or debugfs, then you may try to recover your files with ext3grep or ext4magic. The generation of ext3grep’s stage2 cache file depends on the size and speed of your hard drive’s partition, with typical speeds close to one minute for every 2 GB (30 s per GB, or 8 hours per TB).
If the above options didn’t recover your files, then you may try a program that searches for identifying patterns throughout the entire partition, like foremost, scalpel, or Photorec. ext3grep’s –search options may also be used for this purpose.
ext3/4 filesystem details
This section lists resources about the extended filesystem families (ext2/3/4), which will be useful for those wanting to understand more about how the filesystem functions and how extundelete is able to undelete a file. Also note that the ext3grep link provides an example of advanced usage of ext3grep, which can help explain how to use extundelete to comprehensively search for an important deleted file, as both programs have many features in common.
- Information about the ext2 filesystem
- e2fsprogs: the standard utilities for ext2/3/4 filesystems
- Carlo Wood’s explanation of the ext3 filesystem and ext3grep
- Why recovering a deleted ext3 file is difficult
How extundelete works
extundelete uses some concepts and code first shown to be successful by the ext3grep program. extundelete is able to recover the contents of an inode by searching the file system’s journal for an old copy of that inode. It then uses that information to determine the file’s location within the file system. Then, extundelete reads the corresponding data and copies it to a file in the recovery directory.
extundelete is able to match the inode number of a file to a file name by searching the deleted entries in a directory, which are often left behind after deleting the file. If the deleted entry does not exist in the directory in the file system, extundelete will look for a match in older copies which are still in the journal.
Current abilities of extundelete
- extundelete is able to undelete a file from an ext3 filesystem or an ext4 file system, as long as the ext4 filesystem has a journal.
- extundelete will not restore hardlinks or softlinks, but will restore the file a link points to.
- extundelete will not restore extended attributes.
- If you run in to a problem that results in the program not working properly, please send a note to the mailing list, and it will likely be fixed in the next version. For a complete example of how to use extundelete, see the README file.
Links
- extundelete SourceForge project page
- extundelete mailing list – Send a message here to report your experience with extundelete, or for any other questions or comments about extundelete.
- extundelete command-line options summary
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!