Ubuntu 24.04 LTSから26.04 LTSへのアップグレード手順｜do-release-upgradeで本番サーバーを安全に移行するチェックリスト

ＨＯＭＥ＞リナックスマスター.JP 公式ブログ＞ Linux学習ガイド, Ubuntu ＞ Ubuntu 24.04 LTSから26.04 LTSへのアップグレード手順｜do-release-upgradeで本番サーバーを安全に移行するチェックリスト

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

「24.04 LTSで動いている本番のUbuntuサーバーを、26.04 LTSにアップグレードしたい。でも何から手を付ければいいのか」
そう迷われている方に向けて、本番サーバーで実際に踏む順番で手順をまとめます。

本記事は机上のコマンド集ではありません。私が受講生から「アップグレードして起動しなくなった」という相談を繰り返し受けてきた経験から、「ここで躓く」「ここを飛ばすと戻せない」というポイントを中心に書いています。

一気にコマンドを流す前に、まずは読み物としてひととおり目を通してみてください。

この記事でわかること
・do-release-upgradeでUbuntu 24.04 LTSから26.04 LTSへ上げる正規の手順
・アップグレード前に必ず取っておくべきスナップショット・バックアップのポイント
・PPAや独自リポジトリを事前に無効化する理由と具体的なコマンド
・アップグレード中に出る"Configuration file `/etc/xxx'"プロンプトの安全な答え方
・失敗時のロールバックと「復旧できるSSH経路」の確保方法

Ubuntu 24.04 LTSから26.04 LTSへのアップグレード手順｜do-release-upgradeで本番サーバーを安全に移行するチェックリスト

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

図解60P／登録10秒／解除も3秒／詳細はこちら

なぜ"ただアップグレードするだけ"が難しいのか

Ubuntuのメジャーバージョンアップは、コマンド一発で終わるように見えて、本番サーバーでは事故が起きやすい作業のひとつです。

20年以上Linuxサーバーの現場を見てきて、アップグレードで止まるパターンはだいたい決まっています。

・PPAや外部リポジトリがアップグレード先で互換性切れになり、依存関係が壊れる
・SSHセッションが切れた瞬間にプロセスが死んで、中途半端な状態で停止する
・/etcの設定ファイルに対するマージ判断を誤り、サービスが起動しなくなる
・起動しなくなったときに、コンソールアクセスの手段を用意していない

どれも「アップグレード前に一手間かけておけば防げる」類の事故です。この記事で紹介する順番は、その一手間を抜かないためのものだと思ってください。

前提条件：このまま進めていい環境かを確認する

手を動かす前に、いまの環境が「24.04 LTS → 26.04 LTSへ正規ルートで上げられる状態か」を確認します。

1. 現行バージョンの確認

$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.x LTS
Release:        24.04
Codename:       noble

「24.04.x LTS」と出ることが前提です。24.04のポイントリリース（24.04.3以降）まで上がっていないと、do-release-upgradeが26.04への経路を案内してくれない場合があります。その場合はまず通常のアップデートで最新のポイントリリースまで上げます。

$ sudo apt update
$ sudo apt -y full-upgrade
$ sudo reboot

2. カーネルとサービスの健康確認

$ uname -r
$ systemctl --failed
$ systemctl list-units --state=failed

failedなユニットが残ったままアップグレードに入ると、26.04側で同じサービスが復旧しても、エラーがアップグレードのせいなのか元からなのか切り分けられなくなります。"アップグレード前の時点でfailedはゼロ"を目指してから進めてください。

3. ディスク容量の確認

do-release-upgradeは、新しいパッケージを一時領域に展開してから入れ替えます。/と/var、/bootそれぞれに最低でも数GB以上の空き容量が必要です。

$ df -h /
$ df -h /var
$ df -h /boot

特に/bootは、カーネルが古いまま残り続けている環境だと容量不足になりやすい場所です。事前に不要カーネルを削除しておきます。

$ sudo apt autoremove --purge

必ず最初に取っておく：スナップショットとバックアップ

ここから先は「戻せる状態にしてから進める」という鉄則の話です。

私の失敗談を正直に書きます。過去、「たぶん大丈夫だろう」と思ってスナップショットを取らずにアップグレードを始めたサーバーが、途中でネットワーク経路のトラブルで止まり、再起動後にSSHが上がってこなくなったことがありました。復旧に半日かかりました。

それ以来、「アップグレード前にスナップショットを取らない選択肢はない」を徹底しています。

クラウド環境の場合

・AWSなら該当EC2のAMIを作成、または全EBSボリュームのスナップショットを取得
・Azureなら該当VMのマネージドディスクのスナップショットを取得
・GCPなら該当インスタンスの永続ディスクのスナップショットを取得

スナップショットを取った時刻とボリューム名を、作業記録として残しておきます。切り戻しのときに「どれが直前のものか」で迷いたくないからです。

オンプレ・VM環境の場合

VMware・Proxmox・VirtualBoxなどの仮想基盤であれば、仮想マシンのスナップショット機能を使います。物理サーバーの場合は、LVMスナップショットか、少なくとも以下を手動で退避しておきます。

・/etc 一式（tarで丸ごと）
・稼働中サービスの設定（nginx、apache、postgresql、mysql等の設定＋データ）
・/var/log の直近分

$ sudo tar czf /root/etc-backup-$(date +%Y%m%d).tar.gz /etc
$ sudo tar czf /root/home-backup-$(date +%Y%m%d).tar.gz /home

事前作業：PPAと独自リポジトリを無効化する

ここを飛ばすと、だいたいアップグレード中のどこかで止まります。

24.04時代に追加したPPAや外部リポジトリは、26.04のリポジトリURLがまだ存在しないケースが多く、apt updateで404エラーを引き起こします。do-release-upgrade自身も、多くの場合これらを自動で無効化してくれますが、"自動でやってくれるのを前提にする"のはリスクです。

現在有効なリポジトリ一覧を確認

$ ls /etc/apt/sources.list.d/
$ grep -rhE '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

PPAの無効化

# 例：ondrej/php PPAを無効化する場合
$ sudo add-apt-repository --remove ppa:ondrej/php

無効化したPPAのリストは、作業ノートに控えておいてください。アップグレード後、26.04対応版のPPAが用意されていれば、そちらを再度追加する作業が発生します。

その他の独自リポジトリ

DockerやNode.js、Grafana等のベンダー提供リポジトリについては、/etc/apt/sources.list.d/配下のファイルをリネームして一時退避します。

$ sudo mv /etc/apt/sources.list.d/docker.list /etc/apt/sources.list.d/docker.list.disabled

アップグレード実行：do-release-upgradeの正しい流れ

ここからが本番の作業です。tmuxかscreenの中で実行してください。SSH接続が切れてもセッションが生き残るようにするためです。

1. tmuxセッションを開始

$ sudo tmux new -s upgrade

このセッションの中ですべての作業を行います。万が一SSHが切れても、再接続してからsudo tmux attach -t upgradeで続きを見られます。

2. アップグレードマネージャーを最新化

# tmux内で
$ sudo apt update
$ sudo apt install update-manager-core

3. do-release-upgradeを実行

$ sudo do-release-upgrade

実行すると、以下のような流れで進みます。

・新しいリリース（26.04 LTS）の検出と確認プロンプト
・リポジトリURLの書き換え（/etc/apt/sources.list系）
・サードパーティリポジトリの無効化警告
・パッケージリストの取得
・アップグレード内容のサマリと最終確認
・ダウンロード・展開・インストール
・/etc配下の設定ファイルに対するマージプロンプト
・古いパッケージの削除確認
・再起動の確認

ここで必ず目を通すのが「Configuration file `/etc/xxx'」というプロンプトです。

"Configuration file"プロンプトの答え方

このプロンプトは、/etc配下の設定ファイルについて「パッケージ側の新バージョンと、あなたが編集した現行ファイルが違います。どうしますか？」という問いかけです。

選択肢は通常5つあります。

・Y（install the package maintainer's version）：パッケージ側の新設定で上書き。あなたが加えた変更は消える
・N（keep your currently-installed version）：いま動いている設定ファイルを維持。新バージョンの変更は反映されない
・D（show the differences between the versions）：差分を表示。一度確認するための選択
・Z（start a shell to examine the situation）：サブシェルに入って手動確認
・I（default is to keep your current version）：エンターのみでデフォルト＝Nと同じ

私の基本方針は、「まずDで差分を見て、判断が付かなければN（現行維持）、SSH関連のファイルだけは特に慎重に」です。特に/etc/ssh/sshd_configはYを選ぶとリモート接続設定が失われる可能性があるため、N（現行維持）にして、アップグレード後に新旧ファイルを手動で比較します。

失敗に備える：復旧経路を最初に確保する

アップグレード中にSSHが落ちて戻ってこなくなる、という事故は本当にあります。

そのためにも、作業開始前に「SSHが死んでも入れる経路」を最低ひとつ確保しておきます。

クラウド環境の場合

・AWSならセッションマネージャー接続を有効化しておく（SSM Agentがインストール済みか確認）
・Azureならシリアルコンソールからアクセスできるか事前に試す
・GCPならシリアルコンソールの出力を有効化し、メタデータ経由のコンソール接続を確認

# AWS SSM Agentの状態確認（24.04のUbuntuでは通常プリインストール）
$ sudo systemctl status amazon-ssm-agent

オンプレの場合

iLO・iDRAC・IPMIなどのBMC経由のコンソール、または物理コンソールへのアクセス手段を、手元のメモに書き出しておきます。「サーバールームの何番の棚」「どのIPで管理画面に入る」レベルまで具体的に、です。

アップグレード後に必ず確認する項目

再起動後、最初にやるべき確認は以下です。

1. バージョン確認

$ lsb_release -a
# Release: 26.04 になっていればOK

2. 失敗したサービスの洗い出し

$ systemctl --failed
$ journalctl -b -p err

アップグレード直後にfailedが出るサービスは、だいたい以下のどれかです。

・設定ファイルを"パッケージ新バージョンで上書き（Y）"した結果、従来の独自設定が失われた
・26.04で廃止または名称変更されたパラメータが残っていた
・PPAから入れていたパッケージの依存が解決できず、古いバージョンが残留

1つずつjournalctlで原因を追っていきます。

3. リポジトリ状態の確認

$ grep -rhE '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/
$ sudo apt update

エラーが出る行は、無効化し忘れた外部リポジトリです。26.04対応版があれば差し替え、なければ一旦コメントアウトします。

4. 不要になったパッケージの整理

$ sudo apt autoremove --purge
$ sudo apt clean

ロールバックの現実：戻す前提で設計する

ここまでやっても、アップグレード後に「どうしても動かない」という状況は発生します。

正直に書くと、Ubuntuのdo-release-upgradeには"きれいに戻す手順"はありません。apt historyを使って個別パッケージを戻すことは技術的には可能ですが、数百〜千以上のパッケージが動いた後にそれを手動で戻すのは現実的ではありません。

そのため、ロールバック戦略は実質的に「最初に取ったスナップショットに戻す」の一択です。

・クラウド：AMI・スナップショットから新しいインスタンスを起動し、DNSを差し替える
・仮想基盤：スナップショットをrevertして、アップグレード前の状態に戻す
・物理：LVMスナップショットを使ったロールバック、または/etc・/homeの退避ファイルからの手動復元

どの経路を取るにしても、「切り戻し後にどのくらいの時間でサービスを再開できるか」を事前にシミュレーションしておいてください。本番環境で初めて切り戻しを試すのは、個人的に最も避けたいシナリオです。

セミナーでよく聞かれる質問

Q. 24.04から26.04へは直接アップグレードできますか

できます。UbuntuのLTSは基本的に、前のLTSから次のLTSへdo-release-upgradeで直接移行できる設計です。

ただし、最新のポイントリリース（24.04.x）まで上がっていることが前提になります。まだ26.04がリリース直後の段階では、do-release-upgradeのデフォルト動作が「LTSから次のLTSへの案内」になっていない場合があるので、sudo do-release-upgrade -dオプション（開発版への案内）を使う時期があるかもしれません。この挙動は26.04.1が出てから自然に変わります。

Q. GUI環境のデスクトップPCでもこの手順でいいですか

基本的な流れは同じですが、デスクトップPCの場合は/homeのバックアップを特に丁寧に取ってください。サーバーと違って、個人の作業ファイルや設定ファイルが/home配下に集中しているためです。

また、グラフィックドライバ（特にNVIDIA）関連のパッケージは、26.04でのバージョン差で画面が出なくなる事例があります。ディスプレイマネージャの起動確認までは、SSHで別端末から並行してモニタしておくと安全です。

Q. 本番サーバーではアップグレードより、新規構築＋データ移行のほうがいいのでは

これはよく議論になる点ですが、私の立場は「規模と性質によって使い分け」です。

・10台以上のサーバー群、IaCで構成されている、構成ドリフトを許容したくない：新規構築＋データ移行のほうが結果的に安全
・単発のサーバー、構成が複雑で手作業の蓄積が多い、新規構築の再現に時間がかかる：アップグレードのほうが実務的

判断基準は「スナップショットから戻す余裕があるか」「構成を再現するのにかかる時間」の2点だと思っています。

Ubuntu 24.04 LTSから26.04 LTSへのアップグレード手順｜do-release-upgradeで本番サーバーを安全に移行するチェックリスト - まとめ

まとめ：アップグレードは"戻せる状態"を作ってから

Ubuntu 24.04 LTSから26.04 LTSへのアップグレードで、記事本文に沿って特に強調したかったのは以下の3点です。

・スナップショットは"保険"ではなく"前提"。取らずに始める選択肢はない
・Configuration fileプロンプトは飛ばさず、SSHとサービス設定は特に慎重に
・SSHが死んでも入れる経路を、作業前に最低ひとつ確保

コマンド手順そのものは、do-release-upgrade一発で済むと言えば済みます。ただ、本番サーバーで事故らないかどうかを分けるのは、コマンドの上手さではなく、「戻せる状態にしてから進めたか」の一点だけです。

本記事のチェックリストをそのまま台本として使ってもらえれば、致命的な失敗は避けられるはずです。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒／詳細はこちら

Linux無料マニュアル（図解60P）名前とメールで30秒登録

この記事を書いた人

宮崎智広（みやざきともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

次のページへ：Ubuntu 26.04 カーネル管理の基本｜HWE・GAの違いとアップデート制御コマンド
前のページへ：Ubuntu 26.04でよくあるトラブル12選｜起動しない・ネット繋がらない・GUI落ちる時の対処
この記事の属するカテゴリ：Linux学習ガイド・Ubuntuへ戻る