효과적인 Linux 파일시스템 오류 문제 해결 및 복구 방법

파일시스템 오류는 수리를 서두르면 일반적인 Linux 중단을 데이터 손실 사고로 바꿀 수 있습니다. 첫 번째 작업은 쓰기를 중지하고, 장치를 식별하며, 메타데이터를 수정하는 도구를 실행하기 전에 올바른 복구 경로를 선택하는 것입니다.

이 가이드는 fsck 및 ext2/3/4용 e2fsck와 같은 파일시스템별 도구를 사용한 실용적인 Linux 파일시스템 오류 문제 해결에 중점을 둡니다. 가장 안전한 워크플로는 지루합니다: 로그를 검사하고, 가능한 것을 백업하고, 파일시스템을 마운트 해제하고, 올바른 검사기를 실행하고, 디스크를 서비스에 반환하기 전에 결과를 확인합니다.

1. 파일시스템 손상 인식 및 식별

파일시스템 오류는 종종 여러 명확한 징후를 통해 나타납니다. 조기 발견은 사소한 손상이 전체 데이터 손실로 확대되는 것을 방지하는 데 중요합니다.

손상의 일반적인 증상

• I/O 오류: 파일 액세스 중에 보고되는 커널 오류로, 종종 "입/출력 오류" 또는 유사한 메시지를 표시합니다.
• 파일 누락 또는 손상: 성공적으로 저장한 후에도 파일이 사라지거나 쓰레기 데이터를 포함합니다.
• 느린 성능: 특히 디스크 작업 중 과도한 시스템 느림은 시스템이 손상된 메타데이터를 해석하는 데 어려움을 겪고 있음을 나타낼 수 있습니다.
• 마운트 실패: 시스템이 부팅 중 특정 파티션을 마운트할 수 없어 종종 사용자를 응급 셸로 떨어뜨립니다.
• 커널 로그 메시지: 커널에 의해 기록된 중요한 오류로, dmesg 명령 또는 /var/log/syslog나 journalctl 내에서 볼 수 있습니다.

모니터링해야 할 주요 영역

파일시스템 손상은 일반적으로 메타데이터 구조, 특히 다음에 영향을 미칩니다:

1. 슈퍼블록: 전체 파일시스템 구조(크기, inode 수, 블록 수, 상태)에 대한 중요한 정보를 포함합니다.
2. Inode 테이블: 실제 파일(소유권, 권한, 물리적 블록 위치)을 설명하는 구조입니다.
3. 데이터 블록 포인터: 어떤 물리적 블록이 어떤 파일에 속하는지 매핑하는 오류입니다.

슈퍼블록이 손상된 경우, 백업 슈퍼블록을 사용하여 복구하거나 교체할 때까지 전체 파일시스템에 일반적으로 액세스할 수 없습니다.

# 최근 디스크 활동 오류에 대한 커널 로그 확인
dmesg | grep -Ei 'error|fail|i/o'

# 지속적인 경고 또는 오류에 대한 시스템 저널 검토
journalctl -xb

2. 준비: 마운트 해제된 파일시스템 규칙

절대적으로 중요: 현재 마운트되어 활성화된 파일시스템에서 fsck와 같은 복구 유틸리티를 절대 실행해서는 안 됩니다. 그렇게 하면 즉각적이고 돌이킬 수 없는 손상을 초래하고 완전한 데이터 손실로 이어질 수 있습니다. 파일시스템은 검사 전에 마운트 해제되거나 읽기 전용(ro)으로 마운트되어야 합니다.

데이터 파티션 마운트 해제

루트가 아닌 파티션(예: /home, /data)의 경우:

# 장치 경로 식별 (예: /dev/sdb1)
df -h

# 대상 파티션 마운트 해제
sudo umount /dev/sdb1

# 마운트 해제 성공 확인
df -h | grep sdb1

루트 파티션 (/) 처리

루트 파티션은 시스템이 정상적으로 실행되는 동안 마운트 해제할 수 없으므로 세 가지 주요 옵션이 있습니다:

1. 단일 사용자/복구 모드로 재부팅: 많은 최신 배포판은 루트 파일시스템을 읽기 전용으로 마운트하는 복구 모드를 제공하여 fsck를 안전하게 실행할 수 있습니다.
2. 라이브 배포판 사용 (권장): USB 또는 ISO 이미지(예: Ubuntu Live, CentOS Live)를 사용하여 서버를 부팅하고 이 별도의 운영 환경에서 검사를 수행합니다.
3. 다음 부팅 시 강제 검사: 일부 구형 시스템에서는 /forcefsck 파일을 터치하면 다음 부팅 주기 중에 시스템이 fsck를 실행하도록 강제합니다. (이 방법은 ext4와 같은 최신 저널 파일시스템에서는 덜 안정적입니다.)

3. 파일시스템 복구를 위한 fsck 활용

fsck는 파티션 유형에 따라 적절한 파일시스템 검사 도구(예: ext4용 e2fsck, XFS용 fsck.xfs)를 자동으로 호출하는 래퍼 명령입니다.

기본 fsck 사용법

fsck를 실행할 때는 항상 마운트 지점이 아닌 전체 장치 경로를 지정하십시오.

# /dev/sdb1을 확인하는 기본 명령
sudo fsck /dev/sdb1

필수 fsck 옵션

옵션	설명	경고/참고
-f	파일시스템이 깨끗해 보여도 강제로 검사합니다. (매우 권장)
-y	모든 질문에 '예'라고 가정하고 오류를 자동으로 수정합니다.	주의해서 사용: 데이터를 복구할 수 없는 경우 삭제하거나 격리할 수 있습니다.
-n	모든 질문에 '아니오'라고 가정하고 변경 없이 시험 실행을 수행합니다.	평가 전용으로 유용합니다.
-p	사용자에게 묻지 않고 안전한 문제를 자동으로 복구합니다.	주요 손상이 아닌 경우 일상적인 검사에 사용하십시오.

예: 자동 복구로 강제 검사

# 파티션이 먼저 마운트 해제되었는지 확인하십시오!
sudo fsck -f -y /dev/sdb1

fsck가 실행되면 블록, inode 목록, 디렉토리 연결, 참조 횟수 및 그룹 설명자를 확인하는 5가지 주요 단계를 거칩니다.

팁: 파일시스템 유형(예: ext4)을 알고 있다면 래퍼를 우회하고 더 큰 제어를 위해 특정 도구를 직접 사용할 수 있습니다: sudo e2fsck -f -y /dev/sdb1

4. 일반적인 오류 메시지 이해 및 처리

복구 프로세스 중에 fsck는 구조적 오류를 수정하기 위해 사용자에게 권한을 요청할 수 있습니다. 이러한 프롬프트를 이해하면 최선의 조치를 결정하는 데 도움이 됩니다.

Inode 오류

오류: Inode X에 잘못된 블록이 있습니다. 지우시겠습니까?

• 의미: Inode X가 설명하는 파일이 유효하지 않거나 할당되지 않았거나 다른 파일에 속한 블록을 가리킵니다.
• 조치: 일반적으로 '예'를 선택하는 것이 올바른 접근 방식입니다. 해당 inode가 나타내는 파일은 손실되지만 파일시스템 구조는 유지됩니다.

블록 수 오류

오류: Inode X의 블록 수가 Y입니다. Z여야 합니다. 수정하시겠습니까?

• 의미: 메타데이터는 파일이 Y 블록을 사용한다고 생각하지만 물리적 계산에 따르면 Z 블록이 실제로 할당되어 있습니다. 이는 일반적인 불일치 형태입니다.
• 조치: 항상 '예'를 선택하여 블록 수 불일치를 수정하십시오.

디렉토리 오류 및 lost+found

fsck가 존재하지만 더 이상 디렉토리 항목에 연결되지 않은 파일(inode)을 찾으면 고아로 간주됩니다. fsck는 이러한 파일을 파티션 루트에 있는 lost+found라는 특수 디렉토리로 자동 이동합니다.

lost+found에서 복구

1. fsck가 완료되면 파티션을 다시 마운트하고 lost+found 디렉토리로 이동합니다.
2. 파일은 inode 번호로 이름이 바뀝니다(예: #12345).
3. 이러한 파일을 수동으로 검사하여 원래 내용을 확인하고 이름을 바꿔야 합니다.

sudo mount /dev/sdb1 /mnt/data
cd /mnt/data/lost+found
sudo file ./#12345
# 텍스트인 경우 'cat' 또는 'less'를 사용하여 내용을 확인합니다.

5. 고급 복구: 손상된 슈퍼블록 처리

기본 슈퍼블록이 심각하게 손상된 경우 fsck는 즉시 실패하며 구조를 읽을 수 없다고 보고합니다. 다행히 ext2/3/4 파일시스템은 슈퍼블록의 백업 복사본을 저장합니다.

백업 슈퍼블록 찾기

백업 슈퍼블록은 파일시스템 종속 위치에 저장됩니다. 파일시스템을 생성하는 데 사용된 것과 동일한 블록 크기 옵션을 사용하여 mke2fs -n으로 나열하거나 충분한 메타데이터가 읽을 수 있는 경우 dumpe2fs로 나열할 수 있습니다. -n 없이 mke2fs를 실행하지 마십시오. 새 파일시스템이 생성됩니다.

# 파일시스템을 생성하지 않고 백업 슈퍼블록이 있을 위치 출력
sudo mke2fs -n /dev/sdb1

# 또는 메타데이터를 충분히 읽을 수 있는 경우 기존 ext 파일시스템 검사
sudo dumpe2fs /dev/sdb1 | grep -i 'superblock'

백업 슈퍼블록에서 복원

fsck가 실패하면 -b 옵션을 사용하여 e2fsck가 특정 백업 슈퍼블록 위치를 사용하도록 강제할 수 있습니다.

예: 블록 8193에 있는 백업 슈퍼블록 사용.

# 참고: 파티션이 마운트 해제되어 있어야 합니다.
sudo e2fsck -b 8193 /dev/sdb1

성공하면 백업 복사본을 사용하여 파일시스템 메타데이터를 재구성하여 종종 완전한 복구로 이어지지만 마지막 정리 동기화 이후의 가장 최근 변경 사항이 손실될 수 있습니다.

6. 예방 조치 및 모범 사례

파일시스템 손상을 방지하는 것은 항상 복구하는 것보다 낫습니다.

정상 종료

항상 시스템이 정상적으로 종료되도록 하십시오. 갑작스러운 정전은 커널이 보류 중인 쓰기를 디스크에 플러시하지 못할 수 있으므로 메타데이터 손상의 주요 원인입니다.

정기적인 모니터링

도구를 사용하여 물리적 드라이브(HDD/SSD)의 상태를 모니터링하십시오. smartctl은 S.M.A.R.T. 데이터를 읽을 수 있어 임박한 하드웨어 오류를 나타내며, 이는 종종 파일시스템 손상보다 먼저 발생합니다.

# sda의 기본 SMART 상태 데이터 확인
sudo smartctl -H /dev/sda

저널링 및 백업

ext4 및 XFS와 같은 최신 파일시스템은 저널링을 사용하여 충돌 후 일관성을 빠르게 복구하여 사소한 손상을 완화합니다. 그러나 저널링은 정기적이고 안정적인 백업을 대체하지 않습니다. 심각한 하드웨어 오류나 사람의 실수는 가장 강력한 복구 도구조차 우회할 수 있으므로 중요한 데이터의 최신 오프사이트 백업을 항상 유지하십시오.

안전한 복구 요약

파일시스템 손상이 의심되면 먼저 쓰기를 중지하고 두 번째로 복구하십시오. 로그를 캡처하고, 데이터가 중요할 때 블록 수준 백업을 만들고, 파일시스템을 마운트 해제하고, 파일시스템 유형과 일치하는 검사기를 사용하십시오. 복구 후 lost+found를 검사하고, SMART 데이터를 검토하며, 동일한 실패 디스크를 반복적으로 복구하는 대신 의심스러운 스토리지를 교체하십시오.