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は、別物なのだ。
このページでは、私が行っているBack upについて説明する。
File ServerのHDDが故障した場合、いち早く、しかも完璧に修復する必要がある。
これに対応するために、私は、Back upを保存し、故障時に、新規のHDDを取り付け、Back up deviceから、コピーするのではなく、日ごろから、メインとして使っている、HDDと同容量のHDDを付け、cloneをつくり、一定の周期でメインHDDと全く同じ内容に自動的に保ち、メインHDDが故障したときは、このcloneを、物理的にメインHDDと置き換え、運用を続ける方法をとっている。
まず、Systemの概要を示す。
OS | Rad Hat Linux 9 (RHL9) |
HDD | ATA133 120GB x2 |
主な用途 | File Server |
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ではなく、デバイス名で取り扱うように修正する。
/etc/fstab:
/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するため、故意にそうしている。
デスクのcloneを作るのに、重宝なMirrordirという、アプリケーションがある。RHL9には、含まれていないので、rpmをdownloadして、Installするか、Sourceを持ってきて、自分でbuildするかして、使用できるようにする。
buildは./configureしてmakeするのが普通だが、Mirrordirは。これとは少し異なる。INSTALLを読めば、すぐわかることなのだが、
./0install-quick /usr
または、
./0install-quick /usr/local
のように、Install先を指定して、スクリプトを実行する。
下記のような、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を明記した、ラベルを貼り付けておく。
この方式では、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を破壊する危険もない。
Copyright (c) 2033