[Linux] 디스크 파티션 검사/복구 하기 (with. Emergency)

서버가 강제로 다운되거나 장애가 발생한 직후 Emergency 모드로 진입하는 경우의 대처 방안.

 

개요

서버 부팅 시 Emergency Mode로 진입하는 경우, 시스템의 주요 파일 시스템 손상 또는 마운트 실패 등으로 인해 정상적인 init 프로세스를 진행할 수 없을 때 발생한다. 

이 글은 이러한 상황에 대한 원인 분석, 진단 방법, 복구 절차를 안내한다.

 

주요 원인

원인	설명
/etc/fstab 오류	존재하지 않는 장치를 마운트하려 하거나, UUID 또는 마운트 옵션 오류 등
필수 파티션 마운트 실패	/, /boot, /usr 등의 파티션이 정상적으로 마운트되지 않음
파일 시스템 손상	주로 fsck 오류로 감지되며, EXT4 또는 XFS에서 발생 가능
디스크 I/O 오류 또는 인식 실패	하드웨어 장애, 커넥터 불량, 블록 장치 오류 등

 

원인 분석

 1. 네트워크 인터페이스 확인

네트워크 인터페이스가 활성화 되어있으며, 네트워크가 제대로 인식되었는지 확인한다.

ifconfig

 

 2. 시스템 로그 확인

시스템의 전반적인 로그를 보며 시스템 에러나 전반적으로 특이사항이 없는지 확인한다.

less /var/log/messages

 

부팅 로그를 통해 시스템 부팅 시 emergency 모드로 부팅되었는지, boot 디렉터리가 정상적으로 마운트 되었는지 확인한다.

cat /var/log/boot.log​

 3. 마운트 상태 확인

주요 파일 시스템( /, /boot, /var 등 )이 정상적으로 마운트 되었는지 확인한다.

df -h

 

boot 파일 시스템이 마운트되지 않은 경우 서비스 상태를 확인한다.

systemctl status boot.mount

 

 

‼️ 네트워크 인터페이스가 비활성화 되어있고, 주요 파일 시스템(/, /boot, /var 등)이 정상적으로 마운트되지 않았다면 시스템 장애로 Emergency 모드로 부팅 되었을 확률이 높다.   
( 현재 부팅 모드 확인 : cat /proc/cmdline )

---

 

디스크 및 파일시스템 점검

 1. 디스크 인식 여부 및 파티션 구조 확인

디스크 장치가 시스템에 인식되어있는지 확인하여 마운트 실패 원인이 물리적인 디스크 손상인지 판단할 수 있다.

lsblk
dmesg | grep -i sda

 

 2. SMART 진단 (하드웨어 상태 점검)

하드웨어 장애가 의심되는 경우 SMART(Self-Monitoring, Analysis and Reporting Technology) 데이터를 통해 자세한 상태를 확인할 수 있다.

설치 필요 (apt install smartmontools)

smartctl -a /dev/sda

 

 3. 파일 시스템 마운트 파티션 확인

Emergency 모드를 해제하고 시스템을 정상화 하려면 장애가 발생한 주요 파일 시스템을 다시 마운트해줘야 하기 때문에 파일 시스템이 기존에 마운트되던 파티션을 확인해둬야 한다.

 

fstab 설정 내용에서 장애가 발생하여 마운트되지 않은 파일 시스템의 기존 마운트 파티션 UUID 확인한다.

cat /etc/fstab

 

fstab에서 확인한 장애 발생 파티션의 UUID와 매칭하여 파티션 명칭 및 타입을 확인한다.

blkid

 

⛔️ 하드웨어 장애로 판단되면 아래 파일 시스템 복구를 시도하지 말고 먼저 이미지를 백업해두고 아래 내용으로 해결되지 않을 경우 디스크를 교체하는 것이 좋을 것 같다..

---

 

파일 시스템 검사 및 복구

 1-1. EXT 계열 파일 시스템인 경우

fsck 명령을 통해 ext 계열 파일 시스템의 오류를 검사하고 수정할 수 있다.

점검 단계에서 확인한 파티션 적용 (ex. /dev/sda2)

fsck {partition}

 

 

⚙️ fsck 명령으로 해결되지 않거나 실패하는 경우 [-f] 옵션을 사용하면 모든 파일 시스템을 강제로 검사한다.

이때 복구 여부는 사용자에게 물어보게 되는데 [-y] 옵션을 사용하면 파일 시스템 복구 여부를 묻지 않고 자동으로 복구를 진행하게 된다. 

fsck -f -y {partition}

 

 

 1-2. XFS 파일 시스템인 경우

xfs_repair 명령을 통해 xfs 파일 시스템의 메타데이터 오류를 검사하고 복구를 시도할 수 있다.

점검 단계에서 확인한 파티션 적용 (ex. /dev/sda2)

xfs_repair {partition}

 

⚙️ 로그 영역이 심하게 손상되어 xfs_repair가 정상 복구를 거부하는 경우 [-L] 옵션으로 xfs의 로그를 강제로 삭제하고 복구를 진행할 수 있다.

손상된 로그를 강제로 초기화하고 메타데이터 기반으로 복구를 진행하는 것이기 때문에 디스크에 반영되지 못한 최근 변경 사항이 손실될 수 있으니 마지막 수단으로 사용해야 한다.

 xfs_repair -L {partition}

⛔️ 강제 옵션을 사용하거나 명령 실행 중 임의로 중단할 경우 데이터 손실의 위험이 있기 때문에 주의가 필요하다.

 

 2. /boot 파티션 수동 마운트

복구가 성공적으로 완료되었다면 장애가 발생했던 파일 시스템을 수동으로 마운트 한다.

mount {partition} /boot

 

 3. 시스템 재부팅

수동 마운트가 정상적으로 되었다면 굳이 재부팅하지 않아도 되지만 마운트가 잘 되지 않거나 확실한 확인이 필요한 경우 깔끔하게 재부팅 하는것이 편하다.

reboot

 

 

※ 저널링 파일 시스템인 XFS, ext4 등은 로그(저널) 영역에 메타데이터 변경사항을 기록해 복구에 활용하지만, 로그가 심하게 손상되면 복구가 어려워질 수 있으며, XFS의 경우 마지막 수단으로 로그를 초기화(-L 옵션)해야 할 수도 있다.

 

 

📌 참고: XFS 에러 메시지

maximum metadata LSN (1:457) is ahead of log (1:2)
- 메타데이터 로그 순서가 실제 로그 기록보다 앞설 때 발생하는 일관성 오류.
format log to cycle 4
- 로그 순환 주기를 다시 포맷하고 정리하여 복구 시도.

 

🛑 파일 시스템 복구 불가 또는 강제 마운트된 경우

1. Live CD/USB 등 부팅 매체를 사용하여 Recovery Mode로 부팅
2. 마운트 및 파일 시스템 복구 후 재부팅
3. Recovery Mode로 해결되지 않는다면 Rescue Mode로 부팅하여 자세한 검사 필요

 

❗️ 주의 사항

- xfs_repair -L 명령어는 데이터 손실 위험이 있기 때문에 로그 복구가 실패한 경우 최후의 수단으로 사용해야 한다.
- 마운트 된 상태에서는 fsck, xfs_repair을 사용하면 심각한 문제가 발생할 수 있다.
- 중요한 데이터는 가능하면 백업 후 복구를 시도 할 것을 권장한다. (아래 링크 참고)

 

 

💾 RedHat: XFS 파일시스템 백업 문서

https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/8/html/managing_file_systems/proc_backing-up-an-xfs-file-system-with-xfsdump-backing-up-an-xfs-file-system#proc_backing-up-an-xfs-file-system-with-xfsdump-backing-up-an-xfs-file-system

 

 

Centos7 기준으로 작성된 내용입니다.