백업수퍼블록을 이용한 파일시스템 복구하기

백업수퍼블록을 이용한 파일시스템 복구하기

 

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

 

 

 

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

 

 

 

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

 

 

 

 

 

이 방법은 e2fsck의 -b옵션을 이용한 방법이며 "-b 백업수퍼블록번호"를 함께 주면 됩니다.

 

 

 

 

먼저 백업수퍼블록에 대한 이해를 드리기 위하여 간단한 설명을 드리도록 하겠습니다.

 

 

 

 

 

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

 

 

 

 

 

/dev/sda3파일시스템을 대상으로 작업한 다음 실행결과를 보십시요.

 

[root@su250 ~]# dumpe2fs /dev/sda3 | grep superblock dumpe2fs 1.41.3 (12-Oct-2008)   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 [root@su250 ~]#

 

위의 예는 /dev/sda3이라는 파일시스템의 수퍼블록과 백업수퍼블록의 위치를 확인한 예입니다.

 

 

 

정리하면 다음과 같습니다.

 

 

 

 

 

        - 메인수퍼블록 : 0번 블록에 위치함.

        - 첫번째 백업수퍼블록 : 32768번 블록에 위치함.

        - 두번째 백업수퍼블록 : 98304번 블록에 위치함.

        - 세번째 백업수퍼블록 : 163840번 블록에 위치함.

        - 네번째 백업수퍼블록 : 229376번 블록에 위치함.

 

여기서 메인수퍼블록(Primary superblock)은 0번 블록에 위치하며 파일시스템의 맨 앞부분에 위치합니다.

 

 

 

메인수퍼블록에는 파일시스템의 매우 중요한 정보들(이들 정보에 대해서는 이 웹사이트(www.linux.co.kr)의 dumpe2fs 강좌 참조바람.)이 저장되어 있으며 이 메인수퍼블록이 손상되면 파일시스템이 정상 작동되지 않습니다.

 

 

 

 

 

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

 

 

 

우리 같은 시스템관리자들은 이런 상황에 놓여졌을 때에는 백업수퍼블록을 이용할 수 있어야 합니다.

 

 

 

즉, 메인수퍼블록이 손상되었을 경우에는 백업수퍼블록을 이용하여 메인수퍼블록을 복구할 수 있습니다.

 

 

 

왜냐하면 백업수퍼블록에는 메인수퍼블록의 백업본이 존재하기 때문이며, 또한 위의 예에서 보시는 바와 같이 여러 개의 백업수퍼블록이 존재하기 때문에 이 중 하나를 가지고 메인수퍼블록을 복구할 수 있으면 됩니다.

 

 

 

 

 

즉, 메인수퍼블록이 손상되었을 때에 첫번째 백업수퍼블록을 이용하여 복구한다.

 

 

 

 

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

 

 

 

 

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

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

……

 

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

 

 

 

결론적으로 우리는 백업수퍼블록이 존재하고 있는 블록번호를 알고 있어야 합니다.

 

 

 

이것을 확인하는 방법은 위의 예와 같이 “dumpe2fs /dev/sda3 | grep superblock”으로 확인할 수 있습니다.

 

 

 

 

 

결론적으로 e2fsck를 이용하여 백업수퍼블록을 이용하여 복구하는 방법은 다음과 같습니다.

 

 

 

 

 

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

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

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

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

 

        … 이상과 같이 백업수퍼블록을 이용하여 복구할 수 있습니다.

 

 

 

 

 

만약 복구하는 과정에서 너무 많은 “Fix?”와 같은 질문이 지속된다면 위의 옵션 다음에 -y옵션과 -p옵션을 함께 사용하는 것도 좋은 방법입니다.

 

 

 

 

 

즉, -y옵션은 모든 질문에 yes라고 자동응답을 하는 것이며, -p옵션은 자동복구모드로서 사용자에게 별도의 질문 없이 그냥 자동복구를 하는 모드입니다.

 

 

 

즉, 다음과 같은 방법의 사용도 권장할 만한 방법입니다.

 

 

 

 

 

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

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

        - 첫번째 백업수퍼블록 이용한 복구 : e2fsck -b 163840 -y /dev/sda3

        - 첫번째 백업수퍼블록 이용한 복구 : e2fsck -b 229376 -y /dev/sda3

 

이와 같은 방법으로 복구를 하면 됩니다.

 

 

 

 

 

이번에는 /dev/hdc2파일시스템을 대상으로 작업을 해보겠습니다.

 

 

 

앞의 복구방법보다 훨씬 강력한 방법으로 -f옵션을 추가하여 강제복구를 하는 다음과 같은 방법도 있습니다.

 

 

 

 

 

[root@su249 ~]# e2fsck -b 98304 -f -y /dev/hdc2 dumpe2fs 1.41.3 (12-Oct-2008) Superblock has an invalid ext3 journal (inode 8). Clear? yes   *** ext3 journal has been deleted - filesystem is now ext2 only ***   Resize inode not valid.  Recreate? yes   Pass 1: Checking inodes, blocks, and sizes Root inode is not a directory.  Clear? yes   Inode 39, i_blocks is 90032, should be 90024.  Fix? yes … … 이하생략

 

만약 ext3파일시스템을 복구하려고 한다면 앞에서 사용했었던 -j옵션을 다음과 같이 함께 사용하시기 바랍니다.

 

 

 

보다 효과적인 복구가 가능해 질 것입니다.

 

 

 

 

 

[root@su249 ~]# e2fsck -b 98304 -j ext3  -y /dev/hdc2 dumpe2fs 1.41.3 (12-Oct-2008) Superblock has an invalid ext3 journal (inode 8). Clear? yes   *** ext3 journal has been deleted - filesystem is now ext2 only ***   /backup was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes Root inode is not a directory.  Clear? yes

 

즉, 위의 예는 /dev/hdc2파일시스템이 ext3타입이기 때문에 -j옵션을 사용하여 ext3타입으로 지정하였고 -y옵션을 사용하여 모든 질문에 yes라고 답하도록 하였으며 -b옵션에는 두번째 백업수퍼블록을 이용하여 복구를 시도한 예입니다.

 

 

 

 

 

참고로 mke2fs로 파일시스템을 생성한 후에는 종종 “lost+found”라는 디렉토리가 생성이 됩니다.

 

 

 

이 디렉토리는 파일시스템의 점검작업 결과로 연결되지 않은 파일에 대한 정보를 저장하고 있는 장소입니다.

 

 

 

즉, 파일명과 파일의 위치가 정확하게 파악되지 않아서 임시로 보관해둔 곳입니다.

 

 

 

따라서 e2fsck로도 복구되지 않은 파일들은 이 디렉토리에 보면 숫자로 된 파일들이 다수 존재하고 있음을 보실 수 있을 것입니다.

 

 

 

이 파일들을 cat이나 vi등으로 열어보면 일반적인 파일내용과 거의 유사함을 알 수 있습니다.

 

 

 

 

 

[root@su249 backup]# ls -l total 1100 drwx------ 7409 root root 1122304 Jan  5 18:08 lost+found [root@su249 backup]# [root@su249 backup]# [root@su249 backup]# [root@su249 backup]# cd lost+found/ [root@su249 lost+found]# [root@su249 lost+found]# ls -l | more total 1144920 -rw-r--r-- 1 root       root              61002 Oct  4  2009 #1795281 -rw-r--r-- 1 root       root               9185 Oct  3  2009 #1795282 -rw-r--r-- 1 root       root              20168 Sep  5  2009 #1795283 -rw-r--r-- 1 root       root             134642 Aug 19  2009 #1795284 -rw-r--r-- 1 root       root              73685 Aug  3  2009 #1795285 -rw-r--r-- 1 root       root              72773 Jul 12  2009 #1795286 -rw-r--r-- 1 root       root               1730 Jul 13  2009 #1795287 -rw-r--r-- 1 root       root              50765 Jul 13  2009 #1795288 -rw-r--r-- 1 root       root              91953 Jul 13  2009 #1795289 -rw-r--r-- 1 root       root             185774 Oct 11  2009 #1795290 -rw-r--r-- 1 root       root              55479 Aug 23  2009 #1795291

 

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

 

 

 

필자는 파일시스템 복구작업을 현명하게 하는 것도 중요하지만 데이터의 백업이 가장 우선시 되어야 한다고 강조하고 싶습니다.