Ubuntu 26.04 강좌 / 부팅·커널·네트워크 장애 복구하기

Ubuntu 장애 복구는 먼저 콘솔에서 어디까지 부팅되는지 확인하고 직전 변경과 로그를 보존한 뒤 범위를 좁힙니다. SSH에 연결되지 않는다는 이유만으로 운영체제가 부팅되지 않았다고 판단할 수는 없습니다. 부팅·커널·네트워크·앱을 나누어 조사하고 되돌릴 설정을 하나씩 선택합니다. 관련 조건과 절차는 리눅스 로그로 장애 원인 좁히기에서 확인할 수 있습니다. 관련 조건과 절차는 장애를 재현하고 증거로 복구하는 종합 실습에서 확인할 수 있습니다.

장애 단계와 변경할 대상을 구분하기

가능하면 복구 전에 상태를 보존하고 기존 백업과 암호화 해제 키를 확보합니다. 실습을 위해 운영 서버의 디스크나 네트워크를 고의로 망가뜨리지 않습니다. 조사 기록에는 시각·오류 원문·마지막으로 성공한 작업·직전 변경을 남기고 비밀 키나 인증 정보는 넣지 않습니다.

로그인할 수 있을 때 읽기 전용으로 조사하기

cat /etc/os-release
uname -r
systemctl --failed
df -h
lsblk -f
findmnt /
sudo journalctl --list-boots
sudo journalctl -b -p err --no-pager

이전 부팅 기록이 있으면 sudo journalctl -b -1 -p err --no-pager로 비교합니다. 과거 로그가 없다는 사실은 장애가 없었다는 증거가 아닙니다. 디스크가 가득 차도 로그를 일괄 삭제하지 말고 원인과 저장 위치를 확인해 필요한 기록을 보존합니다. 오류 행만으로 인과 관계를 알기 어려우면 해당 시각 전후와 유닛별 기록을 조사합니다.

복제 VM에서 제한된 서비스 실패와 복원 연습하기

원본과 격리한 연습 VM에서 콘솔로 로그인해 수행합니다. 아래 새 unit은 부팅에 활성화하지 않고 파일을 지우거나 네트워크를 바꾸지도 않습니다. 먼저 정상 실행을 확인한 뒤 false를 사용하는 drop-in으로 의도한 실패를 만들고 그 파일만 제거해 복원합니다. 이 실습은 서비스 진단 경로이며 실제 커널·부팅 장애까지 재현한 것은 아닙니다.

(
set -eu
unit=ubuntu-recovery-lab.service
file=/etc/systemd/system/$unit
drop=/etc/systemd/system/$unit.d
if sudo test -e "$file" || sudo test -L "$file" || sudo test -e "$drop"; then
    printf 'Lab unit already exists; choose a new name.\n' >&2
    exit 1
fi
sudo sh -c 'set -C; cat > "$1"' sh "$file" <<'EOF'
[Unit]
Description=Bounded Ubuntu recovery exercise
[Service]
Type=oneshot
ExecStart=/usr/bin/true
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
sudo systemctl start "$unit"
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo install -d -m 0755 "$drop"
sudo sh -c 'set -C; cat > "$1/10-failure.conf"' sh "$drop" <<'EOF'
[Service]
ExecStart=
ExecStart=/usr/bin/false
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
if sudo systemctl start "$unit"; then
    printf 'Unexpected success: inspect the loaded unit.\n' >&2
    exit 1
fi
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo journalctl -u "$unit" --since '5 minutes ago' --no-pager
)

기준 실행은 Result=success·ExecMainStatus=0, 실패 실습은 Result=exit-code·ExecMainStatus=1을 기대합니다. oneshot의 inactive와 실패를 구분하고 journal의 실패 시각·실행 명령을 비교합니다. 다음 복원은 이 파일을 방금 만들었고 이후 편집이 없는 조건에서만 실행합니다.

(
set -eu
sudo rm -- /etc/systemd/system/ubuntu-recovery-lab.service.d/10-failure.conf
sudo systemctl daemon-reload
sudo systemctl reset-failed ubuntu-recovery-lab.service
sudo systemctl start ubuntu-recovery-lab.service
sudo systemctl show ubuntu-recovery-lab.service -p Result -p ExecMainStatus
)

다시 success·0인지 확인합니다. 완전히 정리하려면 unit이 이번 실습 파일인지와 비활성 상태를 확인하고 빈 drop-in 디렉터리와 unit만 제거한 뒤 daemon-reload합니다. 실제 부팅 장애의 이전 커널·복구 모드 판단은 아래 절차와 구분해 기록합니다.

업데이트 뒤 부팅 실패와 이전 커널 확인하기

업데이트 직후 부팅이 실패하고 GRUB과 이전 커널을 사용할 수 있다면 콘솔의 Advanced options for Ubuntu에서 이전 커널을 선택해 부팅을 시험합니다. GRUB 표시 방법은 펌웨어·호스트·타이밍에 따라 달라 VM 콘솔이나 기기의 부팅 조작 방법을 확인해야 합니다. 암호화 디스크는 여전히 해제가 필요합니다.

이전 커널로 부팅되면 uname -r을 기록하고 업데이트 이력·해당 커널 로그·관련 드라이버와 DKMS 상태를 비교합니다. 이 결과만으로 새 커널이 유일한 원인이라고 단정하지 않습니다. 실행 중인 커널과 정상 부팅용 커널을 보존하고 확인한 원인에 맞게 수정한 뒤 일반 부팅을 확인합니다.

Ubuntu Wiki의 Recovery mode 안내에서 GRUB 복구 메뉴와 사전 조건을 확인할 수 있습니다.

초기 RAM 디스크 도구를 구분하기

26.04의 기본 초기 RAM 디스크 기반은 Dracut으로 전환되었지만 기존 initramfs-tools 구성도 있을 수 있습니다. 부팅 복구에서 다른 LTS 문서의 재생성 명령을 바로 실행하지 말고 실제 설치 도구와 /boot의 부팅 자료부터 확인합니다.

dpkg-query -W dracut dracut-core initramfs-tools 2>/dev/null
command -v dracut update-initramfs
ls -lh /boot

도구가 설치되어 있다는 사실만으로 현재 부팅 이미지가 그 도구로 만들어졌다고 단정하지 않습니다. 암호화·LVM·RAID와 선택 커널에 맞는 설정 및 공식 복구 안내를 확인하고, 재생성 전에 정상 커널·콘솔·백업을 보존합니다.

Ubuntu 26.04의 Dracut 전환 설명

복구 모드에서도 확인 후 쓰기를 허용하기

복구 메뉴의 root 셸은 강한 권한을 가지며 일반 로그인과 다릅니다. 디스크 인식·여유 공간·마운트 상태·수정할 파일을 먼저 확인합니다. 루트 파일 시스템이 읽기 전용이고 실제 설정 수정에 쓰기가 필요한 경우에만 복구 셸에서 다음 작업을 검토합니다.

findmnt /
mount -o remount,rw /

복구 셸에서는 root로 실행하므로 sudo를 붙이지 않았습니다. 파일 시스템 손상이나 입출력 오류가 있으면 쓰기를 반복하지 말고 자료 보존과 구성에 맞는 구조 절차를 우선합니다. 마운트된 파일 시스템에 수정 모드 fsck를 실행하거나 대상이 불명확한 디스크를 초기화하지 않습니다.

네트워크 설정 변경 후 연결이 끊겼을 때

ip -br address
ip route
resolvectl status
sudo netplan get
systemctl is-active NetworkManager systemd-networkd
sudo ss -lntp

콘솔에서 실제 인터페이스·관리 주체·유효한 Netplan 설정을 확인합니다. 가장 최근 바꾼 파일을 변경 전 백업과 비교하고 다른 이름의 YAML 파일을 추가해 덮어쓰려 하지 않습니다. cloud-init 등에서 생성하는 설정인지도 확인합니다.

올바른 백업으로 되돌릴 때는 현재 설정도 보존하고 netplan generate가 성공한 뒤 콘솔을 확보한 상태에서 sudo netplan try --timeout 120을 사용합니다. 자동 복귀가 실패할 수도 있으므로 실제 주소·경로·DNS와 새 SSH 연결을 별도로 확인합니다. 네트워크가 정상이라면 SSH 키·대기 포트·UFW도 각각 조사합니다.

netplan try의 제약과 복귀 후 확인 사항은 26.04 매뉴얼을 확인하세요.

자료 보존과 복구 완료 판단하기

설치된 운영체제에서 조작할 수 없으면 검증한 Live ISO 등 복구 환경을 검토합니다. 디스크 접근 전에 암호화·LVM·RAID를 확인하고 원본을 설치 대상으로 잘못 선택하지 않습니다. 범용 GRUB 재설치나 파티션 재생성 명령을 추측해 실행하지 말고 실제 구성에 맞는 절차와 검증된 백업을 선택합니다.

복구 후 재부팅·새 SSH 연결·서비스·앱 읽기와 쓰기·로그·백업을 확인합니다. 무엇을 되돌렸고 무엇이 개선되었는지, 미해결 사항과 재발 시 수집할 기록을 남깁니다. 응답이 돌아온 순간보다 정상 운영을 지속할 수 있는지가 복구 완료의 기준입니다.