Root Filesystem 손상과 복구

서론

몇 주전, 집에 있는 서버의 전원이 내려갔다.
UPS의 전원 공급 선이 접촉 불량으로 전력 공급이 원활하지 못했기 때문이다.

물론 문제를 해결하고 전원을 다시 공급했지만, 개발 서버만 자동 복구에 실패했다.
처음에는 전원을 공급하지 못한 기간이 길었음을 의심했다. (약 1주일)

이는 보드에 내장되어 있던 CR2032 배터리가 방전되어 보드 내부에 있는 롬 플래시에 전원을 공급하지 못했을 수도 있기 때문이였다.
롬 플래시는 휘발성이므로 배터리를 탈착하는 행위를 통해 전원 공급을 해주지 못하면 데이터가 휘발되어 부트 프로파일이 날아가게 된다.

하지만, 실제로 들어가서 확인해보니 이야기가 달라졌다.
개발서버에 모니터를 연결하니 Emergency Shell이 나를 반겨주었다.

dmesg 명령을 통해 원인을 살펴보니, 원인은 File System 체크 중 unexpected inconsistency가 발생한 것이였다.

당연히 File System에서 Failure가 발생한 이유는 마운트가 정상적으로 해제되기도 전에 강제로 전원을 끊어버렸기 때문일 터였다.

이제 복구 할 시간이다.

fsck는 Partition/File System 복구의 만능 도구다. 이것을 사용해서 복구 할 것이다.
/dev/sda~가 아닌 /dev/mapper/~-root에서 Failure가 발생했으므로, 해당 부분을 잡는다.

fsck -fy /dev/mapper/~-root 명령어를 통해 File System을 자동으로 복구한다.

일단, orphaned inode 리스트를 바로 잡아준다.

마지막으로, 여러 절차를 거쳐 File System 복구를 끝낸다.

File System 복구가 끝났다면, 재부팅한다.

만약 부팅시 fsck로 File System을 체크해서 문제가 없다면 부팅이 정상적으로 될 것이다.

부팅이 정상적으로 되면, Service의 Failure를 점검한다.
또한, S.M.A.R.T를 통해 Reallocated Sector가 발생하진 않았는지 확인한다.
Docker 위에 작동하는 Service는 자동으로 복구되도록 해놓았으므로, 로그만 확인 해주었다.

어떤 원리로 Failure가 발생했는지는 몰라도 원인은 확실히 전원 공급의 실패일 것이다.
하지만 무슨 원리로 문제가 발생했는지 명확히 안다면, 유사한 상황에 유연하게 대처 할 수 있을 것이다.

Linux의 File System에서 사용되는 자료구조다.
다양한 Unix-style File System (ZFS, btrfs, etc.)에서 전부 사용된다.

chmod를 통해서 권한 설정을 할 때, 이 inode에 권한 정보가 저장되는 것이기도 하다.

Linux를 통해 Directory를 돌아다니다 보면 lost+found 라는 폴더를 찾을 수 있을 것이다.
이게 무엇일까?

아까 부팅시에 fsck로 File System을 체크한 것을 알 수 있었을 것이다.
fsck가 체크 도중 orphaned inode를 발견하고 directory를 하나 생성해 모아 둔 것이다.

한편, 어떤 프로세스가 해당 파일을 열고 있는 상태에서 파일을 지워버리면 어떻게 될까?

Windows는 오류를 내보내고 삭제를 거부한다.

하지만 Linux는 그대로 지워버리는데, 이는 데이터는 남겨두지만, File System의 inodes 리스트에서 분리만 시켜둔 것이다.
그래서 파일 삭제 후, ls 같은 명령으로 확인해보면 리스트에서 바로 삭제되어 있는 것을 확인 할 수 있다.

그럼 분리시킨 파일의 inode는 뭐라고 부를까?

이게 바로 orphaned inode인 것이다.

orphaned inode는 이런 일 뿐만 아니라 다양한 이유로 발생한다.
File System Corruption이 발생 (Power-loss와 같은 다양한 이유)하게 되면,
이 inodes tree가 깨지는 일이 발생 할 수 있다.

그래서 부모 inode로부터 끊어진 자식 inode가 통째로 orphaned inode가 되어버리는 것이다.