[Linux] 리눅스 파일 시스템 장애 대응 (Emergency mode)

[Troubleshooting] 리눅스 파일 시스템 장애 대응: 표준 파티션 및 LVM 논리 볼륨 통합 가이드

분류: 인프라 운영 / 시스템 복구 (Internal)

1. 개요 (Background)

서버 프리징이나 강제 재부팅 후 발생하는 Emergency Mode는 파일 시스템의 정합성(Consistency)이 깨졌을 때 시스템을 보호하기 위한 방어 기제이다.
관리자는 단순히 리부팅을 반복하기보다, 손상된 영역을 정확히 진단하고 해당 파일 시스템 타입에 맞는 복구 도구를 사용하여 데이터를 보존해야 한다.

💡 2. 긴급 권한 획득 (Root Shell 진입)

패스워드 미설정 또는 분실 시 GRUB 부트 로더 파라미터를 수정하여 즉시 쉘 권한을 확보할 수 있다.

• Step 1: 부팅 메뉴에서 대상 커널 선택 후 e 키 입력
• Step 2: linux 라인 끝의 ro quiet splash를 rw init=/bin/bash로 수정
• Step 3: Ctrl + X로 부팅하여 비밀번호 없이 쉘 진입

3. 장애 진단 및 타겟 분석 (Deep Diagnosis)

"어디가, 어떻게, 어떤 파일 시스템으로 깨졌는가"를 확인하는 단계이다.

[진단 프로세스 상세]

1. 실패 원인 확인 (journalctl -xb): 로그를 아래로 내려 failed to mount 또는 Dependency failed 메시지를 찾음. 여기서 마운트되지 않은 장치명(예: /dev/sda2 또는 /dev/mapper/...)을 특정함.
2. 파일 시스템 타입 판별 (lsblk -f): 복구 도구 선택을 위해 필수적임. FSTYPE 열을 확인하여 EXT4인지 XFS인지 식별함.
3. LVM 구조 분석 (lsblk): 물리 디스크(sda)와 논리 볼륨(LV)의 관계를 파악함. LVM 계층 구조에서는 최하단의 논리 장치 경로를 타겟팅해야 한다.

Target A. 표준 파티션

식별: sda1, sda2 등 숫자 형태

※ 주로 /boot 등 부팅 관련 소량 영역

Target B. LVM 논리 볼륨

식별: /dev/mapper/ 경로명 사용

※ / (root), /data 등 데이터 집약 영역

4. 상황별 파일 시스템 정밀 복구

※ 주의: 모든 복구 명령어는 대상 파티션이 Unmount 상태여야 함. 마운트된 상태에서 실행하면 심각한 데이터 손상이 발생할 수 있다.

Case 1. EXT4 파일 시스템 (표준 및 LVM 공통)

fsck 도구를 사용하여 인덱스 및 메타데이터를 수리한다.

# 표준 파티션 복구
fsck -y /dev/sda2

# LVM 논리 볼륨 복구
fsck -y /dev/mapper/ubuntu--vg-lv--root

⚙️ fsck로 해결되지 않거나 실패하는 경우 [-f] 옵션을 사용하면 모든 파일 시스템을 강제로 검사한다. [-y] 옵션을 함께 사용하면 복구 여부를 묻지 않고 자동으로 복구 진행.

fsck -f -y {partition}

Case 2. XFS 파일 시스템 (엔터프라이즈 서버 대중적)

XFS는 구조상 fsck 대신 xfs_repair 도구를 사용해야 정확한 수리가 가능하다.

# 일반적인 XFS 수리 (LVM 경로 예시)
xfs_repair /dev/mapper/ubuntu--vg-lv--data

# 로그 손상으로 수리가 거부될 경우 (강제 로그 초기화)
xfs_repair -L /dev/mapper/ubuntu--vg-lv--data

※ -L 옵션은 최후의 수단이며, 마지막 저널링 로그를 유실시킬 수 있으니 주의해야 한다.

⚙️ 로그 영역이 심하게 손상되어 xfs_repair가 정상 복구를 거부하는 경우 [-L] 옵션으로 xfs의 로그를 강제로 삭제하고 복구를 진행할 수 있다.
손상된 로그를 강제로 초기화하고 메타데이터 기반으로 복구를 진행하는 것이기 때문에 최근 변경사항이 손실될 수 있으니 마지막 수단으로 사용해야 한다.

5. 사후 관리 및 재발 방지 (Post-Mortem)

• 불필요한 컨테이너 관리: 장애 유발 가능성이 있는 정지된 컨테이너나 고스트 이미지를 제거하여 I/O 부하를 줄임.
  docker stop $(docker ps -a -q) (필요 시 전체 중지)
  docker rm $(docker ps -a -q) (모든 컨테이너 제거)
  docker system prune -a --volumes (미사용 리소스 완전 정리)
• 비대 로그(Log) 파일 정제: Docker 컨테이너 로그 용량 제한 설정을 검토하고 수동으로 비움.
  truncate -s 0 /var/lib/docker/containers/*/*.log
• 최종 건전성 확인: mount -a 실행 후 리부팅하여 정상 진입 여부를 확인함.

Tip: 장애 복구 후 df -i 명령어로 Inode 잔여량을 확인하는 습관도 재발 방지에 도움이 된다.