Back upしてます？

System運用に、Back upが欠かせないことに、異論はないと思う。しかし、実際に、どのような方法で、どれくらいの頻度で、Back upするかについては、いろいろな考え方がある。

以前は、diskの容量も少なく、DDS-2 Tape Driveや、CD-Rに焼く方法で、行っていた。

しかし、今では、120GBを超える大容量HDDが主流になり、DLT Tapeでも、苦しくなってきた。しかも、これらのBack up deviceは非常に高価だし、同じテープを繰り返し使うのでは、磨耗するので、定期的にかけかえる必要があり、手間もランニングコストもかかる。

RAIDでミラーリングする方法もあるが、これは、HDDの故障に対応する物で、たとえば操作ミスで、消してしまったり、意図せず書き換えてしまったFileを元に戻すことは出来ない。RAIDとBack upは、別物なのだ。

運用ポリシー

File ServerのHDDが故障した場合、いち早く、しかも完璧に修復する必要がある。

これに対応するために、私は、Back upを保存し、故障時に、新規のHDDを取り付け、Back up deviceから、コピーするのではなく、日ごろから、メインとして使っている、HDDと同容量のHDDを付け、cloneをつくり、一定の周期でメインHDDと全く同じ内容に自動的に保ち、メインHDDが故障したときは、このcloneを、物理的にメインHDDと置き換え、運用を続ける方法をとっている。

システムの概要

Samba Serverとなっており、Windowsユーザーも、原則的に、このマシンに、ネットワークを介して接続し、個々のマシンのLocal HDDに置いたデーターは、保護しない。

Internet Serverのファイルは、nfsでexportし、File Serverが、クライエントとして、mountして、Local File同様に、Back upするようにしてある。

HDDはできるだけ同じ容量の物を2台用意し、片方(hda)を通常使用に、もう片方(hdc)をBack up用に使用する。

準備

RHL9では、基本的にパーテーションをDisk Labelで識別し、Mountするようになっている。

しかし、ここで述べる方法は、全くのcloneを作り、障害が発生したとき、HDDを物理的に差し替え、最後にBack upしたときの状態に直ちに復帰させる物で、同じDisk LabelがついたHDDが複数存在することになり、大変に都合が悪い。

/etc/fstab, /etc/grug.confを書き換え、LABELではなく、デバイス名で取り扱うように修正する。

/dev/hda7	/	ext3	defaults 1 1
/dev/hda1	/boot	ext3	defaults 1 2
none	/dev/pts	devpts	gid=5,mode=620 0 0
none	/proc	proc	defaults 0 0
none	/dev/shm	tmpfs	defaults 0 0
/dev/hda3	/tmp	ext3	defaults 1 2
/dev/hda2	/usr	ext3	defaults 1 2
/dev/hda8	/mnt	ext3	defaults 1 2
/dev/hda5	/var	ext3	defaults 1 2
/dev/hda6	swap	swap	defaults 0 0

/etc/grub.conf:

title Red Hat Linux (2.4.20-8)
root (hd0,0)
kernel /vmlinuz-2.4.20-8 ro root=/dev/hda7
initrd /initrd-2.4.20-8.img

の様にである。

Back up用の、hdcの記述がないが、これは、Back upするときだけ、mountし、Back upが終了すれば、umountするため、故意にそうしている。

MirrordirのInstall

デスクのcloneを作るのに、重宝なMirrordirという、アプリケーションがある。RHL9には、含まれていないので、rpmをdownloadして、Installするか、Sourceを持ってきて、自分でbuildするかして、使用できるようにする。

buildは./configureしてmakeするのが普通だが、Mirrordirは。これとは少し異なる。INSTALLを読めば、すぐわかることなのだが、

./0install-quick /usr

または、

./0install-quick /usr/local

のように、Install先を指定して、スクリプトを実行する。

Backup ScriptとCron

下記のような、scriptを各パーテーションについて用意する。

/bin/nice -19 /sbin/fsck.ext3 -p /dev/hdc2 || echo "/dev/hdc2 is crashed" | mail root -s "bk report"
mount /dev/hdc2 /cbk_usr
/bin/nice -19 /usr/bin/mirrordir /usr /cbk_usr
date > /cbk_usr/Backupdate.txt
umount /cbk_usr

そして、適当と思われる周期でBack upされるように、/etc/cron.daily, /etc/cron.weeklyなどに置き、実行フラグを立てる。

Back up中以外は、mountしないので、誤ってけすこともなく、突然電源が切れても、損傷を受ける危険性は小さい。

/devのような、特殊ファイルが入ったrootパーテーションは、

mount /dev/hdc7 /cbk
(cd / ; tar clf - .) | (cd /cbk && tar xpf -)
date > /cbk/Backupdate.txt

のように、gnu tarを使えば良い。

非常訓練

Back upの意義は、もしものとき、システムを速やかに復旧できるかどうかにかかっている。

上記のように、ハード、ソフトの準備を行っても、本当に/dev/hdaが壊れてしまったときに、/dev/hdcは使えるかどうか、実際に行ってみる必要がある。

実際、hdaをはずし、hdcをhdaが繋がっていたところに差し替え、起動し、正しく動作するか、十分に検査する。

｢非常訓練｣をしても、本当に故障して復旧作業が必要になった際は、やはりそれなりに焦るので、非常訓練を行うついでに、こまごまとして操作を含めて、詳細な「マニュアル｣を作成しよう。

また、やってみればすぐ気付くことだが、同じ容量の（場合によりメーカーも同じ）HDDをはずして交換するのだから、区別がつかなくなり、混乱して交換したつもりが、故障したほうをもう一度取り付けてしまう危険がある。

HDDには、人が見てはっきり区別がつくようにhda/hdcを明記した、ラベルを貼り付けておく。

Fileの復元

この方式では、HDDが故障してしまったときに、すぐ直近のBack upを行ったときの状態に復元できるほか、誤ってファイルを消してしまったり、復元不能な状態に書き換えてしまった場合にも、次のBack up動作を開始する前なら、元に戻すことができる。

rootになり、手動でmountして、必要なファイルを取り出しても良いが、

bkmount:

mount -r /dev/hdc7 /cbk
mount -r /dev/hdc8 /cbk/mnt
mount -r /dev/hdc2 /cbk/usr
mount -r /dev/hdc8 /cbk/var
mount -r /dev/hdc1 /cbk/boot

bkumount

umount /cbk/mnt
umount /cbk/usr
umount /cbk/var
umount /cbk/boot
umount /cbk

のようなスクリプトを用意しておくと、メインHDDと同じfile treeができ、しかもread onlyなので、誤って、back upを破壊する危険もない。

OS	Rad Hat Linux 9　(RHL9)
HDD	ATA133 120GB x2
主な用途	File Server