Linux: dump and restore mini-HOWTO FUKUSHIMA Osamu, (福島於修), 2.0, 16 Aug. 2000 この文書は BSD 由来のツール dump(8) および restore(8) の利用方法とテー プドライブのオペレーションに関することを解説するものです。バックアップ 作業全般に関する注意点にも触れています。 ______________________________________________________________________ 目次 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.1.1 バックアップしないファイルを除外する 5.2 フルバックアップ 5.2.1 ファイルシステムを静止する 5.2.2 ドライブの準備 5.2.3 dump する 5.3 ダンプレベルとインクリメンタルバックアップ 5.4 dump の記録 5.5 rdump 5.6 テープの保管 5.7 スケジューリング 6. restore 6.1 レストアの際の注意 6.2 フルレストアの手順 7. バックアップは本当に必要か? A. この文書について A.1 Copyright notice A.2 責任の放棄 A.3 謝辞 A.4 フィードバック A.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 を使ってインクリメンタルバックアップを続けていて、ある日全てをフル レストアしてみたら、はるか昔に消したはずのファイルがいっぱいで、ファイ ルシステムが溢れてしまった、という事態には決してなりません。 以上のことをまとめると、 o 特定のディレクトリやファイルをアーカイヴするには、 cpio, tar, afio などが向いている o ファイルシステムのアーカイヴには、dump が向いている といえます。目的に応じて、これらのツールを使い分けるとよいでしょ う。この文書は dump/restore に関する物なので、以下に記述されている のは、ファイルシステムのバックアップに関することであると考えてくだ さい。 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/pack- ages/ext2fs/dump-0.3.tar.gz から入手できます。 LSM ファイルには 2.0.x 以降のカーネルについての記述 がありませんが、これらの新しいカーネルを走らせているシステムでも問題な く利用できるはずです。 dump プログラムは ext2 ファイルシステムの構造に 依存しているので、自分で make するためには Ext2fs library が必要です。 このライブラリも上記のディレクトリから入手可能です。 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/ で入手することができます。このバージョンでは、マルチボリュームのバック アップがサポートされています。その他にも dump/restore の 0.4b は、0.3 と比較すると数多くの Bugfix と新しい機能の追加が行われています。主なも のは: o FreeBSD-3.1-RELEASE で行われた Bugfix と機能追加の輸入 o Red Hat, Debian, SuSE が作成したパッチの取り込み o マルチボリュームのアーカイヴの取り扱いに関する Bugfix 類 o リモートバックアップ時に rsh 以外の remote shell を使えるようになっ た o ext3 ファイルシステムへの対応 o kerberos サポート o buffer overflow 問題の解決 o dump 終了時に特定の command を実行できるようになった (-F) o restore するファイル名のリストを外部から読み込めるようになった (-X) o restore の対話モードでの GNU readline サポート などです (2000/07/05 現在)。 なお、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 /dev/nst? と /dev/st? の二種類があります。 (もしなければ、MAKEDEV コマ ンドで作成してください。) このうち、st? はコマンドがドライブに対して発 行されたあとに、自動的に先頭まで巻き戻し(rewind)するデバイスであ り、nst? は巻き戻ししない(no rewind)デバイスです。このあたりには好みが あるのですが、私は no rewind の方が好きです。今回は /dev/nst0 をター ゲットのデバイスとして利用することにします。ターゲットのデバイスが決 まったら、そのデバイスファイルから ``/dev/tape'' というシンボリックリ ンクを作成してください。こうしておくと、mt などのコマンドでデバイス名 を省略できます。 % 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/ から入手できます。 MTX の使い方に関しては ``このセクションの最後''で解 説します。 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)があるごとに、数字が増えます。 (以後の説明、プレインテキスト版ではいくつかの図が使われています。可能 であれば等幅のフォントで閲覧してください) V (<--- Tape Head) /==================================================================/ | B<--- BOT Mark) -> Tape End / \================================================================/ V: Tape Head B: BOT Mark E: EOF Mark 通常、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 その場合は、別のデバイスファイルを -f コマンドで指定して試してみてくだ さい。正常なメッセイジが表示されたなら、リンクをはり直しておいてくださ い。 では、実際に幾つかのファイルをテープに書いて、練習してみることにしま しょう。どこか適当な場所に練習用のディレクトリを作成し、その中 に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 でテープに書き込んでみます。 % tar cf /dev/tape file-01 エラーがなにもなければ、うまくいっています。念のために mt のステータス を確認してみましょう。 % 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 大丈夫ですね。EOF がひとつ追加されたので、ファイル番号が一つインクリメ ントされて、1 になっています。 /dev/tape は /dev/nst0 つまり no rewind のデバイスに書き込んだので、テープヘッドは今書いたファイルの終端 (EOF) にあります。すでに次のファイルを書く準備が完了しているということです。 V /==================================================================/ | B[file-01]E / \================================================================/ V: Tape Head B: BOT Mark E: EOF Mark では、残りのファイルは連続して書いてしまいましょう。 (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 ファイルはきちんと書き込まれています。テープヘッドは今書いたファイルの 終端にあります。この様子を図にしてみましょう。 V /==================================================================/ | B[file-01]E[file-02]E[file-03]E[file-04]E[file-05]E[file-06]E / \================================================================/ V: Tape Head B: BOT Mark E: EOF Mark ここで大切なことは、各ファイルには ファイルの中身・ファイルの終端マー クのふたつがあるということです。これは、ファイルが正常にテープに格納さ れると、自動的にそのようになります。ファイルを読み出すときは、前のファ イルの終端マークにテープヘッドを位置させることによって、ファイルの先頭 ブロックから読み出せることになります。また、ファイルを追加して書き込む ときは、前のファイルの終端マークにヘッドが達していなければなりません。 言い換えれば、複数のファイルが連続して記録されているとき、前のファイル の終端マークは、次のファイルの先頭ブロックの開始位置といえます。当然で すが、もしファイルの中身の部分から書き込み始めると、元のファイルの中身 は失われてしまいます。 それでは、複数のファイルが順に記録されたテープから、特定のファイルだけ を取り出す方法を練習しましょう。例として、今記録したテープか ら、file-03 がアーカイブされた部分を取り出すことを考えてみます。目的の ファイルが記録された位置にヘッドを移動することが必要になります。 まず、いったん先頭に巻き戻してから、file-03 がアーカイヴされた位置に ヘッドを移動しましょう。 % mt rewind V /==================================================================/ | B[file-01]E[file-02]E[file-03]E[file-04]E[file-05]E[file-06]E / \================================================================/ V: Tape Head B: BOT Mark E: EOF Mark file-03 が記録されている部分はテープの中の、ファイル番号 2 の位置で す。現在ヘッドは BOT (テープの頭)にありますから、ここに移動するために は、EOF (ファイル終端マーク) をふたつスキップすることになります。 % mt fsf 2 mt のオプションコマンド fsf は、指定個数の EOF をスキップして次のファ イルの先頭ブロックにヘッドを移動するコマンドです。fsf 2 では、現在の位 置から 2 つ先のファイル開始位置にヘッドを移動することを意味していま す。 % mt fsf 2 V /==================================================================/ | B[file-01]E[file-02]E[file-03]E[file-04]E[file-05]E[file-06]E / \================================================================/ V: Tape Head B: BOT Mark E: EOF Mark % 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 ここでステータスが意味しているものは「ファイル番号 2 (すなわち、ここで は file-02 がアーカイヴされている部分) の終端マーク」であり、言い換え れば「ファイル番号 3 の先頭ブロック開始位置」を意味しています。tar で 中身を見てみましょう。 % tar tf /dev/nst0 file-03 意図した通りに、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 ここではステータスに EOF が表示されていないことに注意してください。tar でふつうにアーカイヴを読み出すと、tar は自身の End of file マークを検 知して、そこで読出しを停止します。これはテープに記録されている EOF と はまた別のものです。 V /==================================================================/ | B[file-01]E[file-02]E[file-03 F]E[file-04]E[file-05]E[file-06]E / \================================================================/ V: Tape Head B: BOT Mark E: EOF Mark 図の F (画像では青印) が、tar の End of file マークです。したがっ て、tar で読出した直後は、まだヘッドは記録されたブロックの中にありま す。このまま次のアーカイヴを連続して tar で読出そうとすると、今度はテ ープに記録された EOF マークをすぐに読み込むことになり、tar は無言のま まに終了することになります。もし連続して tar で読出す場合は、その前に % mt fsf として、EOF マークをひとつ読み飛ばせはいいのです。ちょっと間違いやすい ところなので、覚えておいてください。 さて、現在は mt fsf で file-03 がアーカイヴされたブロックの EOF マーク にヘッドがあるとします。このアーカイヴをもう一度読出したいときはどうす ればいいでしょうか。巻き戻しながら二つ目の EOF マークを読み込んだと き、このファイルの先頭になるのです。 V <====== V /==================================================================/ | B[file-01]E[file-02]E[file-03]E[file-04]E[file-05]E[file-06]E / \================================================================/ V: Tape Head B: BOT Mark E: EOF Mark このためには、以下のようにします。 % mt bsfm 2 これは mt の拡張されたコマンドで、ふるい mt にはないものもあります。そ の場合は bsf と fsf を組み合わせて処理することになるのですが、紛らわし いのでここでは省略します。 次に、現在記録されているファイルに追加して記録するときの操作を説明しま す。mt eod で、現在記録されているブロックの最後の EOF にヘッドが移動し ます。ただし、この機能はドライブによってはうまくいかないこともあるの で、実際にためして確認しておく必要があります。もし、うまくいかなくても きちんとオペレーションの記録がとってあれば fsf などで処理できます。 最後に、テープを巻き戻して排出させましょう。これもドライブの種類に依存 することが多いのですが、大抵の場合は % mt offline これで(必要なら)自動的に巻きもどされ、ドライブからテープが Eject され ます。 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'' というのが実際に読み書きを行う装置で、現在は 空 (Empty) になっています。 ``Storage Element 1-6'' は、カートリッジ・ マガジンの状態を示しています。各番号はマガジン内での装填順で、これをス トレージ番号と呼びます。現在は六つのすべてのマガジンにテープが装填され た状態 (Full) であることを示しています。 では、``Data Transfer Element'' にテープをロードしてみましょう。この操 作も mtx でおこないます。オプショナルコマンド ``load'' に、ストレージ 番号を付加するだけです。 # mtx -f /dev/nst1 load 1 Loading Storage Element 1 into Data Transfer Element...done これで一番目のテープがロードされました。status コマンドで確認してみま しょう。 # 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 ``Data Transfer Element'' にストレージ番号 1 のテープがロードされたこ とがわかります。同時に、マガジン内のストレージ番号 1 の位置は空になっ ていることも確認できます。 この状態になれば、あとは通常のドライブと同様に 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 うまくいきました。この状態で、別のストレージ番号を指定してロードする と、先にロードされていたテープは自動的に unload され、指定されたテープ が代わりにロードされます。マガジン内のストレージは、番号だけでなく「次 のテープ」「前のテープ」といった指定方法も可能です。先ほどのテープ 2 がロードされた状態で、オプショナルコマンド ``next'' を発行してみましょ う。 # mtx -f /dev/nst1 next Unloading Data Transfer Element into Storage Element 2...done Loading Storage Element 3 into Data Transfer Element...done ストレージ番号 2 のテープが unload され、代わりにストレージ番号 3 のテ ープがロードされました。ここから、もう一度前のテープに戻るには オプ ショナルコマンド ``previous'' を使います。 # 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 ______________________________________________________________________ この例では、/tmp, /var/spool/news に加えて /proc そして swap の第 5 フィールドも 0 になっています。よく、これらが 1 になっている人を見掛け ますが、まったく意味がありませんし、誰かに見られると恥ずかしいので、つ いでに直しておきましょう。 5.1.1. バックアップしないファイルを除外する ディスクの区画分けの状態によっては、バックアップするファイルシステムの 中に、バックアップしたくないファイル群が含まれてしまうことがあります。 どうしてもそれらを除外したい場合は、専用のツールを使ってファイルが使用 する 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 というふうに、chattr コマンドで +d の no dump flag をつけたもの は、dump の対象から外せます。上の例では、Squid cache system が使用する キャッシュディレクトリとその巨大な中身に対して、そのような目印をつけて います。ディレクトリに対してこの目印がつくと、その後は中に作成される ファイルも同じ属性になります。 ただし level 0 のフルダンプの際デフォルトではこの指定は無視され、実際 に効果があるのは level 1 以降のインクリメンタルバックアップの時になり ます。もし level 0 の時も同じ効果を得たい場合は dump の h オプションで 指定する必要があります。 5.2. フルバックアップ 5.2.1. ファイルシステムを静止する では、いよいよフルバックアップを行います。 フルバックアップの前には、システムをシングルユーザモードに移行し、各 ファイルシステムを静的な状態にして fsck をかけて、ファイルシステムに矛 盾が生じていないことを確認したほうがよいでしょう。フルバックアップは めったに行うものではありませんから、面倒でもやっておくことをお勧めしま す。 # init 1; exit まず、これでシングルユーザモードになります。 次に、ファイルシステムをひとつずつアンマウントし、ファイルシステムの チェックを行います。 # umount /usr/local; e2fsck -afv /dev/sdd1 (いちいちアンマウントするのが面倒であれば、システムが起動するときに、 あらかじめ Boot prompt で ``linux -b'' を指定して、ルートファイルシス テムだけをマウントした状態にする方法もあります。) チェックはバックアップの対象となっている全てのファイルシステムに対して 行います。ルートファイルシステムだけは注意が必要で、一旦リードオンリー でマウントし直し、e2fsck をかけます。 # mount -r -n -o remount / ; e2fsck -afv /dev/hda3 すべてのチェックが完了したら、 # mount -w -n -o remount / として、ふたたびリードライトでルートファイルシステムをマウントします。 (リードオンリーのままだと、dump がバックアップ情報を残すことができませ ん。) ネットワーク越しに dump をする場合など、/usr ファイルシステムが 必要な場合は、それらのファイルシステムを再度マウントし、ネットワークが 利用可能な状態にします。 5.2.2. ドライブの準備 次に、バックアップメディアの準備をします。ここでは EXABYTE のEXB-8200 ドライブ (SCSI) に、112m の 8mm データカートリッジを使うことを例にしま す。 最初に行うことは、テープヘッドのクリーニングです。EXABYTE の場合は、ク リーニングテープを装填すると、自動的にロードされてヘッドのクリーニング を行い、最後に巻き戻さずに Eject します。この作業は、とくに level 0 の dump を行う際には必ず実行する癖をつけてください。テープの読み書きの際 にエラーが起きる可能性を確実に減少してくれます。 それからドライブに新品のテープを装填します。テープにはあらかじめラベル を貼っておきましょう。これをサボると、あとでだんだんわけがわからなくな りますよ。ラベルの内容は、これまでに購入したテープの通し番号で充分で す。後述しますが、ラベルにあれこれ書くよりも、別に専用の管理ノートを用 意して、細かなメモはそちらに記録することをおすすめします。テープをドラ イブに装填し終えたら、mt コマンドでステータスを確認します。 # mt status SCSI 1 tape drive: : : このコマンドの出力は、ドライブの種類によって異なります。ここでは、テー プがロードされていることが確認できれば充分です。 5.2.3. 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 ここでは、8mm テープの容量におよそ 2.3GB という多めの見当 (blocksize で 2.3GB を割った数値を) を dump に指示しています。density や tape length の指示はメディアの終了を検出できないドライブを使う場合に dump にメディア交換のタイミングを教えてやるためのオプションです。しかし、最 近のほとんどのドライブはテープエンドをきちんと検出できるので、このよう な方法でも問題がないでしょう。 正常に 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 を実行すると、2 日目以降は前日から更新のあったファイル だけをバックアップします。こうすることによって、バックアップに要する時 間を最大限に節約することができます。 もうちょっと凝った方法としては、``ハノイの塔のシーケンス'' という方法 で 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 に戻る ______________________________________________________________________ という順に dump を進めます。level 0 のテープは安全な場所に永久保管 し、level 0 dump では常に新しいテープを使うようにします。 level 1 のテ ープはローテーション分 (上の図の例では 2セット) 用意します。それ以外の テープは 1 set ずつで充分です。 この方法のメリットは、ある時点でのファイルシステムの状態を長い時間保存 でき、かつバックアップの時間とメディアを節約できることです。 ところで 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 ______________________________________________________________________ というぐあいです。これは、dump のステートメント出力を perl などで整形 すれば簡単ですから、それほど手間はかかりません。これをプリントアウトし て、バインダに綴じておけばOK です。 バックアップとは直接の関係はありませんが、ついでに 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 ______________________________________________________________________ の結果、rmt が見つからなかった場合は、シンボリックリンクを作成して rmt が rsh 環境での実行ファイル検索パスに含まれるようにしてください。 また、通常バックアップの作業は root で行うことになりますが、 root がパ スワードなしにリモートシェルを実行できる環境はセキュリティを考えると問 題があります。 多少なりとも危険を回避するためには、dump 専用の uid を用意した方がよい でしょう。手順は以下の通りです。 o LAN 内のすべてのホストに vipw でユーザ名 fsdump を追加する。パスワ ードは ``*'' でよい。 o ユーザ名 fsdump のホームディレクトリを /etc/fsdump にする。 o ホストの OS が Linux の場合はユーザ名 fsdump を disk グループに追加 する。 (その他の OS にも、同等のグループが存在するはずです) o テープドライブの接続されたホストの /etc/fsdump に .rhostsファイルを 作成し、LAN 内のユーザ fsdump がパスワードなしでアクセスできるよう に記述する。 o リモートからの 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 ______________________________________________________________________ と dump を続けたケースでは、level-3 のアーカイヴは、その後に続く level-2 の dump が行われた時に無効になります。同じように、 level-5 の アーカイヴは、その後に続く level-4 の dump が行われた時に、無効になり ます。極端にいうと、level-0 の dump が行われれば、それまでの level-[1-9] のアーカイヴは、すべて無効です。 したがって、フルレストアをする際には、無効になったレベルのバックアップ を飛ばして restore を実行することになります。上記のシーケンスの場合、 ______________________________________________________________________ 0 2 4 6 8 ______________________________________________________________________ と restore していけば、ファイルシステムは最後のバックアップの状態に戻 ります。 これを ``ハノイの塔シーケンス'' にしたがってそのまま 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. フルレストアの手順 以上のことをふまえた上で、トラブルによってフルレストアが必要になったケ ースの手順を参考としてまとめておきます。 o ハードウェアの故障が原因なら、まずその問題を解決する。 o dump 状況を記録したノートをよくにらんで、復旧の手順を紙に書き出して 確認する。 o テープドライブにセットするテープは、ノッチが書き込み禁止になってい ることを必ず確認する。 o レスキューシステムで起動する。 o 復旧のターゲットとなるディスクをフォーマットする。 o 復旧のターゲットとなるディスクを仮のディレクトリにマウントする。 o restore が使用するテンポラリスペースを確保する。 o インクリメンタルアーカイヴを順にレストアする際には、最後のレストア が終了するまで ./restoresymtable を消さない。 o OS のブート手段 (lilo など)を再設定する。 o restore がすべて終わり、復旧に成功したことが確認できたら o ./restoresymtable を削除する o level 0 の dump を新しいテープに行う。 (古いテープも当分の間保存 する) 7. バックアップは本当に必要か? さて、バックアップは本当に必要なのでしょうか? 「再インストールすれば、それですむ」という考え方もあります。でも日常的 に Linux を使っていれば、ファイルシステム上には苦労して作り上げたプロ グラム、書きかけのドキュメント、大切な人からもらったラブレターがホーム ディレクトリのどこかにあります。一度失われてしまったそれらのファイル は、システムを再インストールしても、もう戻ってきません。 そして、あなたがシステム自体に手を加えたり (大抵の場合、/etc のファイ ルの大半には手が入ってます)、独自にソフトウェアのインストールをしてい たりしたら、被害はさらに拡大します。あなたはシステムを再インストールし た後、すべてのコンフィグレーションをやり直し、ソフトウェアを元通りの形 で動作するようにコンパイル・インストールすることになるでしょう。 ``ext2 ファイルシステムは頑丈なのでめったなことでは壊れない。したがっ てバックアップは必要ない'' という意見もあります。確かに ext2 ファイル システムが破綻をきたすことはほとんどありません。私の経験では、ext2 ファイルシステムがソフトウェア上の問題が原因で破壊されてしまったことは ありません。 しかし、どんなに注意をはらっても、いつかファイルに関するトラブルに遭遇 します。あるユーザがひとつのファイルを削除してしまうという、軽度のミス もあれば、ハードウェアのトラブルが原因でファイルシステムに矛盾を生んで しまうこともあります。私は SCSI ホストアダプタに異常が生じて機能を停止 してしまった経験を持っています。この時は e2fsck では修復できないエラー がディスクに生じてしまい、失われてしまった多数のデータを回復するには バックアップに頼る以外ありませんでした。 バックアップの作業は、それ自体がシステムのリソースを必要としますし、な により「とっても退屈」な作業です。しかし、これはなにより大切な任意保険 と考えてください。それも、その辺の保険会社がトラブルの時にあれこれ理由 をつけて支払いをしぶるのに比べれば、ずっと正直で確実な保険です。 A. この文書について A.1. Copyright notice Copyright(c) 1998,1999 by FUKUSHIMA Osamu この文書の著作権(C)は福島於修 が保持します。この著作 権表示が全てのコピーに残されるかぎり、この文書は自由に複製・配布するこ とができます。部分的に配布する場合には、著作権に関する記述と完全な文書 の在処を併記すると共に、それが部分的な配布であることを明記されるようお 願いします。なお、これらの複製・配布にあたっては、著作権保持者の許可は 必要ありません。 A.2. 責任の放棄 この文書の内容は無保証であり、私は本文書の内容についての責任を否認しま す。本文書に含まれている例などを使用するのは、全て読者の責任で行ってく ださい。 A.3. 謝辞 集合型テープドライブの章を執筆するにあたり、ＮＥＣ (ＮＥＣソリューショ ンズ) 様から検証用機材をお借りしました。ありがとうございました。 A.4. フィードバック 質問・コメント・訂正などこの文書に関するご意見は: FUKUSHIMA Osamu までお願いします。 A.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 に関する章を追加.