BACKRUSH  유닉스명령  다음  자료실  Ascii Table   원격접속  달력,시간   프로세스  
지하철노선   RFC문서   SUN FAQ   SUN FAQ1   C메뉴얼   PHP메뉴얼   너구리   아스키월드 아이피서치

글쓴이: linu e2fsck명령어 조회수: 1456


e2fsck명령어는 fsck명령어의 확장명령어라고 할수 있으며, 리눅스에서 사용가능한 거의 모든 종류의 파일시스템("ext2", "ext3", "ext4" 등)의 점검과 복구를 할수 있는 명령어이다.

파일시스템 오류로 인하여 시스템 부팅이 정상적으로 되지 않을 경우에 이 명령어를 이용하여 파일시스템의 오류를 수정하고 정상적으로 부팅하는 경우도 있다.

-. e2fsck종료코드

0 = 에러없이 정상적인 종료.

1 = 파일시스템을 복구하였음.

2 = 파일시스템이 복구되었으며 시스템이 재부팅되어야함.

4 = 작업대상 파일시스템에 문제가 있으나 복구하지 않고 그대로 두었음

8 = 실행에러

16 = 사용법(Usage)또는 문법(Syntax)에러를 의미

32 = e2fsck작업이 사용자에 의해서 취소(Cancle)되었음

128 = 공유 라이브러리(Shared library)에러



-. e2fsck에서 점검하는 실제항목들

1. inodes점검

2. blocks점검

3. sizes점검

4. 디렉토리구조 점검

5. 디렉토리 연결성점검

6. 파일링크 정보 점검

7. 전체파일 개수 점검

8. 전체블록수중 사용중인 블록 점검 등


[root@os1 ~]# e2fsck -f -j ext3 /dev/sdb2

e2fsck 1.39 (29-May-2006)

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/sdb2: 11/50304 files (9.1% non-contiguous), 1664/100406 blocks


-. 백업수퍼블록을 이용한 파일시스템 복구하기(-b)

만약 e2fsck로 파일시스템이 자동복구 되지 않을 경우에는 백업수퍼블록을 이용하여 복구해주어야 한다.

이 방법을 이용하면 물리적으로 문제있는 부분 이외에는 거의 대부분의 경우 데이터복구를 할수 있다.

단, 리눅스의 파일시스템구조와 수퍼블로그이 정확한 개념, 그리고 백업수퍼불록의 위치를 알아야만 가능한 방법이다.



-b옵션에 "백업수퍼블록번호"를 함께 주면 된다.

-b "백업수퍼블록번호"

리눅스파일시스템은 블록그룹(Block group)이라는 것으로 기본구조를 이루고 있다.

아래는 /dev/sdb파일시스템을 대상으로 수퍼블록과 백업수퍼블록의 위치를 확인한것이다.

[root@os1 ~]# dumpe2fs /dev/sdb | grep superblock

dumpe2fs 1.39 (29-May-2006)

Primary superblock at 0, Group descriptors at 1-1

Backup superblock at 32768, Group descriptors at 32769-32769

Backup superblock at 98304, Group descriptors at 98305-98305

Backup superblock at 163840, Group descriptors at 163841-163841

Backup superblock at 229376, Group descriptors at 229377-229377

메인수퍼블록 = 0

첫번째 백업수퍼블록 = 32768

두번째 백업수퍼블록 = 98304

세번째 백업수퍼블록 = 163840

네번째 백업수퍼블록 = 229376



메인수퍼블록은 0번블록에 위치하며 파일시스템의 맨 앞부분에 위치한다. 메인수퍼블록에는 파일시스템의 매우 중요한 정보들이 저장되어 있어 이부분이 손상되면 파일시스템이 정상 작동되지 않는다.

따라서, 메인수퍼블록이 손상되었을 경우에는 그 파일시스템에 존재하는 모든 파일들에 대한 읽기/쓰기가 불가능해진다.

백업수퍼블록에는 메인수퍼블록의 백업본이 존재하기 때문에 메인수퍼블록이 손상되었을경우 백업수퍼블록을 이용하여 메인수퍼블록을 복구할수 있다.



따라서 메인수퍼블록을 복구하는 순서를 본다면,

첫번째 백업수퍼블록으로 복구되지 않을경우 두번째 백업수퍼블록으로 복구한다.

두번째 백업수퍼블록으로 복구되지 않을경우 세번째 백업수퍼블록으로 복구한다.

세번째 백업수퍼블록으로 복구되지 않을경우 네번째 백업수퍼블록으로 복구한다.

생략....



이상과 같이 파티션(파일시스템)의 용량이 크면 클수록 백업수퍼블록의 개수도 많아지게 된다.

백업수퍼블록을 이용하여 메인수퍼블록을 복구하려할 경우 백업수퍼블록의 블록번호를 알고 있어야한다.

위에서 본것과 같이 백업수퍼블록의 블록번호를 확인하려면 dumpe2fs /dev/sdb | grep superblock명령어를 사용하면 된다.



>백업수퍼블록을 이용하여 메인수퍼블록을 복구하는 방법

첫번째 백업수퍼블록을 이용한 복구 : e2fsck -b 32768 /dev/sdb

두번째 백업수퍼블록을 이용한 복구 : e2fsck -b 98304 /dev/sdb

세번째 백업수퍼블록을 이용한 복구 : e2fsck -b 163840 /dev/sdb

네번째 백업수퍼블록을 이용한 복구 : e2fsck -b 229376 /dev/sdb

생략...



복구하는 과정에서 너무 많은 "FIx?" 와 같은 질문이 반복된다면, -y옵션과 -p옵션을 함께 사용하는 것이 좋다.



메인수퍼블록을 복구 할때 -f옵션을 함께 사용하면 보다 강력한 강제복구를 수행하게 된다.

[root@os1 ~]# e2fsck -f -j ext3 -b 32768 /dev/sdb -y

e2fsck 1.39 (29-May-2006)

/dev/sdb is mounted.



WARNING!!! Running e2fsck on a mounted filesystem may cause

SEVERE filesystem damage.



Do you really want to continue (y/n)? yes



Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

Free blocks count wrong for group #0 (23981, counted=17397).

Fix? yes



Free blocks count wrong (249499, counted=242915).

Fix? yes



Free inodes count wrong for group #0 (16373, counted=16157).

Fix? yes



Free inodes count wrong (131061, counted=130845).

Fix? yes





/dev/sdb: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdb: 227/131072 files (0.4% non-contiguous), 19229/262144 blocks

사용한 명령어를 살펴보겠다.

e2fsck : 파일시스템 점검/복구

-f : 강제 점검/복구

-j ext3 : 파일시스템이 ext3형식임을 지정

-b 32768 : 블록번호 32768인 첫번째 백업수퍼블록을 이용하여 메인수퍼블록을 복구

/dev/sdb : 복구하려는 파일시스템(장치)

-y : "Fix?"에 무조건 yes라고 응답하도록 설정



#mke2fs혹은 mkfs명령어를 이용하여 파일시스템을 생성한후에 "lost+fount"라는 디렉토리가 생성된다. 이 디렉토리는 파일시스템의 점검작업 결과로 연결되지 않은 파일에 대한 정보를 저장하고 있는 장소이다.

파일명과 파일위치가 정확하기 파악되지 않아서 임시로 보관해둔곳이다. 따라서 e2fsck로도 복구되지 않은 파일들은 이 디렉토리에 보면 숫자로 된 파일들이 다수 존재하고 있음을 볼수 있을것이다. 이 파일들은 cat이나 vi등으로 열어보면 일반적인 파일내용과 거의 유사함을 알수 있다.

따라서 불가피한 경우에는 "lost+found"내에 있는 숫자로 된 파일들을 대상으로 하나씩 복구해야 하는 경우도 있다.

관련글 : 없음 글쓴시간 : 2020/02/27 23:28 from 122.32.218.68

  조직의 보안 정책에서 인증되지 목록보기 새글 쓰기 지우기 응답글 쓰기 글 수정 cmd 에서 dns 바꾸기  
BACKRUSH  유닉스명령  다음  자료실  Ascii Table   원격접속  달력,시간   프로세스  
지하철노선   RFC문서   SUN FAQ   SUN FAQ1   C메뉴얼   PHP메뉴얼   너구리   아스키월드 아이피서치