Azure VM 부팅 불가? Boot Diagnostics로 복구

서론

운영 중인 Azure VM이 갑자기 부팅되지 않으면(SSH/RDP 불가, 부팅 화면에서 멈춤, 재부팅 루프) 가장 먼저 확인해야 할 것은 **“VM이 어디 단계에서 죽는가”**입니다. 이때 Azure의 Boot Diagnostics(부트 진단) 는 거의 유일하게 “로그인 이전” 구간(커널/부트로더/초기 init)에서 무슨 일이 벌어졌는지를 보여줍니다.

이 글은 다음 흐름으로 정리합니다.

Boot Diagnostics로 부팅 단계/원인 범주를 빠르게 분류
시리얼 콘솔/스크린샷/로그에서 결정적 단서 뽑기
Azure에서 자주 쓰는 복구 루트 3가지(Serial Console, 디스크 오프라인 수정, OS 디스크 스왑)
재발 방지 체크리스트

> 장애 대응은 “관측(Observability) → 원인 범주화 → 안전한 복구 루트 선택”이 핵심입니다. 클러스터 장애를 로그로 30분 내 분류하는 접근이 궁금하다면, 진단 프레임은 Cloudflare 520·521, Nginx·ALB 로그로 30분 진단 글의 구조도 참고할 만합니다.

Boot Diagnostics란? (무엇을, 어디까지 볼 수 있나)

Azure VM의 Boot Diagnostics는 대략 다음을 제공합니다.

부팅 스크린샷: BIOS/UEFI, GRUB, Windows 부팅 로고, 커널 패닉 등 “눈에 보이는” 단계
시리얼 콘솔 로그(Serial Console/SAC 포함): 커널 메시지, initramfs, systemd 초기화 로그 등
(설정에 따라) 진단 데이터를 저장할 Storage Account/Managed Storage

즉, 네트워크가 죽었거나 SSH 데몬이 뜨지 않아도, 부팅 이전의 단서를 확보할 수 있습니다.

활성화/확인 위치

Azure Portal → VM → Boot diagnostics
(가능하면) 장애 전부터 Enable 해두는 것이 베스트

> Boot Diagnostics가 꺼져 있으면, 장애 시점에 켜더라도 “과거 로그”는 없을 수 있습니다. 하지만 이후 재부팅 과정부터는 캡처가 됩니다.

1단계: 스크린샷으로 “부팅 실패 구간”을 분류하기

Boot Diagnostics의 스크린샷은 생각보다 강력합니다. 아래처럼 구간을 나누면 다음 액션이 거의 정해집니다.

A. BIOS/UEFI 단계에서 멈춤

화면이 멈추거나 디스크를 못 찾는 메시지
원인 후보: 디스크 손상/연결 문제, 부트 순서 문제(드물지만), 플랫폼 이슈
다음 액션: OS 디스크 상태 확인, 스냅샷/복제 후 디스크 스왑 고려

B. GRUB/부트로더 단계에서 멈춤 (Linux)

grub rescue>
no such partition, unknown filesystem
원인 후보: 파티션 테이블/파일시스템 손상, /boot 문제, 커널/GRUB 업데이트 실패
다음 액션: 디스크를 다른 VM에 붙여 GRUB/커널/UUID 복구

C. 커널 로딩 후 패닉/재부팅 루프

Kernel panic - not syncing / VFS: Unable to mount root fs
initramfs 쉘로 떨어짐
원인 후보: initramfs 손상, root 디바이스 UUID 변경, fstab 오류, 드라이버/커널 불일치
다음 액션: Serial Console로 진입 가능하면 즉시 수정, 아니면 오프라인 마운트 후 /etc/fstab, initramfs 재생성

D. systemd에서 멈춤/응답 없음

A start job is running for ...
특정 마운트/서비스에서 타임아웃
원인 후보: fstab의 네트워크/디스크 마운트 실패, 손상된 유닛, 용량 100%로 인한 서비스 실패
다음 액션: emergency 모드 진입 후 fstab/유닛 수정, 디스크 정리

E. Windows 로고/자동 복구 루프

Preparing Automatic Repair
부팅 로고에서 반복
원인 후보: 업데이트/드라이버 문제, BCD 손상, 디스크 오류
다음 액션: Serial Console(SAC) 또는 복구 VM에서 BCD/시스템 파일 점검

2단계: 시리얼 로그에서 “결정적 키워드” 찾기

Boot Diagnostics의 시리얼 로그(또는 Serial Console 출력)는 텍스트 검색이 핵심입니다.

Linux에서 자주 보는 키워드

VFS: Unable to mount root fs → root 디바이스/UUID/드라이버 문제
Entering emergency mode → 보통 fstab/마운트 실패
Dependency failed for /... → systemd 유닛 의존성 문제
No space left on device → 디스크 100% (특히 /var, /)
EXT4-fs error, XFS (sdaX): Corruption detected → 파일시스템 손상

Windows에서 자주 보는 키워드

INACCESSIBLE_BOOT_DEVICE → 스토리지 드라이버/부팅 디바이스 문제
0xc000000e → BCD/부팅 구성 문제

3단계: 복구 루트 선택 (가장 안전한 순서)

복구는 “데이터 보존”과 “복구 속도”의 균형입니다. 일반적으로 다음 순서가 안전합니다.

Serial Console로 즉시 수정(가능하면 가장 빠름)
OS 디스크를 다른 VM에 attach해서 오프라인 수정(가장 범용)
OS 디스크 스왑/복제(시간이 없거나 손상이 의심될 때)

복구 루트 A: Azure Serial Console로 진입해 즉시 복구

Serial Console은 네트워크 없이도 콘솔로 붙는 방식이라, SSH가 죽어도 살릴 수 있습니다.

Linux: fstab 오류로 emergency 모드에 빠진 경우

증상: systemd가 마운트에서 멈추거나 emergency 모드.

콘솔에서 root로 로그인
/etc/fstab 확인

sudo -i
cat /etc/fstab
systemctl --failed
journalctl -xb | tail -n 200

자주 터지는 케이스:

디스크 UUID가 바뀌었는데 fstab이 예전 UUID를 참조
NFS/SMB 같은 네트워크 마운트가 부팅을 막음

임시 복구(부팅 우선): 문제 라인을 주석 처리하거나 nofail,x-systemd.device-timeout=10 옵션 추가

# 예: 부팅을 막는 마운트에 nofail 추가
UUID=xxxx  /data  ext4  defaults,nofail,x-systemd.device-timeout=10  0  2

수정 후 재부팅:

reboot

Linux: 디스크 용량 100%로 서비스가 못 뜨는 경우

부팅은 되지만 로그인/서비스가 안 올라오는 경우도 있습니다.

df -h
journalctl -xb | grep -i "no space" -n
sudo du -xhd1 /var | sort -h

로그/캐시 정리 예:

# journald 로그 축소
journalctl --vacuum-time=3d

# apt 캐시 정리(ubuntu/debian)
apt-get clean

# 오래된 로그 정리(상황에 맞게)
find /var/log -type f -name "*.gz" -delete

복구 루트 B: OS 디스크를 다른 VM에 붙여 오프라인 수정(가장 범용)

Serial Console이 안 되거나, 커널/부트로더 단계에서 죽는다면 이 방법이 가장 확실합니다.

절차 개요

문제 VM Stop(Deallocate)
OS 디스크를 Detach (또는 스냅샷 생성)
건강한 “복구 VM(Rescue VM)”에 Attach
복구 VM에서 디스크 마운트 후 설정 파일 수정/부트로더 복구
원 VM에 다시 연결하거나, 복구된 디스크로 부팅

> 데이터 보존을 위해, 가능하면 먼저 Snapshot을 떠두고 작업하세요.

Linux 예시: 디스크 attach 후 마운트

복구 VM에서 디스크가 /dev/sdc로 붙었다고 가정합니다.

lsblk
sudo mkdir -p /mnt/rescue
sudo mount /dev/sdc2 /mnt/rescue

# 부트 파티션이 분리된 경우
sudo mkdir -p /mnt/rescue/boot
sudo mount /dev/sdc1 /mnt/rescue/boot

fstab/네트워크 마운트/UUID 수정

sudo nano /mnt/rescue/etc/fstab

chroot로 들어가 initramfs 재생성(커널/드라이버 불일치 대응)

배포판에 따라 명령이 다릅니다.

# 필수 바인드 마운트
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

# Ubuntu/Debian 계열
update-initramfs -u -k all

# RHEL/CentOS 계열
dracut -f

exit

GRUB 복구(부트로더 문제일 때)

UEFI/BIOS 구성에 따라 다르지만, 전형적인 BIOS 기반 예시는 아래와 같습니다.

sudo chroot /mnt/rescue /bin/bash
grub-install /dev/sdc
update-grub
exit

> UEFI 환경에서는 EFI 파티션(/boot/efi) 마운트가 필요합니다. Azure VM의 이미지/세대(Gen1/Gen2)에 따라 부팅 체인이 달라질 수 있으니, 스크린샷에서 BIOS/UEFI 여부를 먼저 확인하세요.

복구 루트 C: OS 디스크 스왑(시간이 없을 때 가장 빠른 복구)

원인을 파고들 시간이 없고 “서비스 복구가 우선”이면, 다음 전략이 현실적입니다.

OS 디스크를 Snapshot → 새 디스크 생성
새 디스크로 VM을 띄워 부팅 여부 확인
부팅이 되면, 원 디스크는 포렌식/원인 분석용으로 보관

이 방식은 파일시스템 손상/부트로더 손상 의심 시 특히 유효합니다.

자주 터지는 원인 TOP 6와 빠른 처방

1) /etc/fstab 오타/UUID 변경

증상: systemd emergency, 마운트 대기
처방: nofail 추가, UUID 재확인(blkid), 네트워크 마운트는 x-systemd.automount 고려

2) 커널 업데이트 후 initramfs/드라이버 불일치

증상: VFS: Unable to mount root fs
처방: 오프라인 chroot 후 initramfs 재생성, 필요 시 이전 커널로 부팅

3) 디스크 가득 참(특히 /var)

증상: 서비스 미기동, 로그인 불가, journald 폭주
처방: 로그/캐시 정리, 디스크 확장 후 파일시스템 확장

4) 파일시스템 손상

증상: EXT4/XFS corruption, 부팅 중 fsck
처방: 오프라인에서 fsck/xfs_repair (데이터 손실 가능성 주의)

5) 클라우드-인잇/에이전트 문제

증상: 네트워크 설정 꼬임, SSH 키 적용 실패
처방: cloud-init 로그 확인, 네트워크 설정 롤백

6) 부트로더 손상(GRUB/BCD)

증상: grub rescue, Windows 부팅 오류 코드
처방: GRUB reinstall / Windows BCD 복구

운영 팁: 부팅 장애를 “재발 방지”하는 설정

Boot Diagnostics는 항상 켜두기

장애 시점에 켜면 늦습니다. 운영 VM 템플릿(Terraform/Bicep)에서 기본 활성화하세요.

변경 작업은 되돌릴 수 있게

커널/패키지 대규모 업데이트 전 스냅샷
fstab/네트워크 변경 전 백업
IaC로 변경 이력 관리

장애 진단의 공통 패턴: “증상은 다르지만, 로그가 답이다”

부팅 장애든, 쿠버네티스 동기화 실패든, 결국은 관측 지점 확보 → 원인 범주화 → 최소 변경으로 복구입니다. 배포/동기화 관점의 트러블 슈팅 패턴은 Argo CD Sync Failed/OutOfSync 원인 10가지도 같은 결로 읽힙니다.

체크리스트: 15분 내 1차 복구 플로우

Portal에서 Boot Diagnostics 스크린샷 확인 → 실패 구간(A~E) 분류
시리얼 로그에서 키워드 검색(VFS, emergency, fstab, corruption)
Serial Console 가능하면 즉시 fstab/용량/서비스 실패부터 해결
안 되면 OS 디스크 스냅샷 → 복구 VM에 attach → 오프라인 수정(chroot)
그래도 불안정하면 OS 디스크 스왑으로 서비스 먼저 살리고, 원 디스크로 원인 분석

마무리

Azure VM 부팅 불가는 “접속이 안 된다”는 점 때문에 막막하지만, Boot Diagnostics만 제대로 활용하면 원인 범주를 빠르게 좁히고 복구 루트를 선택할 수 있습니다. 특히 fstab/UUID, initramfs, 파일시스템 손상, 부트로더는 반복 출현하는 단골 원인입니다.

원하시면, 사용 중인 OS(예: Ubuntu 22.04 Gen2/Windows Server 2022), 증상 스크린샷/시리얼 로그 일부를 기준으로 **정확한 복구 명령(UEFI GRUB 복구, dracut, BCD 등)**까지 케이스별로 더 구체화해드릴 수 있습니다.