稼働中のUbuntuを更新する：事前準備・接続復旧・再起動後の確認

稼働中のUbuntuサーバーを更新するときは、パッケージを新しくする作業に加えて、サービスを止め、再起動後に運用へ戻す手順が必要です。SSHがつながらなくなる、認証設定が新しい仕様に合わない、バックアップを取り出せない、といった問題は、更新コマンドが終わった後にも起こります。

この記事では、Ubuntu 24.04から26.04へのLTS移行と、移行後の通常更新で得た知見を、ほかのサーバーにも応用できる手順として整理します。前提は、管理者権限があり、サービス停止を伴う保守時間を確保できることです。まず共通の準備と実施手順を示し、後半では接続・認証・起動のトラブルを切り分けます。

Ubuntu 24.04から26.04へ移行するか、通常更新に留めるか

新しいOS世代の機能が必要か、現行世代の修正だけで足りるかを先に決めます。リリース更新では外部認証・VPN・DBの互換性確認を追加し、通常更新ではパッケージの予定差分と再起動の影響を中心にします。どちらも復旧コンソールと実復元が使えない状態では開始しない、という判断基準を用意します。

Ubuntu Server：LTS移行の条件と準備

1. 更新の種類と作業範囲を決める

最初に、OSの世代を変えるのか、同じ世代のパッケージを更新するのかを決めます。両者では、必要な変更量と確認事項が異なります。

作業	例	使用する仕組み	事前に確認すること
通常更新	Ubuntu 26.04内の修正やカーネル更新	APT	更新・追加・削除の予定、サービス再起動の影響
リリース更新	Ubuntu 24.04から26.04へ移行	do-release-upgrade	公式の移行条件、互換性、廃止・分割されたパッケージ

apt-get dist-upgradeは、設定済みの取得元に対して依存関係を調整するコマンドです。名前に「dist」があっても、Ubuntuの次のLTSへ移行する専用コマンドではありません。リリース更新はUbuntu公式の手順に沿って行います。本番環境で開発版向けの-dを付けたり、APTの取得元だけを手作業で書き換えたりする方法は採りません。DebianからUbuntuへの変更も、この手順で行える更新には含まれません。

対象はホスト名だけでなく、そのサーバーが依存するDNS、認証、データベース、接続用VPNまで確認します。複数台を更新するなら、依存先が安定していることを確かめながら1台ずつ進めます。別の保守作業やバックアップ処理と重なる場合は、先に順序を決めてください。

あわせて、「復元に失敗した」「必要なパッケージが取得できない」「正常停止できない」「復旧コンソールへ入れない」といった中止条件を決めます。保守時間の終わりまで更新を続けるより、復旧に使う時間を先に残しておく方が判断しやすくなります。

2. SSHが切れても操作できる経路を確保する

更新前に、VPSやクラウドの管理画面から復旧コンソールへ到達できることを確認します。画面を開くだけでなく、実際にOSを操作できるログイン手段が必要です。SSHと同じVPNや認証サーバーに依存する経路だけでは、その依存先が止まったときに復旧できません。

再起動ボタンで直るのは、一時的な停止や不調の場合です。設定エラーや起動順序の問題は、再起動しても再現します。更新途中かどうか分からない状態で再起動を繰り返す前に、コンソールから現在の状態を確認できるようにしておきます。

プロバイダーのディスクイメージを使う場合は、取得中に起動・操作が制限されるか、完了までの見込み、保存容量と課金単位を調べます。アプリケーションのバックアップを使う場合は、OSを再構築し、設定を戻す手順も必要です。どちらを選んでも、戻せる範囲と不足する範囲を作業前に書き出してください。

3. バックアップを別の場所へ実復元する

バックアップジョブが成功していても、必要なデータが含まれ、読み戻せるとは限りません。更新前に、対象ホスト・保存時刻・保存内容を確認した世代を、空の検証用ディレクトリへ復元します。

たとえば、resticというバックアップツールを使っている場合は、既存の接続設定を使える管理者用シェルで次のように確認できます。snapshot_idは、確認した世代のIDに置き換えます。latestに任せずIDを固定すると、検証中に新しい保存処理が走っても対象が変わりません。

# 既存のリポジトリ接続設定を使う。秘密値をコマンドに直書きしない。
snapshot_id='確認したスナップショットID'
umask 077
restore_dir=$(mktemp -d /var/tmp/restore-check.XXXXXX) || exit 1
restic restore "$snapshot_id" --target "$restore_dir" --verify

本番のデータディレクトリは復元先に指定しません。resticは既存ファイルを上書きできるため、公式の復元仕様を確認し、隔離した空の場所で検証します。R2などのオブジェクトストレージを使う構成例は、バックアップの実復元を組み込む方法でも紹介しています。

復元後は、データ形式に合わせて次を確かめます。

データ	確認すること	それだけでは確認できないこと
ZIPなどのアーカイブ	展開・整合性検査、必要なファイルの有無	アプリケーションが起動し、内容を使えること
SQLのダンプ	隔離したDBへの取り込み、スキーマと主要データ	添付ファイルや外部ストレージとの整合性
SQLite	復元ファイルの存在・サイズ、DBの整合性検査	サービス全体の復旧
設定・証明書・鍵	対象ファイル、所有者、権限、参照先	外部サービス側の設定や有効性

稼働中のDBファイルをそのままコピーすると、保存中の状態が混ざることがあります。DBやアプリケーションが提供する整合性を保つバックアップ方式を使い、データと関連ファイルの時点もそろえます。検査用コマンドが空のDBを新規作成することもあるため、「整合性検査が成功した」の前に、復元したファイルが実在することを確認します。

認証基盤などを起動して検証する場合は、同じ識別情報を持つ複製が本番へ通信しないよう、ネットワークも隔離します。コンテナや名前空間を使うなら、分離できていることを検査してからマウントや起動へ進めます。検証用の/runを用意する処理が、本番ホストの/runを覆わないことも確認が必要です。

4. 設定だけでなく「元の稼働状態」を保存する

設定ファイルのコピーに加えて、次の状態を記録します。退避先は管理者だけが読める場所にし、既存の記録を上書きしないよう作業ごとに分けます。

保存対象	後で照合する内容
OS・パッケージ	リリース、稼働中カーネル、導入済みパッケージ、APTの取得元とhold
ネットワーク・SSH	Netplan、SSH設定、VPN設定、ファイアウォールの管理方式
サービス	unitとdrop-in、起動時の有効・無効、現在の稼働状態
定期処理	timer、cron、バックアップの有効・無効と次回実行
アプリケーション	設定、データの場所、コンテナの構成、外部依存先

Netplanとsystemdを使うUbuntuでの退避例です。対象のディレクトリが存在することを確認し、sudo -iでrootのシェルへ入ってから実行します。mktempで作るディレクトリはrootだけがアクセスできる新しい場所になり、以前の記録を上書きしません。

umask 077
record_dir=$(mktemp -d /root/ubuntu-upgrade.XXXXXX) || exit 1
cp -a /etc/netplan /etc/ssh /etc/systemd/system "$record_dir/" || exit 1
apt-mark showhold > "$record_dir/apt-hold.txt"
systemctl list-unit-files > "$record_dir/unit-files.txt"
systemctl list-units --type=service --all > "$record_dir/services.txt"
systemctl list-timers --all > "$record_dir/timers.txt"
cat /proc/sys/kernel/random/boot_id > "$record_dir/boot-id.txt"

この例に、アプリケーション固有の設定や外部ストレージのデータは含まれません。上の表で整理した対象を追加し、退避先の場所を作業記録に残します。

確認用コマンドの例です。ホスト名、接続先、設定内容が含まれる出力は、公開せず作業記録として保管します。

cat /etc/os-release
uname -r
cat /proc/sys/kernel/random/boot_id
apt-mark showhold
systemctl list-timers --all
systemctl --failed
sudo sshd -t

sshd -tはSSH設定の構文確認です。成功しても、外部から到達できることまでは分かりません。Netplanも、構文・生成結果と実際の通信を別に確認します。

更新のためにtimerを止めたり、一時的にholdを変更したりする場合は、元の状態と理由を記録します。作業後に一律で「全部有効」にすると、意図して止めていた処理まで動き出します。設定を戻す際も、/etc全体を古い状態へ置き換えるのではなく、今回変更した箇所を差分で照合します。

5. 利用者がいない瞬間を、停止できる状態へつなげる

利用者がいないときだけ止めたいサービスでは、人数や接続数が0になったことに加えて、観測範囲と時刻を確認します。入口のプロキシだけを見ても、その奥のサーバーや実行中ジョブまで無人とは限りません。

判定に使う対象を先に一覧化し、すべての対象で最新の値を取得します。取得失敗、欠測、古い値、監視対象外のサーバーがある場合は、停止を許可しません。「値がない」を0へ変換すると、監視の故障時に停止してしまいます。

たとえば、通常は数秒ごとに更新される監視なら「観測時刻と元データの更新時刻がともに15秒以内」という条件を設定できます。この15秒は設計例です。実際の更新間隔に合わせて決め、時刻のずれも確認してください。人数だけで判断できる場合、利用者名の収集や定期的なコンソールへの一覧コマンド送信は不要です。

停止直前は、次の順序にします。

1. 全対象の利用者・処理数が0で、競合する保守処理がないことを確認する。
2. アプリケーションやロードバランサーで新規受付を閉じる。既存の処理は正常終了まで待てる方式にする。
3. 受付を閉じた後に生成された新しい値で、全対象が0であることを再確認する。
4. 正常終了を要求し、プロセスの終了とデータ保存の完了を確認する。
5. 更新・再起動後の動作確認を終えてから、受付を戻す。

受付停止後に利用者が見つかったら、停止へ進まず、事前に決めた待機・受付復元の手順を使います。先ほどの0を使い回しません。

ファイアウォールで制御する場合は、新規接続と既存接続の扱い、IPv4・IPv6、TCP・UDPを確認します。UDPは接続の扱いがアプリケーションによって異なるため、アプリケーション側の保守モードも検討します。管理用SSHやVPN、内部通信を残し、再起動中も受付停止が維持されることを確かめます。専用の一時ルールを使い、復帰時にそのルールだけを外せるようにします。

正常終了の要求と、正常終了の完了を分ける

systemctl stopを使う場合は、対象unitのExecStop、停止猶予時間、強制終了の設定を先に確認します。ExecStopが終了要求を送るだけで戻ると、残ったプロセスがsystemdに終了させられることがあります。systemdの仕様に沿って、正常終了を待つ処理まで含めます。

コンソール入力で終了させるサービスでは、正しいコマンドが対象プロセスへ改行付きで届くことも必要です。unit内のコマンド行では、シェルの$()やパイプが自動で使えるとは限りません。必要な処理は小さなスクリプトへまとめ、対象プロセスを誤認しない確認と終了待ちを入れます。タイムアウトした場合は、強制終了して更新を続けるのではなく、正常停止できない原因を調べます。

6. 通常更新は、索引取得・予定確認・適用を分ける

復元確認と停止の準備ができたら、まずパッケージ索引を取得します。一部の取得元が失敗したまま、古い索引を使って次へ進まないようにします。

# この段階ではパッケージを更新しない
sudo apt-get update -o APT::Update::Error-Mode=any &&
  sudo apt-get -s --no-remove dist-upgrade

シミュレーションの終了コードと、更新・追加・削除の予定を確認します。--no-removeは、削除が必要な場合に中止するための条件です。カーネルなどでは新規パッケージの追加が必要になるので、「追加0」を通常更新の共通条件にはしません。APTの仕様では、シミュレーション中の状態は固定されません。実行直前にも、別のAPT処理が走っていないことと予定の変化を確認します。

予定に問題がなく、対象サービスの停止を確認できたら適用へ進みます。needrestartを使う環境で、追加の再起動提案を一覧表示にする例は次のとおりです。

# 通常更新の予定を確認し、必要なサービスを正常停止した後に実行する
sudo env NEEDRESTART_MODE=l apt-get --no-remove dist-upgrade

NEEDRESTART_MODE=lはneedrestartの一覧表示モードを指定します。パッケージ自身の設定処理によるサービス再起動まで、すべて禁止する設定ではありません。SSHやVPNへの影響も含め、復旧経路を確保した保守枠で実施します。確認なしの-yや、すべての設定ファイルを一律で置き換える指定は付けません。

SSH切断に備えて、tmuxのような、切断後も処理を継続できる管理者用セッションを使い、コマンドの終了結果を記録します。自動実行にする場合は、対象ホスト、OS世代、設定の照合結果、バックアップ検証、停止状態を実行直前に検査し、途中の段階も保存します。接続が切れたからといって、同じ更新を重ねて起動しません。

段階配信で残った更新の扱い

Ubuntuの段階配信は、一部の利用者から通常更新を提供し、問題があれば配信を抑える仕組みです。通常更新で段階配信による保留が残った場合は、その理由を記録します。保留件数を0にするためだけに強制適用へ切り替える必要はありません。Ubuntuの段階配信の説明

ただし、リリース更新の準備は別です。Ubuntuの公式手順では、段階配信分も含めて現在のリリースを更新するよう案内しています。do-release-upgradeの前提条件には、その時点の公式手順を適用してください。リリース更新では必要なパッケージ置換や削除もあるため、上の通常更新用コマンドをそのまま移行手順にしません。

実行前には、次のコマンドで提供されている移行先を確認します。

sudo do-release-upgrade -c

意図したLTSが提示され、現在のリリースの更新と再起動、復元検証、互換性の確認が終わってから、保守枠でsudo do-release-upgradeを実行します。確認だけで移行先が提示されない場合は、提供条件を調べます。開発版の指定で先へ進みません。設定ファイルの変更確認が出たら、差分を見て接続・認証設定への影響を判断します。

7. SSHが戻らないときは、通信と起動を順に調べる

SSHがつながらない場合は、復旧コンソールから次を切り分けます。

確認する段階	確認例	次に調べること
OSが起動しているか	コンソール、systemctl --failed	緊急モード、失敗したunit、パッケージ設定の中断
IPと経路があるか	ip address、ip route	Netplanの生成元、インターフェース名、経路の変化
SSHが待ち受けているか	sshd -t、SSHのservice・socket	設定エラー、実際の待受ポート
外部から到達できるか	別ホストから接続	ファイアウォール、VPN、クラウド側の通信制御

journalは現在の起動を対象に調べます。journalctl -b -u 対象unitで起動失敗や取消の理由を確認し、systemctl show 対象unit -p After -p Before -p Requires -p Wantsで依存関係を確認します。

接続用VPNの起動が取り消される場合、ネットワークの設定だけでなく起動順序も疑います。古いsocket unitがVPNを待ち、そのVPNが別の起動段階を待つことで循環する例があります。現在使っている待受と通信を確認してから、役割を終えたunitだけを修正します。socket activationでは接続を待つserviceがinactiveでも正常なことがあるため、状態表示だけで不要とは判断しません。

cloud-initがネットワークを再生成する場合

cloud-initは、クラウド上の初期設定などを行う仕組みです。既存Netplanを管理者が維持する設計では、更新後の再生成で設定が変わらないか確認します。ネットワーク生成を無効化する設定は、/etc/cloud/cloud.cfg.d/内の管理用ファイルへ次のように記述します。

network:
  config: disabled

これはcloud-initのネットワーク生成だけを無効化する設定です。クラウドのメタデータからネットワークを受け取る環境には一律で適用しません。設定の管理元を確認し、既存Netplanの退避・ハッシュ照合、生成結果の確認、通常再起動後の通信まで検証します。

8. 認証や起動の互換問題は、該当する構成だけ確認する

以下は、該当するソフトウェアを使っている環境向けの確認です。導入していないサーバーへ追加する必要はありません。

SambaでWindowsドメインの認証を提供している場合

SambaのAD/DCは、Windowsドメインの認証やディレクトリを提供する構成です。Ubuntu 26.04への移行では、公式の移行注意事項に従い、旧OS側でsamba-ad-dcの導入状態を確認します。

dpkg-query -W -f='${Status}\n' samba-ad-dc
apt-cache policy samba-ad-dc

install ok installedを確認し、未導入なら公式の取得元と追加予定を確認してから、旧OS側で導入します。必要なパッケージを補う作業に、ドメインの再作成や機能レベルの変更を混ぜません。

バックアップには、DBファイルの単純コピーではなくsamba-tool domain backupの適切な方式を使います。復元検証ではDBに加えて、隔離した環境でのディレクトリ応答も確認します。Samba 4.23を使った検証では、DB・PIDの保存先を変えても、内部ソケット用の/run/samba/nmbdがなく起動できない例がありました。永続データと実行時ディレクトリを分けて点検すると、バックアップの破損と検証環境の不足を切り分けられます。

SSSDで外部の認証基盤と連携している場合

SSSDは、LinuxをADやLDAPなどのユーザー情報・認証基盤へ接続するための仕組みです。SSSD 2.10ではconfig_file_versionが廃止されています。古い設定が残っている場合は、元ファイルの所有者・権限を保存してから修正し、sudo sssctl config-checkで確認します。

起動方法にも注意します。SSSD本体のmonitorから起動するresponderと、systemdのsocketから起動する同じresponderが競合する場合があります。responderはユーザー情報照会や認証などを担当するプロセスです。導入版の設定仕様とログを照合し、競合する対象だけを調整します。

修正後はユーザー情報の取得、必要な認証処理、ドメインのOnline状態を確認します。AD連携なら、既存のmachine keyでのadcli testjoinも確認項目です。鍵の再発行やドメインへの再参加へ進む前に、設定と起動方法の問題を切り分けます。

更新が中断し、パッケージや起動ファイルが不完全な場合

まずsudo dpkg --auditとsudo apt-get checkで未設定パッケージや依存関係を確認します。別のAPT・dpkg処理が進行中なら、重ねて起動しません。ロックファイルを削除して強行する方法も使いません。

処理が終わっており、未設定パッケージの続きを実行する状況だと確認できた場合は、sudo dpkg --configure -aで設定を再開します。終了結果を確認してから次へ進み、取得元や依存関係の問題が残る場合は先に解決します。

新カーネルが導入されていても、起動に必要なinitrdが欠けていれば正常起動できません。/bootの容量、導入済みカーネル、対応する起動ファイルを確認します。initrdを新規作成するupdate-initramfs -c -k 対象バージョンと、既存のものを更新する-uは用途が異なります。update-initramfsの仕様

修復対象のカーネルは導入済み一覧から選びます。uname -rが示すのは現在動いているカーネルなので、更新前の古い版を指していることがあります。

通常の起動ができず、一時的なroot復旧シェルを使う場合は、認証を迂回する操作として管理者の許可と手順を確認します。最初は読み取りで点検し、必要な変更だけを行います。一時的な起動指定やサービス起動抑止を戻し、最後は通常のsystemd起動で検証します。復旧シェル上でサービスを起動できただけでは、自動起動の確認にはなりません。

9. 再起動後の完了条件を照合する

更新が終わったら、パッケージの設定処理が完了していることを確認してから通常再起動します。再起動後は、更新前の記録と次の項目を照合します。

完了条件	確認する証拠
通常起動できた	boot IDが変化し、復旧シェルや緊急モードに残っていない
予定したOS・カーネルで動いている	/etc/os-releaseとuname -r。導入済み一覧だけで判断しない
パッケージが整合している	dpkg --audit、apt-get checkの結果
必要なサービスが自動復帰した	service・socket・コンテナと失敗unit、外部からの応答
接続と認証が使える	別ホストからのSSH・VPN・必要な認証経路
一時変更が片付いた	受付、ファイアウォール、timer、hold、unitと設定の差分
更新後の状態を復元できる	新しい保存世代を実復元した結果と検証内容

動作確認は、更新したホストの内側からだけでなく、実際の利用経路に近い別ホストから行います。APIなら、正常な要求に成功することに加えて、認証が必要な経路では認証なしの要求が仕様どおり拒否されることも確認します。HTTP 200だけでは、認証境界やアプリケーションの主要機能は確認できません。

受付を戻した後は、保守用の一時unitやルールが残っていないことを確認します。バックアップが有効な対象では、完成状態を改めて保存し、その新しい保存世代を復元して検証します。更新前の復元成功を、更新後のバックアップの証拠に流用しません。意図して停止していたバックアップは、元の停止状態を維持します。

最後の作業記録には、変更した内容、コマンドの終了結果、復旧で追加した操作、確認できた範囲、残った保留を記載します。実ユーザーのログインや主要操作を試していないなら、その項目は未確認として残します。バックアップの一部を取り出せたことと、別環境でサービス全体を復旧できたことも分けて記録してください。