|
Ext4magic: Inode - Directory - Journal - Install - Time_Options - Histogram - Scenarios - Tips&Tricks - Manpage - Expert-Mode |
Create a copy of the journal to a different file system before you umount the deleted and now empty file system.
sync
debugfs -R "dump <8> /tmp/JOURNAL.copy" /dev/sdb1
Now do not write to that file system on /dev/sdb1 any more and execute no fsck on /dev/sdb1
Prevent a automatic mount on next reboot, and do not mount it self again
For safety if enough free disk space available, create a copy of /dev/sdb1 as a image
dd if=/dev/sdb1 of=/tmp/PartitionCOPY_sdb1.image
Recover process depends on the number and size of deleted files and may take a long time.
ext4magic /dev/sdb1 -M -d /mnt/FREE_SPACE
ext4magic /dev/sdb1 -j /tmp/JOURNAL.copy -M -d /mnt/FREE_SPACE
ext4magic /tmp/PartitionCOPY_sdb1.image -M -d /mnt/FREE_SPACE
The whole file system is deleted. The deletion process
took longer than 5 minutes.
The reason why this has required a
long time, could be:
Slow hard drive and a lot of files
Deletion is usually been kicked off by commands like mv or rsync or by scripts that delete step by step
Several log running processes which delete files or directories are executed in sequence
Some deleted files were still open by processes (These files are deleted later when this process is terminated)
The operating system or other programs have changed or deleted some files in this filesystem after deletion even before the umount.
The recovery process is identical as in scenario 1. In addition the time parameter has to be used. AFTER time parameter has to be a few seconds before the first file was deleted. If the AFTER time parameter is not used ext4magic will recover only files which were deleted the last 5 minutes of the whole deletion process.
ext4magic /dev/sdb1 -M -d /mnt/FREE_SPACE -a 1330465566Use histogram function to find the exact time to use for AFTER time.
Method and all as in scenario 1, but now use not -M , this would recover all undeleted files also. Here you should use the -m option instead. This will only search for deleted files and deleted data areas. If it was a longer deletion process or you don't know for sure whether some additional data was written after the deletion process, use the AFTER option and use the time just before the deletion has started.
ext3 home filesystem /dev/sda6 in the directory "/home/rob/Bilder/" images were deleted.
It should only be deleted pictures with the extension "*. jpg_"
But all the pictures "*.jpg" now deleted
A lot of other images and directories are still there, these are okay
The error was noticed quickly
For precaution, create a copy of the journal
All users must logoff
Switch to runlevel 3
umount the /home file system
# su -
# debugfs -R "dump <8> /tmp/sda6.journal" /dev/sda6
# init 3Switch now to a console and log in as root
# umount /home
There is enough space in the /tmp directory, we use /tmp/RECOVER to write the files.
Deleting happened a few minutes ago and thus the last 20 minutes should be listed with the histogram
# ext4magic /dev/sda6 -H -a (date -d "-20minutes" +%s)
Filesystem in use: /dev/sda6
|-----------c_time Histogram----------------- after -------------------- Sat Mar 24 17:23:56 2012
1332606356: 1 |***** | Sat Mar 24 17:25:56 2012
1332606476: 2 |********** | Sat Mar 24 17:27:56 2012
1332606596: 0 | | Sat Mar 24 17:29:56 2012
1332606716: 2 |********** | Sat Mar 24 17:31:56 2012
1332606836: 4 |******************** | Sat Mar 24 17:33:56 2012
1332606956: 2 |********** | Sat Mar 24 17:35:56 2012
1332607076: 0 | | Sat Mar 24 17:37:56 2012
1332607196: 10 |**************************************************| Sat Mar 24 17:39:56 2012
1332607316: 0 | | Sat Mar 24 17:41:56 2012
1332607436: 0 | | Sat Mar 24 17:43:56 2012
|-----------d_time Histogram----------------- after -------------------- Sat Mar 24 17:23:56 2012
1332606356: 0 | | Sat Mar 24 17:25:56 2012
1332606476: 0 | | Sat Mar 24 17:27:56 2012
1332606596: 0 | | Sat Mar 24 17:29:56 2012
1332606716: 2 |**** | Sat Mar 24 17:31:56 2012
1332606836: 27 |**************************************************| Sat Mar 24 17:33:56 2012
1332606956: 0 | | Sat Mar 24 17:35:56 2012
1332607076: 0 | | Sat Mar 24 17:37:56 2012
1332607196: 9 |***************** | Sat Mar 24 17:39:56 2012
1332607316: 0 | | Sat Mar 24 17:41:56 2012
1332607436: 0 | | Sat Mar 24 17:43:56 2012
ext4magic: EXIT_SUCCESS
27 files were deleted at 17:33:56
Some time later other
files were modified or deleted. (Probably is's mostly KDE/GNOME
files or other configuration files written during the user logout.)
A good time window in this case is AFTER time
1332606716 (from histogram) and the default BEFORE
time (now).
A list of all the deleted and ready to recover files
in directory rob/Bilder can be created with
# ext4magic /dev/sda6 -a 1332606716 -f rob/Bilder -l
Filesystem in use: /dev/sda6
Using external Journal at File /tmp/sda6.journal
Activ Time after : Sat Mar 24 17:31:56 2012
Activ Time before: Sat Mar 24 17:50:20 2012
Inode found "rob/Bilder" 1143236
Inode 1143236 is allocated
98% rob/Bilder/cimg1435.jpg
100% rob/Bilder/cimg1436.jpg
100% rob/Bilder/cimg1439.jpg
100% rob/Bilder/cimg1442.jpg
100% rob/Bilder/cimg1443.jpg
100% rob/Bilder/cimg1444.jpg
100% rob/Bilder/cimg1445.jpg
100% rob/Bilder/cimg1446.jpg
100% rob/Bilder/cimg1456.jpg
100% rob/Bilder/cimg1457.jpg
100% rob/Bilder/cimg1458.jpg
100% rob/Bilder/cimg1541.jpg
99% rob/Bilder/cimg1442.jpg_
100% rob/Bilder/cimg1443.jpg_
100% rob/Bilder/cimg1444.jpg_
100% rob/Bilder/cimg1445.jpg_
100% rob/Bilder/cimg1446.jpg_
ext4magic: EXIT_SUCCESSTwo files cimg1435.jpg cimg1442.jpg_ are already corrupted (percentage < 100%) and have overwritten/reused data blocks and therefore cannot be recovered with their original content.
To find out which files are missing in the above list, list the directory content. These missing files are mark as deleted (<inodenr>) and have no file size in the following output. There is no undeleted copy of the inode for these files any more in the journal so there is no recovery possible for these files.
# ext4magic /dev/sda6 -a 1332606716 -f rob/Bilder
....
< 1142574> _ 755 (1) 1000 100 0 24-Mar-2012 17:33 cimg1433.jpg
< 1143164> _ 755 (1) 1000 100 0 24-Mar-2012 17:33 cimg1434.jpg
< 1143169> _ 755 (1) 1000 100 2022342 21-Feb-2010 21:27 cimg1435.jpg
< 1143180> _ 755 (1) 1000 100 1871073 21-Feb-2010 21:27 cimg1436.jpg
< 1143187> _ 755 (1) 1000 100 0 24-Mar-2012 17:33 cimg1437.jpg
< 1143197> _ 755 (1) 1000 100 0 24-Mar-2012 17:33 cimg1438.jpg
< 1143218> _ 755 (1) 1000 100 1844663 21-Feb-2010 21:27 cimg1439.jpg
....
< 1143291> _ 755 (1) 1000 100 2066004 21-Feb-2010 21:28 cimg1458.jpg
< 1143314> _ 755 (1) 1000 100 0 24-Mar-2012 17:33 cimg1459.jpg
< 1143316> _ 755 (1) 1000 100 0 24-Mar-2012 17:33 cimg1460.jpg
< 1143317> _ 755 (1) 1000 100 0 24-Mar-2012 17:33 cimg1461.jpg
< 1143155> _ 755 (1) 1000 100 0 24-Mar-2012 17:33 cimg1537.jpg
< 1143320> _ 755 (1) 1000 100 0 24-Mar-2012 17:33 cimg1538.jpg
< 1143330> _ 755 (1) 1000 100 0 24-Mar-2012 17:33 cimg1539.jpg
< 1143340> _ 755 (1) 1000 100 0 24-Mar-2012 17:33 cimg1540.jpg
....
First recover all undamaged files from which a inode copy is available, You can use the journal copy /tmp/sda6.journal (but in this case it's not necessary)
# ext4magic /dev/sda6 -a 1332606716 -f rob/Bilder -j /tmp/sda6.journal -r -d /tmp/RECOVER
"/tmp/RECOVER" accept for recoverdir
Filesystem in use: /dev/sda6
Using external Journal at File /tmp/sda6.journal
Activ Time after : Sat Mar 24 17:31:56 2012
Activ Time before: Sat Mar 24 17:58:05 2012
Inode found "rob/Bilder" 1143236
Inode 1143236 is allocated
-------- /tmp/RECOVER/rob/Bilder/cimg1436.jpg
-------- /tmp/RECOVER/rob/Bilder/cimg1439.jpg
-------- /tmp/RECOVER/rob/Bilder/cimg1442.jpg
-------- /tmp/RECOVER/rob/Bilder/cimg1443.jpg
-------- /tmp/RECOVER/rob/Bilder/cimg1444.jpg
-------- /tmp/RECOVER/rob/Bilder/cimg1445.jpg
-------- /tmp/RECOVER/rob/Bilder/cimg1446.jpg
-------- /tmp/RECOVER/rob/Bilder/cimg1456.jpg
-------- /tmp/RECOVER/rob/Bilder/cimg1457.jpg
-------- /tmp/RECOVER/rob/Bilder/cimg1458.jpg
-------- /tmp/RECOVER/rob/Bilder/cimg1541.jpg
-------- /tmp/RECOVER/rob/Bilder/cimg1443.jpg_
-------- /tmp/RECOVER/rob/Bilder/cimg1444.jpg_
-------- /tmp/RECOVER/rob/Bilder/cimg1445.jpg_
-------- /tmp/RECOVER/rob/Bilder/cimg1446.jpg_
ext4magic: EXIT_SUCCESS15 lost JPEG files were recovered successfully. Actually only 11 files should have been recovered because the files with a trailing _ were deleted by intention. They have to be deleted manually form /tmp/RECOVER/rob/Bilder.
In this case, not all the lost files were restored.
You can try to restore some more files with the magic-function of
ext3magic. In this case the file system is ext3 and ext4magic-0.2.4
is required. (For an ext4 filesystem ext4magic-0.3.0 is
required)
Check the ext4magic version with with
# ext4magic -V -x
ext4magic version: 0.2.4
libext2fs version: 1.41.9
CPU is little endian.
ext4magic /dev/sda6 -a 1332606716 -j /tmp/sda6.journal -m -d /tmp/RECOVERMaybe this recovers now many files, mainly symlinks and empty files. These files are not important, later on you can delete all these files. This command also will recover the files from the previous recovery a second time. The interesting part comes at the end of the process. Additional recovered files are detected by the file carving function:
.....
MAGIC-3: start ext3-magic-scan search. Please wait, this may take a long time
-------- /tmp/RECOVER/MAGIC-3/image/jpeg/0004741651.jpg
-------- /tmp/RECOVER/MAGIC-3/image/jpeg/0004742628.jpg
-------- /tmp/RECOVER/MAGIC-3/image/jpeg/0004747759.jpg
-------- /tmp/RECOVER/MAGIC-3/image/jpeg/0004748648.jpg
-------- /tmp/RECOVER/MAGIC-3/image/jpeg/0004749081.jpg
-------- /tmp/RECOVER/MAGIC-3/image/jpeg/0004749585.jpg
-------- /tmp/RECOVER/MAGIC-3/image/jpeg/0004595413.jpg
-------- /tmp/RECOVER/MAGIC-3/image/jpeg/0004597802.jpg
-------- /tmp/RECOVER/MAGIC-3/image/jpeg/0004603959.jpg
ext4magic: EXIT_SUCCESSThe magic-function has found another 9 JPEG files.
Now mount /home again, start the runlevel 5 and
login as user.
As root, copy back the recovered files to
/home/rob/Bilder/
cp /tmp/RECOVER/rob/Bilder/*.jpg /tmp/RECOVER/MAGIC-3/image/jpeg/*.jpg /home/rob/Bilder/Check the JPEG files with display , xv or gimp or a other tool. Some files got different names during the file carving function and must be renamed to get their original filename.
In this example 20 of 21 accidentally deleted JPEG files could be recovered. One file was lost during overwritten data blocks.
An important file "/home/rob/DB/HWSD.mdb" was overridden in a directory on /dev/sda6 by a incorrect zip command :
zip -r - base/ > "HWSD.mdb"The /tmp directory is /dev/sda3 and still has plenty of space for temporary files. /dev/sda6 can not be unmounted immediately..
If the filesystem can not either be mounted read-only or umounted avoid all unnecessary writes to the filesystem. Create a copy of the file system journal on a different file system /tmp/journal.copy
debugfs -R "dump <8> /tmp/journal.copy" /dev/sda6
This process may unfortunately fail if there doesn't exist an old inode copy any more.
Find out what inode number of the file "/home/rob/DB/HWSD.mdb"
# ls -il HWSD.mdb
742663 -rw-r--r-- 1 rob users 20704805 Mar 1 23:46 HWSD.mdbDetermine which inode copies of these inode are in the journal. Do not use the journal of the file system, use the copy /tmp/journal.copy
# ext4magic /dev/sda6 -j /tmp/journal.copy -I 742663 -T
Filesystem in use: /dev/sda6
Using external Journal at File /tmp/journal.copy
Inode 742663 is at group 91, block 2981896, offset 1536
Transactions of Filesystemblock 2981896 in Journal
FS-Block Journal Transact
2981896 13542 711337
2981896 13547 711338
2981896 13560 711339
Dump Inode 742663 from journal transaction 711337
Inode: 742663 Type: regular Mode: 0644 Flags: 0x0
Generation: 3901765187 Version: 0x00000000
User: 1000 Group: 100 Size: 32739328
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 64016
Fragment: Address: 0 Number: 0 Size: 0
ctime: 1320716830 -- Tue Nov 8 02:47:10 2011
atime: 1330641812 -- Thu Mar 1 23:43:32 2012
mtime: 1320716830 -- Tue Nov 8 02:47:10 2011
Size of extra inode fields: 4
Dump Inode 742663 from journal transaction 711338
Inode: 742663 Type: regular Mode: 0644 Flags: 0x0
Generation: 3901765187 Version: 0x00000000
User: 1000 Group: 100 Size: 20704805
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 40488
Fragment: Address: 0 Number: 0 Size: 0
ctime: 1330641988 -- Thu Mar 1 23:46:28 2012
atime: 1330641812 -- Thu Mar 1 23:43:32 2012
mtime: 1330641988 -- Thu Mar 1 23:46:28 2012
Size of extra inode fields: 4
Dump Inode 742663 from journal transaction 0
Inode: 742663 Type: regular Mode: 0644 Flags: 0x0
Generation: 3901765187 Version: 0x00000000
User: 1000 Group: 100 Size: 20704805
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 40488
Fragment: Address: 0 Number: 0 Size: 0
ctime: 1330641988 -- Thu Mar 1 23:46:28 2012
atime: 1330642018 -- Thu Mar 1 23:46:58 2012
mtime: 1330641988 -- Thu Mar 1 23:46:28 2012
Size of extra inode fields: 4
ext4magic: EXIT_SUCCESSYou can identify the inode copies by the file size, and the ctime. In this case, 3 copies are present. The first one is a copy from the original file. Use the transaction number from this copy to restore the file. (transaction = 0, the last , this is the real inode of the filesystem, not a journal copy) Write the recovered file to another file system. /tmp and use option "-r". If there are any blocks of this file already reused the file will not be recovered.
# ext4magic /dev/sda6 -j /tmp/journal.copy -I 742663 -t 711337 -r -d /tmp
"/tmp" accept for recoverdir
Filesystem in use: /dev/sda6
Using external Journal at File /tmp/journal.copy
Dump Inode 742663 from journal transaction 711337
Inode: 742663 Type: regular Mode: 0644 Flags: 0x0
Generation: 3901765187 Version: 0x00000000
User: 1000 Group: 100 Size: 32739328
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 64016
Fragment: Address: 0 Number: 0 Size: 0
ctime: 1320716830 -- Tue Nov 8 02:47:10 2011
atime: 1330641812 -- Thu Mar 1 23:43:32 2012
mtime: 1320716830 -- Tue Nov 8 02:47:10 2011
Size of extra inode fields: 4
-------- /tmp/<742663>
ext4magic: EXIT_SUCCESSIf the recovery was successfully check the file and copy it back to it's original location.
# ls -l "/tmp/<742663>"
-rw-r--r-- 1 rob users 32739328 Nov 8 02:47 /tmp/<742663>
# file "/tmp/<742663>"
/tmp/<742663>: Microsoft Access Database
# cp "/tmp/<742663>" /home/rob/DB/HWSD.mdb
Don't use the journal later on if the filesystem was modified in the meantime. In addition don't use debugfs to create a new copy or use ext4magic to read the journal on the file system until the file system was unmounted and mounted again. Otherwise ext4magic recovery may create incorrect results because some parts of the file system journal will be cached when it's read with debugfs and will be out of sync with the actual contents on the filesystem on the disk.
Hard disk sdb should be deleted by using "dd". However, accidentally an incorrect target sdd was entered for the "dd" command. The error detected immediately and the command canceled. There were only about 100 MByte written to disk sdd.
sdd1 (at the front of the disk) is a ext3 or ext4 file system and contains important files.
sdd has a conventional IBM PC partitioning scheme
Important to remember now, the MBR and the included partition table has also been destroyed as well. But at the moment the current running kernel knows the old partition. This should be used if you have no backup of the partition table. After a reboot the kernel can not find a valid partition table and thus no file system on this disk any more. You can find these informations at the /sys/block directory. The partition starts on the disk (a 512 Byte blocks) can find at /sys/block/sdd/sdd*/start and the partition size at /sys/block/sdd/sdd*/size. Locate these files start and size for all partitions of the overwritten disk and save them. You can use this later to restore the partition table. The following script will do this for all block devices. You can run this as non-root user
#!/bin/bash
printf "%s\t%10s\t%10s\n" Part Start Size
for SYS in /sys/block/*
do
DEVICE=$(echo -n ${SYS}/; echo ${SYS##*/})
for PART in ${DEVICE}*
do
if [ -f $PART/start ]
then
START=$(cat $PART/start)
SIZE=$(cat $PART/size)
printf "%s\t%10lu\t%10lu\n" ${PART##*/} $START $SIZE
fi
done
done
If the filesystem sdd1 is still mounted, umount it now. This
will still write some filesystem meta information, which could be
valuable later on. If you have enough free disk space on another
disk, then back up now the sdd1 partition as an image.
dd if=/dev/sdd1 of=/mnt/FREE_SPACE/sdd1_copy.imageIf the system runs normal in this state, do not switch off or reboot the computer now if you need one of the partitions of sdd. Without recreating the partition table, you have no access to the data any more. It's time to make a backup of this data.
Do not continue until you have not even created a copy of the whole disk.
Enough free disk space is required to write the recovered files from sdd1.
You need a ext4magic with Expert-Mode enabled. (for example: one of these). You can check with the following command:
ext4magic -V -x
needed is also a small script from the (Expert-Mode site).
|
Attention: |
|
Never use both the original disk and the copy of the disk together for recovery activities. The last one will be used only for the generation of new copies, if it's necessary. |
If you could create a copy of the sdd1 partition before the computer is shut down, they can be used directly with ext4magic. Otherwise, the partition table must first be restored or must created such an image of the defect partition (this Howto use the copy of the overwritten disk, sde).
If you have saved the output of /sys/block/sdd/sdd*/start and /sys/block/sdd/sdd*/size before a reboot, you can use sfdisk to create a new partition table with the correct data.
Example: the saved data from the /sys/block/ files:
/sys/block/sdd/sdd1/start 63
/sys/block/sdd/sdd2/start 392112
/sys/block/sdd/sdd3/start 8205120
/sys/block/sdd/sdd1/size 3392049
/sys/block/sdd/sdd2/size 7813008
/sys/block/sdd/sdd3/size 8293824
Use this data for create a new partition table on
the disk copy /dev/sde.
sfdisk
accepted these values as "SECTORS"
You can do this interactiv, or with a Here
Document
# sfdisk -uS /dev/sde <<EOF
63,3392049
392112,7813008
8205120,8293824
0,0
EOFor create a simple text file with following content
# partition table for sde (a copy of destroyed sdd)
unit: sectors
/dev/sde1: start= 63, size= 392049, Id=83
/dev/sde2: start= 392112, size= 7813008, Id=83
/dev/sde3: start= 8205120, size= 8293824, Id=83
/dev/sde4: start= 0, size= 0, Id= 0and use this as following
sfdisk /dev/sde < TEXTFILEcheck the output of command to whether the partition table was written correctly.
If there exists an extended partition it's size
value is not correctly. It must be calculated by you. But, don't do
this now. For now set only the first (the damage) partition and the
other three set to empty partitions.
If the first partition was
logical partition 5 (/dev/sde5)
then the partition now will become partition 1 (/dev/sde1).
The other partitions /dev/sde2
to /dev/sde4
will be empty partitions. When the files of the
first partition have been recovered with ext4magic, clean the
partition table and use fdisk
and delete the partition now (/dev/sde1)
and use gpart
or testdisk
to find the correct logical partitions.
Instead to restore the partition table you can create a partition image. Use the information of start and size to create an image of the first partition with dd
dd if=/dev/sde of=/tmp/image_of_sde1 bs=512 skip=63 count=392049
You need here the script from the Expert-Mode site This can find out the copies of the superblock. Use this script if you have set the partition table:
SCRIPT /dev/sde1or if the copy of this partition is a image:
SCRIPT IMAGE_NAMEThis will work on a disk only if the partition start in the partitions table is set correct. The script will output some command lines which you can use with ext4magic to recover the filesystem. Select one of these command lines and add to it "-d FREE_SPACE" (FREE_SPACE is the place for the recovered files on a ext3/4 filesystem)
ext4magic "/dev/sde1" -s 4096 -n 4096000 -c -D -d /mnt/recoverThis will try to recover all files with existing metadata and also all files for which the metadata was destroyed but copies of the metadata is still in the journal. Depending on the level of destruction and the contents of the journal more or less large fragments of the directory structure and individual files may be found.
|
Ext4magic: Inode - Directory - Journal - Install - Time_Options - Histogram - Scenarios - Tips&Tricks - Manpage - Expert-Mode |