우분투 서버 비상 모드 부팅: 단계별 복구 가이드

업데이트 또는 정전 후 Ubuntu 서버가 재시작된 다음 "비상 모드 진입" 메시지가 표시되고 멈춥니다. SSH에 접속할 수 없고, 서비스가 중단되며, 콘솔에 유지 보수 요청 메시지가 나타납니다. 이는 일반적으로 systemd가 필수 부팅 단계를 완료하지 못했음을 의미하며, 파일 시스템 검사 실패 또는 필수 마운트 위치를 찾을 수 없는 경우가 많습니다. 이 메시지를 단서로 활용하여 파일 편집이나 복구 명령 실행 전에 오류가 발생한 부분을 확인하십시오.

이 가이드는 systemd를 사용하는 일반적인 Ubuntu Server 설치에 적용됩니다. Ubuntu Core, 암호화된 시스템, 클라우드 이미지 및 공급자 관리 서버에서는 명령 및 부팅 메뉴가 다를 수 있습니다. 최신 Ubuntu 매뉴얼 페이지에서는 emergency.target을 일반 서비스를 시작하거나 일반 파일 시스템을 마운트하지 않는 최소한의 셸로 설명합니다. 접근 경로에 따라 루트 파일 시스템은 읽기 전용 또는 읽기/쓰기 권한을 가질 수 있습니다. 따라서 첫 번째 단계는 검사 및 백업입니다.

1. 변경하기 전에 오류 원인을 먼저 읽으십시오.

메시지가 표시되면 로컬 콘솔 또는 공급자 콘솔에 로그인하십시오. 물리적 머신에서는 키보드와 모니터를 연결하고, 가상 서버에서는 공급자의 직렬 콘솔 또는 복구 콘솔을 사용하십시오. 전체 오류 메시지, 특히 와 같은 장치 이름 systemd-fsck@dev-disk-by-uuid-....service이나 로 끝나는 마운트 장치를 사진으로 찍거나 복사하십시오 .mount. UUID 누락, 파일 시스템 검사 실패 및 서비스 오류는 각각 다른 해결 방법이 필요합니다.

비상 셸에서 오류가 발생한 장치와 현재 부팅 로그를 확인하십시오.

systemctl --failed
journalctl -xb

마지막 "종속성 실패" 줄뿐만 아니라 의미 있는 첫 번째 오류를 찾으십시오. 로그에 마운트가 식별되면 마운트 지점과 장치 UUID를 기록해 두십시오. 스토리지와 관련 없는 서비스가 식별되면 /etc/fstab임의로 변경하지 말고 해당 특정 장치와 systemctl status unit-name최근 로그 메시지를 검사하십시오.

2. 루트 파일 시스템에서 편집이 허용되는지 확인하십시오.

설정 파일을 편집하기 전에 루트 파일 시스템이 어떻게 마운트되는지 확인하십시오.

findmnt /

옵션이 표시되면 ro루트 파일 시스템은 읽기 전용입니다. 파일 시스템에 다른 문제는 없고 간단한 구성 수정이 필요한 경우 읽기/쓰기 모드로 다시 마운트하십시오.

mount -o remount,rw /

변경 사항을 확인하려면 다시 실행하십시오 findmnt /. 재마운트가 실패하면 중지하고 오류를 기록하십시오. 읽기 전용 루트는 파일 시스템 문제에 대한 보호 조치일 수 있습니다. 쓰기를 강제하거나 마운트를 반복적으로 재시도하면 복구가 더 어려워질 수 있습니다. 루트 볼륨이 손상된 것으로 보이면 복구 환경을 사용하거나 공급업체의 지원을 받으십시오.

3. 디스크를 검사하고 /etc/fstab 파일과 비교하십시오.

일반적인 원인은 오래된 /etc/fstab항목입니다. 디스크가 제거되었거나, UUID가 변경되었거나, 마운트 경로가 잘못 입력되었을 수 있습니다. 먼저 감지된 파일 시스템과 해당 식별자 목록을 표시합니다.

lsblk -f
blkid

다음으로 마운트 테이블 구성을 읽어보세요.

cat /etc/fstab

lsblk -f구성된 각 UUID를 또는 명령의 출력과 비교하여 blkid마운트 지점과 파일 시스템 유형이 올바른지 확인하십시오. /dev/sdb1현재 문자만으로 장치 이름을 대체하지 마십시오. 장치 순서는 변경될 수 있습니다. UUID는 일반적으로 더 안정적이지만 실제 파일 시스템과 일치해야 합니다.

이 /etc/fstab파일은 부팅 시 systemd 마운트 단위로 변환됩니다. 파일의 필드와 옵션은 특정한 의미를 가지므로, 익숙하지 않은 항목이 있으면 Ubuntu 공식 fstab 설명서를 참조하십시오.

4. 선택 사항이지만 누락된 마운트를 일시적으로 우회합니다.

오류가 발생하는 항목이 의도적으로 누락된 비필수 데이터 디스크를 가리키는 경우, 해당 항목을 백업한 /etc/fstab다음 해당 줄의 시작 부분에 주석 처리를 하여 해당 줄만 주석 처리 #하십시오. 이렇게 하면 누락된 마운트가 부팅 차단 요인인지 테스트할 수 있습니다. 시스템의 저장소 구조를 이해하지 못하는 한 루트 파일 시스템이나 암호화된 볼륨 항목은 주석 처리하지 마십시오 /boot.

cp -a /etc/fstab /etc/fstab.before-emergency-fix
nano /etc/fstab

또는 일반적인 작동에서 디스크가 선택 사항이어야 하는 경우, nofail의도된 동작을 확인한 후 마운트 옵션을 고려하십시오. 이 옵션은 정말로 선택적인 마운트에만 사용하십시오. 필수 시스템 볼륨에 이 옵션을 추가하면 실제 스토리지 오류를 숨길 수 있습니다. 네트워크 파일 시스템에는 추가적인 systemd 관련 옵션과 네트워크 종속성이 필요할 수 있으므로, 관련 없는 설정에서 옵션을 복사하지 마십시오.

편집 후 systemd에게 생성된 유닛을 다시 로드하도록 요청하고 파일을 테스트하십시오.

systemctl daemon-reload
mount -a

모든 출력을 읽으십시오. 오류가 없이 반환되었다고 해서 모든 애플리케이션이 마운트된 데이터를 사용할 수 있다는 것을 보장하는 것은 아니지만, UUID, 구문 또는 마운트 오류가 보고되면 수정해야 할 부분이 무엇인지 알 수 있습니다. systemd-fstab-generator 설명서는 systemd가 fstab 항목을 마운트 단위로 변환하는 방법을 설명합니다.

5. 잘못된 UUID, 경로 또는 마운트 옵션을 수정합니다.

디스크는 존재하지만 UUID가 다른 경우, 해당 필드를 업데이트하기 전에 올바른 파일 시스템을 식별했는지 확인하십시오 UUID=.... 마운트 지점 디렉터리가 있는지, 파일 시스템 유형이 정확한지, 해당 파일 시스템에 대해 옵션이 유효한지 확인하십시오. 한 번에 하나의 항목만 수정하고 다시 실행 systemctl daemon-reload하십시오 mount -a.

선택 사항인 이동식 또는 보조 데이터 디스크의 경우, 적절한 선택적 마운트 정책을 설정하면 장치가 없어 부팅이 차단되는 것을 방지할 수 있습니다. 중요한 볼륨의 경우, 오류를 숨기지 말고 장치, 케이블, 암호화 매핑 또는 식별자를 수정하십시오. 오류가 발생한 장치가 LUKS 또는 LVM 장치인 경우, 관련 매핑 및 볼륨 상태를 검사하고, 해당 UUID를 유사한 이름의 파티션으로 대체하지 마십시오.

6. 대상이 마운트 해제된 경우에만 파일 시스템 검사를 실행하십시오.

콘솔에 파일 시스템 오류가 구체적으로 보고되면 복구하기 전에 파일 시스템 유형과 장치를 확인하십시오. 마운트된 파일 시스템, 특히 활성 루트 파일 시스템에 대해서는 복구 유틸리티를 실행하지 마십시오. Ubuntu fsck 설명서에는 래퍼 명령에 대한 설명이 나와 있으며, 올바른 검사 및 복구 옵션은 파일 시스템에 따라 다릅니다.

ext2, ext3 또는 ext4 데이터 파티션의 경우, 먼저 `--mounted` 명령으로 마운트되어 있지 않은지 확인하십시오 findmnt. 마운트되어 있다면 확인하기 전에 마운트를 해제하십시오. 적절한 복구 환경에서 ext4 파티션을 확인하는 일반적인 방법은 다음과 같습니다.

sudo e2fsck -f /dev/DEVICE

/dev/DEVICE올바른 파티션을 찾은 후에만 교체하십시오 lsblk -f. 검사기의 질문과 상태를 읽고, 데이터 손실 위험을 제대로 이해하지 못한 채 "모든 항목에 예" 옵션을 자동으로 선택하지 마십시오. 실행 중인 비상 셸에서 마운트 해제할 수 없는 루트 파일 시스템의 경우, 라이브 또는 공급자 복구 환경으로 부팅하여 오프라인 상태에서 확인하십시오. Btrfs, XFS 및 기타 파일 시스템은 서로 다른 도구와 복구 절차를 사용합니다. 특히, 일반적인 fsck명령어를 모든 파일 시스템 유형이 복구되었다는 증거로 간주하지 마십시오.

7. GRUB 또는 외부 복구는 셸을 사용할 수 없는 경우에만 사용하십시오.

서버가 비상 셸에 도달하지 못하면 GRUB 메뉴를 열고 배포판의 복구 항목이 있는 경우 해당 항목을 시도하십시오. 일반적인 Ubuntu 설치에서는 레거시 BIOS 시스템에서는 Shift 키를 누른 상태로, UEFI 시스템에서는 Esc 키를 눌러 메뉴에 접근할 수 있지만, 호스팅된 가상 머신은 다른 콘솔 흐름을 사용할 수 있습니다. 일회성 systemd 비상 부팅을 위해 관리자는 선택한 GRUB 항목을 편집하고 systemd.unit=emergency.targetLinux 커널 명령줄에 추가할 수 있습니다. 이 변경 사항은 해당 부팅에만 적용되므로 다음 정상 부팅 전에 제거해야 합니다. 자세한 내용은 공식 GNU GRUB 메뉴 참조를 확인하십시오 .

부팅 볼륨을 마운트할 수 없는 경우, 라이브 Ubuntu 환경이나 클라우드 제공업체의 복구 시스템을 사용하여 볼륨을 검사하십시오. 암호화된 저장소의 잠금을 해제하고 LVM을 활성화하는 것은 설치 환경과 일치하는 경우에만 수행하십시오. 복구 모드에서 서버의 루트 파일 시스템을 마운트하는 것은 추가적인 위험을 수반하므로, 디스크와 파일 시스템이 확인될 때까지 해당 시스템에 쓰기 작업을 수행하지 마십시오. Ubuntu Core는 자체적인 복구 워크플로를 사용하며, 데스크톱이나 기존 서버 GRUB 복구 절차를 그대로 따라 해서는 복구가 불가능합니다.

8. 재부팅 후 수리 완료 여부를 확인합니다.

보고된 원인이 해결되고 마운트 테스트가 통과되면 재부팅하십시오.

reboot

시작 후 호스트가 평소와 같이 다중 사용자 대상에 도달했는지, 예상되는 파일 시스템이 마운트되었는지, 중요한 서비스가 활성화되었는지 확인하십시오.

systemctl is-system-running
systemctl --failed
findmnt --target /

`check_data_mount_points` 명령어를 사용하여 예상되는 데이터 마운트 지점을 확인하고 findmnt /path/to/mount, `check_critical_services` 명령어를 사용하여 중요 서비스를 확인하십시오 systemctl status service-name. 비상 모드가 다시 활성화되면 동일한 복구 작업을 반복하는 대신 새 부팅 시 발생한 첫 번째 오류를 다시 검토하십시오. 복구 성공은 서버가 정상적으로 부팅되고 필요한 스토리지 및 서비스에 접근할 수 있음을 의미합니다. 단순히 로그인 프롬프트가 나타나는 것만으로는 충분하지 않습니다.

현재 systemd 동작에 대한 자세한 내용은 Ubuntu 특수 유닛 설명서를 참조하십시오 . 패키지 버전 및 복구 메뉴는 Ubuntu 릴리스 및 호스팅 플랫폼에 따라 다를 수 있으므로 명령이나 유닛이 다를 경우 설치된 릴리스의 설명서를 참조하십시오.