OSのバックアップ･リストアツールReaR(7): ReaRのトラブルシューティング

今回は、ReaR (Relax-and-Recover) でエラーが発生したときに、どういう方法でトラブルシューティングをしたら良いのかを書きます。Relax-and-Recoverはその名の通り、ユーザの手をあまり煩わせることなく(リラックスして)、システム全体のバックアップとリカバリーを行える便利なツールですが、常にエラーが発生しないという訳ではありません。どちらかというとエラーが発生するケースは結構多い気がします。ReaRで困ったときに、どうしたら良いか、の参考にして頂ければ嬉しいです。

まずはReaRの仕組みを理解しよう..
ログ出力に関する引数オプション
バックアップ処理はレスキューシステムの作成処理とバックアップファイルの作成処理で構成される
オプション(変数)の意味を知るには..
トラブルの事例を検索するには…
このブログにおける関連リンク

まずはReaRの仕組みを理解しよう..

ReaRの仕組みと言いますか、コンセプトやポリシーと言ったほうが良いかもしれませんが、、

ReaRは bashスクリプトで出来ている

という点を理解しておきましょう。定義ファイルのように思っていた /etc/rear/local.conf も、ReaRのスクリプト群で参照されるbashの変数の定義です。更に正確に言うと、ReaRの中で実行されるbashスクリプトです。だからbashの文法でif文を書くこともできます。
Ubuntu Server 24.04 LTSのバックアップでは、「rear -v mkbackup」の実行前に、環境変数 LD_PRELOAD に /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-255.so を定義しておく必要がありましたが、/etc/rear/local.conf に以下の行を追加しても、同じ結果になったのは /etc/rear/local.conf もbashスクリプトであるためです。

export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-255.so

ReaRの実体は、/usr/share/rear/ 配下にインストールされるbashスクリプトの集合体です。処理のstepに対応したディレクトリの下に分類されて格納されています。
ReaRのログには、処理の中で、定義ファイルや各種のbashスクリプトが実行されていることを、以下の例のような「Including …」というメッセージで確認することができます。

2024-06-04 12:43:57.617073083 Including /etc/rear/local.conf
～ 2024-06-04 12:43:57.631353635 Including init/default/005_verify_os_conf.sh
～

従って、エラーメッセージの発生したタイミングと「Including …」のメッセージから、どのbashスクリプトでエラーが発生したのかを判断することができます。また、エラーメッセージを検索キーとして、以下のようにgrepコマンドで検索すれば、エラーが発生したbashスクリプトを探し出すこともできます。

grep -R 'エラーメッセージ' /usr/share/rear

ログ出力に関する引数オプション

VERBOSEモードを有効にする(-v)

VERBOSE(冗長)モードはrearコマンドに「-v」オプションを付ければ有効になります。というか、バックアップを実行するときに、当たり前のように「rear -v mkbackup」のように実行したので、既にVERBOSEモードは有効にして使っていたんですね。
「冗長」の意味は、ログに出力するメッセージを端末画面にも表示するよ、という意味で使われています。ちなみに、「-v」オプションを付けずに「rear mkbackup」を実行すると…

端末画面にはログが出力されません…

エラーやワーニングは表示してくれるのですけどね、、、バックアップ中、長時間に渡ってメッセージが表示されないと不安になりますし、エラー発生のタイミングも分かりにくいです。>_<
もちろん、ログファイル /var/log/rear/rear-<hostname>.log は作成されているので、それを見れば処理の経過やエラーメッセージを後から確認することはできます。
更に、VERBOSEオプション(-v)を有効にすれば、ログファイルにも多くのメッセージが出力されるよらうになります。見たところ、レスキューシステムを作成する処理において、どんなライブラリモジュールがリンクされるのかが詳細に表示されていました。。

DEBUGモードを有効にする(-d)

DEBUGモードはrearコマンドに「-d」オプションを付ければ有効になります。前述の「-v」オプションに加えて、「-v -d」を指定してバックアップを実行したところ、ログファイルは 8526行となり、「-v」オプションだけを指定した場合と比較して、42行しか増えていません。ファイルを比較して見ても、特に何か有用な情報が追加されているようにも思えず。。。数十行程度の増加であれば、指定しておいても良いかもしれません。

DEBUGSCRIPTモードを有効にする(-D)

DEBUGSCRIPTモードは、bashスクリプトを実行する際に「set -x」を指定して実行します。要するに、実行されたコマンド(というかコマンドだけではないので「実行文」ですね…)の履歴がログに逐一出力されるということです。manページでは「-v -d」も同時に指定してね、と書いてあります。
ログファイルの行数は一気に増えて30874行になりました。正直な感想としては、全ての実行文の内容が見れるのはトラブルシューティングのためには有用かもしれないですが、全体がとても見にくく、逆にエラーを見逃してしまうリスクがあると思いました。
前述の通り、ReaRのシステムは全てがbashスクリプトで出来ていますので、問題が発生しているbashスクリプトを直接修正して、必要な箇所で「set -x」(実行文の表示を有効にする)と「set +x」(実行文の表示を無効にする)を挿入するほうが、トラブルシューティングにも効率が良いと思いました。

VERBOSE(-v), DEBUG(-d), DEBUGSCRIPT(-D) の指定でログ出力はどう変わる?

それぞれのオプションのあり/なしで出力がどのように異なるのか、以下の表にまとめてみました(行数は私がテストした際の行数ですのであくまでも目安に..)。

オプション指定	端末出力	ログファイルの出力	ログファイルの行数
なし	エラー,ワーニングのみ	ReaRのbashスクリプトの実行履歴主要なログメッセージ	1174
-v	処理のログとエラー,ワーニング	上記に加えて詳細なログ	8484
-v -d	上記に加えてデバッグ出力	上記に加えてデバッグ出力	8526
-v -d -D	上記と同じ	上記に加えてbashスクリプト内の実行文の履歴	30874

DEBUGSCRIPT(-d)のオプションはさすがにログの出力行数が多くてチェックするのが大変ですね。。VERBOSEオプション(-v)は付けておいて損はないですので、ぜひ付けてバックアップを実行しましょう。DEBUG(-d)はお好きにどうぞ。付けておいても邪魔にはなりません。

バックアップ処理はレスキューシステムの作成処理とバックアップファイルの作成処理で構成される

ReaRのバックアップ処理は、最初にレスキューシステムの作成が行われて、その後にシステムのバックアップファイル作成が行われます。

# rear -v mkbackup

を実行すると、実はレスキューシステムの作成とバックアップファイルの作成の両方の処理が実行されます。それぞれの処理を個別に実行したい場合は、以下のように実行します。

# rear -v mkrescue ※レスキューシステムの作成
# rear -v mkbackuponly ※システムのバックアップファイルの作成

レスキューシステムが何かというと、バックアップしたデータをストレージにリカバリーするには、仮のOSをメモリ上に起動して、ReaRのリカバリ処理を実行する必要がありますが、このときのメモリ上に起動する仮のOSのことを差します。。レスキューシステムはリカバリーされるシステム本体ではないので、レスキューシステムの作成が完全でなくても、リカバリーに成功する場合もあります。
具体的に言うと、Ubuntu Server 24.04 LTSのバックアップでは、レスキューシステムの作成において、/usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-255.so というモジュールを組み込みできなかったのですが、そのレスキューシステムがうまく動作したので、バックアップファイルをリカバリーすることには成功しました。

バックアップ処理におけるstage

更に正確に表現すると、ReaRのバックアップ処理は、いくつかの stage に分割されて実行されています。ISOファイルにバックアップを作成した際には、以下の stage が実行されていました。

2024-06-04 12:43:57.620692032 Running ‘init’ stage
～
2024-06-04 12:43:57.681527580 Running ‘prep’ stage
～
2024-06-04 12:43:58.410086517 Running ‘layout/save’ stage
～
2024-06-04 12:43:59.590173925 Running ‘rescue’ stage
～
2024-06-04 12:44:00.711282406 Running ‘build’ stage
～
2024-06-04 12:44:36.265720298 Running ‘pack’ stage
～
2024-06-04 12:45:45.640776387 Running ‘backup’ stage
～
2024-06-04 12:49:38.126605284 Running ‘output’ stage
～

pack stageの中でレスキューシステムのRAMイメージ initrd.cgz が作成されていますので、ここまでが前半工程(レスキューシステムの作成)と言えるでしょう。
bacup stageでは、バックアップファイル backup.tar.gz が作成され、output stageでは、(今回のケースでは) ISOファイルの作成が行われます。
このような流れを理解しておくと、トラブルシューティングの際に原因の分析に役に立つかと思います。

オプション(変数)の意味を知るには..

/etc/rear/local.conf に定義するReaRの変数の意味を知る一つ目の手段は、「man rear」でReaRのマニュアルページを参照することです。基本的な変数についてはこの方法で確認するのが良いでしょう。もっとシンプルな日本語の説明が欲しい…という場合は、過去の記事をご参照下さい。

･OSのバックアップ･リストアツールReaR(2):ReaRのオプション

ReaRの変数の意味を知る二つ目の手段は、あたりまえですが、Relax-and-Recover User Guide Documentation を見ることです。Basic configuration のページをみると親切な説明が書いてあります。こちらも英語ですね。。。

ReaRの変数の意味を知る三つ目の手段は、デフォルトの設定ファイル /usr/share/rear/conf/default.conf を参照することです。

このファイルは、ReaRの変数のデフォルト設定が定義されているだけではなく、それぞれの変数の詳細な説明がコメント行で記載されています。変数に関連するgithubのissueへのURLを記載されていることも多いです。そのissueを読めば、githubにReaRの問題が投稿され、解決方法が議論された上で、ReaRのソースコード(と言ってもbashスクリプト)に反映されてきたんだなあと、背景を知ることもできるのはとても奥深いです。。結構、参考になります。

トラブルの事例を検索するには…

ReaRのgithub

Relax-and-Recoverプロジェクトでは、ソースコード管理とissue追跡(問題の報告や改善、新機能の議論)にgithubを使っています。従って、Relax-and-Recoverプロジェクトのgithubのissue追跡で検索をすれば、有益な解決方法が見つかります。
ただ、githubの検索機能はあまり優れていない印象を受けます。検索窓にエラーメッセージをそのまま入力して事例がヒットしないこともあるので入力する文字列を工夫みると良いでしょう。

issue追跡の検索窓の初期値は「is:issue is:open」となっているので、Open(議論中)のもののみが表示されています。

問題の検索をするときには、「is:issue is:open」を削除してから、エラーメッセージを入力するのが良いでしょう。試しに、Ubuntuのバックアップのときに発生していたメッセージ「Failed to copy all contents of /lib/modules/6.8.0-31-generic (dangling symlinks could be a reason)」を入力してみます。