8.4. Red Hat Enterprise Linux 固有の情報

8.4.2.1. tar

tar ユーティリティは UNIX システム管理者の間でよく知られているユーティリティです。システム間でソースコードの一部やファイルを共有するためのアーカイブメソッドの一種です。Red Hat Enterprise Linux に含まれている tar 実装は GNU tar で、豊富な機能を備える tar 実装のひとつです。

tar を使用すると、ディレクトリの内容のバックアップが次のようなコマンドを発行するだけで簡単に行なえます。

tar cf /mnt/backup/home-backup.tar /home/

このコマンドは /mnt/backup/ に home-backup.tar という名前のアーカイブファイルを作成します。アーカイブには /home/ ディレクトリの内容が含まれます。

ファイルのアーカイブはデータをバックアップするのとほぼ同じ大きさになります。バックアップするデータの種類により、アーカイブファイルを圧縮するとかなりサイズを縮小することができます。アーカイブファイルは先のコマンドにオプションを 1 つ付けると圧縮することができます。

tar czf /mnt/backup/home-backup.tar.gz /home/

結果、home-backup.tar.gz アーカイブファイルはこれで gzip 圧縮されました [1]。

tarには多くのオプションがあります。詳細についてはtar(1) の man ページをご覧ください。

8.4.2.2. cpio

cpio ユーティリティも 伝統的な UNIX プログラムです。データをある場所から別の場所へ移動するための汎用用途で使用できる優れたプログラムで、バックアッププログラムとして役立ちます。

cpio の動作は tar とは若干異なります。tar とは異なり、cpio は標準入力で処理するためにファイルの名前を読み込みます。cpio の場合ファイル一覧を生成する一般的な方法は、find などのプログラムを使用してその出力が cpio にパイプされるようにするものです。

find /home/ | cpio -o > /mnt/backup/home-backup.cpio

このコマンドは /mnt/backup/ ディレクトリ配下に home-backup.cpio という名前の cpio アーカイブファイルを作成します(/home/内のすべてを含んでいる)。

	ヒント
	find には豊富なファイル選択基準があるため、高度なバックアップが簡単に作成できます。例えば、次のコマンドでは去年アクセスされなかったファイルに関してだけバックアップを行ないます。

find /home/ -atime +365 | cpio -o > /mnt/backup/home-backup.cpio
            

cpio (及び find) には数多くのオプションがあります。詳細については cpio(1) 及び find(1) それぞれの man ページをご覧ください。

8.4.2.3. dump/restore — マウントされているファイルシステムには使用しないでください

dump と restore プログラムは同じ名前の UNIX プログラムに相当する Linux プログラムです。UNIX の経験がある多くのシステム管理者は dump と restore が Red Hat Enterprise Linux でのバックアップに適したプログラムだと感じているかもしれませんが、dump を使ったある方法が問題となることがあります。これについてのLinus Torvald 氏のコメントです。

From:	 Linus Torvalds
To:	 Neil Conway
Subject: Re: [PATCH] SMP race in ext2 - metadata corruption.
Date:	 Fri, 27 Apr 2001 09:59:46 -0700 (PDT)
Cc:	 Kernel Mailing List <linux-kernel At vger Dot kernel Dot org>

[ linux-kernel added back as a cc ]

On Fri, 27 Apr 2001, Neil Conway wrote:
> > I'm surprised that dump is deprecated (by you at least ;-)).  What to
> use instead for backups on machines that can't umount disks regularly? 


Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.

So anybody who depends on "dump" getting backups right is already playing
Russian roulette with their backups.  It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being "backed up".

Dump was a stupid program in the first place. Leave it behind.

> I've always thought "tar" was a bit undesirable (updates atimes or
> ctimes for example).

Right now, the cpio/tar/xxx solutions are definitely the best ones, and
will work on multiple filesystems (another limitation of "dump"). Whatever
problems they have, they are still better than the _guaranteed_(*)  data
corruptions of "dump".

However, it may be that in the long run it would be advantageous to have a
"filesystem maintenance interface" for doing things like backups and
defragmentation..

		Linus

(*) Dump may work fine for you a thousand times. But it _will_ fail under
the right circumstances. And there is nothing you can do about it.

この問題に関して、マウントされているファイルシステムでの dump/restore の使用は強く反対します。しかし、dump はもともとマウントされていないファイルシステムのバックアップ用にデザインされたので、umount でファイルシステムをオフラインにできる状況なら dump は実行可能なバックアップ技術です。

8.4.2.4. AMANDA (Advanced Maryland Automatic Network Disk Archiver)

AMANDA はメリーランド大学が作成したクライアント/サーバベースのバックアップアプリケーションです。クライアント/サーバのアーキテクチャを用いることにより、単一バックアップサーバ(通常、高速ディスクにかなりの空き領域を持ち、目的のバックアップデバイスで構成されたかなり強力なシステム)で多くのクライアントシステムをバックアップすることができ、AMANDA クライアントソフトウェア以外には何も必要ありません。

バックアップに必要なリソースをひとつのシステムに集中し、バックアップサービスを必要とするシステムそれぞれには追加のハードウェアが必要なくなるため、このバックアップ方法は非常に意味があります。AMANDA はバックアップの集中管理も行なうようデザインされているため、システム管理者の負担がかなり軽減されます。

AMANDA サーバはバックアップメディアのプールを管理して管理者が指示した保存期間中すべてのバックアップを保持するためにプールを回転させます。すべてのメディアはデータで事前にフォーマット化され、AMANDA が適切なメディアが使用可能かどうかを検出することができます。また、AMANDA はロボットメディア変更ユニットと連結することができるので、完全なバックアップの自動化が可能になります。

AMANDA は tar か dump のいずれかを使用して実際のバックアップを行なうことができます(ただし、dump での問題が 項8.4.2.3 で提起されているため、Red Hat Enterprise Linux では tar の使用をお勧めします)。このように、AMANDA バックアップはファイルを復元するのに AMANDA を必要としません。

操作においては、通常、AMANDA がデータセンターのバックアップ時間枠内で 1 日に 1 度実行されるようスケジュールします。AMANDA サーバはクライアントシステムに接続して行なわれるべきバックアップの概算サイズを生成するよう指示します。概算がすべて算出されると、サーバはスケジュールを立てて、自動的にバックアップするシステムの順番を確定します。

実際にバックアップが開始されると、ネットワーク経由でデータがクライアントからサーバへ送られ、保留ディスクに保存されます。バックアップが終了すると、サーバは保留ディスクからバックアップメディアへの書き込みを開始します。同時に、他のクライアントがバックアップを保留ディスクへ保存するためサーバへ送信しています。結果、バックアップメディアへの書き込みにデータが連続して流れるようになります。バックアップはバックアップメディアに書き込まれるので、サーバの保留ディスクからは削除されます。

すべてのバックアップが終了すると、バックアップのステータスが概略されたレポートがシステム管理者に電子メールで送信されるため、確認作業が簡単に手早く行なえます。

データの復元が必要とされる場合、AMANDA にはユーティリティプログラムがあり、これによりオペレータがファイルシステム、日付、ファイル名を識別できます。識別が完了すると、AMANDA は適切なバックアップメディアを識別してから目的のデータを検索し復元します。前述したように、AMANDA は AMANDA の支援なしでもデータを復元することができるよう設計されていますが、適切なメディアの識別には時間がかかり、マニュアルのプロセスになります。

このセクションは最も基本的な AMANDA についての概念だけに触れています。AMANDA について詳しく調べるには、amanda(8) の man ページから始めてください。