beautifulsoups.dev
Published on

Azure VM 부팅 실패(XFS 로그) 즉시복구 가이드

Authors

서론

운영 중인 Azure Linux VM이 갑자기 부팅에 실패하면서 콘솔에 XFS (…): log mount/recovery failed 류의 메시지가 보이면, 대부분 XFS 저널(log) 손상 또는 스토리지/전원 이벤트로 인한 비정상 종료가 트리거가 됩니다. 이때 중요한 건 “원인 분석”보다 먼저 서비스 복구(RTO) 입니다. Azure 환경에서는 OS 디스크(VHD/Managed Disk)를 원래 VM에서 분리(detach) → 복구용 VM에 연결(attach) → 오프라인에서 xfs_repair 수행 → 다시 원래 VM에 연결하는 방식이 가장 빠르고 안전합니다.

이 글은 “XFS 로그 때문에 부팅이 막힌 Azure VM”을 대상으로, 포털/CLI 중심의 즉시 복구 런북(runbook) 형태로 정리합니다. (재발 방지와 사후 분석 포인트도 함께 다룹니다.)

증상 패턴: XFS 로그로 인한 부팅 실패

다음과 같은 패턴이면 XFS 로그 손상을 의심할 수 있습니다.

  • Serial Console / 부팅 화면에서 멈춤
  • mount 단계에서 루트(/) 또는 /var, /home 등이 올라오지 않음
  • 대표 메시지 예시
XFS (sda2): log mount/recovery failed: error -5
XFS (sda2): Corruption detected. Unmount and run xfs_repair
mount: /sysroot: can't read superblock on /dev/sda2
Entering emergency mode...

대개 다음 이벤트가 원인입니다.

  • 강제 재부팅/강제 종료(Stop/Deallocate 직전 I/O 플러시 실패)
  • 호스트 장애/일시적인 스토리지 지연
  • 디스크 꽉 참(ENOSPC) 이후 메타데이터 손상
  • 커널/드라이버 업데이트 직후 리부트 실패

즉시 복구 전략(권장): OS 디스크 오프라인 복구

부팅이 안 되는 VM 내부에서 손을 대기 어렵기 때문에, Azure에서는 OS 디스크를 다른 “복구 VM”에 붙여 오프라인에서 수리하는 방식이 가장 확실합니다.

복구 개요

  1. 문제 VM 중지(Stop) 및 OS 디스크 분리
  2. 동일 리전/가용성 조건의 복구 VM 준비
  3. 문제 OS 디스크를 복구 VM에 데이터 디스크로 연결
  4. 복구 VM에서 파티션 확인 → 마운트(가능하면 ro) → xfs_repair 수행
  5. 필요 시 -L로 로그 초기화(마지막 수단)
  6. 디스크 분리 후 원래 VM에 OS 디스크로 재연결

> 핵심: xfs_repair -L은 로그를 버리고 복구하므로, 데이터 손실 가능성이 있습니다. 하지만 루트 파일시스템이 아예 마운트되지 않는 상황에선 RTO 관점에서 현실적인 선택이 됩니다.

사전 체크: 스냅샷(백업)부터

어떤 복구든 “원본 보존”이 우선입니다.

  • Managed Disk라면 Snapshot 생성
  • 가능하면 Azure Backup 복구 지점도 확인

CLI 예시(스냅샷):

# 변수
RG="prod-rg"
DISK_NAME="vm01-osdisk"
SNAP_NAME="${DISK_NAME}-snap-$(date +%Y%m%d%H%M)"

# 디스크 ID 조회
DISK_ID=$(az disk show -g "$RG" -n "$DISK_NAME" --query id -o tsv)

# 스냅샷 생성
az snapshot create -g "$RG" -n "$SNAP_NAME" --source "$DISK_ID" -o table

Step-by-step: 포털 기반 즉시 복구

1) 문제 VM 중지 및 OS 디스크 분리

  1. Azure Portal → Virtual machines → 문제 VM
  2. Stop(중지)
  3. Disks → OS disk 확인
  4. OS 디스크 이름 기록(나중에 재연결)

> OS 디스크 분리는 VM/이미지 구성에 따라 UI 동선이 다를 수 있습니다. 일반적으로는 “디스크 리소스(Managed Disk) 화면”에서 Detach를 수행합니다.

2) 복구 VM 준비

  • 동일 리전
  • 가능하면 동일 OS 계열(예: RHEL 계열이면 RHEL/Alma/Rocky, Ubuntu면 Ubuntu)
  • 충분한 권한(sudo)

3) 복구 VM에 문제 OS 디스크 Attach

복구 VM → Disks → Add data disk → 기존 디스크 선택 → 문제 OS 디스크 선택 → Save

4) 복구 VM에서 디스크/파티션 식별

# 새로 붙은 디스크 확인
lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS

# 파티션/UUID 확인
sudo blkid

대개 /dev/sdc2, /dev/sdd2 같은 형태로 보이고, FSTYPE이 xfs로 표시됩니다.

5) 파일시스템이 마운트되어 있으면 해제

xfs_repair는 대상이 마운트되어 있으면 실행할 수 없습니다.

# 마운트 여부 확인
mount | grep -E "xfs|sd[c-z]"

# 마운트되어 있다면 해제
sudo umount /dev/sdc2

6) 1차 시도: 무손실 xfs_repair

먼저 로그를 버리지 않는 기본 복구를 시도합니다.

sudo xfs_repair /dev/sdc2
  • 완료 후 에러가 사라지면 가장 좋습니다.
  • 하지만 로그 자체가 깨진 케이스는 “로그를 0으로 만들라”는 메시지가 나올 수 있습니다.

7) 최후 수단: 로그 초기화(-L)

부팅을 막는 핵심이 XFS log라면 -L로 통과시키는 경우가 많습니다.

# 위험: 최근 트랜잭션(메타데이터/파일 변경)이 유실될 수 있음
sudo xfs_repair -L /dev/sdc2

권장 흐름:

  • 가능한 경우, 스냅샷을 이미 떠둔 상태에서만 -L 수행
  • 복구 후에는 애플리케이션 레벨 정합성(DB, 큐, 파일 업로드 등) 점검 필수

8) 마운트 테스트 및 fstab/GRUB 점검

복구가 끝났다면 마운트가 되는지 확인합니다.

sudo mkdir -p /mnt/rescue
sudo mount -o ro /dev/sdc2 /mnt/rescue

# 중요한 경로 확인
ls -al /mnt/rescue
ls -al /mnt/rescue/etc

# fstab 확인(장치명 대신 UUID 권장)
cat /mnt/rescue/etc/fstab

sudo umount /mnt/rescue

만약 /etc/fstab에 특정 디스크가 UUID 변경 등으로 잘못되어 있으면 부팅이 계속 실패할 수 있습니다. 이 경우에는 fstab을 수정해야 하는데, OS 디스크를 “데이터 디스크로 붙인 상태”에서도 수정 가능합니다.

예: chroot로 들어가 수정하는 패턴

sudo mount /dev/sdc2 /mnt/rescue
sudo mount --bind /dev /mnt/rescue/dev
sudo mount --bind /proc /mnt/rescue/proc
sudo mount --bind /sys /mnt/rescue/sys

sudo chroot /mnt/rescue /bin/bash

# chroot 내부에서
vi /etc/fstab
exit

sudo umount /mnt/rescue/dev /mnt/rescue/proc /mnt/rescue/sys
sudo umount /mnt/rescue

원래 VM로 되돌리기: Detach → OS 디스크 재연결

  1. 복구 VM에서 문제 디스크 Detach
  2. 원래 VM에서 OS 디스크로 다시 연결(또는 디스크 스왑)
  3. VM Start

부팅 후에는 다음을 확인합니다.

  • journalctl -xb에서 XFS 관련 에러 재발 여부
  • dmesg | grep -i xfs
  • 서비스 레벨(웹/배치/DB) 정상 여부

Azure CLI로 하는 디스크 스왑(런북 형태)

포털 대신 CLI로도 복구 플로우를 자동화할 수 있습니다. 아래는 “복구 VM에 OS 디스크를 데이터 디스크로 붙였다가 떼는” 기본 예시입니다.

RG="prod-rg"
BROKEN_VM="vm01"
RESCUE_VM="vm-rescue"

# 문제 VM OS 디스크 이름 얻기
OSDISK_NAME=$(az vm show -g "$RG" -n "$BROKEN_VM" --query "storageProfile.osDisk.name" -o tsv)

# 문제 VM 중지
az vm deallocate -g "$RG" -n "$BROKEN_VM"

# 복구 VM에 데이터 디스크로 attach
az vm disk attach -g "$RG" --vm-name "$RESCUE_VM" --name "$OSDISK_NAME"

복구 VM에서 수리 후 detach:

az vm disk detach -g "$RG" --vm-name "$RESCUE_VM" --name "$OSDISK_NAME"

> 실제로 “OS 디스크 스왑(새 디스크를 OS로 지정)”까지 CLI로 하려면 az vm update --os-disk 등의 조합이 필요하고, VM 생성 방식(Managed Disk/이미지/암호화)에 따라 옵션이 달라집니다. 운영 표준 런북에는 조직 표준에 맞춘 스크립트를 별도로 고정해 두는 것을 권장합니다.

자주 막히는 포인트(실전)

1) xfs_repair 실행 파일이 없다

복구 VM에 xfsprogs가 없으면 설치합니다.

  • RHEL/Alma/Rocky:
sudo dnf install -y xfsprogs
  • Ubuntu:
sudo apt-get update
sudo apt-get install -y xfsprogs

2) LVM 위에 XFS인 경우

파티션이 바로 XFS가 아니라 LVM이면, VG/LV를 활성화해야 합니다.

sudo pvscan
sudo vgscan
sudo vgchange -ay

sudo lvs
# 예: /dev/mapper/rootvg-rootlv
sudo xfs_repair /dev/mapper/rootvg-rootlv

3) 암호화(Encryption)나 보안 설정

  • Azure Disk Encryption(ADE) 또는 DM-Crypt 사용 시, 복구 VM에서 키/권한이 없으면 볼륨을 열 수 없습니다.
  • 이 경우 “복구 VM”도 동일한 Key Vault 권한/정책이 필요합니다.

4) 재부팅 후 또 깨진다

단발성 로그 손상이 아니라면 아래를 의심합니다.

  • 디스크 I/O 오류(플랫폼 이벤트/호스트 이슈)
  • VM 강제 종료/스케일 작업 중 반복
  • 파일시스템이 거의 가득 참

이때는 OS 디스크 메트릭/플랫폼 이벤트, 애플리케이션의 종료 방식(systemd stop timeout)까지 같이 봐야 합니다.

재발 방지 체크리스트

  • 정상 종료 습관화: 자동화 작업에서 az vm restart/강제 종료 대신 서비스 stop → sync → 재부팅
  • 디스크 여유 공간 모니터링: 특히 /var 90% 이상 경고
  • 정기 스냅샷/백업: 최소 일 1회 + 변경량 큰 서비스는 더 촘촘히
  • 커널/에이전트 업데이트 정책: 업데이트 후 자동 재부팅 타이밍 통제
  • 부팅 진단(Boot diagnostics) 활성화: 장애 시 콘솔/스크린샷 확보

운영에서 “장애는 반복된다”는 전제하에, 원인 분석뿐 아니라 복구 자동화가 중요합니다. 예를 들어 재시도/백오프 설계가 장애 전파를 막듯이(429 대응처럼), 인프라 복구도 런북화가 핵심입니다. 관련 사고 대응 설계 관점은 OpenAI 429·insufficient_quota 재시도와 백오프 설계 글의 패턴을 인프라 자동화에 응용해 볼 만합니다.

마무리

Azure VM이 XFS 로그 손상으로 부팅에 실패하면, 가장 빠른 길은 OS 디스크를 분리해 복구 VM에서 오프라인 수리하는 것입니다. 요약하면:

  • 스냅샷으로 원본 보존
  • 복구 VM에 디스크 attach
  • xfs_repair → 안 되면 xfs_repair -L
  • 마운트 테스트 및 fstab 점검
  • 원래 VM에 되돌려 부팅 확인

이 절차를 팀 런북으로 고정해 두면, 새벽 장애에서도 “부팅 불가”를 수십 분 내로 정상화할 수 있습니다.

Discuss on Twitter • View on GitHub