- Published on
Azure VM 부팅불가, Boot Diagnostics로 복구하기
- Authors
- Name
- 스타차일드
- https://x.com/ETFBITX
운영 중인 Azure VM이 갑자기 부팅 불가 상태가 되면, 가장 먼저 해야 할 일은 “원인 추정”이 아니라 “증거 확보”입니다. Azure에서는 Boot Diagnostics가 그 출발점입니다. 부팅 단계에서 네트워크 접속이나 에이전트가 죽어도, 콘솔 수준에서 스크린샷과 시리얼 로그를 남겨주기 때문에 장애 원인을 빠르게 좁힐 수 있습니다.
이 글에서는 다음을 목표로 합니다.
- Boot Diagnostics로 부팅 단계별 증상을 식별하는 방법
- 안전한 복구를 위한 스냅샷, 복구 VM 구성
- 흔한 부팅 실패 케이스별 오프라인 수정 절차
- 재발 방지를 위한 운영 체크리스트
리눅스 기준으로 설명하지만, Windows도 흐름은 동일합니다.
1) 장애 대응의 원칙: “스크린샷, 로그, 디스크”부터
부팅 불가 장애에서 가장 위험한 실수는, VM을 재배포하거나 디스크를 바로 건드려 증거를 날리는 것입니다. 다음 순서로 접근하세요.
- Boot Diagnostics에서 스크린샷과 시리얼 로그 확보
- OS 디스크 스냅샷 생성(가장 중요)
- 필요 시 복구 VM을 만들어 OS 디스크를 데이터 디스크로 붙여 오프라인 수정
부팅 실패가 디스크 손상, 커널 패닉, fstab 오기재, GRUB 문제, 용량 100퍼센트 등 다양한 원인으로 발생할 수 있기 때문에, “현재 상태를 보존”하는 것이 복구 성공률을 높입니다.
2) Boot Diagnostics 켜기와 확인 포인트
Boot Diagnostics 활성화
Azure Portal에서 VM을 선택한 뒤 다음을 확인합니다.
Boot diagnostics가 Enabled인지- 저장 위치가 Managed storage인지(권장) 또는 Storage account인지
이미 부팅 불가 상태여도 Boot Diagnostics가 켜져 있으면 마지막 부팅 시도의 스크린샷과 로그가 남아 있는 경우가 많습니다.
스크린샷에서 보는 대표 신호
Boot Diagnostics 스크린샷은 “어느 단계에서 멈췄는지”를 알려줍니다.
- GRUB 메뉴에서 멈춤: 부트로더 설정, 커널 이미지, initramfs 문제 가능
Kernel panic문구: 커널 모듈, 루트 파일시스템 마운트 실패, 드라이버 문제 가능fsck반복 또는emergency mode: 파일시스템 오류,fstab문제 가능- 로그인 프롬프트는 뜨지만 SSH 불가: 네트워크, 방화벽, SSH 설정, 클라우드 에이전트 문제 가능
시리얼 로그에서 보는 대표 신호
스크린샷이 정적이라면, 시리얼 로그는 더 구체적인 단서를 제공합니다.
VFS: Unable to mount root fs같은 메시지- 특정 디바이스 UUID를 찾지 못한다는 메시지
systemd가 특정 유닛에서 타임아웃나는 지점- 디스크 I/O 에러, read-only remount
이 단계에서 “대략 어디를 고쳐야 하는지” 가닥이 잡힙니다.
3) 복구 전 안전장치: OS 디스크 스냅샷 만들기
오프라인 수정은 강력하지만, 잘못하면 부팅 불가를 더 악화시킬 수 있습니다. 반드시 OS 디스크 스냅샷을 먼저 찍습니다.
Azure CLI로 스냅샷 생성 예시
# 변수 예시
RG="prod-rg"
VM_NAME="prod-vm01"
SNAP_NAME="prod-vm01-osdisk-snap-20260224"
# OS 디스크 ID 조회
OS_DISK_ID=$(az vm show -g "$RG" -n "$VM_NAME" --query "storageProfile.osDisk.managedDisk.id" -o tsv)
# 스냅샷 생성
az snapshot create \
-g "$RG" \
-n "$SNAP_NAME" \
--source "$OS_DISK_ID"
스냅샷은 “되돌릴 수 있는 지점”을 만들어줍니다. 복구 작업 중 실수해도 다시 시작할 수 있습니다.
4) 가장 실전적인 복구: 복구 VM에 OS 디스크를 붙여 오프라인 수정
부팅이 안 되면 VM 내부에서 수정할 수 없습니다. 이때는 별도 복구 VM을 만들고, 문제의 OS 디스크를 데이터 디스크로 연결해 수정합니다.
절차 개요
- 문제 VM을 Stop(Deallocate)
- OS 디스크를 분리하거나, 스냅샷에서 새 Managed Disk 생성
- 복구 VM(같은 리전, 같은 가용성 요구사항)을 준비
- 복구 VM에 문제 디스크를 데이터 디스크로 Attach
- 복구 VM에서 마운트 후 설정 수정
- 원래 VM에 디스크를 다시 연결하거나 새 디스크로 교체
운영 환경에서는 “원본 디스크를 직접 수정”하기보다, 스냅샷에서 새 디스크를 만들어 그 디스크를 수정한 뒤 교체하는 방식이 더 안전합니다.
복구 VM에서 디스크 마운트 예시(리눅스)
# 디스크 확인
lsblk
# 예: /dev/sdc1 이 루트 파티션이라고 가정
sudo mkdir -p /mnt/rescue
sudo mount /dev/sdc1 /mnt/rescue
# 부팅 관련 파일을 수정하려면 /boot, /boot/efi도 필요할 수 있음
# 예: EFI 파티션이 /dev/sdc15 라면
sudo mkdir -p /mnt/rescue/boot/efi
sudo mount /dev/sdc15 /mnt/rescue/boot/efi
이제 /mnt/rescue 아래가 “부팅 불가 VM의 파일시스템”입니다.
5) 원인별 복구 시나리오
여기부터는 Boot Diagnostics에서 얻은 단서를 바탕으로 가장 흔한 케이스를 빠르게 처리하는 방법입니다.
케이스 A: fstab 오기재로 Emergency mode
특정 디스크 UUID가 바뀌었거나, 존재하지 않는 마운트 대상을 fstab에 넣으면 부팅이 멈춥니다.
복구 VM에서 다음을 확인합니다.
# fstab 확인
sudo sed -n '1,200p' /mnt/rescue/etc/fstab
# 실제 UUID 확인
sudo blkid
대응 방법
- 잘못된 라인을 주석 처리
nofail,x-systemd.device-timeout=10s같은 옵션으로 부팅 연속성 확보
예시(오프라인 수정)
sudo nano /mnt/rescue/etc/fstab
수정 후에는 마운트 테스트를 해보는 것이 좋습니다.
# 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
mount -a
exit
케이스 B: 디스크 100퍼센트로 부팅 실패 또는 서비스 실패
루트 파티션이 꽉 차면 systemd가 임시 파일을 만들지 못해 부팅이 비정상 종료되거나, 부팅은 되지만 핵심 서비스가 올라오지 않을 수 있습니다.
오프라인에서 용량을 확보합니다.
sudo du -sh /mnt/rescue/var/log/* 2>/dev/null | sort -h | tail
sudo du -sh /mnt/rescue/var/* 2>/dev/null | sort -h | tail
로그가 폭증한 경우 오래된 로그 정리, 저널 크기 제한 등을 적용합니다.
# 예: 오래된 압축 로그 삭제(환경에 맞게 신중히)
sudo rm -f /mnt/rescue/var/log/*.gz
sudo rm -f /mnt/rescue/var/log/*.[0-9]
디스크를 지웠는데도 용량이 안 줄어드는 대표 원인은 “삭제된 파일을 어떤 프로세스가 계속 잡고 있는 상황”입니다. 부팅이 되는 상태라면 lsof로 추적하는 접근이 유효합니다. 관련해서는 리눅스 디스크 100%인데 삭제해도 용량이 안 줄 때(lsof) 글의 점검 흐름을 같이 참고하면 좋습니다.
케이스 C: 커널 업데이트 후 Kernel panic 또는 initramfs 문제
커널 업데이트 이후 드라이버 모듈 문제나 initramfs 생성 실패로 부팅이 깨지는 경우가 있습니다.
Boot Diagnostics 로그에서 커널 패닉 메시지나 특정 커널 버전에서만 실패하는 흔적이 보이면, 복구 VM에서 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
# 배포판에 맞는 명령 사용
# Ubuntu/Debian 계열 예시
update-initramfs -u -k all
update-grub
exit
가능하면 “마지막으로 정상 부팅되던 커널”을 기본값으로 되돌리고, 문제가 된 커널을 제거하는 것도 방법입니다.
케이스 D: SSH만 안 되는 경우(부팅은 됨)
Boot Diagnostics 스크린샷에 로그인 프롬프트가 보이거나, 시리얼 로그가 정상적으로 Reached target을 지나는데 SSH만 실패한다면 OS 부팅 문제라기보다 네트워크 또는 SSH 설정 문제일 수 있습니다.
점검 포인트
- NSG 인바운드 22 허용 여부
- NIC에 Public IP가 붙어 있는지, 또는 Bastion 경유인지
sshd_config설정 오류, 키/권한 문제- 클라우드 에이전트(예: waagent) 상태
이 경우에도 복구 VM에 디스크를 붙여 /etc/ssh/sshd_config, /etc/hosts.allow, /etc/hosts.deny, 방화벽 설정 등을 오프라인으로 확인할 수 있습니다.
6) Boot Diagnostics를 더 잘 쓰는 운영 팁
Serial Console과 함께 쓰기
Boot Diagnostics가 “로그를 남기는 것”이라면, Serial Console은 “직접 조작”에 가깝습니다. 조직 보안 정책상 막혀 있는 경우도 있지만, 허용된다면 다음 상황에서 특히 유용합니다.
- 네트워크 단절로 SSH가 불가능할 때
- 부팅은 됐는데 인증/키 문제로 접속이 막혔을 때
- GRUB에서 커널 파라미터를 임시로 바꿔 부팅을 시도할 때
다만 이 글의 핵심은 Boot Diagnostics 기반 복구이므로, Serial Console은 보조 수단으로만 두는 편이 안전합니다.
장애 타임라인 만들기
부팅 장애는 “직전에 무슨 변경이 있었는지”가 절반입니다.
- 마지막 패키지 업데이트 시간
- 디스크 확장, 파티션 변경, 마운트 변경
- 보안 에이전트 설치/업데이트
- 커널/드라이버 업데이트
이런 변경 이력을 남겨두면 Boot Diagnostics 로그와 결합해 원인 규명이 빨라집니다.
CI나 자동화 변경이 원인이 되는 경우도 많습니다. 예를 들어 캐시 미스나 락파일 변화로 배포 산출물이 달라지는 이슈처럼, “겉보기엔 동일한 배포인데 결과가 달라지는 상황”이 장애로 이어질 수 있습니다. 배포 파이프라인 쪽 점검은 GitHub Actions 캐시 미적중 원인 - key·restore-keys·락파일도 함께 참고할 만합니다.
7) 복구 후 검증 체크리스트
디스크를 원래 VM에 되돌린 뒤에는 “부팅만 되면 끝”이 아니라, 다음을 확인해야 재발을 줄일 수 있습니다.
- 부팅 직후
dmesg,journalctl -b에 디스크 오류가 없는지 systemctl --failed로 실패 유닛 확인/etc/fstab의 불필요한 마운트 제거 또는nofail적용- 루트 디스크 여유 공간 확보 및 로그 로테이션 정책 점검
- 커널/드라이버 업데이트 정책(자동 업데이트 범위) 재검토
- 백업 및 스냅샷 정책(주기, 보존 기간, 복구 리허설)
8) 정리: Boot Diagnostics는 “복구의 시작점”이다
Azure VM 부팅불가 상황에서 Boot Diagnostics는 단순한 옵션이 아니라, 장애 대응의 출발점입니다.
- 스크린샷으로 멈춘 단계 파악
- 시리얼 로그로 실패 원인 후보를 좁힘
- 스냅샷으로 안전장치 확보
- 복구 VM에 디스크를 붙여 오프라인으로 수정
이 흐름을 표준 운영 절차로 만들어두면, 새벽 장애에서도 “감으로 재부팅 반복”하는 대신 재현 가능하고 안전한 복구가 가능합니다.