버전 업그레이드 명령어

잡동사니

작성일 2020-05-26 최근 수정일 2026-11-03

Ubuntu Server의 운영체제 릴리스를 다음 버전으로 올릴 때는 sudo do-release-upgrade를 사용합니다. 현재 버전의 패키지를 먼저 최신 상태로 만들고, 지원되는 업그레이드 경로와 복원 가능한 백업을 확인한 뒤 진행해야 합니다.

패키지 업데이트와 릴리스 업그레이드의 차이

do-release-upgrade는 Ubuntu의 기본 패키지 구성과 시스템 설정을 다음 릴리스에 맞게 전환하는 도구입니다. 패키지 목록을 갱신하는 apt update나 현재 릴리스의 패키지를 갱신하는 apt upgrade와 목적이 다릅니다. 일상적인 패키지 관리는 Ubuntu Server의 apt 사용법을 참고하세요.

장기 지원 릴리스인 LTS(Long Term Support)는 바로 다음 LTS로 순서대로 업그레이드합니다. 예를 들어 22.04 LTS에서 26.04 LTS로 이동하려면 24.04 LTS를 거쳐 각 단계의 동작을 확인해야 합니다. 버전을 건너뛰려고 저장소의 코드명을 일괄 변경하지 마세요. 지원 경로와 지원 기간은 Ubuntu 릴리스 주기에서 확인할 수 있습니다.

새 LTS가 나왔다고 모든 기존 서버에 즉시 업그레이드가 제공되는 것은 아닙니다. LTS 간 업그레이드는 일반적으로 첫 번째 포인트 릴리스 이후 제공되며, 실제 제공 여부는 업그레이드 도구의 확인 결과를 따릅니다. 이미 지원이 끝난 릴리스는 아래 절차가 그대로 통한다고 가정하지 말고 별도의 복구·이전 계획을 세우세요.

시작 전에 백업과 복구 접속 준비하기

서비스 중단 시간을 확보하고, 관리자 권한을 가진 계정으로 작업합니다. 목표 Ubuntu 버전의 릴리스 노트와 애플리케이션 지원 조건도 확인하세요. 웹 서버가 부팅되는 것과 사용 중인 PHP·데이터베이스·확장 모듈이 정상 동작하는 것은 별개의 확인 항목입니다.

백업: 서비스 데이터, 데이터베이스, /etc의 설정, 인증서와 복구에 필요한 비밀정보를 안전한 별도 위치에 보관합니다. 데이터베이스는 해당 제품의 일관성 있는 백업 방법을 사용하고 복원 가능 여부를 확인합니다. 실행 중인 가상 머신의 스냅샷만으로 데이터베이스의 일관성이 보장된다고 판단하지 않습니다.
복구 접속: 물리 콘솔, 원격 관리 콘솔 또는 클라우드 직렬 콘솔처럼 SSH(Secure Shell) 연결이 끊겨도 접근할 방법을 준비하고 실제로 접속할 수 있는지 확인합니다. SSH로 진행할 수 있어도 SSH 하나만을 복구 수단으로 삼지 않습니다.
클라우드 조건: 제공 업체의 이미지·커널·부팅 방식과 관리 에이전트 지원 조건을 확인합니다. 클라우드 서버가 모두 인플레이스 업그레이드를 금지하는 것은 아닙니다. 복원이 어렵거나 서비스 호환성을 먼저 검증해야 한다면 새 서버를 구축해 데이터를 이전하는 방법도 비교합니다.

다음 명령은 현재 릴리스, 파일 시스템의 여유 공간·아이노드, 불완전한 패키지 상태와 보류된 패키지를 확인합니다. 아래 명령들은 업그레이드를 시작하지 않습니다.

cat /etc/os-release
uname -r
df -h / /boot
df -i / /boot
sudo dpkg --audit
apt-mark showhold

VERSION_ID를 기록하고, /와 /boot의 공간 부족을 먼저 해결하세요. 필요한 공간은 설치 구성과 변경 계획에 따라 달라집니다. dpkg --audit에 문제가 표시되면 먼저 조사하고, 보류된 패키지도 이유를 확인한 뒤 처리합니다. 업그레이드를 통과시키려고 보류를 일괄 해제하지 마세요.

현재 릴리스 업데이트와 대상 설정 확인하기

현재 릴리스의 패키지 목록을 갱신한 뒤 모든 업데이트를 적용합니다. 다음은 Ubuntu Server 공식 업그레이드 절차에 안내된 준비 명령입니다.

sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true

dist-upgrade는 현재 설정된 저장소에서 의존성을 조정하며 패키지를 제거할 수도 있습니다. 실행 계획을 읽고 예상하지 못한 중요 패키지 삭제가 있으면 진행하지 마세요. 위 옵션은 단계적 배포 중인 업데이트도 포함하며, 이 명령 자체가 Ubuntu 릴리스를 바꾸는 것은 아닙니다. 두 명령이 성공하고 미적용 업데이트가 없는 상태를 먼저 만듭니다.

/run/reboot-required 파일이 있는지 확인합니다. 파일이 있으면 현재 업데이트를 마무리하기 위한 재부팅이 필요합니다.

if [ -f /run/reboot-required ]; then
    cat /run/reboot-required
fi

재부팅이 필요한 경우 작업 시간 안에 sudo reboot를 실행하고 다시 접속하여 서비스 상태를 확인한 뒤 다음 단계로 이동합니다. 파일이 없다고 애플리케이션 검증까지 끝난 것은 아닙니다.

do-release-upgrade 명령이 없으면 명령을 제공하는 패키지를 설치하고, 릴리스 알림 정책을 확인합니다.

sudo apt install ubuntu-release-upgrader-core
cat /etc/update-manager/release-upgrades

이미 명령이 있다면 설치 단계는 생략해도 됩니다. LTS 서버를 다음 LTS로 유지하려면 설정 파일의 Prompt=lts를 사용합니다. Prompt=normal은 중간 릴리스도 확인하는 정책이며, 버전을 건너뛰게 하는 옵션이 아닙니다. 변경이 필요하면 기존 파일을 별도 이름으로 백업하고 sudoedit /etc/update-manager/release-upgrades로 해당 항목만 수정하세요. 정책의 차이는 Ubuntu의 LTS·중간 릴리스 전환 안내에 설명되어 있습니다.

업그레이드 대상 확인 후 실행하기

먼저 업그레이드 가능한 릴리스가 있는지 확인합니다. -c는 확인 후 종료하는 옵션으로 실제 업그레이드를 시작하지 않으며, 애플리케이션 호환성까지 시험하는 기능은 아닙니다.

sudo do-release-upgrade -c

대상이 없다고 나오면 현재 버전과 지원 경로, Prompt 설정, 미적용 업데이트, 네트워크 및 릴리스 제공 상태를 확인합니다. do-release-upgrade 매뉴얼의 -d는 개발 릴리스를 확인하는 옵션이며, 첫 포인트 릴리스 전 새 LTS 평가에도 쓰일 수 있습니다. 운영 서버에서 “새 버전이 없다”는 메시지를 없애기 위해 무조건 붙이지 마세요.

백업·복구 준비를 마쳤고 제시되는 대상이 계획과 일치하면 다음 명령으로 시작합니다. 자동 승인 옵션을 붙이지 말고 질문에 응답할 수 있는 상태에서 작업하세요.

sudo do-release-upgrade

변경 요약: 대상 릴리스, 제거·설치할 패키지, 다운로드 크기와 필요 공간을 검토합니다. 중요 서비스가 제거되는 등 계획과 다르면 진행 승인 전에 중단하고 원인을 해결합니다. 패키지 설치가 시작된 뒤에는 프로세스를 강제 종료하거나 전원을 끄지 않습니다.
설정 파일 질문: 기존 설정과 패키지 제공 설정의 차이를 보고 결정합니다. 차이 보기와 유지·교체 선택은 실제 화면의 안내를 따릅니다. 모든 설정을 무조건 유지하거나 교체하면 기존 서비스 설정 또는 새 버전의 필수 변경을 놓칠 수 있습니다.
외부 저장소와 접속: PPA(Personal Package Archive)와 서드파티 저장소는 업그레이드 중 비활성화됩니다. 별도 복구용 SSH 포트가 안내되는 경우에는 실제 안내에 맞춰 방화벽·클라우드 보안 규칙을 검토하고 관리자 접근 범위로 제한합니다. 방화벽 전체를 끄거나 불필요한 포트를 상시 개방하지 않습니다.

오래된 패키지 삭제 질문도 목록을 읽고 판단합니다. 완료 후 재부팅 안내가 나오면 서비스 중단 시간 안에 재부팅하고, 콘솔 접근은 사후 확인이 끝날 때까지 유지합니다.

재부팅 후 버전과 서비스 확인하기

다시 접속해 목표 릴리스로 전환되었는지와 실패한 서비스가 있는지 확인합니다. 커널 버전은 업그레이드 전 기록 또는 목표 릴리스의 패키지 정보와 비교하고, 패키지 목록도 다시 갱신합니다.

cat /etc/os-release
uname -r
systemctl --failed
sudo apt update
apt list --upgradable

VERSION_ID가 목표 값인지 확인하고, systemctl --failed에 실패 항목이 있다면 개별 원인을 조사합니다. 실패 항목이 없더라도 웹 페이지 응답, 데이터베이스 읽기·쓰기, 예약 작업, 모니터링과 백업 작업을 실제 서비스 기준으로 확인해야 합니다. 새 SSH 세션도 연결해 본 뒤 복구 콘솔을 닫으세요.

외부 저장소는 새 Ubuntu 릴리스 지원 여부와 설치된 패키지의 호환성을 확인한 뒤 필요한 것만 다시 설정합니다. 이전 코드명의 저장소를 한꺼번에 활성화하지 마세요. 추가 정리는 서비스가 안정적으로 동작하는 것을 확인한 뒤 삭제 예정 패키지를 검토하며 진행합니다.

오류와 접속 중단에 대응하기

오류가 나면 마지막 메시지와 /var/log/dist-upgrade/의 로그를 보존합니다. Ubuntu의 업그레이드 오류 보고 안내도 이 디렉터리의 로그를 확인 자료로 안내합니다. 먼저 파일 목록을 확인하고 존재하는 로그를 읽으면 실패 단계와 패키지 관련 원인을 좁히는 데 도움이 됩니다.

sudo ls -lah /var/log/dist-upgrade/
sudo less /var/log/dist-upgrade/main.log

SSH가 끊겼다면 복구 콘솔로 기존 업그레이드 프로세스와 진행 상태부터 확인합니다. 연결이 끊겼다는 이유만으로 업그레이드를 새로 실행하거나 APT 잠금 파일을 삭제하지 마세요. 패키지 처리 도중의 중단은 오류 로그와 현재 패키지 상태에 맞는 복구가 필요합니다.

릴리스 업그레이드를 취소해 이전 Ubuntu로 되돌리는 일반적인 단일 명령은 없습니다. 복원이 필요하면 검증해 둔 서버 백업과 데이터베이스 백업을 서로 일치하는 시점으로 복원하거나, 준비한 이전 서버로 전환합니다. 백업 이후 발생한 데이터 쓰기를 어떻게 보존할지도 함께 판단해야 합니다. Prompt 설정 파일을 원래대로 돌리는 것만으로 이미 바뀐 운영체제가 복구되지는 않습니다.

잡동사니