beautifulsoups.dev
Published on

Azure VM 부팅 실패? Boot diagnostics로 즉시 복구

Authors

운영 중인 Azure VM이 갑자기 부팅에 실패하면 체감상 가장 답답한 점은 “접속이 안 된다”는 사실입니다. SSH도, RDP도 막히면 애플리케이션 로그는커녕 OS 레벨에서 무슨 일이 벌어졌는지 확인할 길이 없어 보입니다. 이때 가장 먼저 켜야 하는 기능이 Boot diagnostics 입니다.

Boot diagnostics는 VM의 부팅 과정에서 생성되는 콘솔 출력(serial console 로그 유사) 과 부팅 화면 스크린샷을 저장해 주기 때문에, 네트워크가 죽었거나 에이전트가 비정상이어도 “부팅 단계에서 어디까지 진행됐는지”를 빠르게 확인할 수 있습니다. 이 글에서는 부팅 실패를 Boot diagnostics로 진단하고, 원인별로 복구까지 이어지는 흐름을 실전 체크리스트 형태로 정리합니다.

언제 Boot diagnostics가 가장 유효한가

다음 증상이면 우선순위 1순위로 Boot diagnostics를 확인하세요.

  • VM 상태는 Running인데 SSH 또는 RDP가 타임아웃
  • Starting에서 오래 멈추거나, 재부팅을 반복
  • 커널 패닉, 드라이버 문제, 파일시스템 오류 등으로 OS가 정상 부팅을 못함
  • OS 업데이트 이후 부팅이 깨짐
  • 디스크/부트로더/파티션 변경 이후 부팅 불가

반대로, 애플리케이션만 죽고 OS 접속은 되는 상황이라면 Boot diagnostics보다 서비스 로그나 systemd 상태 점검이 더 빠릅니다. 그런 케이스는 아래 글의 체크리스트가 도움이 됩니다.

Boot diagnostics 동작 원리와 한계

무엇을 저장하나

  • 부팅 화면 스크린샷 1장 또는 일정 주기 이미지
  • 콘솔 출력 로그(부팅 과정 메시지)

어디에 저장하나

  • 보통 Azure Storage 계정(진단용 스토리지)에 저장됩니다.
  • 최근에는 Managed 방식으로 포털에서 간편 활성화가 가능하며, 내부적으로 관리형 스토리지를 사용합니다.

한계(중요)

  • 게스트 OS 내부 로그(예: /var/log/syslog, journalctl)를 직접 보여주진 않습니다.
  • OS가 콘솔로 메시지를 출력하지 않도록 설정돼 있으면 정보가 제한적일 수 있습니다.
  • 부팅이 특정 단계에서 완전히 멈추면 마지막 출력만 남습니다.

그럼에도 “부팅이 어디서 멈췄는지”만 알아도 복구 방향이 크게 좁혀집니다.

포털에서 3분 안에 진단 정보 확보하기

  1. Azure Portal에서 대상 VM 선택
  2. 좌측 메뉴에서 Boot diagnostics 진입
  3. Screenshot 확인
  4. Serial log 또는 Console output 다운로드/열람

여기서 핵심은 스크린샷과 로그를 함께 보는 것입니다.

  • 스크린샷은 fsck 프롬프트, initramfs 쉘, 커널 패닉 같은 “멈춘 화면”을 직관적으로 보여줍니다.
  • 로그는 네트워크 이전 단계(커널, initramfs, systemd 초기화)에서의 오류 문자열을 제공해 원인 키워드를 뽑을 수 있습니다.

로그에서 자주 보이는 패턴 6가지와 즉시 복구 루트

아래는 Boot diagnostics에서 자주 만나는 메시지 유형과, 그 다음 액션을 “복구 루트”로 정리한 것입니다.

1) 파일시스템 오류 또는 강제 복구 모드

징후:

  • 스크린샷에 자동 복구 실패, fsck 요구, read-only 마운트 등

복구 루트:

  • 가장 안전한 방법은 OS 디스크를 다른 VM에 붙여 오프라인 복구하는 것입니다.
  • VM을 강제 재부팅 반복하면 손상이 커질 수 있으니, 우선 Stop 후 디스크 기반 복구를 고려하세요.

2) 커널 패닉 또는 드라이버/모듈 문제

징후:

  • 로그에 Kernel panic 문구
  • 특정 드라이버 로딩 후 멈춤

복구 루트:

  • 최근 커널 업데이트 직후라면, 부트로더에서 이전 커널로 부팅이 가능한지 확인해야 하지만 Azure 환경에선 콘솔 상호작용이 제한될 수 있습니다.
  • 현실적으로는 오프라인으로 /boot 및 커널 모듈, initramfs 구성을 점검하거나, 스냅샷 기반 롤백이 더 빠릅니다.

3) 부트로더/파티션/UUID 불일치

징후:

  • VFS: Unable to mount root fs 유사 메시지
  • UUID를 찾지 못한다는 로그

복구 루트:

  • 디스크 구조 변경(파티션 조정, 복제, 마이그레이션) 이후 자주 발생합니다.
  • 오프라인으로 fstab 및 initramfs 설정을 점검해 루트 디바이스 식별자를 수정합니다.

4) cloud-init 또는 초기화 스크립트에서 멈춤

징후:

  • 화면상 cloud-init 단계에서 정지
  • 사용자 데이터 스크립트 실행 후 멈춘 흔적

복구 루트:

  • 부팅을 막는 스크립트가 있다면 오프라인으로 비활성화하거나, 다음 부팅에서 실행되지 않도록 상태 파일을 조정합니다.

5) 디스크 공간 부족으로 부팅 실패

징후:

  • 로그에 No space left on device
  • systemd가 중요한 유닛을 시작 못하고 드롭

복구 루트:

  • 오프라인으로 로그/캐시 정리 또는 디스크 확장 후 파일시스템 확장

6) 네트워크 문제로 “부팅은 됐는데 접속이 안 됨”

징후:

  • 스크린샷 상 로그인 프롬프트 또는 정상 부팅 화면
  • 하지만 SSH/RDP만 안 됨

복구 루트:

  • 이 경우는 부팅 실패가 아니라 네트워크/NSG/라우팅/DNS 또는 방화벽 이슈일 가능성이 큽니다.
  • Boot diagnostics로 OS가 살아있음을 확인한 뒤, NSG 인바운드 규칙, NIC, UDR, Azure Firewall, 게스트 방화벽을 순서대로 확인합니다.

“가장 확실한” 복구: OS 디스크 오프라인 마운트

부팅 자체가 깨진 경우, Azure에서 가장 재현성 높은 방법은 문제 VM의 OS 디스크를 분리해서 정상 VM에 붙인 뒤 수정하는 방식입니다. Azure에서는 이 흐름이 표준적인 Break-glass 절차로 많이 쓰입니다.

절차 개요

  1. 문제 VM Stop (deallocate)
  2. OS 디스크 스냅샷 생성(안전장치)
  3. OS 디스크를 분리(detach)
  4. 별도의 복구용 VM에 디스크를 데이터 디스크로 attach
  5. 복구용 VM에서 마운트 후 설정 수정
  6. 원래 VM에 다시 OS 디스크 attach
  7. 부팅 테스트

Azure CLI 예시

아래 예시는 흐름을 보여주기 위한 템플릿입니다. 실제 값은 환경에 맞게 바꾸세요.

# 변수
RG="prod-rg"
VM="broken-vm"
RECOVERY_VM="recovery-vm"
OS_DISK_NAME=$(az vm show -g "$RG" -n "$VM" --query "storageProfile.osDisk.name" -o tsv)

# 1) VM 중지(할당 해제)
az vm deallocate -g "$RG" -n "$VM"

# 2) OS 디스크 스냅샷 생성
DISK_ID=$(az disk show -g "$RG" -n "$OS_DISK_NAME" --query id -o tsv)
az snapshot create -g "$RG" -n "${OS_DISK_NAME}-snap" --source "$DISK_ID"

# 3) OS 디스크 분리
az vm disk detach -g "$RG" --vm-name "$VM" --name "$OS_DISK_NAME"

# 4) 복구 VM에 attach
az vm disk attach -g "$RG" --vm-name "$RECOVERY_VM" --name "$OS_DISK_NAME"

복구 VM에 붙인 뒤에는 OS 종류에 따라 마운트와 수정이 달라집니다.

Linux에서 마운트 및 fstab 점검 예시

# 어떤 디스크로 붙었는지 확인
lsblk

# 예: /dev/sdc1 이 루트 파티션이라고 가정
sudo mkdir -p /mnt/rescue
sudo mount /dev/sdc1 /mnt/rescue

# fstab, 네트워크, cloud-init 등 점검
sudo nano /mnt/rescue/etc/fstab
sudo cat /mnt/rescue/var/log/cloud-init.log 2>/dev/null || true

# 필요 시 chroot 진입
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

# 예: initramfs 재생성(배포판별로 다름)
# Ubuntu/Debian 계열
update-initramfs -u

exit
sudo umount -R /mnt/rescue

이 방식의 장점은 “부팅이 안 되는 VM”에서도 파일을 직접 고칠 수 있다는 점입니다. 특히 fstab의 잘못된 UUID, cloud-init 스크립트 무한 대기, 디스크 풀 문제 같은 케이스에 강합니다.

Boot diagnostics를 켜두는 운영 팁

1) 장애 전에 미리 활성화

장애가 난 뒤에도 켤 수는 있지만, “장애 직전 부팅”의 흔적을 더 안정적으로 남기려면 기본적으로 켜두는 편이 좋습니다. 특히 프로덕션 VM은 표준 베이스라인에 포함시키는 것을 권장합니다.

2) 스토리지 접근 권한과 보존 정책

진단 로그가 스토리지에 저장되는 구조라면, 운영팀이 해당 스토리지에 접근 가능한지, 보존 기간이 충분한지 점검해야 합니다. 장애 대응 중에 권한 문제로 로그를 못 보면 의미가 반감됩니다.

3) 스냅샷 우선 문화

부팅 실패는 원인 분석보다 “서비스 복구”가 먼저인 경우가 많습니다. Boot diagnostics로 원인을 좁히되, 수정 작업 전에는 스냅샷을 먼저 떠서 되돌릴 수 있게 하세요.

장애 대응 흐름을 짧게 정리하면

  1. 포털에서 Boot diagnostics로 스크린샷과 로그 확보
  2. 부팅 자체 실패인지, 네트워크로 인한 접속 실패인지 구분
  3. 부팅 실패라면 Stop (deallocate) 후 OS 디스크 스냅샷
  4. 오프라인 마운트로 fstab, initramfs, cloud-init, 디스크 용량 등을 수정
  5. 재부팅 후 정상화

부팅 장애는 “접속이 안 되니 아무것도 못한다”에서 시작하지만, Boot diagnostics를 활용하면 최소한 부팅 단계의 단서를 확보할 수 있고, 오프라인 디스크 복구까지 연결하면 상당수 케이스는 당일 내로 복구가 가능합니다.

Discuss on Twitter • View on GitHub