SLES Btrfs Snapper のアップデート失敗後のロールバック：安全な復旧ガイド

SLESのアップデートが失敗したからといって、必ずしもサーバーを再インストールする必要はありません。ルートファイルシステムにBtrfsを使用し、Snapperが有効になっている標準的なSUSE Linux Enterprise Serverのインストール環境では、アップデート前のスナップショットを起動し、現在のシステムを変更せずにテストを行い、その正常な状態を新しい書き込み可能なルートファイルシステムとして設定できる場合が多くあります。

重要なのは「どのスナップショットが最新か」という単純な判断ではなく、「どの程度ロールバックすべきか」という判断です。アップデートによって複数のパッケージ、ライブラリ、サービス、または構成ファイルが変更され、マシンが正常に動作しなくなった場合は、Snapper システム全体のロールバックが適切です。構成ファイルが 1 つだけ間違っている場合は、そのファイルを復元する方が通常は影響が少なくて済みます。このガイドでは、両方の選択肢について説明し、SUSE が 2026 年 10 月に提供開始予定の SLES 15 SP7 リカバリ モデルに準拠します。

変更を加える前に、復旧方法を選択してください。

SUSE では、変更の取り消しとシステムロールバックを区別しています。変更の取り消しは、スナップショットを比較し、選択したファイルの変更を元に戻します。ロールバックは、スナップショットの状態を基に新しい書き込み可能なルートファイルシステムを作成します。SUSE は、ルートファイルシステムのロールバックを実行する際には、まず対象のスナップショットを起動することを推奨しています。これは、コミットする前に候補を検証できるためです。詳細については、SLES 15 SP7 管理ガイドを参照してください。

ステップ1：このサーバーが標準のSnapperロールバックパスをサポートしていることを確認します。

スナップショットを選択する前に、次の 3 つの事項を確認してください。ルートファイルシステムが Btrfs であること、Snapper に という名前の構成があることroot、および Btrfs ルートが単一のデバイス上にあること。SUSE は、デフォルトのルートサブボリュームレイアウトに対するブート可能なロールバックのサポートについて説明しており、ルート Btrfs ファイルシステムは 1 つのデバイスを報告する必要があると述べています。

findmnt /
sudo snapper list-configs
sudo /sbin/btrfs filesystem show /

XFSやExt4などのファイルシステムが報告された場合はfindmnt /停止してください。そのルートではBtrfsスナップショットブートワークフローが利用できません。エントリsnapper list-configsがない場合はroot、自動ルートスナップショットが有効になっていない可能性があります。また、btrfs filesystem show /複数のデバイスが報告された場合も停止してください。SLES 15 SP7のドキュメントでは、そのレイアウトはブート可能なルートロールバックでサポートされているとは記載されていません。

ステップ2：更新失敗直前のスナップショットを特定する

スナップショットの一覧を表示し、日付、種類、スナップショット作成前の関係、および説明を確認してください。

sudo snapper list

デフォルトのSLES設定では、YaSTとZypperのアクティビティによってスナップショットペアが作成されますpre。postスナップpreショットはトランザクション前のファイルシステムの状態を表し、対応するpostスナップショットはトランザクション後の状態を表します。障害発生時よりも古いという理由だけでスナップショットを選択しないでください。スナップショットのタイムスタンプと説明を更新ウィンドウと一致させてください。

変更の失敗がサービスパックの移行であった場合、SUSEのSLES 15 SP7アップグレードガイドでは、管理者に対し、移行直前に作成されたスナップショットを探すよう具体的に指示しており、関連するスナップショットには「重要」というマークが付いていることを明記しています。

ステップ3：候補となるスナップショットが実際に何を変更するのかを検証する

現在のシステムが起動する場合は、再起動する前に候補となるスナップショットと現在の状態を比較してください。これにより、アップデートが1つの構成ファイルのみを変更したのか、それとも広範囲のシステムファイルを変更したのかが明らかになります。

sudo snapper status SNAPSHOT_ID..0
sudo snapper diff SNAPSHOT_ID..0 /etc/some-file.conf

選択的復元の方がより良いトレードオフとなる場合

既知のファイルのうち1つに問題があり、更新されたシステムの残りの部分は正常である場合、そのファイルだけを復元することで、無関係なシステム変更が元に戻るのを防ぐことができます。SUSEはこの形式について次のように説明しています。

sudo snapper -c root -v undochange SNAPSHOT_ID..0 /etc/some-file.conf

ファイル名を安易に省略しないでください。ファイル名がないと、undochange2つの状態間で変更されたすべてのファイルを元に戻すことができます。SUSEは、完全なルートロールバックを模倣するためにファイル復元を使用することは推奨されないと警告しています。パッケージトランザクションは相互依存する多くのファイルを変更する可能性があるため、更新の失敗がシステム全体にわたる場合は、完全にテストされたロールバックの方が原因究明が容易です。

ステップ4：GRUBから候補スナップショットを起動する

マシンを再起動します。SLES GRUB 2 メニューで、読み取り専用スナップショットからブートローダーを起動するオプションを選択し、アップデート前の状態に一致するスナップショットを選択します。画面レイアウトはファームウェアやブート構成によって異なる場合がありますが、SLES 15 SP7 ではこの項目を「読み取り専用スナップショットからブートローダーを起動する」と説明しています。

このSLESメカニズムでは、デフォルトのSnapper構成からのスナップショットのみrootが起動可能です。スナップショットメニューが表示されない場合は、ブートエントリを作成しないでください。Snapperが有効になっているか、ルートレイアウトがデフォルトのサポート構造になっているか、インストールされているブートローダーが正常に動作しているかを再確認してください。

ステップ5：ルートが読み取り専用の状態でスナップショットをテストする

スナップショットが起動したら、実際にスナップショットから実行されていること、およびルートファイルシステムが読み取り専用になっていることを確認してください。

findmnt /
mount | grep ' on / '

アップデート後に失敗した項目（サービス起動、ネットワーク構成、認証、アプリケーション起動、カーネル依存動作、その他の関連チェックなど）をテストしてください。読み取り専用のスナップショットを通常の運用環境の起動として扱わないようにしてください。ルートファイルシステムのスナップショットされた部分に書き込みができないという理由だけで、一部の操作が失敗する場合があります。

スナップショットが適切でない場合は、再起動して別の候補を試してください。ロールバックコマンドを実行するまでは、そのスナップショットは新しい書き込み可能なシステムルートにはなりません。

ステップ6：スナップショットがチェックを通過した後のみ、ロールバックをコミットしてください。

起動したスナップショットが期待どおりに動作したら、それを永続化します。

sudo snapper rollback

後でスナップショットを識別しやすくするために、説明を追加できます。

sudo snapper rollback -d "Rollback after failed update"

SLESの管理ドキュメントによると、Snapperはロールバック前の状態のスナップショットを作成し、書き込み可能な新しいスナップショットを作成してデフォルトのルートにします。これは重要な安全上の特性です。ロールバックによって古いルートが単純に上書きされるわけではありません。

コマンドの実行が完了したら、再起動してください。

sudo reboot

次回の起動時には、古い読み取り専用スナップショットを再度起動するのではなく、通常のデフォルトのSLESエントリを選択してください。

ステップ7：復元されたルートが書き込み可能であり、デフォルトになっていることを確認します。

通常起動後、ルートマウントとスナップショットリストを確認してください。

findmnt /
sudo snapper list

最初に失敗した機能チェックを再度実行してください。それでもアプリケーションが失敗する場合は、そのアプリケーションの一部がルートスナップショットに含まれていないディレクトリに存在するかどうかを検討してください。

ステップ8：リポジトリを更新し、パッケージの状態を確認する

通常のパッケージ更新の場合は、次の更新を試みる前にリポジトリを更新し、パッケージの依存関係を確認してください。サービスパックのロールバックの場合は、リポジトリと製品登録の確認が特に重要です。リポジトリセットが一致しないと、システムがすぐに不整合な状態に戻ってしまう可能性があるためです。

sudo zypper ref -fs
sudo zypper lr -u
sudo zypper verify

サービスパックの復旧については、公式のSLESアップグレードガイドに記載されているチェック手順に従ってください。このガイドでは、ロールバック後にリポジトリ構成と製品登録を確認することが明示的に求められています。

Snapperのルートロールバックでは復元できないもの

これは、本番サーバーでロールバックを使用する前に理解しておくべき最も重要な制限事項です。デフォルトの SLES ルート スナップショットでは、揮発性データやユーザー またはアプリケーション データが予期せず復元されないように、いくつかのサブボリュームが除外されます。製品固有のリストには、、、、、、、、およびアーキテクチャ固有のブートローダー パスが含まれる場合があります。/home現在のリストと理由については、SUSE のSnapperの基本概念に関するドキュメントを参照してください。/opt/usr/local/srv/tmp/var/run

この設計はデータを保護する一方で、トレードオフを生み出します。除外されたサブボリューム内のデータは最新の状態のままであるにもかかわらず、システムコードが以前の状態に戻ってしまう可能性があるのです。SUSEは、サードパーティ製ソフトウェアの/opt互換性が損なわれたり、アクセス許可が変更されたり、スナップショット取得後に書き込まれたデータ形式をアプリケーションが理解できなくなったりするなど、いくつかの潜在的な影響を指摘しています。

これは特にデータベースやサーバーアプリケーションにとって重要です。アップデートにスキーマの移行や、/varまたはの下にあるアプリケーションデータの変更が含まれていた場合/srv、ルートロールバックではそのデータ変更が元に戻らない可能性があります。システムスナップショットだけで十分だと判断する前に、アプリケーション独自のダウングレードまたは復元手順を確認してください。

避けるべきよくある間違い

• スナップショットをテストする前にロールバックします。読み取り専用のスナップショットを最初に起動する方が、ターゲットの状態を確認できるため、より安全なSLESワークフローです。
• 誤ってアップデート後のスナップショットを選択してしまう可能性があります。スナップショット番号だけに頼るのではなく、種類、日付、説明、およびアップデート前後の関係を確認してください。
• undochangeパッケージ全体のトランザクションに使用します。これは特定のファイルに対して有効ですが、SUSEは完全なルート復旧にはブートアンドロールバック方式を推奨しています。
• ルートディレクトリを遡って移動することを想定しています。/varデフォルト/homeのサブボリューム除外は意図的なものです。
• 単一デバイス要件を無視して、 SLES 15 SP7 では、単一デバイスの Btrfs ルートに対するブート可能なルートロールバックのサポートについて説明しています。
• 同じアップデートをすぐに再試行してください。まず、アップデートが失敗した理由を特定し、リポジトリを確認し、パッケージの不具合、互換性のないサードパーティ製ソフトウェア、ディスク容量不足、またはローカル構成の問題のいずれが原因であるかを判断してください。

システムがトランザクション更新を使用する場合

SLES はトランザクション サーバー ロールでインストールすることもできます。これは異なる動作モデルで、更新はスナップショットに適用され、再起動時にアクティブ化されます。これらのシステムでは、SUSE はtransactional-update rollbackスナップショットをデフォルトのルートとして設定する機能を提供しています。システム ロールを事前に特定せずに、トランザクション サーバー リカバリ レシピを従来の読み書き SLES インストールに混在させないでください。公式の動作については、SLES 15 SP7 トランザクション アップデートのドキュメントに記載されています。

回復チェックリスト

• /Btrfsであることを確認し、 rootSnapperの設定が存在し、ルートBtrfsファイルシステムが1つのデバイス上にあることを確認します。
• 更新失敗直前のスナップショットを特定してください。
• 変更の範囲を理解する必要があるときにsnapper status、これを使用してください。snapper diff
• undochange明確に分離されたファイルに対してのみ、選択的処理を優先してください。
• システムアップデートが失敗した場合は、GRUBから候補スナップショットを起動し、読み取り専用でテストしてください。
• snapper rollback候補者が正しく行動した後でのみ実行してください。
• 通常のデフォルトエントリを再起動し、復元されたルートが書き込み可能であることを確認してください。
• サービスパックの復旧後、リポジトリを更新し、パッケージの状態を確認し、登録状況をチェックしてください。
• 復旧完了を宣言する前に、除外されたサブボリュームについて、アプリケーションまたはデータ形式の不一致がないか確認してください。

最も重要なトレードオフは、精度と一貫性です。選択的なファイル復元では変更は少なくなりますが、何が破損したのかを正確に把握する必要があります。テスト済みのシステムロールバックでは変更は多くなりますが、一貫性のあるスナップショットのルート状態を復元するため、複数のコンポーネントに影響を与えた更新の失敗に適しています。SLES では、候補を検証する前にロールバックを不可逆的にするのではなく、読み取り専用のスナップショットブートを判断基準として使用するのが最も安全なワークフローです。