9.10. バックアップ

バックアップを取ることは管理者の主要な責任の 1 つです。しかし、これは通常極めるのが難しい強力なツールを使う複雑な問題です。

バックアップ作業に関して言えば amanda、bacula、BackupPC などの多くのプログラムが存在します。これらは多くの機能を備えるクライアント/サーバシステムで、その設定はかなり難しいです。いくつかのプログラムは難しさを和らげるためのユーザフレンドリーなウェブインターフェースを提供しています。しかし Debian には、すべての考え得る使用事例に対応できる、他の数多くのバックアップソフトウェアが含まれています。ソフトウェアを確認するには apt-cache search backup を使ってください。

この節ではプログラムの使い方を詳細に説明するのではなく、Falcot Corp の管理者がバックアップ戦略を定義する際にどのように考えたかを説明します。

Falcot Corp では、バックアップには 2 つの目標があります。具体的に言えば、誤って削除したファイルを回復することと、ハードドライブに障害が起きた際にコンピュータ (サーバおよびデスクトップ) を素早く復元することです。

9.10.1. `rsync` を使ったバックアップ

テープへのバックアップは遅くて費用がかかりすぎるとみなされ、データは専用サーバのハードドライブにバックアップされることになりました。専用サーバはソフトウェア RAID (第 12.1.1 節「ソフトウェア RAID」を参照してください) を使ってデータをハードウェア障害から守っています。デスクトップコンピュータは個別にバックアップされませんが、ユーザは部署のファイルサーバの個人アカウントはバックアップされると知らされています。毎日異なるサーバにバックアップを行う目的で、rsync コマンド (同名のパッケージに含まれます) が使われています。

BACK TO BASICS ハードリンク、ファイルの別名

ハードリンクはシンボリックリンクと異なり、リンクされたファイルと区別できません。本質的に、ハードリンクの作成は既存のファイルに別名を与えることと同義です。そのため、ハードリンクの削除はそのファイルに関連する名前を削除するに過ぎません。他の名前がまだそのファイルに関連付けられている場合、データの実体はファイルシステムから削除されません。コピーと異なり、ハードリンクはハードドライブ上に追加的な領域を必要としない点について注意することは興味深いです。

ハードリンクは ln target link コマンドで作成されます。ここで link ファイルは target ファイルの新しい名前です。ハードリンクは target と link が同じファイルシステム上にある場合に限り作成できます。対してシンボリックリンクはこの制限を受けません。

利用できるハードドライブの空き領域によっては、完全な日次バックアップができない場合があります。このため、まず rsync コマンドは今回のバックアップの内容を前回のバックアップの内容へのハードリンクの形で複製します。このおかげで、ハードドライブ領域を無駄に消費することがなくなります。そして rsync プロセスは前回のバックアップ以降に変更されたファイルだけを置き換えていきます。このメカニズムにより、多くのバックアップを少ない領域に保存することが可能です。すべてのバックアップは即座に利用できる上に即座にアクセスできるので (たとえば、ネットワーク共有されたディレクトリの中に置かれるので)、ある日付同士の違いを素早く比較できます。

dirvish プログラムを使えば、このバックアップメカニズムを簡単に実現できます。dirvish プログラムはバックアップストレージ領域 (dirvish 用語で「bank」) を使い、「bank」の中に一連のバックアップファイルのタイムスタンプを付けたコピー (dirvish の文書ではこれらを「vault」と呼びます) を置きます。

主要な設定は /etc/dirvish/master.conf ファイルに書かれています。/etc/dirvish/master.conf ファイルでは、バックアップストレージ領域の場所、管理する「vault」のリスト、バックアップの保存期限のデフォルト値を定義します。残りの設定、すなわち vault でバックアップするファイルセットに固有の設定は bank/vault/dirvish/default.conf ファイルに書かれています。

例 9.3 /etc/dirvish/master.conf ファイル

bank:
    /backup
exclude:
    lost+found/
    core
    *~
Runall:
    root    22:00
expire-default: +15 days
expire-rule:
#   分  時    日  月        曜日 保存期限
    *   *     *   *         1    +3 months
    *   *     1-7 *         1    +1 year
    *   *     1-7 1,4,7,10  1

bank 設定はバックアップが保存されるディレクトリを表します。exclude 設定を使うと、バックアップからファイル (またはファイルタイプ) を除外することが可能です。Runall はタイムスタンプを付けてバックアップするファイルセットのリストです。これにより、万が一割り当てられた時間に正確にバックアップが実行されない場合でも、バックアップコピーに正確な時刻を割り当てることが可能です。ここで指定する時刻は実際の実行時刻の直前の時刻でなければいけません (/etc/cron.d/dirvish によれば、Debian では実際の実行時間はデフォルトで午後 10 時 4 分です)。最後に expire-default と expire-rule 設定でバックアップ保存期限ポリシーを定義します。上の例は、各四半期の最初の日曜日に作成されたバックアップを永久に保存し、それに当てはまらない各月の最初の日曜日に作成されたバックアップを 1 年経過後に削除し、それに当てはまらない日曜日に作成されたバックアップを 3 カ月経過後に削除します。その他の日次バックアップは 15 日間保存されます。ルールが適用される順番が問題です。Dirvish は最後にマッチしたルールを使い、expire-rule にマッチするものがなければ expire-default を使います。

例 9.4 /backup/root/dirvish/default.conf ファイル

client: rivendell.falcot.com
tree: /
xdev: 1
index: gzip
image-default: %Y%m%d
exclude:
    /var/cache/apt/archives/*.deb
    /var/cache/man/**
    /tmp/**
    /var/tmp/**
    *.bak

上の例では、バックアップするファイルセットを指定しています。具体的に言えば、バックアップ対象は rivendell.falcot.com マシン (ローカルデータをバックアップするには、単純に hostname の出力するローカルマシンの名前を指定します) にあるルートツリーの内容 (tree: /) から exclude で指定したものを除外したファイルです。さらに、バックアップ対象は tree と同一のファイルシステムの内容 (xdev: 1) に制限されます。他のマウントポイントのファイルはバックアップされません。保存されたファイルのインデックス (index: gzip) が生成され、イメージには現在の日付に関連する名前 (image-default: %Y%m%d) が付けられます。

多くのオプションがあり、すべては dirvish.conf(5) マニュアルページに書かれています。一度これらの設定ファイルを作ったら、dirvish --vault vault --init コマンドを使って、各ファイルセットを初期化します。ここまでが済むと、毎日の dirvish-runall 実行時に期限切れになったバックアップコピーが削除され、その直後に自動的に新しいバックアップコピーが作成されます。

9.10.2. バックアップなしのマシンの復元

バックアップされていないデスクトップコンピュータに対しては Simple-CDD でカスタマイズされた DVD-ROM からシステムを再インストールするのが簡単でしょう (第 12.3.3 節「Simple-CDD、一体型の解決策」を参照してください)。インストールを最初からやり直すので、初回インストール後に行われたすべての設定は失われます。これは問題ではありません。なぜなら、アカウントに関して言えばシステムはすべて中央 LDAP ディレクトリの情報を参照しており、多くのデスクトップアプリケーションに関して言えば dconf のおかげで事前設定されているからです (詳しい情報は第 13.3.1 節「GNOME」を参照してください)。

Falcot Corp の管理者は自分たちのバックアップポリシーの限界を理解しています。テープを耐火金庫に入れるかのようにバックアップサーバを保護することができないため、管理者はバックアップサーバを他のサーバと別の部屋に設置しました。そうすればサーバルームの火事などの災害が起きてもその他のサーバと一緒にバックアップも破壊されることを避けられるからです。さらに、管理者は 1 週間に 1 回 DVD-ROM に増分バックアップ (最後のバックアップ以降に修正されたファイルだけのバックアップ) をとるようにしています。

GOING FURTHER SQL と LDAP サービスのバックアップ

多くのサービス (SQL や LDAP データベースなど) は単純にファイルをコピーするだけではバックアップできません (それらのサービスをバックアップの作成中に適切に中断しない限りバックアップできません。サービスの中断は通常問題です。なぜなら、サービスが常に利用できることを意図されているからです)。そのような場合、安全にバックアップできる「データダンプ」を作るために「エクスポート」メカニズムを使うことが必要です。データダンプは通常サイズのとても大きいファイルですが、データダンプのサイズは圧縮によってかなり小さくなります。要求されるストレージ領域を減らすために、完全なテキストファイルを保存するのを 1 週間に 1 回、diff を保存するのを毎日に制限しています。差分は diff file_from_yesterday file_from_today で生成されます。バイナリダンプから増分差分を作成するには xdelta プログラムを使ってください。