以下のテキストは、執筆時当時の情報を元に書いたものであり、 現在の情勢にそぐわないことを含む場合があるので注意されたい。 また、テキストは最終提出原稿で校正を経る前のものなので、実際にUNIXUSER 本誌に記載されたものとは異なる。誤字脱字等そのままである。
致命的な誤り以外は加筆修正等は行なわないので情報の鮮度に気をつけつつ 利用して欲しい。
→目次
===========================================
Part 2 ストレージのバックアップ
===========================================
「コンピュータを構成する部品の中で、何が一番大切か」
という問に対して何を思い浮かべるだろう。「頭脳」と言われるCPUが根幹的役割
を持っているのは確かだが、CPUは壊れても換えがきく。ところがハードディスク
ドライブ(HDD)はそうはいかない。中味が常に重要だからだ。消えたら取り戻せな
いデータを、消失から守る方法を考えよう。ただし今回の特集の対象をふまえて、
「できるだけ安く」という観点も考慮していこう。
■
■Part 2のメニュー
■
実は本誌2001年11月号に筆者自身によるバックアップを話題とした記事がある。
バックアップという行為はいつでも重要で、一度ディスククラッシュが起きて復
旧に当たるときには基本的なコマンドしか使えないうえに、紙メディアにしか頼れ
ないことが多いので、2001年の時とほぼ同じ内容をもう一度ということでも構わ
ないと指示されたのだが、それだけでは寂しいので今回の対象をふまえ、
自宅で使っているPCのHDDが壊れた、
バックアップは……次から取ります(;_;)
でもお金がかかるのはちょっとね…
というストーリーを前提に、現実的にどう行動したらいいか、を織り交ぜていき
たい【註 ろ】。
---[註 ろ]------------------------------------------------------------
バックアップ手法そのものに絞った解説はバックナンバーか、
http://www.gentei.org/~yuuji/support/uu/200110/part3.html
を参照して欲しい。
----------------------------------------------------------------------
■
■バックアップ先を考える
■
個人的な話だが、先日HDDデータをバックアップすることに特化した製品に関する
プレゼンテーションを聞いた。「IDEディスクを20個ほど用意して、ちょっと豪華
なRAID箱に入れて、rsyncをcronで仕込んだら、似たようなものができそうだな」
と思ってしまったそれの値段は、山形なら立派な家が建ちそうな金額で……でも
そういうもんだろうな、と感じた。要するに開発・宣伝・販売・サポートをする
ための人件費を合わせるとそうなるのだ。大きなサイト向けの製品では、
Windowsエンドユーザに使わせるためのGUIなどを開発するのにかかるコストも馬
鹿にならないだろう。
しかし…だ、エンドユーザから見えない縁の下で、管理者がごくごく基本的で伝
統的なバックアップを取っていれば問題ない。同時にエンドユーザに「重要なファ
イルは絶対にローカルPC(だけ)に置かせない」という方針を徹底させることがで
きれば不慮のPCトラブルからの復旧も早い上に個人PC盗難・紛失による損害も軽
減できる【註 い】。
---[註 い]------------------------------------------------------------
持ち出しPC内のデータの保護に関してはそれだけで1つの大きなトピックである
が、今回は触れない。
----------------------------------------------------------------------
「バックアップ専用装置」があればそれに越したことはないが、そうでない場合
はどうしたらいいだろう。現在のように大容量化したHDDのバックアップを取る場
合、もはやHDD以外の選択肢は厳しくなって来た。実際のところ、金額的に最も有
利なのがHDDといえる。
■
■バックアップ方法と注意点
■
ストレージ内データのバックアップ(以下、単にバックアップ)は、もちろん「不
慮のトラブル」による消失からデータを保護することが目的だが、たんに「ハー
ドウェアやソフトウェアに起因するファイル消失」だけを対象とするのではなく、
「人為的ミスによるファイル消失」も視野にいれておくと価値あるバックアップ
体制が築ける。そのためにはどういう点を考慮すれば良いだろうか。
第一に、バックアップをどこに取るかについて慎重に決めなければならない。毎
日必要になるほど重要なデータは、それを格納しているホストがダウンしただけ
で取り出せなくなり、業務に支障を来たす。それを考えるとバックアップは別の
ホストに取っておくのが望ましい。しかし、操作ミスでデータが消えた場合は、
バックアップがすぐ取り出せる位置にあることが重要なので、必ずしも別ホスト
に置く必要はない。
第二に、バックアップを取る「場所」だけでなく「タイミング」も重要で、ハー
ドウェアトラブルに備えたバックアップは「壊れる直前のもの」が欲しいのでで
きるだけ頻繁に取ることに価値があるが、人為的ミスに備えたバックアップはむ
しろ逆のケースが多い。「間違って消したことに次の日に気付いた」ということ
もあるので、1週間〜1ヶ月間隔という長い周期で取る方が有意義かもしれない
【註 る】。
---[註 る]------------------------------------------------------------
任意の時点のファイルを確実に戻したい場合は、CVSやSubversionといった
履歴管理システムを使うか、複数世代のバックアップを効率的に取るスクリプト
pdumpfs (http://namazu.org/~satoru/pdumpfs/)
glastree (http://www.igmus.org/code/)
などを利用するのが良いだろう。
----------------------------------------------------------------------
第三に重要な点は「バックアップしてあること」と「そのバックアップ先」を忘
れないようにすることである。いったんやり方さえ把握すればバックアップを自
動的に行なうための設定はたやすい。消えて悲しい思いをするディレクトリはど
んどん自動バックアップ対象に入れると良い。ただ、そうするとどのディレクト
リをどのホストのどの場所にバックアップしていたのか分からなくなって来る。
場所を思い出せないならまだしも、バックアップがあることを忘れて再構築に無
駄な時間を費やすこともしばしばある。分かりやすい場所(たとえばfstab)にバッ
クアップ先もメモしておくと良い。
■
■HDDが逝っちゃった!
■
機会があれば色々な人にバックアップが大事だということを日ごろから必ず説明
していて、もちろん大切さは理解してもらえる。しかし悲しいかな、HDDの故障を
経験する前に実際にバックアップを実践しはじめた人はいない。しばらく利用を
続けていてHDDのアクセス時に異音がし始めて、慌てて店に行く、というのがお約
束のパターンである。やれやれと思いつつも、健康な精神の人間としての正しい
挙動なのかと最近は納得している。しかし、HDDが不調になっても完全に壊れてい
なければほとんどのデータは取り出せる。諦めず、故障時にできるだけ復旧に努
めることは、データとバックアップの大切さを知る良い薬になるといえる。
機械では、可動部があるものが一番壊れやすい。おそらく多くの読者も経験的に
HDDが最も早く壊れるという印象を持っているだろう。コンシューマ向けHDDに対
する個人的印象では、常用しているHDDの寿命は、極端に短いもので1年、良く持
つもので5年、平均的には2〜3年といったところだ。さらにもうひとつの経験則を
いうと、HDDは必ず数年内に壊れるのだが、いきなり完全にアクセスできなくなる
ようなことはまれで、ほとんどの場合特定のファイルをアクセスするとエラーを
出すようになり、次第にそれがひどくなっていく、といったケースが多い。「カ
ツンカツンカツン…」と何度もリトライを繰り返す音が出るようになったらそれ
は最終警告だと考え、一刻も早く手を打とう。
●新しいHDDを用意するまでの対処
一度障害の出始めたHDDはどんどん状態が悪くなるので、通常の使用はなるべく
控え、すぐに大事なデータの救出に努める。手順としては、
(1) シングルユーザモードで起動し必要なパーティションをリードオンリマウン
トする。
(例 /usr パーティション)
# mount -r /usr
(2) ほんとうに重要なファイルだけコピーする(コピーの方法はPart2後半参照)
(3) 2が無事終わったら、該当パーティション内の全てのファイルのコピーを
試みる
となるだろう。
もし、(2)や(3)の段階でリードエラーが頻発するようなら、現状での読み出しは
あきらめ、次のステップに進む。壊れたファイルシステム修復のためfsckをかけ
たくなるが、障害の出始めたディスクに対して行なうと障害の度合いを高める危
険もある。
●新しいHDDに載せ替えてからの対処
問題のあるHDDを外し、新しいHDDにシステムをインストールする。その後、問題
のあるHDDからのデータの吸い出しに移るわけだが、このようなときには【図 は】
のようなパーツがあるととても便利である。
---[図 は]------------------------------------------------------------
%image usb-hdd1.jpg
USB 2本差しの2.5インチ IDE-HDD → USB アダプタケーブル
%image usb-hdd2.jpg
アダプタに2.5インチHDDをつなぎ、PCに接続したところ。
2本のケーブルのうち1本はデータ用、もう1本は補助電源供給用。
----------------------------------------------------------------------
IDEのHDDをUSBインタフェースに変換するアダプタは数多く販売されているの
でそれらを常備しておくと、こうした緊急時に大活躍する。また、普段のバック
アップ先のHDDを接続するためにも利用価値が高い。
問題のあるHDDをUSBアダプタ経由で本体に接続したら、パーティションイメージ
をまるごと読み取る。
たとえば、データを取り出したいパーティションが /dev/da0s1e だとする。あら
かじめ、このパーティション全体の大きさよりも大きなパーティションを確保し
ておき、作業ディレクトリをそこに設定したうえで、以下のようにdd コマンドを
起動する。
# dd if=/dev/da0s1e of=hogehoge ibs=1b \
conv=noerror,sync
noerror はエラーが起きても中止しないことを、syncは入力ファイルと出力ファ
イルのバイトオフセットを同期することを意味する。これにより、入力側にエラー
が出たときは読めなかったバイト数だけ出力側にNULLを書き出す。
パーティション全データの読み出しは、もともとサイズが大きい上に不良ブロッ
クへのアクセスも含まれるため相当な時間がかかるが辛抱強く待とう【註 ほ】。
---[註 ほ]------------------------------------------------------------
dd 起動コマンドラインに obs=2M などと大きめのobsを指定すると速度向上が
望める場合もある。
----------------------------------------------------------------------
パーティションイメージをファイルに落とせたら、それを仮想デバイスとしてOS
に認識させる。FreeBSDの場合は mdconfig で、Linuxの場合は losetup で行な
う。ddで吸い出した hogehoge ファイルを対象とする例を示す。
【FreeBSD】
mdconfig -t vnode -a -f hogehoge -u 1
("1"の部分は空いているデバイス番号なら何番でも良い)
【Linux】
losetup /dev/loop1 hogehoge
("1"の部分は空いているデバイス番号なら何番でも良い)
これで救出パーティションを、FreeBSDの場合は /dev/md4 経由で、Linuxの場合
は /dev/loop1 経由でアクセスできる。これらのデバイスファイルに対してfsck
をかければ、mountできる程度には修復できるだろう。ただし、fsckの実行状況に
よっては壊滅的になる場合もあるので、せっかく読み込んだイメージファイルは
さらに別のファイルにコピーしてから作業するのが良いだろう。
●superblockが壊れた!
破損の著しいパーティションにfsckをかけたときに、
Cannot find file system superblock
といったメッセージが出てくることがある。superblockとは当該ファイルシステ
ムのサイズや空きブロック数、状態などを格納する特別なブロックで、これが壊
れるとファイルシステムそのものの認識ができなくなる。そのため、superblock
はパーティション内部に何個もコピーが作られ、標準superblockが読めないとき
の代替として利用できるようになっている。何番目のブロックにsuperblockが作
られるかはnewfs(mke2fs)するときに表示される。
-----------------------------------------------------
【FreeBSD】
# newfs /dev/md1a
/dev/md1a: 100.0MB (204784 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 25.00MB, 1600 blks, 3200 inodes.
super-block backups (for fsck -b #) at:
160, 51360, 102560, 153760 ← これ
【Linux】
# mke2fs /dev/hdd1
mke2fs 1.35 (28-Feb-2004)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
12768 inodes, 50872 blocks
2543 blocks (5.00%) reserved for the super user
First data block=1
7 block groups
8192 blocks per group, 8192 fragments per group
1824 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961 ← これ
-----------------------------------------------------
fsckは標準superblock破損時には第1の予備を探しに行くが、それが壊れていたり
見つからなかった場合には人間が手動で指定する必要がある。その他の
superblockの位置をあとから知るには、newfs(mke2fs)に -n オプションを付けて
起動すれば良い。-n は実際にフォーマットすることなくnewfsするときと同じ統
計情報を表示するので、superblock一覧を得ることができる。別のsuperblock を
指定してfsckするには -b オプションを利用する。
-----------------------------------------------------
【FreeBSD】
# fsck_ffs -b 123456 /dev/da0s1e
【Linux】
# e2fsck -b 123456 /dev/hdd1
-----------------------------------------------------
●パーティションテーブルが壊れた!
上記の例は障害HDDのパーティションテーブルが読めた場合だが、パーティション
テーブルが壊れるとファイルシステムとしてのアクセスが不能となる。たとえほ
かの部分に大した損傷がなくても fsck すらできなくなる。パーティションテー
ブルは、少なくともパラメータだけ覚えておけばなんとかなるので、新しいマシ
ンや新規HDDでの運用を始めたときには必ずパーティションテーブルもバックアッ
プしておくと良い【註 と】。ただしパーティションテーブルをメモしたファイル
をそのHDDに入れておいては意味がないので、別のHDDに保存するか、印刷してマ
シン本体に貼り付けておくと良い。
---[註 と]------------------------------------------------------------
主にセキュリティ上の理由からだが、NetBSDのようにシステム標準のcronジョブ
でパーティションテーブルのバックアップを取るシステムもある。
----------------------------------------------------------------------
・パーティションテーブルの表示と保存
FreeBSDでは、スライス情報とBSDラベル情報の両方を保存しておく。【実行例 に】
にしたがって得られた結果を安全でなおかつすぐに思い出せる位置に保存してお
こう。
---[実行例 に]--------------------------------------------------------
【FreeBSD】
* ad0のスライス情報を調べる
# fdisk ad0
~~~~~~~~~
parameters extracted from in-core disklabel are:
cylinders=319120 heads=16 sectors/track=63 (1008 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=319120 heads=16 sectors/track=63 (1008 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is: <<--- ad0s1がFreeBSDパーティション
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) <<--- 開始セクタ63、321669432ブロック
start 63, size 321669432 (157065 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
The data for partition 3 is:
The data for partition 4 is:
* ad0s1のBSDラベルを調べる
# disklabel ad0s1
~~~~~~~~~~~~~~~
# /dev/ad0s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 2097152 0 4.2BSD 1024 8192 22
b: 2097152 2097152 swap
c: 321669432 0 unused 0 0 # "raw" part, don't edit
e: 2097152 4194304 4.2BSD 1024 8192 22
f: 12582912 6291456 4.2BSD 1024 8192 46232
g: 302795064 18874368 vinum
【Linux】
hdaを調べる場合
# fdisk -l /dev/hda
~~~~~~~~~~~~~~~~~
Disk /dev/hda: 2516 MB, 2516484096 bytes
128 heads, 63 sectors/track, 609 cylinders
Units = シリンダ数 of 8064 * 512 = 4128768 bytes
デバイス ブート 始点 終点 ブロック ID システム
/dev/hda1 * 1 13 52384+ 83 Linux
/dev/hda2 14 583 2298240 83 Linux
/dev/hda3 584 609 104832 82 Linux スワップ
----------------------------------------------------------------------
・パーティションテーブルの復元
パーティションテーブルが破損したHDDは、本体から取り外しUSBインタフェース
の外付けHDD箱などに入れて接続することになるだろう。接続が完了したものと
して、その後の手順の概略を示す。実際の作業時に慌てないよう、使用するコマ
ンドのマニュアルを見つつ壊れていもいいHDDで練習しておくと良いだろう。説
明を読むとややこしそうだが、一度実際にやってみると簡単だ。
【FreeBSDの場合】
スライス情報が失われたHDDのデバイスファイルを /dev/da0 と仮定する。
まず
# fdisk -I /dev/da0
として、セクタ0を初期化する。そののち、事前にメモしておいたパラメータでス
ライスを作成する。以下の例は、「スライス1を開始セクタ=63、セクタサイズ
=321669432」と設定するものである。
# fdisk -1 -u /dev/da0
~~~~~~~~~~~~~~~~~~~~
Do you want to change our idea of what BIOS thinks ? [n]
(ディスクのジオメトリ情報が壊れていなければ n )
The data for partition 1 is:
Do you want to change it? [n] y
~
Supply a decimal value for "sysid (165=FreeBSD)" [0] 165
~~~
Supply a decimal value for "size" [0] 321669432
~~~~~~~~~
Explicitly specify beg/end address ? [n] n
~
Are we happy with this entry? [n] y
~
これで書き込みするかのメッセージにyと答えれば復元完了となり、
/dev/da0s1 でスライス1がアクセスできるようになる。
続いて、disklabelでBSDラベル書き込む。【実行例 に】のような作業により、事
前に disklabel コマンドでパーティション情報をファイルに保存してあるものと
する。保存してあるファイルを foo とすると、これを/dev/da0s1 のパーティショ
ン情報として書き込むには
# disklabel -w /dev/da0s1
# disklabel -R /dev/da0s1 foo
とする。これで復元したパーティションに対してfsckなどの操作を行なえるよう
になるはずだ。
【Linuxの場合】
fdiskパーティション情報が失われたHDDのデバイスファイルを /dev/sda と仮定
する。以下の例は、「領域番号2の開始ブロック=14、終了ブロック=583」
と設定するものである。
# fdisk /dev/sda
コマンド (m でヘルプ): n
~
コマンドアクション
e 拡張
p 基本領域 (1-4)
p
~
領域番号 (1-4): 2
~
最初 シリンダ (1-1008, 初期値 1): 14
~~
終点 シリンダ または +サイズ または +サイズM または +サイズK
(1-1008, 初期値 1008): 583
~~~
最後に w で書き込んで終了する。
・違うサイズのHDDにコピーしても復元可能
繰り返しになるが、HDDに障害が発生したとき、そのHDDに対していろいろ修復操
作を繰り返すとリトライが多発して時間がかかる上に、より深刻なダメージを与
えることもある。別の無傷のHDDを用意してそちらにディスクイメージをまるごと
コピーして、無傷HDDにたいして操作した方が良い。このときたとえば不調になっ
たHDDが40GBのものなら、それより大きなHDDにディスクイメージを先頭ブロック
から全てコピーすれば40GBというサイズ情報もコピーされるので修復操作が可能
だ【図 を】。実際にHDDから不調のサインが出始めたら、それより大きなHDDを2
台買って来ると良いだろう。1台は置き換え用として、もう1台はイメージ修復作
業用として利用し、それが終わったらいざというときのためのミラーリング用
HDDとして利用できる。
---[図 を]------------------------------------------------------------
ddでディスク全体をコピー
+------+ +------+
| | | |
| 40GB | ---->| 80GB |
| | | | ←このディスクに対して修復操作
+-TTTT-+ +-TTTT-+ (システムは40GB-HDDだと認識する)
不調HDD 別のHDD
----------------------------------------------------------------------
修復作業終了後、サイズの異なるディスクイメージを持ったHDDを元に戻すには
dd if=/dev/zero of=/dev/sd0 bs=1b count=63 (FreeBSD)
dd if=/dev/zero of=/dev/sda bs=1b count=63 (Linux)
などとして管理ブロックを壊し、fdisk(8)を用いてパーティション作成するとこ
ろからやりなおせば良い。
■
■バックアップ作業
■
「HDDクラッシュに懲りた」のなら、バックアップも進んでやることだろう。
ここでは、「HDDのバックアップはHDDに取る」ことに絞って解説しよう。
●バックアップとは?
バックアップとは、要するに普段使っているファイルのコピーをとることである。
しかしその「コピー」という言葉につられて cp コマンドを使ってはいけない。
初心者を脱して、いよいよUNIX上で作成したファイルが多くなって来たころにバッ
クアップを取りたくなり、UNIXコマンドリファレンス本などを見た記憶から「ディ
レクトリごとコピーするには cp -r だったなあ」と判断してしまうことが多い
が、シンボリックリンク等、ファイルの種別を保存できないため適さない。
ファイルに関する全ての情報をバックアップするためには、tarを利用する。
●tarによるバックアップ
どのUnixでもtar(TapeARchiver)コマンドが付属している。tarはその名の通り、
もともとはテープデバイスに指定したファイルやディレクトリのバックアップを
取るためのものだが、テープデバイスの代わりにアーカイブとなるファイルを指
定することができる。またアーカイブファイルとして標準入出力を指定できるの
で、これを利用してディレクトリのコピーを行なう。
ディレクトリ A 以下の階層全てをディレクトリBにコピーするには以下のように
する。
# tar -cf - A | tar -xpf - -C B
パイプの先でSSHを利用すれば、リモートホストにバックアップを取ることができ
る。
# tar -cf - A | ssh remotehost tar -xpf - -C B
tarの主なコマンドとオプションを【表 ち】に示す。
---[表 ち]------------------------------------------------------------
【tarの主なオプション】
[コマンド]
-c アーカイブを作成
-t アーカイブ内のファイル一覧表示
-x アーカイブをディスクに展開
[オプション]
-f 次の引数をアーカイブファイルとみなす
- を指定すると標準入出力を意味する
-C 次の引数で指定したディレクトリに移動してから
アーカイブの作成/展開を行なう
-p 展開時にファイルのパーミッションを保存する。
-z アーカイブの作成(または展開)時にgzipを呼んで
圧縮(または伸長)を行なう。
--one-file-system
アーカイブ作成時に起点に指定したディレクトリが存在する
ファイルシステム以外にあるファイル・ディレクトリは
アーカイブに含めない。
----------------------------------------------------------------------
●ACLも含めたバックアップ
最近では POSIX ACL(Access Control List)の使えるシステムが一般的になって
来た。ACLを利用すると、システムアカウントをいじることなく手軽にファイル
の保護ができるため、一度利用し始めるとそれなしに戻れなくなるだろう。ただ
し、tar(1)やdump(8)でファイルシステムのバックアップを取ってもACL情報は保
存されないため、リストアしたときにせっかくの設定が台無しになってしまう。
----------[ コラム1 POSIX ACL ]---------------------------------------
POSIX ACLではファイルのアクセス権をきめこまやかに設定できる。伝統的UNIXの
ファイルパーミッションでは、読み・書き・実行の3つの権限の付与を
ファイルの所有者、
同一グループに属する人
その他
に対して決定できる。これに対しACLでは、各権限の付与を任意のユーザやグルー
プに対して決定できる。たとえば、ファイル foo があったとして
「taro と hanako には見せてもいいが、ほかの人には見せない」
ということも可能で、そのためにはsetfcl(1)を用いて以下のように設定する。
% setfacl -m u:taro:r--,u:hanako:r--,g:---,o:--- foo
ファイルに設定されたACLの確認はgetfcl(1)で行なう。
% getfcl foo
~~~~~~~~~~
# file: foo
# owner: yuuji
# group: staff
user::rw-
user:taro:r-- #effective:r--
user:hanako:r- #effective:rw-
group::--- #effective:---
mask:r--
other:---
なお、FreeBSD5でACLを利用する場合はファイルシステムのマウントオプション
に acls が必要なので、たとえば /etc/fstab のエントリが、
/dev/ad0s1e /usr ufs rw 2 2
のパーティションでACLを利用したい場合は、
/dev/ad0s1e /usr ufs rw,acls 2 2
とする。Linux の場合もほぼ同様だが、オプションを acl とする(ただし対応カー
ネルが必要)。
----------------------------------------------------------------------
・starの導入
ACLを設定しているファイルシステムのバックアップを取るには、starを利用す
る。
http://cdrecord.berlios.de/old/private/star.html
starはcdrecordの作者でもある Joerg Schilling 氏の作成したアーカイバであ
る。ftp://ftp.berlios.de/pub/star/alpha/ よりソースアーカイブを入手する。
star-1.5a60.tar.bz2
MD5 (star-1.5a60.tar.bz2) = 6f48614d05a4f91ba024f7b7691236c9
ビルドには同氏によるsmakeを利用するのが望ましいのだが、GNU makeでも可能
なようである。
% gtar jxpf star-1.5a60.tar.bz2
% cd star-1.5a60
% gmake
コンパイルが終了すると
./star/OBJ/ビルドシステム名-cc/
に star_fat コマンドが生成される。
# gmake install
とすると /opt/schily/ 以下に各種ファイルがインストールされる。インストー
ル先ディレクトリを変えるには ./DEFAULTS/Defaults.＜システム名＞ の中の
INS_BASE 変数を変更する。
・starによるACLを含めたバックアップ
starのコマンドラインオプション等は、GNU tar 等に似ているものの微妙に違う。
基本的には、コマンドラインオプションを1つ1つ分けて記述する必要がある。詳
細はstar(1)マニュアルページに譲るとして、ここではディレクトリAをディレク
トリBに「ACLを含めて」バックアップする方法を紹介する。ACLを処理するために
は-acl オプションを付加し、以下のように起動する。
# star -c -Hexustar -acl -C A . | star -xp -acl -C B
-H は、アーカイブのファイルフォーマットを決めるためのオプションで
exustarを指定することでACLを格納できるようになる。
●rsyncによるバックアップ
二つのディレクトリを同期させるためのツールがrsync【註 り】だ。同一ホスト
内でも、リモートホスト間でもどちらでも使える。rsyncもオプションが多数ある
が、ここでは特定のディレクトリ以下のファイル群を別のディレクトリにバック
アップするためのコマンドラインを示す。
# rsync -aH --delete A B
これにより、「ディレクトリAを、ディレクトリB以下にコピーし、なおかつA以下
にないファイルはBからも削除する」ことができる。たとえば、
/home/yuuji と /backup/home/yuuji を同一にしたい
ときは、以下のように起動する。
# rsync -aH /home/yuuji /backup/home
実行前に、コピーされるファイル・削除されるファイルを確認するには n オプ
ションを追加する。
# rsync -aHn /home/yuuji /backup/home
リモートホストのディレクトリと同期させるためにはコピー先ディレクトリに
「ホスト名:」 を前置する。
# rsync -aH A remotehost:B
リモートホスト側に指定するディレクトリBを相対パスで指定すると、ホームディ
レクトリが起点と見なされる。リモートホストへのアクセスはsshが利用される
ので【註 ぬ】、rootユーザで起動する場合はsshログインのための設定を次善に
済ませておく必要がある【コラム 2】。
---[註 り]------------------------------------------------------------
http://rsync.samba.org
----------------------------------------------------------------------
---[註 ぬ]------------------------------------------------------------
rsync 2.6.0 からはリモート接続に用いるコマンドがデフォルトでsshとなった。
----------------------------------------------------------------------
----------[ コラム2 rootユーザのSSHログイン ]-------------------------
バックアップは他のホストに取ることが多い。あらゆるファイルを読み書きため
にはrootユーザで起動する必要があるので、SSHによるログインを可能にしておく
必要がある。rootユーザのリモートログインもSSHであれば比較的安全に行なえる
が、以下の点に注意したい。
* プレインパスワードログインはできないようにする
* rootユーザの ~/.ssh ディレクトリパーミッションには十分に注意する
* 誰でもコンソールに触れる場所に配置しない
* 盗難に気をつける
まず、サーバ(SSHログインされる)側で、rootユーザのSSHログインは公開鍵認証
のみとする。/etc/ssh/sshd_config の PermitRootLogin の項目を以下のように
する。
PermitRootLogin without-password
起動中のsshdにHUPシグナルを送ると設定が反映される。
# kill -1 `cat /var/run/sshd.pid`
次に Host-A(10.1.1.1) から Host-B にSSHログインするための認証鍵の作成を行
なう。作成は、
* クライアント側で鍵を作成
* 公開鍵をサーバ側の ~/.ssh/authorized_keys ファイルに追加
という手順で進める。
Host-A# ssh-keygen -t dsa -f ~/.ssh/backup
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
cron等でバックアップを自動で行ないたい場合はパスフレーズを空にしておく。
でき上がった鍵のうち、公開鍵(.ssh/backup.pub)をHost-B側に安全な手段でコピー
する。
次にHost-B側で ~/.ssh/authorized_keys ファイルに作成した公開鍵を追加する。
Host-B# touch $HOME/.ssh/authorized_keys
Host-B# chmod og-r $HOME/.ssh/authorized_keys
Host-B# vi $HOME/.ssh/authorized_keys
開いたファイルの末尾にbackup.pubファイルの内容を追加する。
このときkterm等からコピーペーストすると余計な改行が入るので
かならずエディタ操作(viなら G:r backup.pub)で挿入する。
挿入された鍵(長い1行)の先頭に、以下の下線部を追加する。
from="10.1.1.1",no-pty,no-port-forwarding ssh-dss AAAA....
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
これでHost-A(10.1.1.1)以外のホストからの、この鍵を用いたログインは禁止さ
れる。
検証するため、Host-Aから.ssh/backup鍵を利用したログインを試行してみる。
Host-A# env - PATH="$PATH" sh (PATH以外の環境変数を捨ててshを起動)
Host-A# ssh -i $HOME/.ssh/backup Host-B hostname
Host-B側でhostnameコマンドが表示されることを確認したら
新しく起動したshを抜ける
試行に成功したらバックアップ用のコマンドラインをシェルスクリプトにしてお
くと良いだろう。以下は Host-A の /home 以下全てを Host-B の
/backup/Host-A にバックアップする例である。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#!/bin/sh
unset SSH_AUTH_SOCK
RSYNC_RSH="ssh -i $HOME/.ssh/backup"; export RSYNC_RSH
rsync -avH --delete /home Host-B:/backup/Host-A
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
----------------------------------------------------------------------
---[註 わ]------------------------------------------------------------
----------------------------------------------------------------------
---[註 か]------------------------------------------------------------
----------------------------------------------------------------------
---[註 よ]------------------------------------------------------------
----------------------------------------------------------------------
---[註 た]------------------------------------------------------------
----------------------------------------------------------------------
yuuji@
Fingerprint16 = FF F9 FF CC E0 FE 5C F7 19 97 28 24 EC 5D 39 BA