Ext3 filesystem’de silinmiş dosyaları kurtarmak için uygulanabilecek birkaç farklı yöntem var.

Yazının devamında, bence en başarılı olan yöntemi aktaracağım sizlere.

Bu yöntemi uygulamak için kullanacağımız 3 program var.  Bunlar:

foremost , blkls (sleuthkit package) , debugfs (e2fsprogs package)

debugfs uygulaması sanırım çoğu dağıtımda işletim sistemine gömülü geliyor.

Büyük ihtimalle diğer iki uygulamayı derlemeniz gerekecek. Yukarıdaki link’lerden kaynak kodlarını indirerek uygulamaları derleyebilirsiniz.

blkls, foremost ve debugfs uygulamalarını edindikten sonra işleme başlayabiliriz.

Not:  Yanlışlıkla sildiğiniz dosyayı geri döndürmye başlamadan önce yaptığınız her hareket (kullanacağımız uygulamaları kurmak, Linux’u reboot etmek, konfigürasyon değişkliği yapmak, vb.) dosyanın kayıpspz geri dönme ihtimalini azaltır. Bu yüzden gerekli uygulamaları testi kırılmadan kurmak doğru bir yöntem olabilir.

Örneğin /tmp klasöründeki tux.pdf dosyasını silelim.

[root@testserver ~]# ls -la /tmp/

total 776

drwx—— 2 root     root      16384 Mar 30 14:33 lost+found

srwxr-xr-x 1 root     root          0 Mar 30 15:51 mapping-root

drwx—— 2 temp_adm temp_adm   4096 Apr 27 08:38 ssh-HteHU16134

-rw-rw-r– 1 temp_adm temp_adm 770042 Nov  2  2006 tux.pdf

[root@testserver ~]# rm /tmp/tux.pdf

rm: remove regular file `/tmp/tux.pdf’? y

Artık dosyamız yok. Ama geri getirmek istiyoruz.

Öncelikle dosyamızın hangi partition’da ve hangi disk’de olduğunu öğrenelim.

[root@testserver ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda3              20G  3.1G   17G  16% /

/dev/sda6             5.9G  141M  5.7G   3% /tmp

/dev/sda5             9.7G  151M  9.5G   2% /home

/dev/sda2              30G  173M   29G   1% /u01

/dev/sda1             190M   12M  177M   7% /boot

tmpfs                 2.0G     0  2.0G   0% /dev/shm

Yukarıda görüldüğü gibi tmp /dev/sda6 diskinde.

Şimdi debugfs komutuyla yanlışlıkla sildiğimiz dosyanın inode tablosundaki yerini bulalım.

[root@testserver ~]# debugfs /dev/sda6

debugfs 1.39 (29-May-2006)

debugfs:  ls -d

2  (12) .    2  (12) ..    11  (20) lost+found    786433  (20) .ICE-unix

163841  (20) .font-unix    753665  (164) ssh-HteHU16134

<98305> (140) tux.pdf <98307> (120) ccG5AR0k.o   <98309> (20) cc3HK5qV.ld

<98310> (80) ccWyJYQv.le   <98311> (20) ccYQe4Ju.ld

<98312> (40) ccgXh5Vg.le   <1146881> (20) orbit-root

98308  (68) mapping-root   <294913> (24) ssh-xWYtZ14637

<524289> (24) vmware-config1    98306  (3780) .vmware-deploy.ERRORED

<720897> (3728) VMwareDnD   <98309> (3708) sh-thd-1269995942

debugfs:

debugfs:

debugfs:

debugfs:

debugfs:  imap <98305>

Inode 98305 is part of block group 3

located at block 98691, offset 0×0000

debugfs:

debugfs:

debugfs:

debugfs:  stats

Filesystem volume name:   /tmp

Last mounted on:          <not available>

Filesystem UUID:          e6eb7744-a1e6-4538-b444-352f8922fdf9

Filesystem magic number:  0xEF53

…

…

Blocks per group:         32768

..

..

debugfs:

debugfs:

debugfs:  quit

debugfs komutuyla elde ettiğimiz verilerden yararlanarak silinen dosyanın bulunduğu block grup’daki tüm veri çekerek dosyayı bulmaya çalışacağız. Block grubun  başlangıç ve bitiş değerini ifade eden 2 değere ulaşmaya çalışacağız.

Başlangıç değerini hesaplamak için: (Block Group * Blocks Per Group)

Bitiş değerini hesaplamak için : ((Block Group + 1) * Blocks Per Group -1)

Bu mantıkla örneğimizdeki değerlerimiz:

3 * 32768  =  98304   ve

4 * 32767  = 131068   olacaktır.

blkls komutuyla bulduğumuz değerler arasındaki tüm veriyi bir dosyaya yazdıracağız.

Dikkat!!: Burada dikkat edilmesi gereken nokta blkls komutunun otput dosyası, kurtarılmaya çalışılan dosyanın bulunduğu partition’a yazılmamalıdır. Hatta mümkünse bu dosya harici bir diske yazılmalıdır.

[root@testserver ~]# blkls /dev/sda6 98304-131068 > /home/emre/recover.dat

Sıra, recover dat dosyasından aradığımız dosya tipindeki veriye/verilere ulaşmaya geldi.

Öncelikle bulunacak (umarım J) dosyaların yazılacağı bir klasör oluşturalım.

[root@testserver ~]# mkdir /home/emre/rescue

foremost komutuyla recover.dat dosyasının içeriğinde pdf hash’lerini tarayarak eşleşen veri kümelerini /home/emre/rescue klasörüne yazdıracağız.

root@testserver ~]# foremost -dv -t pdf -o /home/emre/rescue/ -i /home/emre/recover.dat

Foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus

Audit File

Foremost started at Tue Apr 27 09:43:04 2010

Invocation: foremost -dv -t pdf -o /home/emre/rescue/ -i /home/emre/recover.dat

Output directory: /home/emre/rescue

Configuration file: /usr/local/etc/foremost.conf

Processing: /home/emre/recover.dat

|——————————————————————

File: /home/emre/recover.dat

Start: Tue Apr 27 09:43:04 2010

Length: 122 MB (128425984 bytes)

Num      Name (bs=512)         Size      File Offset     Comment

0:      00070632.pdf         755 KB        36163584

**|

Finish: Tue Apr 27 09:43:05 2010

1 FILES EXTRACTED

pdf:= 1

——————————————————————

Foremost finished at Tue Apr 27 09:43:05 2010

Foremost komutunun çıktısından görüldüğü gibi, komut 1 adet pdf hashing’I tespit etti.

/home/emre/rescue/ klasörünün içeriğine baktığımızda pdf isimli klasörün altında 00070632.pdf isimli bir pdf dosyası var.

Ve bu dosya kuvvetle muhtemel yanlışlıkla sildiğimiz tux.pdf dosyasının ta kendisi.

[root@testserver ~]# tree /home/emre/rescue/

/tmp/rescue/

|– audit.txt

`– pdf

`– 00070632.pdf

foremost komutunu kullanırken –t parametresi ile belirttiğimiz dosya tipleri ön tanımlı olarak şunlar olabilir: jpg, gif, png, bmp, avi, exe, mpg, wav, riff, wmv, mov, pdf, ole, doc, zip, rar, htm, cpp, pst, vb… Şayet tanımlı dosya tipleri dışında bir dosya kurtarmaya çalışıyorsanız  /usr/local/etc/foremost.conf dosyasına bazı eklemeler yapmanız gerekecektir.

Last night I made a test for making a comparison between ext2, ext3 and reiser file systems about missing (!) disk spaces.

Basically I created 3 disk partitions with 1 gb size and formatted them with ext2, ext3 and reiser file system types. Then mounted them to folders same with filesystem names. The result df -h output is as below:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1            1004M   20K  953M   1% /ext2_fs
/dev/sdb2            1004M   17M  937M   2% /ext3_fs
/dev/sdb3            1020M   33M  988M   4% /reiser_fs

As you can see both ext2 and ext3 file systems are reserved 50 megabytes at 1 gigabyte disk partition.
This means 5% of disk is missing!!!

Calm down, here is the reason: (man tells everything to us )

This  reserved disk area avoids fragmentation,  and  allows  root-owned  daemons, such  as  syslog,  to continue to function correctly after on-privileged processes are prevented from writing to the filesystem.  The default percentage is 5%.
This means if you format a 300GB disk with ext2 or ext3, you will lost about 15GB for root owned daemons as default.

But you can modify this ratio by using tune2fs command.

For instance, after umounting the partition, you may run tune2fs command as below for decreasing reserved block at /dev/sdb2 partition to 1%:

tune2fs -m 1 /dev/sdb2

You may sea the result bye typing

tune2fs -l /dev/sdb2

and comparing ” block count” and “reserved block count” values.

I want to remind a little point about tune2fs. tune2fs tool can be used just for ext2 and ext3 file systems.
If you want to use a tool like tune2fs for resier file system you have to use reiserfstune tool.
But you have to consider that there is not a parameter for setting reserved disk percentage for reiserfs.