2026年8月31日、Debian 11のLTSサポートが終了しました。Debian公式は9月以降、同版のセキュリティ更新を提供しないと告知しています。(Debian公式のサポート終了告知) 多サイト運用や依存関係が把握しにくい本番環境は、サポート対象の新環境を用意して段階的に移行してください。構成が単純で、復元可能なバックアップと検証済みの切り戻し手段がある場合に限り、公式手順に沿った原機更新を検討できます。
Debian 11の独立サイトや企業サイトを保守しているサイト管理者は、まずサポート状況と依存関係を確認してください。
WooCommerceなどを運用する技術責任者は、並行して新環境を作る方法と原機更新を比べ、切り替え条件を決めましょう。
VPSや共有ホスティングから独立サーバーへ移るチームにも、移行先での事前検証に役立つ内容です。
最終更新：2026年10月23日。Debian公式のライフサイクル告知とDebian 12・13のリリースノートを照合しました。
Debian 11のサイト移行は、まずサポート状況を確認
サポート終了は、サイトがその日に停止するという意味ではありません。一方で、Debian 11向けのセキュリティ更新が提供されない状態では、従来どおり公開できていることだけを根拠に運用を続けるのは避けてください。サイトの継続性と、OSを安全に保守できるかは別々に判断する必要があります。
今週は、まずサーバーごとに稼働中のサイトと依存関係を洗い出し、原機更新の可否を仮決めしてください。次の表を使い、分からない項目が残る場合は新環境での検証を優先します。
| 判断材料 | 原機での更新を検討できる状態 | 新環境への移行を優先する状態 |
|---|---|---|
| サイト構成 | サイト数が少なく、設定と担当範囲が明確 | 複数サイトが同居し、管理者や構成の記録が不十分 |
| ソフトウェア依存 | Webサーバー、データベース、PHP、追加パッケージを把握している | サイトごとに実行環境が異なる、または第三者製パッケージの役割が不明 |
| 回復手段 | バックアップからの復元を試し、切り戻し方法を説明できる | バックアップの有無や復元手順を確認できていない |
| 切り替え条件 | 更新中の停止を許容でき、検証時間を確保できる | 注文や業務処理への影響が大きく、更新の成否を事前確認したい |
Debian公式の説明に沿って更新する場合も、OSの更新だけでアプリケーションや管理パネルの互換性が保証されるわけではありません。Debian 12の公式更新説明は、Debian 11からの更新手順と事前準備を示しています。更新前のバックアップやサービス中断、再起動を見込んだ計画を立ててください。(Debian 12公式の更新手順)
チームの運用条件から移行経路を選ぶ
単一サイトで構成が把握できているなら、原機更新はサーバーを新たに用意せず進められる選択肢です。ただし、設定済みのパッケージや外部リポジトリが更新後の環境でどう動くかを確認する必要があります。作業前に更新対象、保守時間、復元手順を明文化してください。
複数サイトを管理する場合は、新環境を並行して構築すると、サイト単位で動作を確かめてから切り替えられます。環境の再構築や設定の移し替えは発生しますが、問題が特定のサイトや連携先に限られるかを切り分けやすくなります。これは停止時間がなくなるという意味ではなく、切り替え前に確認できる範囲を広げる方法です。
| 項目 | 原機で段階的に更新 | 新環境を用意して移行 |
|---|---|---|
| 主な準備 | パッケージ、リポジトリ、サービス設定の確認 | OS、Web環境、データベース、サイト設定の再構築 |
| 動作確認 | 更新後に既存環境で実施 | 本番切り替え前にサイトごとに実施 |
| 停止の考え方 | 更新作業や再起動に伴う停止を計画 | データ同期と切り替えに伴う停止を計画 |
| 切り戻し | 更新前のバックアップから復元できるか確認 | 旧環境を残し、戻す条件と手順を決める |
| 向いている条件 | 構成が単純で、復元を検証済み | サイト数が多い、依存関係が複雑、現状の把握が不十分 |
判断に迷う場合は、次の条件分岐を使ってください。
- サイトと依存パッケージを一覧化でき、バックアップからの復元も確認済みなら、Debian公式の更新経路に沿った原機更新を候補にします。
- サイトごとのPHPやデータベース設定に差がある、外部連携が多い、または構成の記録がないなら、新環境を作り、低リスクのサイトから検証します。
- 切り戻しの所要条件や戻す対象データを説明できないなら、どちらの経路も本番で始めず、先に復元テストとデータ保全の計画を整えます。
- Debian 11からDebian 13への直接更新を前提にしているなら、その計画を見直してください。Debian 13の公式更新説明が扱う移行元はDebian 12です。(Debian 13公式の更新説明)
まずサイトごとの依存関係を棚卸しする
「サイトが表示される」だけでは、移行準備が完了したとは言えません。管理画面へのログイン、データベースへの書き込み、決済通知、定期処理など、運用上必要な機能が動くかを確認できる単位で記録します。サイトが複数ある場合も、まとめて同じ設定を適用せず、サイト単位で差を残してください。
| 棚卸し項目 | 記録する内容 | 移行後の確認例 |
|---|---|---|
| サイトのファイル | 配置場所、アップロード先、所有者と権限 | ページ表示、画像や添付ファイルの参照 |
| データベース | 接続先、対象データ、書き込みを止める条件 | ログイン、検索、フォーム送信、注文 |
| 実行環境 | PHPの版、拡張機能、Webサーバー設定 | 管理画面、公開ページ、アプリケーションログ |
| 定期処理 | スケジュール、実行ユーザー、外部連携 | 実行結果とエラー記録 |
| 公開・証明書 | DNSレコード、TLS証明書、更新方法 | 新環境での名前解決とHTTPS接続 |
| 外部サービス | 決済、配送、認証、通知など | テスト用の処理とコールバック受信 |
Debian 12への更新では、公式のリリースノートに記載された準備と既知の注意点を先に確認してください。(Debian 12公式のリリース情報) Debian 13を移行先にする場合も、更新説明だけでなく既知の問題を読み、サイトで使う構成との関係を調べます。(Debian 13公式の既知の問題)
新環境を選ぶ場合は、移行先のOSが現在選べるかを製品情報で確認してください。OVN Cloudのサーバー構成や選択可能なシステムは、日本語のサーバー構成案内で確認できます。
本番切り替え前に確認と切り戻しを準備する
切り替え作業は、事前の検証、データ同期、公開先の変更、変更後の確認に分けます。バックアップや復元は自分のチームで計画し、どの時点のデータを使って戻すのかも決めてください。サーバーを用意しただけで、バックアップやスナップショットが備わると想定しないでください。
- [ ] サイト単位で移行対象を確定する：ファイル、データベース、証明書、DNS、定期処理、外部連携を一覧にします。
- [ ] 更新または移行先をテストする：管理画面へのログイン、ページ表示、フォーム送信、注文、決済通知を確認します。
- [ ] データの保全と復元を試す：ファイルとデータベースを保全し、実際に復元できることを確認します。
- [ ] 切り替え直前の同期点を決める：書き込みを停止または制限する条件と、最後に同期するデータを記録します。
- [ ] 監視項目と切り戻し条件を決める：エラー、書き込み失敗、外部連携の不達など、戻す判断の根拠を決めます。
- [ ] DNSまたはアプリケーションを切り替える：切り替え後は公開ページだけでなく、ログイン、注文、定期処理を再確認します。
- [ ] 更新後の保守状態を確認する：導入したOSが公式のサポート対象であることと、更新を受け取れる状態であることを確認します。
よくある判断を先に整理する
サポート終了後も稼働しているサイトを、そのまま運用してよいでしょうか。
動作中であることは、OSの保守が続いていることを意味しません。更新停止後は、サイトが利用するアプリケーションのリスクも含めて運用判断が必要です。切り替えまでの期間を決め、サポート対象の環境へ移る計画を進めてください。
原機更新と新環境への移行では、どちらを優先すべきでしょうか。
複雑な依存関係や把握しきれていない設定があるなら、新環境を並行して作り、サイトごとに検証する方法を優先します。構成が単純で復元を試している場合は、Debian公式の手順に沿う原機更新も候補になります。更新中の停止を避けられると断定せず、必要な停止時間をチーム内で調整してください。
Debian 11からDebian 13へ直接更新する計画で問題ないでしょうか。
既定の計画にはしないでください。Debian 12の公式説明にある更新経路を確認し、Debian 13への移行は同版の公式説明に沿って段階を検討します。Debian 13の既知の問題も確認し、アプリケーションやパネルが対応するかを別途検証してください。
複数サイトを移すとき、最初に切り替えるサイトはどう選びますか。
外部連携やデータ書き込みの影響が比較的小さく、復旧方法を説明できるサイトから始めます。切り替え後にファイル、データベース、定期処理、ログを確認し、問題がないことを確かめてから重要なサイトへ進みます。一斉に切り替えると、障害の発生箇所と戻す対象を特定しにくくなります。
今週の作業を移行計画に落とし込む
まず、サーバー上のサイト、実行環境、外部連携、復元手順を一覧にしてください。その記録をもとに、原機更新か新環境への移行かをサイトごとに決め、検証日、切り替え条件、切り戻し条件を共有します。Debianの更新経路は公式のリリースノートを基準にし、利用中のアプリケーションや管理パネルの対応は個別に確認してください。
共有ホスティングやVPSでは、利用できるOSや設定が契約範囲に限られる場合があり、複数サイトの異なる依存関係を一か所に整理しにくいことがあります。長期運用で専有リソースとOS選択の自由度を優先するなら、OVN Cloudのような独立したAMD物理サーバーを移行先候補にできます。日本東京の環境や選択可能なシステムを確認し、移行要件に合う構成かを製品情報で照合してください。月単位を含む支払い周期の確認は料金と支払い案内で行えます。
ただし、短期間だけ動かすサイトや負荷の軽い単一サイトでは、移行作業や独立サーバーの運用負担が見合わないこともあります。サーバーを選ぶ前に、サイトごとの依存関係と復元可能性を確認し、切り戻し計画まで整ってから移行日を設定してください。
よくある質問
- Debian 11のサポートが終わったあとも、サイトを公開し続けられますか？ サポート終了後もサイトが直ちに停止するわけではありません。ただし、Debian公式の告知ではDebian 11のLTSが2026年8月31日に終了し、9月以降は同版のセキュリティ更新が提供されないとされています。公開を続ける場合も、更新を受けられる環境へ移る計画を優先してください。
- Debian 11のサイトは、同じサーバー上で更新するのと新環境へ移すのと、どちらが安全ですか？ どちらが安全かは、依存関係と切り戻し手段で変わります。構成が単純で、バックアップから復元できることを確認済みなら、公式手順に沿った段階的な原機更新を検討できます。複数サイトや外部連携があり旧環境の把握が難しい場合は、新環境で個別に動作を確かめてから切り替えるほうが、問題の範囲を分けやすくなります。
- Debian 11からDebian 13へ一度に更新する計画でよいですか？ 標準の計画として、Debian 11からDebian 13への直接更新を前提にしないでください。Debian 12の公式リリースノートにはDebian 11からの更新手順があり、Debian 13の更新説明はDebian 12からの移行を扱っています。各段階の公式説明とアプリケーションの互換性を確認し、段階的な更新か新環境への移行を選びます。
- 複数のサイトを新しいサーバーへ移すとき、切り替えの危険をどう抑えますか？ サイトごとにファイル、データベース、実行環境、証明書、DNS設定、外部サービスとの連携を記録し、影響の小さいサイトから新環境で確認します。注文やフォーム送信などの書き込みを試し、切り替え直前のデータ同期点、監視するエラー、旧環境へ戻す条件を決めてから本番の切り替えに進んでください。