2002-03-18 [長年日記]

_1 私のバックアップ

先日、サーバでとあるプロセスが異常増殖し、メモリを食いつくした揚げ句にシステムがフリーズしました。 ネットワークにもキーボードにも全く反応しなくなったので、仕方がないので強制的にリブートしたら、案の定「LI」と表示されたまま止まってしまいました。

生憎、手元にある他の Linux マシンは私の FIVA だけで (というか Linux マシンが二台もあるデザインオフィスも珍しいかも)、しかも FDD はついていません。 Kondara の IRC で USB フロッピーディスクドライブのデバイス名が /dev/sda だと教わり、急遽 grub のブートディスクを作りました。

さて、私は自分の管理する「サーバ」では、基本的に毎日別のディスクに「そのまんま」のバックアップを取ることにしています。なので、こういう事態がおきても、基本的には grub のブートディスクでバックアップのディスクから起動したら、前日の状態のシステムで起動しますので、あとは起動してからのんびり rsync でユーザのホームディレクトリを '-u, --update update only (don't overwrite newer files)' つきで戻せばサービス復旧です。

ここで大事なのは、「そのまんま」のバックアップを取っておくということです。pdumpfs などの世代バックアップももちろん魅力的なのですが、いざ壊れたときにできるだけ早く復旧するためには、そのまんま起動できる (ほとんど) 同じ状態のシステムが不可欠です。 もう一つ重要なのは、メールのスプールに Maildir 形式を用いていることです。 これですと、メール一つあたりファイル一つですので、rsync -au でユーザのホームディレクトリを書き戻すときに、障害前に削除したメールが復活することはあっても、上書きされてなくなってしまうようなことはありません。 実際、この Maildir 形式のメリットには、今回も含めて何度か助けられました。

具体的には、/opt 以下にバックアップパーティションを構築して、そこにバックアップします。私は全く同じサイズ・ジオメトリの HDD を用意して、パーティションの切り方も全く同じにしています。以下に私のバックアップスクリプト /etc/cron.daily/backup を引用しておきます。

#!/bin/sh
 
# partitions that are not included in / partition
PARTITIONS='boot home var'
 
# force checksum mode once a week
if [ `date '+%w'` = 0 ]; then
  RSYNC_OPT='-c'
fi
 
# mount backup partision
if ! grep -q '/opt ' /etc/mtab > /dev/null; then
    mount /opt || exit 1
fi
 
# backup / partition
nice rsync -a --delete ${RSYNC_OPT} \
  --exclude=/proc \
  --exclude=/opt \
  --exclude=/etc/fstab \
  --exclude=/etc/cron.daily/backup \
  `for i in ${PARTITIONS}; do echo -n "--exclude=/${i} "; done` \
  / /opt/
 
# backup other partitions
for i in ${PARTITIONS}; do
  mkdir -p /opt/${i} # just for the first time
  if ! grep -q "/opt/${i} " /etc/mtab > /dev/null; then
    mount /opt/${i} || exit 1
  fi
  nice rsync -a --delete ${RSYNC_OPT} /${i} /opt/
  umount /opt/${i}
done
 
umount /opt
exit 0

元のディスクで起動する時とバックアップディスクで起動する時とでは、/etc/fstab は当然別であるべきでしょうから、除外していますので、最初にバックアップを取ったときに、必ずしかるべき /etc/fstab をバックアップディスクの方に作る必要があります。 あと、バックアップディスクで運用している時にうっかりバックアップスクリプトが作動して元のディスクを上書きしてしまうと、原因究明や復旧に支障をきたすことが想像されますので、それもバックアップしないようにしてあります。

RAID のように障害が起きにくくする工夫も大切ですが、起きてしまったときに早期に復旧するための工夫も大切です。本当はさらにもう一台ディスクを用意して一日毎に別のディスクにバックアップできればよりよいと思います。 なお、上記のようなバックアップを取っていても、それこそ CPU が火を噴いたりしたら意味がありませんので、定期的にシステムのバックアップを別の場所に保管しておくことももちろん大切ですね。 というわけで、早速 DVD-RAM にバックアップして家に持って帰っておくことにします。

[追記] 上記のスクリプトで末尾の '\' が抜けている行があったので修正しました。 あと、たしかに「RAID が障害を起きにくくする」というのはちょっと違いますね。サービスが止まりにくくするというつもりでした。言葉足らずでごめんなさい。

本日のツッコミ(全1件) [ツッコミを入れる]
_ UmaShika (2002-03-19 01:56)

RAIDは、障害を起きにくくするものではなく、障害の被害を少なくする機構かと。(冗長性、可用性などなど)

[]