“리눅스 ext3 파일시스템에서 삭제된 파일은 복구 할 수 없다.” 라고
알고 계신 분들도 있지만 자료를 찾아보니 복구 가능하군요.
ext2 파일시스템은 간단하게 debugfs(ext2/ext3 file system debugger)툴로 복구할수 있었으나,
예) debugfs: dump /home/invain/linux-2.6.20.tar.gz
ext3 파일시스템에서는 Journaling Transaction Filesystem 구조로 인해
IBM에서 만든 sleuthkit 도구를 활용하여 블록정보를 얻어 계산하여 foremost 라는 툴로 복구 가능합니다.
먼저 필요한 유틸리티를 yum(YellowDog Update Manager; 윰이라 부릅니다.)으로 설치합니다.
root# yum install foremost
sleuthkit 은 yum을 통한 설치가 지원되지 않으므로, 아래와 같이 소스코드를 직접 컴파일하여 설치합니다.
http://www.sleuthkit.org/sleuthkit/desc.php
root# wget http://jaist.dl.sourceforge.net/sourceforge/sleuthkit/sleuthkit-3.0.1.tar.gz root# tar xvfz sleuthkit-3.0.1.tar.gz root# cd sleuthkit-3.0.1 root# ./configure --prefix=/usr ; make ; make install
복구하기
먼저 지워진 파일의 파티션 확인후
1) debugfs 툴로 복구할 파일의 블록정보 얻기
root# debugfs /dev/sdb2
debugfs: cd /home/user/ (지워진 파일의 경로로 이동)
debugfs: ls -d (지워진 파일의 목록출력)
5113273 (12) . 5079050 (4084) .. 2050 (508)
5113275 (28) 032612_0759_22.png 5113276 (28) 032612_0759_1.png
5113277 (28) 032612_0759_10.png 5113278 (28) 033012_0538_31.jpg
5113279 (36) 040312_0631_iDESKCMS64.png
5113398 (12) 2012
0 (28) 033012_0538_19.jpg 5113407 (28) 032612_0759_47.png
5113408 (36) 040312_0631_iDESKCMS62.png 5113409 (28) 033012_0538_49.jpg
5113410 (36) 040312_0631_iDESKCMS10.png 5113411 (28) 032612_0759_61.png
0 (36) 040312_0631_iDESKCMS8.png
5113413 (36) 040312_0631_iDESKCMS19.png 0 (28) 032612_0759_54.png
0 (36) 040312_0631_iDESKCMS42.png 0 (68) 032612_0759_66.png
0 (964) PIC780.png 1900545 (944) mobile-c.png
5113301 (28) 032612_0759_58.png 5113326 (92) 040312_0631_iDESKCMS25.png
5113286 (28) 032612_0759_31.png 5113384 (28) 032612_0759_5.png
5111959 (232) mobile-c100-100×150.gif 5113382 (80) 033012_0538_40.jpg
5113290 (52) 032612_0759_8.png
..이하 목록 생략
*저의 경우 파일번호가 5113398 인 2012 라는 폴더를 통채로 복구할거임.
2) imap 명령으로 BG 구하기 (block group; 파일 5113398의 블록그룹)
debugfs: imap 5113398
Inode 5113398 is part of block group 156
located at block 8323112, offset 0×0280
*파일번호 5113398의 블록그룹은 156
3) stats 명령으로 BPG 구하기 (Blocks per group; 그룹당 해당하는 블록넘버)
debugfs: stats
Filesystem volume name: /
Last mounted on:
Filesystem UUID: 9789df92-6ede-47f3-8a81-38dad297edc5
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 32768
Inode blocks per group: 1024
Filesystem created: Mon May 7 20:56:22 2012
Last mount time: Tue Jul 3 09:25:01 2012
Last write time: Tue Jul 3 09:25:01 2012
–More–
*그룹당 블록넘버는 32768
4) 지워진 파일의 블록범위 계산하기(범의를 계산해야 하는 이유는 아래의 참고자료 설명)
BG = 156
BPG = 32768
공식
(BG 곱하기 BPG) ~ ( (BG + 1) 곱하기 BPG -1)
대입하여 아래처럼 계산
156 x 32768 ~ 157 x 32767
계산된 블록범위 결과
5111808 ~ 5144419
5) 계산된 블록범위를 sleuthkit 으로 ‘block.dat’ 이름으로 덤프뜨기
root# blkls /dev/sda2 5111808-5144419 block.dat
6) foremost 툴로 복구시도
root# foremost -dv -t png -o ./ -i ../block.dat (반드시 빈 디렉토리에서 덤프파일 경로확인)
*주의! foremost 부주의한 사용시 파일시스템이 손상될수 있습니다.
root# foremost -dv -t png -o ./ -i ../block.dat
foremost: /usr/local/etc/foremost.conf: No such file or directory
Foremost version 1.5.7 by Jesse Kornblum, Kris Kendall, and Nick Mikus
Audit File
Foremost started at Fri Aug 17 18:03:03 2012
Invocation: foremost -dv -t png -o ./ -i ../block.dat
Output directory: /root/re/test
Configuration file: /usr/local/etc/foremost.conf
Processing: ../block.dat
|——————————————————————
File: ../block.dat
Start: Fri Aug 17 18:03:03 2012
Length: 13 MB (14573568 bytes)
Num Name (bs=512) Size File Offset Comment
0: 00000096.png 1 KB 49152 (983 x 11)
1: 00002064.png 169 B 1056768 (626 x 24)
2: 00002072.png 170 B 1060864 (625 x 24)
3: 00002080.png 13 KB 1064960 (210 x 59)
4: 00002112.png 53 KB 1081344 (IND BLK bs:=4096) (472 x 225)
5: 00002232.png 136 B 1142784 (192 x 39)
6: 00002240.png 81 KB 1146880 (IND BLK bs:=4096) (406 x 240)
7: 00002416.png 134 B 1236992 (123 x 46)
8: 00002424.png 401 B 1241088 (106 x 44)
9: 00002432.png 131 B 1245184 (156 x 18)
10: 00002440.png 151 B 1249280 (700 x 23)
….생략
Finish: Fri Aug 17 18:03:04 2012
81 FILES EXTRACTED
png:= 81
——————————————————————
Foremost finished at Fri Aug 17 18:03:04 2012
* rm -rf 로 지운 2012라는 폴더안의 81개의 .png 이미지 파일 복구됨.
root# ls
audit.txt (복구된 파일목록 로그) png(디렉토리 생김)
root# cd png
root# ls
00000096.png 00002456.png 00004704.png 00005040.png 00007216.png 00008592.png 00008688.png
00002064.png 00002960.png 00004760.png 00005048.png 00007224.png 00008600.png 00009488.png
00002072.png 00002968.png 00004768.png 00005056.png 00007232.png 00008608.png 00009568.png
00002080.png 00002976.png 00004776.png 00005064.png 00007240.png 00008616.png 00009648.png
00002112.png 00003848.png 00004784.png 00005688.png 00007248.png 00008624.png 00009728.png
00002232.png 00004080.png 00004960.png 00006192.png 00007256.png 00008632.png 00025328.png
00002240.png 00004280.png 00004968.png 00006552.png 00007264.png 00008640.png 00027288.png
00002416.png 00004288.png 00005000.png 00006968.png 00007272.png 00008648.png 00028336.png
00002424.png 00004296.png 00005008.png 00006976.png 00007888.png 00008656.png 00028376.png
00002432.png 00004304.png 00005016.png 00006984.png 00007896.png 00008664.png
00002440.png 00004464.png 00005024.png 00006992.png 00008256.png 00008672.png
00002448.png 00004584.png 00005032.png 00007000.png 00008584.png 00008680.png
파일이름이 바뀌었지만 대부분의 파일복구 확인!
*여러 파일들 한꺼번에 복구할때 (파일종류;확장자 마다 offset이 다름.)
root# foremost -dv -t png, jpg, gif, pdf, doc -o ./ -i ../block.dat
참고자료
펼치기
0. 주제
ext3 파일 시스템에서는 지워진 파일 복구가 왜 어려울까 ?
그리고 왜 중요한 시스템 파일은 백업을 해야 할까?
1. 들어가면서
지워진 파일을 복구 해야할 경우는 어떠한 OS를 사용하던, 누구나 한번쯤 경험해 본 일일 것입니다. 요즘 대부분의 리눅스 배포판은 Ext3 파일시스템을 기본으로 사용합니다. ext3 파일 시스템에서 파일을 복구 하는 것은 아주 힘든 일입니다. 필자는 가능성을 가지고 구글링을 하면서 하나의 문서를 발견하고 그 문서를 읽고는 더이상 찾지 않았습니다.
너무나도 좋은 내용이기에 어설프게 번역해서 본 강좌를 쓰려합니다.
본 강좌의 원문은 : 에서 확인 할 수 있고, 원 저작자의 동의 없이 편역한 것이므로 법적인 문제가 발생한다면, 삭제조치 하겠습니다.
2. 서론
우연히 rm 명령어에 잘못된 인수를 주거나 잘못된 파일을 지정하고, 엔터키를 누르고 조금의 시간이 지난후 실수 한것을 알며 가슴이 철렁해서 급하게 백업 데이터를 찾았지만, 없다는 사실을 알게 된 경험을 해 봤을 것입니다.
FAT, NTFS파일 시스템을 위한 복구(undelete)툴은 많이 있지만, Ext3파일시스템 복구 툴은 거의 없습니다.
Ext3파일시스템은 대부분의 리눅스 배포판의 기본 파일 시스템입니다. Ext3파일 시스템에서 복구가 어려운 것은 중요한 정보(파일 내용이 있는 위치 정보등)을 삭제해 버리기 때문입니다.
본 강자에서는 저수준(low-level)으로 복구가 어렵다는 것을 확인하고, 유효한 복구 방법을 찾아 보도록 하겠습니다. 복구를 위해 몇가지 오픈소스 툴을 이용 하지만, 기술적으로 완벽한 자동화는 어렵습니다.
3. 파일이 무엇일까
어떻게 복구하는지 알기 전에, 파일이 어떻게 저장되는지 알아보도록 하겠습니다.
일반적으로 파일시스템은 디스크 파티션에 위치합니다. 파티션은 일반적으로 512바이트의 섹터들로 구성됩니다.
파티션이 Ext3 파일 시스템으로 포멧될때, 연속적인 섹터들은 블록으로 묶여지며, 이 블록사이즈는 1,024에서 4,096의 범위를 갖습니다. 이 블록들은 다시 블록 그룹으로 묶이며 이 블록 그룹은 수십 수천개의 블록들으로 이뤄집니다. 각 파일은 3개(블록들, 아이노드들, 디렉토리 엔터리)의 주 위치 데이터가 저장되어 있습니다. 파일의 내용은 블록들에 저장되고, 이들은 배타적인 공간에 할당됩니다.
하나의 파일은 필요한만큼의 많은 블록들에 할당되며, 전형적으로 파일은 연속적인 블록들에 할당됩니다. 하지만, 항상 그런것은 아닙니다.
파 일에 관한 데이터는 아이노드구조(structure)에 저장됩니다. 이는 블록그룹의 시작부분인 아이노드 테이블에 위치합니다. 각 블록그룹에 포함될 수 있는 아이노드 수는 한정되어 있습니다. 파일에 관한 데이터는 마지막 수정시간, 마지막접근시간, 마지막 변경시간, 삭제시간 등의 시간데이터를 가지고 있습니다. 파일에 관한 데이터는 파일사이즈, 사용자 아이디, 그룹 아이디, 퍼미션들 그리고 파일내용이 저장된 블록주소가 저장되어 있습니다. 주소의 처음 12블록들은 아이노드와 간접블록이라고 불리는 외부 블록들의 추가 주소를 저장하고 있습니다. 만약 파일이 많은 블록들을 요구하고, 모든 주소가 하나의 간접 블록에 많을수 없다면, 더블 간접블록이 사용된다. 이 주소는 아이노드에 의 해 주어집니다. 이 더블간접블록의 내용에 대한주소 의 단일 간접블록은, 블록의 주소와 파일 내용을 포함합니다. 또한 하나이상의 포인터들의 층을 가진 아이노드는 세배 간접주소 입니다. 마지막으로 파일의 이름은 부모디렉토리의 블록에 위치하는 디렉토리 엔터리에 저장됩니다. EXT3디렉토리는 파일과 비슷하고 블록들은 디렉토리 리스트 구조를 포함합니다. 파일이름, 파일의 정보가 저장된 블록의 주소등의 메터데이터는 저장됩니다.
‘ls -i‘ 명령어를 이용하여 각 파일 이름에 대응하는 아이노드 주소를 알 수 있습니다.
디렉토리 엔터리, 아이노드, 블록들의 관계를 아래 그림에서 확인 할 수 있습니다.
새로운 파일을 생성할 때, 운영체제(OS)는 파일을 배정할 블록들과 아이노드를 선택합니다. 리눅스는 블록들과 아이노드를 부모의 디렉렉토리와 같은 블록 그룹에 배정하려 할 것입니다.
이 원인은 파일들을 같은 디렉토리와 함께두기 위함입니다. 다음에 삭제된 데이터를 쉽게 찾기 위해서 제한하는 것입니다.
EXT3 파일 시스템은 파일시스템의 정보데이터(metadata)를 업데이트 하기 전에 갱신하는 레코드인 저널(journal)을 가지고 있습니다. 시스템의 충돌이 일어난 경우, OS는 저널(journal)을 일고, 저널에 있는 트렌젝션을 재처리 또는 복구(roll back) 합니다. 그래서 각 블록의 메터데이터들을 검사하는 것 보다 복구는 빠르다. Ext2에서는 전체 데이터로 인덱스를 다시 생성하였기에 엄청난 시간이 소요되었습니다. 메터데이터 구조는 디렉토리항목, 저장된 파일이름 그리고 아이노드 포함됩니다. 저널은 업데이트된 모든 블록을 포함하고 있다. 변화된 것만 포함되는 것은 아닙니다. 새로운 파일이 저장되면, 저널은 디렉토리 항목과 아이노드가 포함된 블록들의 업데이트된 것을 포함합니다.
4. 삭제 절차
리눅스에서 Ext3 파일시스템의 파일을 지우면 몇몇 일들이 발생합니다.
(파일이 삭제되면 일반적인 리눅스 OS는 정확하게 어떤 일들이 발생한다는 것을 잊지마시기 바랍니다.) 잠시후, OS는 다음에 사용될 파일을 위해서 각 블록, 아이노드, 디렉토리 엔터리는 할당해제 합니다.
예전 Ext2 파일 시스템은 최소한의 접근이 일어납니다. 이 경우의 복구 절차는 간소합니다.
왜냐하면 아이노드는 블록의 주소를 가지고 있어 debugfs과 e2undel 같은 툴로 쉽게 재 생성 할 수 있었기 때문입니다. 이 일은 블록들이 새롭게 할당되거나, 원래 내용이 덥여쓰여지지 않는다면 가능한 일입니다.
Ext3에서의 더 많은 절차들이 복구를 더욱 어렵게 만듭니다. 블록이 할당해제될때, 파일 크기, 블록주소들이 아이노드에서 지워집니다. 이는 더이상 파일의 내용이 어디에 있는지 결정할 수 없게 만듭니다.
위 그림을 통해서 디렉토리엔터리, 아이노드, 블록들이 할당해제 되는 것을 알 수 있습니다.
5. 복구 시도
지금 까지 파일을 감싸고 있는 요소들과 파일이 삭제될때 지워지는 것을 알았습니다. 두가지 방식을 통해서 파일을 복구 해 볼것입니다. (백업데이터를 이용한 방법 제외)
첫 번째 방식은 응용프로그램 타입의 파일 이 삭제된 경우이고, 두번째 방식은 데이터가 삭제된 경우입니다.
방법에 관계없이 파일 시스템 사용을 중지해야 합니다. 이는 새로운 파일을 복구하려는 데이터 공간에 덮어 써버릴 수 있기 때문입니다. 시스템의 전원을 끄고 다른 리눅스 시스템에 장착하거나, 리눅스 CD로 부팅을 합니다.
첫 번째 할일은 두가지 방법 모두 지워진 파일의 아이노드 주소를 알아내야 합니다. 이는 debugfs 또는 The Sleuth Kit (TSK) 으로 알 수 있습니다. 여기서는 debugfs방법을 사용할 것입니다. debugfs는 대부분의 리눅스 배포판에 포함되어 있고 이는 파일시스템 디버거입니다.
debugfs를 실행시키기 전에 지워진 파일이 있는 파티션의 장치명을 알아야 합니다. 본 강좌의 예제에서는 CD로 부팅하였고, 지워진 파일은 /dev/sda7에 위치합니다.
# debugfs /dev/sda7
debugfs 1.37 (21-Mar-2005)
debugfs:
지워진 파일이 있는 디렉토리로 cd 명령어를 이용하여 이동 합니다.
debugfs: cd /home/doly/
ls -d 명령어는 디렉토리내의 할당되었고 지워진 파일을 보여줍니다.
삭제절차에서 지워지지 않았기 때문에 디렉토리엔터리 구조는 파일이름, 아이노드, 리스트를 저장한다는 것을 기억하시기 바랍니다.
삭제된 파일은 아이노드 번호가 “
debugfs: ls -d
415848 (12) . 376097 (12) .. 415864 (16) .bashrc
[...]
(28) oops.dat
복구하려는 파일은 /home/doly/oops.dat 이며, 이 파일의 아이노드는 415,926 인 것을 알 수 있습니다. (28)은 디렉토리 엔터리 구조가 28 bytes라는 것을 보여준다. 하지만, 이에 관한 것을 무시합니다.
6. 파일 조각 복구
첫번째 복구 방법은, 파일 조각이라고 불리는 방법이며 지워진 파일의 헤더를 이용한 방법입니다. 대부분의 파일 타입은 처음 바이트를 파일헤더로 가지고 있습니다. 본 복구 방법은 이 헤더를 이용하여 파일의 시작을 알아 냅니다. 예를들면, JPEG파일은 0xffd8으로 시작해서, 0xffd9 으로 끝납니다.
지워진 JPEG파일을 복구 하기 위해서는 각블록의 처음 두바이트를 비교하여 처음 두 바이트가 0xffd8인 것을 찾을 것입니다. 이런 블록을 찾으면 0xffd9 을 가지고 있는 블록또한 찾을 수 있을 것입니다. 위에서 찾은 블록들 사이의 데이터를 파일이라고 가정할 수 있습니다.
불행하게도, 모든 파일이 표준적인 푸터(footer)를 가지지는 않는다. 그래서 파일의 끝을 결정하기가 힘듦니다. 파일조각을 모으는 오픈소스 툴인 foremost와 몇 몇 상업적인 툴들을 이용하면 쉽게 가능합니다.
foremost같은 툴을 이용하여 모든 파일시스템을 조사한다면, 정상파일을 포함한 많은 파일들 찾을 것입니다. 이 경우 파일시스템의 크기가 작을때 실행하는 것이 좋습니다.
지워진 파일이 어디에 있는지에 따라 조사할 블록그룹의 데이터 사이즈를 제한 할 수 있습니다. 파일을 위해 할당된 아니노드들, 블록들은 같은 블록그룹에 위치 한다는 것을 기악하시기 바랍니다.
지워진 파일이 사용한 아이노드를 사용하여 그 아이노드가 포함된 블록그룹을 알수 있으며, 그 그룹만 조사하면 더욱 빨리 지워진 파일을 찾을 수 있습니다.
debugfs의 imap 명령어를 이용하여 아이노드가 속하는 블록그룹을 찾을 수 있습니다.
debugfs: imap
Inode 415926 is part of block group 25
located at block 819426, offset 0x0a80
TSK의 fsstat 명령어 또한 알려 준다.
# fsstat /dev/sda7
[...]
Group: 25:
Inode Range: 408801 – 425152
Block Range: 819200 – 851967
다음으로 블록그룹에서 삭제된 파일들의 블록들을 결정해야 합니다.
fsstat 의 결과로 알 수 있지만, 만약 debugfs를 사용한다면, 블록그룹 범위를 계산해야 합니다. stats명령어는 각 블록그룹에서 사용하는 블록수를 보여줍니다.
debugfs: stats
[...]
Blocks per group: 32768
[...]
블록그룹이 25라는 것을 위에서 찾았습니다. 이 블록 그룹의 범위는 819,200 (25 * 32,768) 에서 851,967 (26 * 32,768 – 1)인 것을 알 수 있습니다. 여기서 중점은, 파일 시스템 전체 대신에 128MB를 찾을 수 있다는 것입니다. 비록 파일을 이 블록에 찾지 못한다 하더라도, 모든 파일 시스템을 찾는 보다는 빠를 것입니다.
삭제된 파일은 할당되지않은 블록에 위치하기 때문에 데이터를 분석하여 할당되지 않은 블록들을 파일시스템으로 부터 뽑아냅니다. debugfs는 블록그룹에서 할당되지 않은 블록들을 뽑아내는 것을 지원하지 않습니다.. 그래서 TSK의 dls 툴을 사용합니다.
# dls /dev/sda7 819200-851867 /mnt/unalloc.dat
위의 명령은 블록그룹 25에서 할당되지 않는 블록들을 /mnt/unalloc.dat 파일으로 뽑아내는 명령입니다. 지워진 파일의 블록들을 덮어 써 버리지 않게 생성되는 파일이 다른 파일 시스템에 위치하는 것을 확신해야합니다. /mnt/unalloc.data 파일을 foremost을 이용하여 복구 합니다.
foremost는 설정된(이미 명시된) 파일타입의 파일을 복구 할 수 있습니다.
만약 foremost가 삭제된 파일의 헤더를 가지고 있지 않다면, 비슷한 파일을 찾아 비슷하게 설정파일을 편집해야 합니다.
다음과 같이 실행시킬 수 있다.
# foremost -d -i /mnt/unalloc.dat -o /mnt/output/
-d 옵션은 간접 블록을 검출하며, 그것들을 출력 파일에 포함하지 하지 말라는 옵션입니다.
/mnt/output/ 은 복구되는 파일들을 저장할 경로입니다.
만약에 지워진 파일이 여기에 없다면, 일부 블록그룹 대신 파일 시스템의 전체의 할당되지 않은 블록들에서 찾을 수 있습니다.
7. 저널기반 복구 방법
두번째 방법은 저널을 이용한 파일 복구 방법이다. 아이노드 업데이트는 저널의 처음 기록임을 알고 있습니다. 그러나 중요한 개념은 아이노드의 엔터리 블록은 저널에 기록된다는 것입니다. 그러므로, 아이노드가 업데이트 될 때, 저널은 다른 아이노드 저장공간에 같은 블록을 복사하고 있습니다. 예전판에는 삭제한 파일들의 아이노드는 저널에 있을 것입니다. 왜냐하면 삭제되기전에 다른 파일이 업데이트 되었기 때문입니다. 가장 쉬운 방법은 debugfs 에서 logdump -i 명령으로 예전판의 아이노드를 찾는 것입니다.
debugfs: logdump -i
Inode 415926 is at group 25, block 819426, offset 2688
Journal starts at block 1, transaction 104588
FS block 819426 logged at sequence 104940, journal block 2687
(inode block for inode 415926):
Inode: 415926 Type: regular Mode: 0664 Flags: 0×0
User: 500 Group: 500 Size: 2048000
[...]
Blocks: (0+12): 843274 (IND): 843286
[...]
이경우, 예전의 아이노드 복사본을 찾을 수 있고, 파일의 내용이 들어있는 블록들은 마지막 라인에 보여질 것입니다. 마지막 라인은 843,274블록을 시작으로 12블록이 지워진 파일임을 알 수 있습니다. 이 파일은 크고 간접블록을 요구합니다. 간접블록은 843,286에 위치합니다. 모든 블록이 연속적이고, 조각나 있지 않아야 한다면 이 복구 방법은 좋은 방법입니다.
843,286블록은 근접된 블록 주소를 가지고 있습니다. 그래서 예전판은 근접하는 블록이 어디인지 알려 줍니다.
logdump -b 명령을 사용하여, 저널을 복사 할 수 있습니다.
debugfs: logdump -b 843286 -c
불행하게도 원래의 블록포인트 리스트리스트가 포함된 블록의 복사본을 찾을 수 없습니다.
만약 이 파일의 복구를 원한다면, 다음블록인 843,287블록에 저장되어 있을 것이라고 추측할 수 있습니다.
더 전진적인 접근은 블록들의 현재 할당된 블록은 제외하고 찾는 것입니다. 이 데이터는 dd 또는 Linux Disk Editor 같은 툴을 사용하여 추출할 수 있습니다. 저널은 TSK에서 제공하는 jls , jcat등의 툴을 사용하여 검색 할 수 있습니다.
8. 결론
EXT3에서 파일 복구는 하찮은 문제가 아닙니다. 파일의 백업에 대한 의식을 강화해야 합니다.
파일이 조각나지 않았다면, 헤더를 찾아 분석하는 것이 좋은 방법입니다. 그렇지만, 이 방법은 간접블록은 무시하며, 파일의 끝을 알 수 없는 경우가 많습니다. (모든 파일이 표준적인 푸터(footer)를 가진것은 아닙니다.) 저장시에 로컬블록 릅으로 제한하는 방법은 지운 파일을 찾는데 도움이 될것입니다. 만약 파일들이 지워진 파일과 근접해있고 최근에 업데이트되고 지난판의 아이노드가 있다면 저널은 유용합니다. 하지만, 항상 보증되지 않고, 파일의 간접 불럭이 없어야 합니다.
9. 마치며…(역자주)
원문을 번역하면서 테스트를 진행하였습니다. 지운 파일이 일반적인 웹문서이고 웹문서에서 헤더와 푸터을 명시했다면, 복구는 가능했습니다. 하지만, 명시하지 않은 파일들은 데이터 덩어리에서 찾아내야 하는 곤욕을 치루곤 합니다. ext3 파일 시스템어서는 백업이 가장 중요하며, 백업을 못했고 지워진 몇개의 데이터를 복구 하는 시간이 그 데이터를 새롭게 생성하는 시간보다 적게 소요 된다고 판단된다면 한번 도전해 볼 만 합니다.
출처 : http://www.superuser.co.kr
