Linux: dump and restore mini-HOWTO

FUKUSHIMA Osamu, (福島於修), <fuku@amorph.net>

1. dump/restore: Overview

• 1.1 他のアーカイヴソフトとの比較
• 1.2 他のバックアップソフトとの比較

2. メディアに関すること

3. Linux での利用

• 3.1 dump/restore v0.3
• 3.2 dump/restore v0.4 Beta
• 3.3 デバイスファイル

4. mt コマンド

• 4.1 mt
• 4.2 mt の操作例
• 4.3 MTX の操作例(集合型テープドライブの操作)

5. dump を使ったバックアップ

• 5.1 バックアップするファイルシステムの選択
• 5.2 フルバックアップ
• 5.3 ダンプレベルとインクリメンタルバックアップ
• 5.4 dump の記録
• 5.5 rdump
• 5.6 テープの保管
• 5.7 スケジューリング

6. restore

• 6.1 レストアの際の注意
• 6.2 フルレストアの手順

7. バックアップは本当に必要か?

Appendix

8. この文書について

• 8.1 Copyright notice
• 8.2 責任の放棄
• 8.3 謝辞
• 8.4 フィードバック
• 8.5 履歴

1. dump/restore: Overview

dump(8) と restore(8) は、 BSD 系 UNIX で伝統的に使われてきた、 ファイルシステムのバックアップ・レストアのためのプログラムです。

dump はファイルシステムをバックアップし、 restore はバックアップされたアーカイヴ(書庫)からファイルを復元します。 アーカイヴは普通のファイルとして、 通常のファイルシステムに作成することができますが、 一般的にはバックアップ専用の外部デバイス (テープデバイスなど) に 保存することが多く、dump コマンドにはそのための利便も用意されています。

1.1 他のアーカイヴソフトとの比較

アーカイヴを作成するソフトウェアとしては、他に cpio, tar, afio といったもの があります。これらのソフトウェアはファイル単位でアーカイヴのターゲットを認識 します。したがって特定のファイルやディレクトリをアーカイヴする対象から除外し たり、複数のファイルシステムにまたがって単一のアーカイヴを作成することもでき ます。

一方 dump は物理的なファイルシステム単位でターゲットを認識します。そして、個々 のファイルは i-node の単位で処理されます。特定のファイルをアーカイヴの対象か ら除外するような機能は用意されていません。(これに関しては、別の方法で同じよ うな効果を得ることもできます。詳しくは後述する バックアップしないファイルを除外する を参照してください。)

そのかわり、dump はインクリメンタルアーカイヴ(前回のアーカイヴ時点から更 新されたファイルだけを選び出してアーカイヴする)の機能に関しては、たいへん すぐれた機構を提供しています。また、インクリメンタルアーカイヴに要する時間 も、他の方法にくらべて非常に高速です。

restore は dump を使ってしたアーカイヴファイルを元に、その dump 作業を行っ た時の状態にファイルシステムを復元しようとします。

例えば前回のアーカイヴ時に存在した foo というファイルが、その後不要になっ て削除されたとします。次のインクリメンタルアーカイヴの時点では foo は存在 しないので、dump は「foo というファイルがあったけど、これは削除されています」 という情報をインクリメンタルのアーカイヴファイルに残します。

tar を使ってインクリメンタルバックアップを続けていて、ある日全てをフルレスト アしてみたら、はるか昔に消したはずのファイルがいっぱいで、ファイルシステムが 溢れてしまった、という事態には決してなりません。

以上のことをまとめると、

• 特定のディレクトリやファイルをアーカイヴするには、 cpio, tar, afio などが向いている
• ファイルシステムのアーカイヴには、dump が向いている

1.2 他のバックアップソフトとの比較

dump は tar と同様にファイルをアーカイヴする機能がありますが、それ自体がバッ クアップソフトでもあります。ところで、Linux のバイナリディストリビューション にはバックアップ専用のユーティリティーが付属していることがあります。さまざま な種類のユーティリティーがありますが、外部のアーカイヴツールのフロントエンド として動作するものが多いようです。すべてを実際に使ってみたわけではありません が、メニュー形式でセットアップができるものもあり、なかなか便利に思えます。

これまで、私も何度かそういうユーティリティーを使ってみようかと考えましたが、 結局使わないまま今日にいたっています。ひとつには、すでに dump/restore に慣れ てしまっているので、新しいソフトウェアの使用方法を覚えるのが面倒に感じられる、 ということがあります。しかし、結局のところは「単純なものの方が信頼できる」と いう一点につきるようです。dump で保存したバックアップが必要になる状況は、い わは緊急事態といえます。システムそのものが起動しない状況さえも想定しておかな ければなりません。そう考えると、あまりきちんと整った環境でなくても動作するこ とが期待できるツールの方が何かと都合がいいと思うのです。

私は initrd を利用した緊急起動用のフロッピーディスクを一枚つくって用意してい ます。こういうディスクを実際に作ってみるとわかるのですが、たとえ initrd を利 用しても容量は実に限られています。私の作ったディスクには、周囲にある数台のマ シンをカバーする、いわゆるジェネリックなカーネルと、いくつかのデバイスドライ バのモジュール、そして fdisk, fsck, ed, tar などの基本的な修復のための ツールとともに mt や restore が入っています。まだ実際に役に立ったことはありませんが、このディ スクから起動したシステムでローカルあるいはリモート接続のテープドライブが駆動 できることを確認してあります。正直いって、このフロッピーディスクを作る作業は あまり楽しいものとは言えませんでした。しかし、このフロッピー一枚だけで、必要 とあらばファイルシステムの再構築ができることが確認できたとき、大きな安心感が 得られました。

dump/restore 以外のバックアップ方法を否定するものではありませんが、個人的に はファイルシステムの復旧時にあまりおおげさなツールを必要とする方法はおすすめ しません。バックアップツールを選択するときには、このことを頭の片隅にとめてお いてください。

2. メディアに関すること

最近は大容量のハードディスクドライブがたいへん安価に入手できるので、バックアッ プ専用のメディアとしてこれを選択することは、それほど非現実的なことではありま せん。ハードウェアとしてのメンテナンスも楽ですし、アーカイヴが目に見える形で 保管できるのもメリットといえるでしょう。

もし、バックアップの対象となるディスクの容量が比較的小さいならば、バックアッ プメディアとしてハードディスクドライブを使用することをおすすめします。あるい は、今すぐにテープドライブなどの専用デバイスを購入することがためらわれる場合 に、とりあえずハードディスクドライブで間に合わせるというのもよいでしょう。後 で専用デバイスを入手したときでも、ディスクは無駄にすることなく、通常のファイ ルシステムとして使い続けることができるからです。

バックアップの対象となるディスクの容量が大きいなら、バックアップ専用のデバ イスの購入は検討に値します。テープは当然リムーバブルなので、低コスト で過去のバックアップについての履歴を保存することができるようになります。

dump でのバックアップには、一般的にはテープカートリッジが使われています。PC では、QIC(1/4 inch cartridge), 4mm DAT, 8mm EXABYTE, DLT (Digital Linear Tape) などがよく使われています。

わたしは EXABYTE の EXB-8505 という古い SCSI1 のテープドライブを使っています。 EXABYTE は 8mm ビデオテープに似た専用のカートリッジテープを使用します。 ドライブやメディアの価格が高いのが難点で、 個人が使用するにはあまり向いているとはいえません。 しかし、大容量のバックアップメディアとして長く使われており、 信頼性も高いといえます。

8mm EXABYTE の機構を小型化したようなものが 4mm DDS ドライブです。 比較的安価 (新品が 3 万円ほど売られていることもあります)で しかも容量が大きいので人気があります。 取り扱いも楽で駆動音も静かです。ヘッドの寿命が短いという人もいます。

目安としては、稼働しているファイルシステムのうちもっともサイズの大きな領域が、 分割せずに余裕をもって収まるくらいの容量のあるメディアを選ぶべきです。

テープドライブ全般に関する情報へのポインタとして:

http://www.paranoia.com/~vax/unix_tape.html
``The Source of All Knowledge (英文)''

この文書では、8mm テープドライブ EXB-8200 を例にして、テープ上にバッ クアップ・アーカイヴを作成することを解説していきます。

3. Linux での利用

3.1 dump/restore v0.3

Linux では Remy Card 氏 (card@linux.eu.org) が 4.4BSD の物をベースに移植した 物が使われています。Red Hat や Debian には、dump-0.3 のバイナリパッケージが 付属しています。 ソースパッケージは:

ftp://tsx-11.mit.edu/pub/linux/packages/ext2fs/dump-0.3.tar.gz

dump が ext2 ファイルシステムの構造に依存していることは、 いくつかの制限をもたらしています。

まず Peter Moulder 氏 (reiter@netspace.net.au) が公開している ext2 ファイルシステムへの拡張機能 (e2compr) を使って圧縮されたファイルは、 正常に restore できないことがわかっています (正確にいえば、圧縮されているかどうかを保存しているクラスタービットが 復元されないために、圧縮されたデータへの透過的なアクセスができなくなります)。

したがって、現状では e2compr を利用する場合は dump 以外の バックアップ手段を選ばなければなりません。

もうひとつの制限は、dump バージョン 0.3 はマルチボリュームの バックアップを公式にはサポートしていないことです。 したがってバックアップメディアのサイズがファイルシステムのサイズよりも小さい 場合には、正常にレストアできない可能性もあります。

3.2 dump/restore v0.4 Beta

1996 年 1 月には、4.4BSD-Lite2 の dump をベースに移植した、新しい dump-0.4 のβバージョンがテスト公開されています。 このシリーズは 0.4b4 まで Remy Card 氏 によって作成・配布されて きましたが、その後数年間に渡ってメンテナンスが停止状態になっていました。

1999 年 9 月に Stelian Pop 氏 (pop@cybercable.fr) によって 開発が引き継がれることになり、現在正式公開に向けてβバージョンが出ています。 このβバージョンは:

http://dump.sourceforge.net/

• FreeBSD-3.1-RELEASE で行われた Bugfix と機能追加の輸入
• Red Hat, Debian, SuSE が作成したパッチの取り込み
• マルチボリュームのアーカイヴの取り扱いに関する Bugfix 類
• リモートバックアップ時に rsh 以外の remote shell を使えるようになった
• ext3 ファイルシステムへの対応
• kerberos サポート
• buffer overflow 問題の解決
• dump 終了時に特定の command を実行できるようになった (-F)
• restore するファイル名のリストを外部から読み込めるようになった (-X)
• restore の対話モードでの GNU readline サポート

なお、dump-0.4 のβバージョンのうち、 0.4b14 以前のバージョンにはセキュリティホールが発見されています。 必ず 0.4b16 以降をインストールしてください。

3.3 デバイスファイル

Linux では、テープドライブを使うためのデバイスドライバが標準で提供されていま す。お使いのドライブにあったドライバをカーネルのコンパイル時に組み込んでくだ さい。ローダブルモジュールの形式でもかまいません。

次に、テープドライブのデバイスファイルを確認します。

% ls -l /dev/*st[0-9]
crw-rw-rw-   1 root     disk       9, 128 Oct  5  1995 /dev/nst0
crw-rw----   1 root     disk       9, 129 Oct  5  1995 /dev/nst1
crw-rw-rw-   1 root     disk       9,   0 Oct  5  1995 /dev/st0
crw-rw----   1 root     disk       9,   1 Oct  5  1995 /dev/st1

% cd /dev; ln -s nst0 tape

もし接続されているテープドライブをバックアップ専用のデバイスと考えるなら、 一般ユーザからのアクセスはすべて拒絶したほうがよいでしょう。 その場合は、`Others' のリード/ライト権限を落としてください。 上記の例では、一台目のテープドライブは一般ユーザのアクセス可、 二台目のテープドライブはバックアップ専用で、所有者とグループ `disk' に 属しているユーザ以外はアクセスが不可になっています。

4. mt コマンド

4.1 mt

`mt' は、テープドライブを操作するためのコマンドです。テープの巻き戻し・巻き 送り・頭出しや、ドライブの稼働状況の確認などができます。dump/restore をテー プドライブで使うには、mt での操作は避けて通ることができません。できれば、 練習用の短いテープを用意して、慣れるまでいろいろと試すのもいいでしょう。 `mt' にはドライブに依存する機能もあります。必ず一度マニュアルに目を通して、 あなたがお使いのドライブではどのコマンドが使えるのか把握するようにしてくださ い。

Linux で使える mt としては、BSD のものを ベースに Kai Makisara 氏 (Kai.Makisara@metla.fi) が 移植した mt-st が一般的です。 ソースパッケージは:

ftp://tsx-11.mit.edu/pub/linux/sources/sbin/mt-st-0.4.tar.gz

もし Archive Python 28849 SCSI ドライブのような DDS Autoloader を 利用する場合は Leonard N. Zubkoff 氏 (lnz@dandelion.com) が 作成・配布している MTX も役に立つでしょう。これは:

http://www.dandelion.com/Linux/

4.2 mt の操作例

この章では、実際の mt の操作例を通して、mt の機能について解説していきます。

ドライブにテープ(できれば、練習用のもの)を装填してください。装填が完了したら、 mt コマンドでドライブのステータスを確認してみましょう。mt のオプションコマン ド `status' は、ドライブのステータスを確認するコマンドです。

% mt status
SCSI 1 tape drive:
File number=0, block number=0.
Tape block size 1024 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

まず、メッセージの最終行を見てください。ドライブにテープが装填され、最終行の BOT (Beginning Of Tape Marker) 表示によってのヘッドの位置はテープの先頭にあ ることがわかります。次の ONLINE は、テープドライブがオペレータによって操作可 能な状態であることを意味しています。テープを読み書きするには ONLINE の状態で ある必要があります。現在のファイル番号は 0 になっています。ファイル番号はテー プの先頭から 0 で始まり、ファイル終端マーク(EOF)があるごとに、数字が増えます。

通常、Density や Tape block size は Drive にあわせて最適なものが 自動的にセットされるはずです。 もし、他の OS とテープをやりとりする 予定がある場合は、両方の OS 間で互換性のある形式を選択する必要が あるでしょう。 また、データをハードウェアで圧縮してメディアに記録するドライブの場合、 mt のコマンドで明示的に compression フラグを与えてやる必要があります。 このあたりはドライブの種類や環境によって異なることが多いので、 解説は省略します。くわしくは mt(1) マニュアルページの defsetblk, setblk, defcompression, datcompression, compresson などの項目と、 お使いのドライブのマニュアルを参照してください。

もし、mt status の結果、次のようなメッセージが出た場合は、 /dev/tape のリンクが指しているデバイスファイルがドライブの つながってるものと異なっている可能性があります。

    /dev/nst0: No such device or address

では、実際に幾つかのファイルをテープに書いて、練習してみることにしましょう。 どこか適当な場所に練習用のディレクトリを作成し、その中にfile-01 から file-06 までのダミーファイルを touch コマンドで作成してください。

(tcsh)% foreach num (01 02 03 04 05 06)
foreach? touch file-$num
foreach? end
(tcsh)% ls -l
-rw-r--r--   1 fuku     users           0 Nov 21 01:10 file-01
-rw-r--r--   1 fuku     users           0 Nov 21 01:10 file-02
-rw-r--r--   1 fuku     users           0 Nov 21 01:10 file-03
-rw-r--r--   1 fuku     users           0 Nov 21 01:10 file-04
-rw-r--r--   1 fuku     users           0 Nov 21 01:10 file-05
-rw-r--r--   1 fuku     users           0 Nov 21 01:10 file-06

% tar cf /dev/tape file-01

% mt status
SCSI 1 tape drive:
File number=1, block number=0.
Tape block size 1024 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (81010000):
 EOF ONLINE IM_REP_EN

では、残りのファイルは連続して書いてしまいましょう。

(tcsh)% foreach num (02 03 04 05 06)
foreach? tar cf /dev/tape file-$num
foreach? end

% mt status
SCSI 1 tape drive:
File number=6, block number=0.
Tape block size 1024 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (81010000):
 EOF ONLINE IM_REP_EN

ここで大切なことは、各ファイルには ファイルの中身・ファイルの終端マークのふ たつがあるということです。これは、ファイルが正常にテープに格納されると、自動 的にそのようになります。ファイルを読み出すときは、前のファイルの終端マークに テープヘッドを位置させることによって、ファイルの先頭ブロックから読み出せるこ とになります。また、ファイルを追加して書き込むときは、前のファイルの終端マー クにヘッドが達していなければなりません。言い換えれば、複数のファイルが連続し て記録されているとき、前のファイルの終端マークは、次のファイルの先頭ブロック の開始位置といえます。当然ですが、もしファイルの中身の部分から書き込み始める と、元のファイルの中身は失われてしまいます。

それでは、複数のファイルが順に記録されたテープから、特定のファイルだけを取り 出す方法を練習しましょう。例として、今記録したテープから、file-03 がアーカイ ブされた部分を取り出すことを考えてみます。目的のファイルが記録された位置にヘッ ドを移動することが必要になります。

まず、いったん先頭に巻き戻してから、file-03 がアーカイヴされた位置にヘッドを 移動しましょう。

% mt rewind

file-03 が記録されている部分はテープの中の、ファイル番号 2 の位置です。現在 ヘッドは BOT (テープの頭)にありますから、ここに移動するためには、EOF (ファイ ル終端マーク) をふたつスキップすることになります。

% mt fsf 2

% mt fsf 2

% mt status
SCSI 1 tape drive:
File number=2, block number=0.
Tape block size 1024 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (81010000):
 EOF ONLINE IM_REP_EN

% tar tf /dev/nst0
file-03

% mt status
SCSI 1 tape drive:
File number=2, block number=10.
Tape block size 1024 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (1010000):
 ONLINE IM_REP_EN

図の F (画像では青印) が、tar の End of file マークです。 したがって、tar で読出した直後は、 まだヘッドは記録されたブロックの中にあります。このまま次のアーカイヴを 連続して tar で読出そうとすると、今度はテープに記録された EOF マークをすぐに 読み込むことになり、tar は無言のままに終了することになります。もし連続して tar で読出す場合は、その前に

% mt fsf

さて、現在は mt fsf で file-03 がアーカイヴされたブロックの EOF マークにヘッ ドがあるとします。このアーカイヴをもう一度読出したいときはどうすればいいでしょ うか。巻き戻しながら二つ目の EOF マークを読み込んだとき、このファイルの先頭 になるのです。

このためには、以下のようにします。

% mt bsfm 2

次に、現在記録されているファイルに追加して記録するときの操作を説明します。mt eod で、現在記録されているブロックの最後の EOF にヘッドが移動します。ただし、 この機能はドライブによってはうまくいかないこともあるので、実際にためして確認 しておく必要があります。もし、うまくいかなくてもきちんとオペレーションの記録 がとってあれば fsf などで処理できます。

最後に、テープを巻き戻して排出させましょう。これもドライブの種類に依存することが多いのですが、大抵の場合は

% mt offline

mt をつかったテープのオペレーションはやや難しく、慣れが必要です。 また、 dump の記録で後述しますが、 記録の状態を確認するのが難しいので、実行したオペレーションの内容の記録を保存することが大切です。 ぜひ練習用のテープを用意して、いろいろとためしてみてください。

4.3 MTX の操作例(集合型テープドライブの操作)

複数のテープを連装できるタイプのテープデバイスがあります。 Archive Python 28849-XXX や、HP Surestore 12000, Quantum DLT 2500 XT といった集合型のドライブです。 たいていの場合、複数のテープを専用のカートリッジ・マガジンに装填し、 それをドライブ本体に挿入します。 その後、カートリッジ・マガジンに装填されたテープのうち、 任意の物をローディングすることによって、 実際に読み書きできるようになります。

このメディアチェンジの作業はドライブ本体に専用のスイッチがあって、 それを手動で操作できる場合もありますが、 実際にローディングされたテープが目的のものかどうか確認することが 困難であったり、カートリッジ・マガジンに装填されたテープの 順番通りにしかメディアチェンジできなかったりする場合もあり、 使い勝手があまりよくないこともしばしばあります。

これはこの章の最初に述べたように、 Leonard N. Zubkoff 氏 (lnz@dandelion.com) が作成・配布している MTX を利用することによって、簡単に解決することができます。 MTX は mtx という単独のプログラムです。 現在配布されているバージョンは 1.1 で、 Debian GNU/Linux (potato) ではバイナリも用意されています。

バイナリが入手できない場合でも、 kernel 2.0.30 以降であれば簡単にコンパイルすることができます (これより古いバージョンのカーネルで利用する場合は、 MTX の配布アーカイブに含まれている mtx.doc の ``LINUX KERNEL REQUIREMENTS'' の章を参考にヘッダファイルに小さな変更を加えれば OK です)。 また、コンパイルの際には kernel のソースツリーが必要です。 kernel のソースツリーの状態によっては 「ヘッダファイルが見つからない」 というエラーでコンパイルに失敗することがありますが、その場合は Makefile の CFLAGS の行に -I/usr/src/linux/include を付加してください。

  CFLAGS = -O6 -m486 -fomit-frame-pointer -I/usr/src/linux/include

では、実際に MTX を使って集合型テープドライブを操作してみましょう。 すでにカートリッジ・マガジンにはテープが装填されており、 マガジンがドライブ本体に挿入されているものとします。

この状態では、まだどのテープもマガジンに装填された状態のままで、 テープへッダのある位置にロードされていません。 ためしに mt で確認すると、``テープが挿入されていない'' というステータスが帰ってきます。 mtx にもこのステータスを表示する機能があります。 使い方は mt とまったく同じで、 デバイス名とオプショナルコマンド ``status'' を付加するだけです。

# mtx -f /dev/nst1 status
Data Transfer Element:  Empty
Storage Element 1:      Full
Storage Element 2:      Full
Storage Element 3:      Full
Storage Element 4:      Full
Storage Element 5:      Full
Storage Element 6:      Full

では、``Data Transfer Element'' にテープをロードしてみましょう。 この操作も mtx でおこないます。オプショナルコマンド ``load'' に、 ストレージ番号を付加するだけです。

# mtx -f /dev/nst1 load 1
Loading Storage Element 1 into Data Transfer Element...done

# mtx -f /dev/nst1 status
Data Transfer Element:  Full (Storage Element 1 Loaded)
Storage Element 1:      Empty
Storage Element 2:      Full
Storage Element 3:      Full
Storage Element 4:      Full
Storage Element 5:      Full
Storage Element 6:      Full

この状態になれば、 あとは通常のドライブと同様に mt を使って テープの操作ができるようになっています。 それでは、ロードされたテープをマガジンに戻すにはどうするでしょう。 これはオプショナルコマンド ``unload'' を使うだけです。

# mtx -f /dev/nst1 unload 1
Unloading Data Transfer Element into Storage Element 1...done

テープのロードは、任意のストレージ番号に対して行えます。 では、ストレージ番号 2 のテープをロードしてみます。

# mtx -f /dev/nst1 load 2
Loading Storage Element 2 into Data Transfer Element...done

# mtx -f /dev/nst1 next  
Unloading Data Transfer Element into Storage Element 2...done
Loading Storage Element 3 into Data Transfer Element...done

# mtx -f /dev/nst1 previous
Unloading Data Transfer Element into Storage Element 3...done
Loading Storage Element 2 into Data Transfer Element...done

この他にも ``first (マガジンにある最初のストレージ番号のテープをロードする'' ``last (マガジンにある最後のストレージ番号のテープをロードする)'' などのオプショナルコマンドがあります。 なお、これらのコマンドは、dump-0.4b17 以降であれば、 実際の dump の途中でテープエンドに達したときを見計らって 実行することができます。膨大なディスクを一度にバックアップするときには 大変便利な機能です。

5. dump を使ったバックアップ

5.1 バックアップするファイルシステムの選択

それでは、dump を使っての具体的なバックアップ作業について、順に解説してい きます。

バックアップは「すべてのファイルシステム」に対して行うことが原則です。

ただし、フルレストアする時に、復元される必要のないファイルシステムまで、dump する必要はありません。/tmp が独立したファイルシステムなら、 これは真っ先に除外することができます。 これに類する物としては、proxy デーモンなどのキャッシュ ファイルもそうでしょう。また、Netnews の spool や、overview database, history などは、きっぱりあきらめてしまえば、これも除外することがで きます。

これらを除いて、全てのファイルシステムを対象にします。対象となるファイルシス テムは、/etc/fstab の第5フィールドで 1 のフラグを立てておきます。 以下は、その例です。

# /etc/fstab
#
/dev/hda2  /                ext2  defaults,noquota         1 1
/proc      /proc            proc  defaults,noquota         0 0
/dev/sdb3  /tmp             ext2  defaults,noquota         0 2
/dev/sdb2  /var             ext2  defaults,noquota         1 3
/dev/sdd2  /usr             ext2  defaults,noquota         1 2
/dev/sdd1  /usr/local       ext2  defaults,noquota         1 3
/dev/sde1  /var/spool/news  ext2  defaults,noquota         0 4
/dev/sdc1  /var/spool/ov    ext2  defaults,noquota         0 3
/dev/hda3  /.d1             ext2  defaults,noquota         1 2
/dev/hdb1  /.d2             ext2  defaults,usrquota        1 4
/dev/sdb1  /.d3             ext2  defaults,ro,noquota      1 4
/dev/sda5  /home            ext2  defaults,usrquota        1 3
/dev/fd0   /mnt/floppy      ext2  defaults,noauto,noquota  0 0
/dev/sdb4   none            swap  sw                       0 0

バックアップしないファイルを除外する

ディスクの区画分けの状態によっては、バックアップするファイルシステムの 中に、バックアップしたくないファイル群が含まれてしまうことがあります。 どうしてもそれらを除外したい場合は、専用のツールを使ってファイルが使用する i-node に除外の目印 (no dump flag) をつけることができます。 Proxy キャッシュディレクトリのように、頻繁に更新されるがバックアップの意味が ないファイル群に対して、この attribute を設定するとよいでしょう。

くわしい使い方は lsattr(1) と chattr(1) を参照して欲しいのですが、

# lsattr -d /var/spool/squid
------- /var/spool/squid
# chattr +d /var/spool/squid
# lsattr -d /var/spool/squid
------d /var/spool/squid

ただし level 0 のフルダンプの際デフォルトではこの指定は無視され、実際に効果 があるのは level 1 以降のインクリメンタルバックアップの時になります。 もし level 0 の時も同じ効果を得たい場合は dump の h オプションで指定する必要 があります。

5.2 フルバックアップ

ファイルシステムを静止する

では、いよいよフルバックアップを行います。

フルバックアップの前には、システムをシングルユーザモードに移行し、各ファイル システムを静的な状態にして fsck をかけて、ファイルシステムに矛盾が生じていな いことを確認したほうがよいでしょう。フルバックアップはめったに行うものではあり ませんから、面倒でもやっておくことをお勧めします。

# init 1; exit

次に、ファイルシステムをひとつず つアンマウントし、ファイルシステムのチェックを行います。

# umount /usr/local; e2fsck -afv /dev/sdd1

チェックはバックアップの対象となっている 全てのファイルシステムに対して行います。 ルートファイルシステムだけは注意が必要で、 一旦リードオンリーでマウントし直し、e2fsck をかけます。

# mount -r -n -o remount / ; e2fsck -afv /dev/hda3

# mount -w -n -o remount /

ドライブの準備

次に、バックアップメディアの準備をします。ここでは EXABYTE のEXB-8200 ドライ ブ (SCSI) に、112m の 8mm データカートリッジを使うことを例にします。

最初に行うことは、テープヘッドのクリーニングです。EXABYTE の場合は、クリーニン グテープを装填すると、自動的にロードされてヘッドのクリーニングを行い、最後に 巻き戻さずに Eject します。この作業は、とくに level 0 の dump を行う際には必 ず実行する癖をつけてください。テープの読み書きの際にエラーが起きる可能性を確 実に減少してくれます。

それからドライブに新品のテープを装填します。テープにはあらかじめラベルを貼っ ておきましょう。これをサボると、あとでだんだんわけがわからなくなりますよ。ラ ベルの内容は、これまでに購入したテープの通し番号で充分です。後述しますが、ラ ベルにあれこれ書くよりも、別に専用の管理ノートを用意して、細かなメモはそちら に記録することをおすすめします。テープをドライブに装填し終えたら、mt コマン ドでステータスを確認します。

# mt status
SCSI 1 tape drive:
 :
 :

dump する

さて、いよいよ dump です。使い方はそれほど複雑ではありませんが、パラメータの 指定の仕方にちょっと癖があります。(v0.3 より新しいバージョンでは柔軟な指定も 可能になっていますが、ここでは古典的な文法に従います)

   使用方法: dump `オプション' `パラメータ' `ファイルシステム'
 - オプション: 0123456789BbhfusTdWn
   0 〜 9 :  dump level
   B : ボリュームあたりのレコード数
   b : 1 レコードのブロックサイズ(KB)
   h : nodump アトリビュートが影響する dump level
   f : 出力先ファイル(テープ)の指定
   d : 記録密度
   n : オペレータに注意を促す
   s : テープの長さ
   u : /etc/dumpdates を更新する
   T : /etc/dumpdates に記録する日時を指定する
   W : dump の対象になっているファイルシステムに
             印をつけて表示する
   w : dump が必要なファイルシステムだけを表示する
 - パラメータ
   オプションの順に対応したパラメータを指定する。
   たとえば、``sbf'' の順にオプションを並べた場合は、
    dump sbf `テープの長さ' `ブロックサイズ' `出力先'
             `ファイルシステム'
   という順になる。
 - ファイルシステム 
   dump するファイルシステムのマウントポイントまたはデバイス名

# dump 0uf /dev/nst0 /home

最初の引数の数字は、0-9 の Dump level です。詳しくは後述しますが、`0' がフル バックアップを意味していると思ってください。`u' は、次回のインクリメンタルバッ クアップに備えて /etc/dumpdates を更新することを指示するものです。 /etc/dumpdates には、dump した時刻やレベルが記録されます。この情報は その後 dump プログラムによってインクリメンタルバックアップの際や w, W オプションで参照されます。

テープに dump する場合は blocksize や tape length を指示する必要があるでしょ う。もし「テープの容量は充分なはずなのに、途中で tape end に達してしまう」場 合は、このあたりに工夫が必要です。いい加減なやりかたですが、B option で、容 量を多めに明示してしまう方法もあります。

# dump 0uBf 2300000 /dev/nst0 /home

正常に dump がスタートすれば、いくつかのメッセージとともにバックアップは進行 します。このとき、バックアップ終了までにかかるおおよその時間などが表示されま す。このジョブは、最初のころはバックグラウンドに回さずに、 フォアグラウンドで実行してください。 もしテープエンドに達したり、なんらかのエラーが発生した場合は、 対話的な選択処理を求められることがあるからです。

dump が無事に終了し、まだテープ残量に余裕がある場合は、そのまま続けて別のファ イルシステムの dump を行うことができます。

5.3 ダンプレベルとインクリメンタルバックアップ

dump はダンプレベルを指定されることによって、バックアップの動作を決定します。 ダンプレベルは 0-9 の範囲の整数で、指定がない場合は 1 が指定されてた物と仮定 されます。あるダンプレベルが指定されると、それより小さい数のダンプレベルで dump が実行された時刻より後に更新されたファイルだけをバックアップの対象にし ます。

たとえば、level-4 のバックアップの後、level-5 のバックアップが実行されると、 level-4 バックアップ以降に更新されたファイルが level-5 のバックアップアーカ イブに記録されることになります。

この仕組みを利用すると、インクリメンタルバックアップが簡単にできることになり ます。たとえば、

   1 日目   level 0
   2 日目   level 1
   3 日目   level 2
   4 日目   level 3
   5 日目   level 4
   6 日目   level 5
   7 日目   level 6
   8 日目   level 7
   9 日目   level 8

もうちょっと凝った方法としては、``ハノイの塔のシーケンス'' という方法で dump level のスケジュールを組むというやり方があります。

たとえば:

0    -> 3 -> 2 -> 5 -> 4 -> 7 -> 6 -> 9 -> 8 ->
1(a) -> 3 -> 2 -> 5 -> 4 -> 7 -> 6 -> 9 -> 8 ->
1(b) -> 3 -> 2 -> 5 -> 4 -> 7 -> 6 -> 9 -> 8 -> 0 に戻る

この方法のメリットは、ある時点でのファイルシステムの状態を長い時間保存でき、 かつバックアップの時間とメディアを節約できることです。

ところで level 0 のフルバックアップの際にはシングルユーザモードで作業をしま した。では、level 1 以降のインクリメンタルバックアップの際にはどうすべきでしょ うか。日常的にバックアップをするようになると、いちいちシステムの運用を停めて いられない、というのが実情でしょう。私はマルチユーザモードでやっても構わない と思ってます。このあたりは運用の利便をとるか、安全を取るかの選択になります。

ただし、そのインクリメンタルバックアップの直後に クリティカルなハードウェアなどのメンテナンスが 予定されているようなケースでは、 システム停止直前の状態を確実に保存するために、 level 1 のインクリメンタルバックアップを シングルユーザモードで行うほうがよいでしょう。

5.4 dump の記録

ドライブの準備 の項で「テープのラベルにあれこれ書くよりも、別に専用の管理ノー トを用意して、細かなメモはそちらに記録するほうがよい」と書きました。 これは、記録しなければならない項目がラベルに収まるほど少なくはないからです。

この記録が必要になるのは restore の時です。どのテープのどの位置に、どのファ イルシステムが記録されているのか、すぐにわかるようにしておくことが重要です。 (そういうときは大抵、軽いパニックになっていたりしますから)

ここはひとつ、専用の管理ノートか、プリンタ出力を保存するバインダを用意して、 dump を実行している間に詳細なメモを記録するようにしましょう。記録しておきた いことは:

[Tape No.nnnn]  テープそのものの通し番号
File count:     テープ先頭からの位置
Date:           日付
Host:           dump の対象となったホスト名
Filesystem:     ファイルシステムの名前
Device:         ファイルシステムのデバイス名
Level:          dump level
Blocks:         アーカイヴされたブロック数
Length:         テープ中でこのアーカイヴの占める長さ

[Tape No.0024]
Date:           Wed Nov 12 12:39:57 1996
File count:     1
Host:           nicorn
Filesystem:     /home
Device:         /dev/sda5
Level:          0
Blocks:         392556
Length:         0.16

バックアップとは直接の関係はありませんが、 ついでに fdisk -l の出力などもプリントアウトしておくと、 事故の際の復旧には参考になるでしょう。

(FYI: dump 実行の際にログを自動的に保存するようなスクリプトが
http://shaq.pnl.gov:2080/~d3c572/docs/
で公開されています。私はこれに気づく前に自作のものを使い始めて しまったので詳しいことはわかりません。)

もうひとつ余力があればやっておきたいことは、アーカイヴに格納されたファイルの 一覧をテキストファイルに保存しておくことです。 これは dump を行うごとに mt コマンドでテープを巻き戻し、 restore -t を実行してその出力を保存するとよいでしょう。 このファイルを、たとえば /var/spool/adm/dump_index/ などの ディレクトリ以下に保管しておけば、 部分的な restore の際に、どのアーカイヴに目的のファイルが入っているのか grep コマンドで探し出すことが容易になります。 同時に、restore -t を実行しておくことで、今作成したばかりのアーカイヴが 正しく読み出せるかどうか、確認できることにもなります。

5.5 rdump

rdump を利用してネットワーク越しに dump を実行することもできます。引数などは dump と同じですが、dump 先の指定には、リモートマシン名をつける必要があります。 (実は rdump の実体は dump そのものです)。 以下の例は、ローカルマシンの /home をリモートマシン `tapeserver' に接続された テープデバイスに dump することを示しています:

# rdump 0uf tapeserver:/dev/nst0 /home

ネットワーク越しに dump する際には、 rsh がパスワードなしに実行できる環境になっている必要があります。 さらに、dump はリモートマシン上で rmt を起動しますので、 rmt が rsh 環境での実行ファイル検索パスに含まれている ことも条件になります。Linux のディストリビューションによっては、 rmt が実行ファイル検索パスに置かれていないことがあります。

# rsh remotehost which rmt

また、通常バックアップの作業は root で行うことになりますが、 root がパスワードなしにリモートシェルを実行できる環境は セキュリティを考えると問題があります。

多少なりとも危険を回避するためには、dump 専用の uid を用意した方が よいでしょう。手順は以下の通りです。

• LAN 内のすべてのホストに vipw でユーザ名 fsdump を追加する。 パスワードは ``*'' でよい。
• ユーザ名 fsdump のホームディレクトリを /etc/fsdump にする。
• ホストの OS が Linux の場合はユーザ名 fsdump を disk グループに追加する。 (その他の OS にも、同等のグループが存在するはずです)
• テープドライブの接続されたホストの /etc/fsdump に .rhostsファイルを作成し、LAN 内のユーザ fsdump がパスワードなしで アクセスできるように記述する。
• リモートからの dump は su で fsdump になって作業する。cron から 起動する場合も、fsdump の cron を利用する。

5.6 テープの保管

level 0 のテープはできるだけ長期間保管されることが 望まれます。 いうまでもないことですが、 テープはその性質上、熱やほこり・湿気・磁気に弱いので、 温度変化の激しい場所や直射日光の当る場所などに保管すると、 データが正常に読み出せなくなることがあります。

また、level 0 と 1 のテープはマシンの置いてある部屋以外、 可能であるなら別の建物に保管することが推奨されています。 これは火災などの事故によって、マシンとテープの両方が 一度に失われてしまうことを避けるためです。

部分的な restore を迅速にサービスしたい場合は、 level 2-9 のテープくらいはマシンと同じ部屋に保管しておきたい場合も あるでしょう。 それでも管理者以外の人間が触れることのできる場所に テープが保管されている状態は、セキュリティ上好ましくありません。

もっとも望ましい状態は耐火・耐熱性の金庫などに入れて施錠することです。 これを大げさと思うならば、せめてテープのラベルには「他人が読んでも 中身がわからない」情報だけを書くようにしましょう。 中身を読み出されてしまえば同じことなのですが、悪意を持った人物の 行為を助けるようなことはしないほうがましです。 dump の記録でも触れたように、 別のノートなどに詳細な記録を保管しておけば、混乱の原因にはなりません。

level 0 のテープは定期的にロードしてみて、リードエラーが 起きないことを確認すると安心といわれていますが、ここまでやるのは 本当に大変なので、よほど余力がある場合に限られるでしょう (私はやっていません)。それよりは定期的に level 0 のフルダンプを 新しいテープに行う方が確実です。

5.7 スケジューリング

これでとりあえず手動でバックアップすることができるようになりました。でも、 退屈な作業は長続きしないので、できるだけ作業を自動化することを考えましょう。 同時に、どれくらいの頻度でバックアップをするのか、そのスケジュールも考える 必要もあります。

バックアップの頻度は、システムがどのように利用されているかによって異なります。 また、バックアップ作業をする人がどの程度の労力をかけられるのか、 バックアップアーカイブにはどの程度の完全性が要求されているのか、 その完全性を確保するために犠牲になるものは何か、 どれくらいのコストが必要になるか、 なども考慮に入れて総合的に判断しなければなりません。

理想的には、マシンを使った日は、かならず一度インクリメンタルバックアップをす るべきですが、個人ベースで利用している場合は、数日の間を開けてもかまわないで しょう。逆に神経質な人は特定のファイルシステムだけは数時間に一度バックアップ したいと考えるかも知れません。

目安として「一回のインクリメンタルバックアップの全分量が、一本のテープに収ま らないほど間隔をあけないようにする」ことはひとつの条件です。途中で テープのかけ替えが発生しなければ、無人で作業を行える可能性があるからです。

しかし、テープの余裕がありあまるとしても、最低週に一度はバックアップを更新す ることを目安にしてください。データは、新しい物ほど重要であるケースがほとんど で、一カ月前のデータが復元されても、何の役にも立たない場合があります。

また、バックアップを実行する時間も考慮してください。level 0 のフルバックアッ プの際には、システムの運用を停止しなければなりません。それ以外の level のバッ クアップ作業も、できればシステムの負荷が低く、ファイルシステムの更新頻度が 低い時間帯 (深夜など) を選んだ方がよいでしょう。

これらのバランスを考えて、あなたのシステムに最適なスケジューリングを見つけ出 してください。そのスケジューリングに、テープドライブのクリーニング作業を入れ るのを忘れずに。

6. restore

restore(8) は、dump(8) を使って作成されたアーカイヴからファイルを取り出し、 ファイルシステムに復元するためのプログラムです。 ファイルシステム全体の復元を一度に行うこともできますし、 対話的に必要なファイルを選択し、部分的な復元を行うことも可能です。 dump と restore をパイプで組み合わせることによって、 あるファイルシステムの中身を、別のファイルシステムにコピーすることもできます。 rdump と同様、rrestore はリモートホストに接続されたテープドライブの アーカイブを読出すこともできます。

   使用方法: restore  `キー' [キー修飾文字]
キー (主なもののみ):
 i    対話的にファイルを取り出す
 r    アーカイヴ全体をカレントディレクトリに取り出す
 R    中断したフルレストアを再開する
 t    アーカイヴ中のファイルのリストを出力する
 C    現存するファイルシステムとアーカイヴを比較する
 T    テンポラリディレクトリを指定する
 s    テープの中のアーカイヴの位置を指定する
 x    指定したファイルだけをアーカイヴから取り出す
 f    アーカイヴファイルを指定する
 h    ディレクトリ名を指定したときに、ディレクトリのみを対象にする
 v    冗長に実行する
 y    エラーが発生しても問い合わせをしない

restore rf /dev/nst0
  (テープのアーカイヴからカレントディレクトリに
   ファイルをすべて取り出す)
restore isf 3 /dev/nst0
  (テープの 3 番目のアーカイヴから対話的にファイルを取り出す)
rrestore tf  tapeserver:/dev/nst0
  (ホスト tapeserver に接続されたテープからアーカイヴの
  リストを取り出す)

使い方はそれほどむずかしくありませんが、ちょっと特殊なツールなので 一度は操作して慣れておく必要があります。基本的な操作に関する解説は restore(8) マニュアルの繰り返しになるので、ここでは省略します。

6.1 レストアの際の注意

対話的にファイルの部分レストアをする際に、 一般的には直接ターゲットとなるディレクトリに上書きするのではなく、 空のディレクトリをカレントディレクトリにしてファイルを書き戻し、 その後しかるべき場所にファイルを移動します。 フルレストアの際には、フォーマットしたディスクをマウントし、 そのマウントポイントに移動してから restore を起動します。 したがって、root パーティションを含めたフルレストアの際には、 非常用のレスキューフロッピーディスクなどが必要となります。

注意が必要なのは、フルレストアの際にアーカイヴからファイルを取り出す順番です。 特に r コマンドでアーカイヴ全体を展開する場合は、必ず level 0 のアーカイヴ から開始する必要があります。

また、ある dump レベルより後に、それより若い数のレベルで dump が行われた時、 フルレストアの際には無効になる level がでてきます。 たとえば、``ハノイの塔のシーケンス'' にしたがって

0 3 2 5 4 7 6 9 8

したがって、フルレストアをする際には、無効になったレベルのバック アップを飛ばして restore を実行することになります。上記のシーケ ンスの場合、

0 2 4 6 8

これを ``ハノイの塔シーケンス'' にしたがってそのまま restore しよ うとするとどうなるでしょうか。

level-2 のテープを restore しようとすると、``Incremental tape too high'' とエラーが出てしまい、それ以降の restore では ``Incremental tape too low'' といわれます。

これらのエラーが出た場合は、そのまま restore を続けても正常にフ ルレストアできませんから、最初から restore をやり直してください。

(中間で無効になってしまうレベルが生じてしまうからといって ``ハノイ の塔シーケンス'' に意味がないわけではありません。頻繁に更新される ファイルシステムの、過渡的な状態をできるだけ長い期間保持し、なお かつバックアップのメディアを節約するためには、効率のよい方法とい えます。)

もうひとつ気をつけなければいけないのは、restore は比較的大きなテンポラリ スペースを必要とするということです。 Rescue Disk などで復旧のために起動したときには、 通常わずかなテンポラリスペースしか用意されていません。 復旧しようとするディスクには、当然 mke2fs で新たにファイルシステムを 作成しますが、作業用テンポラリスペースのためにも、別の 空いているファイルシステムを作成してください。 そして、そのスペースを /tmp にマウントするか、restore の T を 使ってテンポラリスペースとして指定するようにしてください。 これはうっかり忘れがちなことなので注意が必要です。

それと、勘違いしてしまう方も多いのですが、 dump/restore はディスクのブートブロックなどは保存/復旧しません。 フルレストアをした後には OS のブートに関わる設定を再確認してください。

6.2 フルレストアの手順

以上のことをふまえた上で、トラブルによってフルレストアが必要になったケースの 手順を参考としてまとめておきます。

• ハードウェアの故障が原因なら、まずその問題を解決する。
• dump 状況を記録したノートをよくにらんで、復旧の手順を 紙に書き出して確認する。
• テープドライブにセットするテープは、 ノッチが書き込み禁止になっていることを必ず確認する。
• レスキューシステムで起動する。
• 復旧のターゲットとなるディスクをフォーマットする。
• 復旧のターゲットとなるディスクを仮のディレクトリにマウントする。
• restore が使用するテンポラリスペースを確保する。
• インクリメンタルアーカイヴを順にレストアする際には、 最後のレストアが終了するまで ./restoresymtable を消さない。
• OS のブート手段 (lilo など)を再設定する。
• restore がすべて終わり、復旧に成功したことが確認できたら
  • ./restoresymtable を削除する
  • level 0 の dump を新しいテープに行う。 (古いテープも当分の間保存する)

7. バックアップは本当に必要か?

さて、バックアップは本当に必要なのでしょうか?

「再インストールすれば、それですむ」という考え方もあります。でも日常的に Linux を使っていれば、ファイルシステム上には苦労して作り上げたプログラム、書 きかけのドキュメント、大切な人からもらったラブレターがホームディレクトリのど こかにあります。一度失われてしまったそれらのファイルは、システムを再インストー ルしても、もう戻ってきません。

そして、あなたがシステム自体に手を加えたり (大抵の場合、/etc の ファイルの大半には手が入ってます)、 独自にソフトウェアのインストールをしていたりしたら、 被害はさらに拡大します。あなたはシステムを再インストールした後、すべてのコン フィグレーションをやり直し、ソフトウェアを元通りの形で動作するようにコンパイ ル・インストールすることになるでしょう。

``ext2 ファイルシステムは頑丈なのでめったなことでは壊れない。 したがってバックアップは必要ない'' という意見もあります。確かに ext2 ファイルシステムが破綻をきた すことはほとんどありません。私の経験では、ext2 ファイルシステムがソフトウェ ア上の問題が原因で破壊されてしまったことはありません。

しかし、どんなに注意をはらっても、いつかファイルに関するトラブルに遭遇します。 あるユーザがひとつのファイルを削除してしまうという、軽度のミスもあれば、ハー ドウェアのトラブルが原因でファイルシステムに矛盾を生んでしまうこともあります。 私は SCSI ホストアダプタに異常が生じて機能を停止して しまった経験を持っています。この時は e2fsck では修復できないエラーがディスク に生じてしまい、失われてしまった多数のデータを回復するにはバックアップに頼る 以外ありませんでした。

バックアップの作業は、それ自体がシステムのリソースを必要としますし、なにより 「とっても退屈」な作業です。しかし、これはなにより大切な任意保険と考えてくだ さい。それも、その辺の保険会社がトラブルの時にあれこれ理由をつけて支払いをし ぶるのに比べれば、ずっと正直で確実な保険です。

8. この文書について

8.1 Copyright notice

Copyright(c) 1998,1999 by FUKUSHIMA Osamu

この文書の著作権(C)は福島於修 <fuku@amorph.net> が 保持します。この著作権表示が全てのコピーに残されるかぎり、 この文書は自由に複製・配布することができます。 部分的に配布する場合には、著作権に関する記述と 完全な文書の在処を併記すると共に、 それが部分的な配布であることを明記されるようお願いします。 なお、これらの複製・配布にあたっては、著作権保持者の許可は必要ありません。

8.2 責任の放棄

この文書の内容は無保証であり、私は本文書の内容についての責任を否認します。 本文書に含まれている例などを使用するのは、全て読者の責任で行ってください。

8.3 謝辞

集合型テープドライブの章を執筆するにあたり、 ＮＥＣ (ＮＥＣソリューションズ) 様 から検証用機材をお借りしました。ありがとうございました。

8.4 フィードバック

質問・コメント・訂正などこの文書に関するご意見は:

FUKUSHIMA Osamu <fuku@amorph.rim.or.jp>

8.5 履歴

1998年 4月20日  初版発行 (Revision 1.3)
1998年 6月 3日  デバイスファイルの permission に関する記述を追加。
                Leonard N. Zubkoff 氏 (lnz@dandelion.com) が作成・配布
                している MTX に関する記述を追加。
1998年11月15日  テープドライブ全般に関する情報へのポインタを追加。
1998年12月12日  dump-0.3 が kernel 2.0.x で使えることを明記。
1999年 2月28日  e2compr 使用時の制限に関する記述を追加。
1999年 3月10日  第2版発行 (Revision 1.4)
1999年 5月23日  rmt が実行PATHに含まれていない場合に関する記述を追加。
1999年 7月30日  restore の際の注意点を追加。
1999年11月30日  Stelian Pop 氏による新しい 0.4 beta シリーズに関して記載。
2000年 1月21日  0.4 beta 公開サイト名の変更。
2000年 8月 1日  MTX に関する章を追加.

[