OSのバックアップ･リストアツールReaR(10): ReaRの仕組みを理解する

ReaR(Relax-and-Recover)はLinuxにおけるバックアップ・リストアツールとしてとても簡易かつ優秀だと思っています。でもその割に、ReaRって認知度が低いんですよね。今回は、ReaRが何者なのかを理解してもらう目的も含めて、Rearの仕組み(動作)について、今更ながらまとめたいと思います。この仕組みを理解しておくことで、トラブルシューティングにも役に立つはずです。

ReaRのバックアップ・リストアの仕組みの基本は tar+gzip
ReaRにおけるバックアップ・リカバリー処理の流れ
このブログにおける関連リンク

ReaRのバックアップ・リストアの仕組みの基本は tar+gzip

皆さんがバックアップをとる手段として、一番使用するツールは何でしょう？

いろいろな意見があるかとは思いますが、Linuxシステムであれば、tar もしくは tar+gzipが一般的なのではないでしょうか。ホームディレクトリ配下を一括してバックアップする、あるいはプロジェクトのディレクトリ配下を一括してバックアップする、といった用途にtar+gzipを使用していると思います。

一方で、OSのシステム全体をバックアップするとなると、少しハードルが高くなります。正確には、OSのシステム全体をリストアすることが簡単ではない、と言ったほうが良いでしょう。なぜなら、/(root) 配下のシステム全体をtar+gzipでバックアップすることは簡単ですが、そのバックアップファイルを展開して /(root) 配下に書き戻すことは簡単ではありません。何故なら、/(root) 配下のファイル群でOSが稼働しているからです。

従って、システム全体をストレージにリストアする場合は、メモリ上に仮のOS(システム)を起動して、バックアップの内容をストレージに書き戻します。このときに起動する仮のシステムがリカバリーシステム(またはレスキューシステム)です。でも素人がいきなりリカバリーシステムを作成するのって難しいですよね。。

ReaRも、バックアップファイルはtar+gzipで作成します。それだけでなく、バックアップを行ったときに、リカバリーシステムも作成してくれるところが、ReaRが良く出来ている点なのです。

ReaRにおけるバックアップ・リカバリー処理の流れ

ReaRにおける、バックアップ処理とリカバリー処理の流れを図にまとめてみました。

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

バックアップ元システムで、ReaRのバックアップ処理を実行するとき、以下のようにrearのコマンドを実行しているかと思います。

# rear -v mkbackup

mkbackupという引数は、バックアップ処理を行う指示ですが、正確にはレスキューシステムの作成と、バックアップファイルの作成を順番に行っています。実は、「rear -v mkbackup」という処理は、以下のように実行するのと等価です。

# rear -v mkrescue
# rear -v mkbackuponly

mkrescueはレスキューシステム(リカバリーシステム)を作成する指示です。レスキューシステムの作成では、リカバリーのときに起動する仮のシステム(リカバリーシステム)として、カーネル(<hostname>.kernel)とRAMイメージ(<hostname>.initrd.cgz)を作成します。

mkbackuponlyは、tar+gzipでバックアップファイル(backup.tar.gz)を作成する指示です。

ちなみに、RAMイメージは、バックアップ対象のシステムと1:1に対応しているので、バックアップ対象システムになんらかの更新を行ったら、RAMイメージも再作成して下さい。そうしないとリカバリー処理でエラーになることがあります。だから、mkrescureとmkbackuponlyはペアで実行する必要があります。
前述の通り、mkbackupを指定すれば、mkrescureとmkbackuponlyの両方が実行されるので、通常はmkbackup指定で実行すればOKです。mkrescureとmkbackuponlyを分けて実行する意味はあるのでしょうか? もしあるとすれば、エラーが発生したときに、どちらの処理で発生しているのかが分かりやすいという点と、mkrescureでエラーが発生するほうが多いので、デバッグをmkrescure単独で行える、という点だと思います。

レスキューシステムをISOイメージとして作成したい場合(OUTPUT=ISO)は、カーネルとRAMイメージは、ReaRが作成するISOファイルの中に格納されます。バックアップファイルの出力先にISOイメージを指定した場合(BACKUP_URL=iso:///<path>)は、バックアップファイルは同じようにISOファイルの中に格納されます。

レスキューシステムは、USBフラッシュメモリとして作成することも(OUTPUT=USB) 、PXEブート用に作成することも(OUTPUT=PXE)可能です。もちろん、バックアップファイルをISOファイル以外(例えば、NFSのファイルシステム)に出力することも可能です。

詳細は、過去の記事をご覧になって下さい。
OSのバックアップ･リストアツールReaR(2):ReaRのオプション

リカバリー処理では、先ずはレスキューシステムを起動する

前述の通り、レスキューシステム(リカバリーシステム)は、バックアップファイルをリストア(ストレージに書き戻す)するためにメモリ上で起動するシステムです。カーネルとRAMイメージで構成され、PXEbootでレスキューイメージを起動するときには、コンソールに以下のメッセージが表示されるので、とても分かりやすいです。

Loading kernel
Loading initial ramdisk

バックアップ時の指定で、レスキューシステムをISOイメージとして作成した場合、作成したISOイメージをDVD-ROMに焼いて、そのDVD-ROMからレスキューシステムを起動します。PXEbootの場合は、カーネルとRAMイメージをtftpサーバに置いて、PXEbootでレスキューシステムを起動します。

レスキューシステムが起動したらrootでログインする。なんとパスワード無しでログインできます。

ファイルシステムをdfコマンドで確認すると、tmpfsとなっていますので、メモリ上にシステムが作成されています。/ (root)配下を確認すると、ちゃんとLinuxとして最小限のファイルとディレクトリが展開されているようです。

さて、この時点ではリストア対象となるストレージはマウントされていません。
レスキューシステムにおいて、リストアすべきストレージは、/mnt/local/ 配下にマウントされますが、この時点では以下の通り、空です。

リカバリー処理は以下のコマンドで実行します。

# rear recover

rear recoverを実行すると、ストレージが /mnt/local/ 配下にマウントされて、バックアップファイルからのリストアが開始されます。
ReaRが優れているのは、バックアップ前のパーティション情報に基づいて、ストレージのパーティション作成も自動でしてくれるし、バックアップ前にソフトウェアRAID(MD Raid)を組んでいれば、それも再構成もしてくれる点です。レスキューシステムのRAMイメージ(<hostname>.initrd.cgz)を、バックアップ対象システムから作成しているのは、ドライバも含めて必要な機能をRAMイメージに取り込むためだと思います。

さて、rear recoverが完了した後に、改めて /mnt/local/ 配下にリストアされたストレージをdfコマンドで確認してみます。

ストレージデバイス /dev/sda2 が /mnt/local/boot/ に、/dev/sd1 が /mnt/local/boot/efi にマウントされています。そして、 / (root) は LVMだったので /dev/mapper/ubuntu–vg-ubuntu—lv/ にマウントされていることが分かります。

そして、最後に reboot すれば、次の起動するときには、ストレージにリストアされた本当のシステムが起動するという訳です。めでたしめでたし。。。