OSのバックアップ･リストアツールReaR(9): COPY_AS_IS って何?

UbuntuでReaR(Relax-and-Recover)のバックアップをしたとき、COPY_AS_ISに関するメッセージが表示されます。これ無視していいんだろか… と気になって眠れない、調べてみても良く分からず、更に眠れない(笑)。ということで COPY_AS_IS変数を指定した場合と指定しなかった場合の挙動を自分で確認してみました。

COPY_AS_IS に関するメッセージとは..

UbuntuのシステムをReaRでバックアップしたときに、以下のようなメッセージが標準エラー出力に出ます。

日本語に訳すと…

・ シンボリックリンク ‘A’ -> ‘B’ は、リカバリーシステムにおいて存在しないディレクトリを参照します。
・デフォルトではコピーされません。だから COPY_AS_IS 変数によって、’B’ をリカバリーシステムに含めることができます。

って、ことのようです。

COPY_AS_IS 変数のデフォルト値 は /usr/share/rear/conf/default.conf で以下の通りに定義されています。

だから、利用者が独自に COPY_AS_IS に要素を追加したい場合は、/etc/rear/local.conf において COPY_AS_IS に要素を追加する形式で定義するのが一般的です。前述のメッセージの要求通りに指定するなら、以下のように定義することになります。

COPY_AS_IS変数を定義して再度バックアップしたら..

さて、メッセージの要求通りに、COPY_AS_IS変数を上記のように定義して再度バックアップ(rear -v mkbackup)してみることにします。
しかし、これでメッセージは無くなると思いきや…今度は、158組のメッセージに増えました。
なぜなら、/usr/src/linux-headers-5.15.0-94/配下の複数のディレクトリ 及び ファイルに対しても同じメッセージが出力されるようになったためです。
うーん、、なんかキリがないですね(笑)。

リカバリーシステムとは何か?

このメッセージが指摘する問題は「リカバリーシステムに ’B’ がコピーされない」ということです。
ここでリカバリーシステムって何を差すのでしょう?

先ず、バックアップ元のシステムがどうなっているかを確認すると、以下のようになっていました。
・/usr/share/misc/magic と /lib/modules/5.15.0-94-generic/build はシンボリックリンクとして存在している。
・参照先の /usr/share/file/magic/ と /usr/src/linux-headers-5.15.0-94-generic/ はディレクトリとして存在している。

次に、ReaRが作成したバックアップファイル backup.tar.gz の中身を確認してみます。
1つ目はCOPY_AS_IS変数を定義しないでバックアップした backup.tar.gz 、2つ目はCOPY_AS_IS変数を上記のように定義してバックアップした backup.tar.gz です。
どちらのファイルの中にも、/usr/share/file/magic/ と /usr/src/linux-headers-5.15.0-94-generic/ は存在していましたし、もちろんシンボリックリンク /usr/share/misc/magic と /lib/modules/5.15.0-94-generic/build も存在していました。
従って、バックアップファイル backup.tar.gz はリカバリーシステムではないようです。
因みに、COPY_AS_IS変数を定義しないでバックアップした backup.tar.gz と COPY_AS_IS変数を上記のように定義してバックアップした backup.tar.gz の中身を比較してみましたが、差はありませんでした。

次に、ReaRがリカバリーした後のシステムではどうでしょうか? 1つ目はCOPY_AS_IS変数を定義しないでバックアップした backup.tar.gzからリカバリーしたシステム 、2つ目はCOPY_AS_IS変数を上記のように定義してバックアップした backup.tar.gz からリカバリーしたシステムです。
バックアップ元のシステムのファイル一覧を「find / -ls」で取得しておき、リカバリー後の2つのシステムにおいても、同様にファイル一覧を取得して比較してみました。
どちらの一覧の中にも、/usr/share/file/magic/ と /usr/src/linux-headers-5.15.0-94-generic/ は存在していましたし、もちろんシンボリックリンク /usr/share/misc/magic と /lib/modules/5.15.0-94-generic/build も存在していました。
従って、リカバリー後のシステムがリカバリーシステムではないようです(リカバリー後のシステムを英語で言うならリカバリードシステム ですものね)。

さて最後になりましたが、リカバリーシステムは <hostname>.initrd.cgz を差すようです。

今回のCOPY_AS_ISに関するメッセージは、バックアップ時に出力されますが、正確には、rear mkrescue (レスキューシステム作成)のプロセスで出力されています。このプロセスでは、レスキューシステムに必要となるカーネル(<hostname>.kernel)とRAMイメージ(<hostname>.initrd.cgz)を作成します。
<hostname>.initrd.cgzの中身を比較してみます。1つ目はCOPY_AS_IS変数を定義しないで作成した <hostname>.initrd.cgz 、2つ目はCOPY_AS_IS変数を上記のように定義して作成した <hostname>.initrd.cgz です。

シンボリックリンク /usr/share/misc/magic , /lib/modules/5.15.0-94-generic/build は、両方のファイルの中に存在しています。しかし、シンボリックリンクの参照先であるディレクトリ /usr/share/file/magic/ と /usr/src/linux-headers-5.15.0-94-generic/ は、COPY_AS_IS変数を定義しないで作成した <hostname>.initrd.cgz には存在しませんが、COPY_AS_IS変数を定義して作成した <hostname>.initrd.cgz には存在しています。

これでやっと理解できました。COPY_AS_IS は、リカバリーシステム(=レスキューシステム)<hostname>.initrd.cgz の中にファイルを含めるための変数ということなのですね。

COPY_AS_IS変数を指定する必要はあるのか..

今回の結論から言えば、COPY_AS_IS変数を定義してもしなくても、バックアップファイル backup.tar.gz の中身は同じでしたし、リカバリーもエラーなく実行できました。従って、今回のケースではCOPY_AS_IS変数は指定する必要はないと言えそうです。
リカバリーシステム(レスキューシステム)は、メモリに展開されて起動するOSで、対象となるサーバのストレージにバックアップを復元するまでの一時的なシステムです。リカバリー後の再起動で、復元されたストレージから新しいシステムが再起動します。よって、リカバリー処理でエラーが発生しない限りは、COPY_AS_IS変数に要素を追加しても追加しなくても良さそうです。
ただ、COPY_AS_IS変数に要素を追加することで、リカバリーシステムの容量が大きく増大するかもしれません。この点には注意が必要そうです。

広告主へのリンク

このブログにおける関連リンク

OSのバックアップ･リストアツールReaR(1):ReaRを使ってみた
OSのバックアップ･リストアツールReaR(2):ReaRのオプション
OSのバックアップ･リストアツールReaR(3):USBフラッシュメモリを使ったバックアップ
OSのバックアップ･リストアツールReaR(4): PXEを利用したOSのクローン
OSのバックアップ･リストアツールReaR(5):UbuntuでReaR
OSのバックアップ･リストアツールReaR(6):UbuntuでReaR(PXE編)
OSのバックアップ･リストアツールReaR(7): ReaRのトラブルシューティング
OSのバックアップ･リストアツールReaR(8): ReaRのcronは削除しよう
OSのバックアップ･リストアツールReaR(10): ReaRの仕組みを理解する
OSのバックアップ・リストアツールReaR(11): バックアップ対象外の指定