|
Attention: |
|
This is a computer translation of the original webpage. It is provided for general information only and should not be regarded as complete nor accurate |
|
Ext4magic: Inode - Directory - Journal - Install - Time_Options - Histogram - Scenarios - Tips&Tricks - Manpage - Expert-Mode |
Contents |
A file system should before the use with ext4magic first umounted or mount it read-only. In some cases this will not be possible, and also the loss of only one file will not always justify this expenditure really. ext4magic has an evasion of this problem, which is classified however at present still as experimental for unique smaller actions.
|
Attention: |
|
The direct use of the journal one a read-write mounted file system produces ext4magic errors and wrong results |
During the reading of the journal the cache of the file system is used, that means Linux holds contents or substantial parts of the journal file in main memory after the first read, and the next reading use only the main memory and no more the disk. That is also for extmagic a great many accesses to the blocks takes place often several times necessarily there and this is importantly faster to read than the blocks again and again.
Linux writes unbuffered and directly into the journal on the disk. ext4magic read the journal buffert from cache, and reads so wrong blocks at the journal position of the first read. That means, the first read and access by ext4magic on the journal and pertinent list or recover is started on thereby, runs still normally, as long as it is not too time-consuming. On a read write mounted file system the kernel continues to write to the journal, a next run of ext4magic and all afterwards read now wrong blocks at this journal position, and this becomes worse with each attempt. Even if a copy of the journal with the official tools is made now, this copy will likewise contain these errors. This error disappears only again, if the file system is completely umounted and new mounted again, (remount is not enough) only then the blocks are again correct readable at this position in the journal.
After a certain time, dependent on the memory
equipment and the memory use of the computer, the journal out of
the Cache of the file system will displace, which cannot however in
such a way exactly certainly or predicts becomes.
With ext4magic and the first attempt the desired
result to really reach, without looking at the journal and inode
data before, is not very probable. If the file system were not
mounted completely read only or to induce the file system now not
to write to journal, is utopian.
It must created a copy of this journal, and later only this journal copy journal instead of the original journal to be used. The journal is a special file in the file system which no listing entry possesses and which only over the inode number themselves to be addressed can. The internal journal of a ext3/4 of file system always uses the Inode number 8 for the journal by default. With debugfs a copy of the journal can is provided. But importantly: also only the first copy is correct, later further copies the journal have the same errors. Also the selection of the journal over debugfs causes thus the cachen journal in the memory. With ext4magic do not thus only try, but to everything only with debugfs a copy of the journal provide, in the first attempt.
# debugfs -R "dump <8> /PATH/journal.copy" /dev/device “/PATH/journal.copy” stands here symbolically for the file name of the journal copy. This should be put on urgently on another file system. “/dev/device” the block DEVICE or the partition is on the file system which can be examined is.
With this snapshot of the journal ext4magic can work exactly the same as with the internal journal, it must only at start as option be indicated, then this is used and not the internal of the file system
# ext4magic /dev/device - j /PATH/journal.copy .........Of course if it is possible, , now write not more as absolutly emergency in the file system. Each write can overwrite some of the blocks of files that you will win again. Only an overwritten data block, depending the used comandline parameter, the file is not restored, or is defective in parts or completely after restoring.
Warning: This procedure is tested, it works, but please be very careful with this feature. Remember, for ext4magic the file system is frozen at the time at which the journal copy created. Any subsequent changes will not recognize by ext4magic. This works only correct for a limited time if you continue to write into the file system.
Images of a file system partitions can be used directly by ext4magic. Differently with images of whole disk. Here those are to file system on the partitions of this image and can be used only over loop DEVICEs. The instruction to connect to such a partition with a loop DEVICE is losetup. Since the partitions inevitably at the beginning of the image file does not stand, must be worked here as an offset-value in byte exactly the beginning of the partition within the image indicates. The offset-value can be calculated by the partition table of the image. For the simpler handling here a small script, which reads the data from the partition table and can computation the values.
#!/bin/bash
# help-loop-image
# Script to calculate the correct offsets for partitions
# of a whole disk image.
# Autor: robi6@users.sf.net (Version 1.0 vom 25.04.2011)
PATH="/sbin:$PATH"
if [ $# -lt 1 ]
then
echo "usage: ${0##*/} <image>"
exit 1
fi
IMAGE=$1
if [ ! -f "$IMAGE" ]
then
echo "ERROR: $IMAGE is no file"
exit 2
fi
LANG=C fdisk -lu "$IMAGE" 2>&1 | tr -d '*' | egrep "${IMAGE}[p]*[0-9]" | while read part start end blocks id rest
do
echo
echo "# $read $part $start $end $blocks $id $rest"
case $id in
f) echo "Extended partition ignored"
continue
;;
82) echo "Swap ignored"
continue
;;
*)
;;
esac
let offset=$start*512
echo "losetup -f \"$IMAGE\" -o $offset"
done
exit 0Save this script as "help-loop-image" and set the executable flags. The Script is called then simply with the image
./help-loop-image IMAGE_FILEThis Script will indicate the possible data partitions 1-9 of the image and in each case to details losetup instruction with the calculated offset-value under it spend and creates a list of losetup commands how you can use for mount the partitions Pick the one of the partion you want to recover and check with
losetup -awhich loop device was used to mount the partition. ext4magic now can use this loopdevice like a normal partition. Example:
ext4magic /dev/loop0 -SAfter conclusion of the work with ext4magic this loop DEVICE should be released again
losetup -d /dev/loop0
There are two different methods Block Device Encryption and Stacked Filesystem Encryption
The following refers to Block Device Encryption
With ext4magic inadvertently deleted files can be recovert again also of encrypted ext3/ext4 file systems. We need the virtual block device on that the file system decoded mapped is. The device should not be mounted at this time. In most cases something manual work is necessary for since the configuration and the automatisms under normal conditions running off should prevent that the file system is decoded attainable in the unmounted condition. How is to be proceeded thereby, is to be reread dependently on the used encrypt technology and in the appropriate documentations. If this should not be possible, then the crypted file system is too at least readonly to mount. Previously the file system must be umountet completely, a remount to readonly is not sufficient.
As example here the proceeding with a container
crypted with LUKS. The container file is in this example the file
/home/test/crypt.iso those at present is not configures and
not mounted.
ROBI@LINUX:~ # file crypt.iso
crypt.iso: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1] UUID: 2ca7be95-439d-499e-849e-cbba5de
ROBI@LINUX:~ # losetup -a
ROBI@LINUX:~ # losetup /dev/loop0 crypt.iso
ROBI@LINUX:~ # losetup -a
/dev/loop0: [0806]:1011860 (/home/test/crypt.iso)
ROBI@LINUX:~ # file -s /dev/loop0
/dev/loop0: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1] UUID: 2ca7be95-439d-499e-849e-cbba5deIn this first section the container is connected with a free loop DEVICE, here also /dev/loop0
Afterwards the LUKS volume is then opened and thus the
virtual file system layer as a device below /dev/mapper/
visible.
In this example : /dev/mapper/cr_crypt.iso
ROBI@LINUX:~ # cryptsetup luksOpen /dev/loop0 cr_crypt.iso
Enter LUKS passphrase for /dev/loop0:
key slot 0 unlocked.
Command successful.
ROBI@LINUX:~ # file -s /dev/mapper/cr_crypt.iso
/dev/mapper/cr_crypt.iso: Linux rev 1.0 ext4 filesystem data (extents) (huge files)
The instruction file - s shows now, this is the ext4 file
system and this device can be accessed now with ext4magic.
in
the example recover the deleted files from directory picture/
ROBI@LINUX:~ # ext4magic /dev/mapper/cr_crypt.iso -r -f picture
"RECOVERDIR" accept for recoverdir
Filesystem in use: /dev/mapper/cr_crypt.iso
Using internal Journal at Inode 8
Inode found "picture" 1817
Inode 1817 is allocated
-------- RECOVERDIR/picture/cimg1442.jpg
-------- RECOVERDIR/picture/cimg1434.jpg
-------- RECOVERDIR/picture/test0004.tif
-------- RECOVERDIR/picture/cimg1435.jpg
-------- RECOVERDIR/picture/cimg1459.jpg
-------- RECOVERDIR/picture/cimg1445.jpg
-------- .........
...... Not forgot, after the work with ext4magic to clear up this. In this case the LUKS volume must be closed again and be dissolved the connection with the loop device again.
ROBI@LINUX:~ # cryptsetup luksClose /dev/mapper/cr_crypt.iso
ROBI@LINUX:~ # losetup -d /dev/loop0
The following is for progressing and contains an example like one with the help of the options from ext4magic also problems to solve can, which appear so easily not solvable on the first view.
The histogram function shows the following expenditure of DELETE Time:
ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso.3 -a 1286031225 -b 1286031288 -H
Filesystem in use: testfile.iso.3
......
|-----------d_time Histogram----------------- after -------------------- Sat Oct 2 16:53:45 2010
1286031231 : 3 |** | Sat Oct 2 16:53:51 2010
1286031237 : 0 | | Sat Oct 2 16:53:57 2010
1286031243 : 0 | | Sat Oct 2 16:54:03 2010
1286031249 : 49 |********************* | Sat Oct 2 16:54:09 2010
1286031255 : 0 | | Sat Oct 2 16:54:15 2010
1286031261 : 6 |*** | Sat Oct 2 16:54:21 2010
1286031267 : 117 |**************************************************| Sat Oct 2 16:54:27 2010
1286031273 : 53 |*********************** | Sat Oct 2 16:54:33 2010
1286031279 : 0 | | Sat Oct 2 16:54:39 2010
1286031285 : 0 | | Sat Oct 2 16:54:45 2010
ext4magic : EXIT_SUCCESS4 erasing processes are to be recognized. The deletion of the 6 files is from interest in the time interval of 16:54: 15 to 16:54: 21. With this erasing process the files were falsely deleted, which we would like now again recovern.
The time options cannot be used here in ext4magic directly, in order to cancel purposefully only certain erasing process from this series. (Comparisons also). Only one time window can be determined, by which can be tried, the there current conditions too recovern. Only the first erasing process (49 files) can be excluded, but the two erasing processes thereafter took place (117 + 53), cannot with the time options not be excluded in such a way, since the files likewise still existed at this time and are deleted now. Only with the time options directly here thus only the last erasing processes could become together complete all recover, which would then contain also the looked for files.
The problem can be circumvented as follows. The cunning ruse are, create lists of recoverable files on different time windows
The first list is to exclude only the first erasing process and contains thus the files 2 to 4 of the erasing process. thus also the looked for files. It becomes thereby the option “- l” in connection with the option “- x” used. Thus a list is provided, the ext4magic with the option “- i input_list” to directly process can. (see also)
The second list, exactly the same with different time, these contains now all files deleted after the appropriate time, the searched files are no more contain there.
A difference list can be generated by these two lists, and if everything ran correctly, it contains exactly the file names of the files we are looking for
ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso.3 -a 1286031255 -b 1286031279 -lx > log_vor ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso.3 -a 1286031261 -b 1286031279 -lx > log_nach ROBI@LINUX:/tmp/test1 # diff log_vor log_nach 4c4 < Activ Time after : Sat Oct 2 16:54:15 2010 --- > Activ Time after : Sat Oct 2 16:54:21 2010 28,32d27 < 100% "tar/ext4magic-0.1.4.tar" < 100% "tar/backup.tgz" < 100% "tar/ext4magic-0.1.3.tar" < 100% "tar/ext4magic-0.1.2.tar" < 100% "tar/backup1.tgz" ROBI@LINUX:/tmp/test1 # diff log_vor log_nach > log_diff
In this file are also still further lines, and which at the start of line still another special character and a percentage stands, is for the option “- i” not of interest,only evaluates per line, which is cleanly enclosed between the double inverted commas. With a time window, in which have existed these files, and the list can recover the files by using ext4magic
ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso.3 -a 1286031255 -b 1286031279 -r -i log_diff
"log_diff" accept for inputfile
"RECOVERDIR" accept for recoverdir
Filesystem in use: testfile.iso.3
Using internal Journal at Inode 8
Activ Time after : Sat Oct 2 16:54:15 2010
Activ Time before : Sat Oct 2 16:54:39 2010
-------- RECOVERDIR/tar/ext4magic-0.1.4.tar
-------- RECOVERDIR/tar/backup.tgz
-------- RECOVERDIR/tar/ext4magic-0.1.3.tar
-------- RECOVERDIR/tar/ext4magic-0.1.2.tar
-------- RECOVERDIR/tar/backup1.tgz
ext4magic : EXIT_SUCCESSTo attentive readers will now be noticeable, it is only 5 files, it should be 6. The mystery solution, the 6. Inode was the directory (tar/), which was deleted also and was repaired automatically also.
The results of the Magic function, (particularly on ext3 with the old method of version 0.2.4) will result in not in every case always useful files. With some file types it is not to be cut ext4magic always possible the files to correct length. It is possible some files are too long or too short around or few zeros. Susceptibly to it at present e.g. are gzip files and Windows Office documents. A too long file will usually open a warning with will produce, will otherwise however normally function. Differently however to short files. They often cannot be opened, annoying with compressed formats, if more than one file is contained.
Some file types can be examined very well and fast over Plugins of the graphic file managers, as far as one has a Desktop system before itself. In addition e.g. count many document formats, pdf, HTML, PICTURES, and many the common Mulitmediatypen. The most common picture formats leave themselves fast and simply also “xv” examine. Special display formats often still leave themselves "display" examine, sometimes goes however without gimp nothing With text files it is often quite lengthy to sort and sight it. more or less carry out however good services.
In the following small collection some commands to examine some file types . In small FOR loops blocked thus fast times an enormous listing is examined for functioning files. Also little background knowledge, e.g. the open Office of documents are zip compressed, and one comes here fast to the goal. The content must be checked, and the files must be sorted to find out the important files and give them correct names
some commands to check the files
|
type |
command |
|---|---|
|
gzip |
gzip -t FILE.gz |
|
bzip2 |
bzip2 -t FILE.bzip2 |
|
zip |
zip -T FILE.zip |
|
xz |
xz -t FILE.xz |
|
7z |
7z t FILE.7z |
|
RAR |
rar t FILE.rar |
|
tar |
tar -tf FILE.tar >/dev/null |
|
cpio |
cpio -it < FILE.cpio >/dev/null |
|
arj |
unarj t FILE.arj |
|
Open Office Documents |
zip -T FILE.o[dt]? |
|
jpeg |
djpeg -gr -scale 1/8 -bmp FILE.jpeg > /dev/null |
Is particularly fatiguing, examine from audio and video files. Small scripts can help here to find out whether the file works. possible tools MPlayer, MEncoder and sox The following checks whether a video can played
for i in *
do
echo "$i"
mplayer -benchmark -nosound -vo null "$i" 2>/dev/null | grep BENCHMARK
doneAudio files, the following may help
for i in *
do
echo -e "\n$i"
sox "$i" -n stat
done
|
Ext4magic: Inode - Directory - Journal - Install - Time_Options - Histogram - Scenarios - Tips&Tricks - Manpage - Expert-Mode |