Rsyncによるデータバックアップ

少し前からバックアップをしないとまずいなと思っている矢先に、現用機が再インストールするような事態に追い込まれてしまいました。幸いにもバックアップテストをしていたので、前日のHPのデータはバックアップできていたので、つなぎで運用を維持できました。ということで、備えあれば憂いなしということで、rsyncでデータのバックアップをすることにしました。RAIDを使ったり、CPUや電源を二重化したりしてサーバ機自体を高信頼化する方法もありますが、ホットスワップ等を考えるとかなりの費用がかかるのと、当然維持費(電気代)も高くなります。また、壊れるのはHDDやCPU、メモリだけとは限らず、奥さんパソコンで経験したようなマザーボード障害となると、簡単には復旧できません。

従って、障害時にとりあえずサーバを復旧させ、時間があるときにサーバを復旧できるよう、他のパソコン(奥さんのパソコン)にLinuxを入れ、不定期ですがデータをバックアップすることにしました。LinuxのインストールについてはWindowsとのデュアルブートも考えたのですが、奥さんが戸惑うとまずいので、リムーバルHDD化してHDD交換でWindowsと切り替えるようにしています。このパソコンは、いろいろなソフトの現用機導入前の検証用にも使っています。

■しかくバックアップポリシー

障害時、サーバの停止期間をなるべく短くするため、以下のような運用方法を前提としました。

現用サーバが不調になったとき、直ちにバックアップ機で代替運用できるよう、可変データをバックアップする。
バックアップ機は常時稼動ではないため、不定期になるべく簡便な方法でデータをバックアップしないと、なかなかバックアップできない(しなくなる)ので、バックアップ機を稼動させるだけで、必要なファイルを一気にバックアップできるようにする。
障害復旧を迅速にできるよう、各デーモンのconfigファイル等もバックアップしておき、システム修復後にバックアップ戻しで復旧できるように考慮する。但し、バックアップ機は検証にも使うため、それ自体サーバとして機能させる必要があり、アドレスやホスト名がおかしくなるので、config関係のデッドコピーは行わない。
バックアップ機への切り替えは、ルータのポートフォワーディング(静的マスカレード)でサーバのアドレスを変更することで対応する。フィルタの見直しや設定の書き換え方法(BA8000 Proでは設定の保存と戻しができるので、これを利用して一気に書き換える手もある)を別途検討する。

◆だいやまーく何故rsyncか?

データをバックアップするには、tar、dd、ftp等、いろいろな方法がありますが、

rsyncは差分バックアップができるため、初回は時間がかかるが、以降は高速なバックアップが可能。(面倒くさがらずにバックックアップするためには所要時間が短いことは重要。)
オプション指定により、パーミッション・オーナ・タイムスタンプなどの情報を継承可能。(復旧戻しを考えると、これも重要な要件。)
自動化が可能。(これは、当然。)

なことから、rsyncを使用することにしました。

◆だいやまーくrsyncの基本的な使い方

rsyncの基本的な使い方は、下記のとおりです。使い方の詳しい情報は検索で探せばいくらでもありますので、ここでは省略します。

rsync オプション [ホスト名:]コピー元ファイル/ディレクトリ名 [ホスト名:]コピー先ファイル/ディレクトリ名

下記は、現用サーバ機でおやじのWebコンテンツをバックアップ機にデッドコピーする場合の例です。

rsync -avz -e ssh /home/oyaji/public_html/ backup.aconus.com:/home/oyaji/public_html/

-avzオプションで、

a: アーカイブモードでディレクトリ内のファイルやディレクトリを、シンボリックリンク・パーミッション・オーナ・タイムスタンプを保持したままバックアップ。
v: バックアップ時にファイル名を表示。
z: データを圧縮して転送。

するようにし、-e sshでsshによる暗号化転送を使用するように指定しています。

オプションとして --delete を指定すると、コピー元にないファイルはコピー先で削除されます。おやじは、よくミスをするので --delete は使わないようにしています。その典型例が、ディレクトリ指定の際の最後に「/」があるかないかによる動作の相違です。この「/」の入力を忘れ、いろいろトラぶったので注意が必要です。

具体的には、上記の例でコピー元の最後の/をつけ忘れると、コピー先で指定したディレクトリの下にpublic_htmlというフォルダが作成されその配下にファイルがコピーされます。

コピー元:/home/oyaji/public_html/a,b,c・・・
コピー先:/home/oyaji/public_html/public_html/a,b,c・・・

ここで、--deleteオプションが指定してあると、コピー先のpublic_html配下に元々あったファイルが削除され、そこにpublic_htmlディレクトリ以下が新規に作成されてしまうので、気が付いた時には手遅れです。

■しかくバックアップの自動化

バックアップの自動化といっても、おやじの環境ではバックアップ機が常時動作しているわけではないので、バックアップの省力化というのが正しいかもしれません。

上記のrsyncの使い方は、現用サーバ機の操作でバックアップ機にデータをコピーするものですが、おやじはバックアップ機を立ち上げるだけでバックアップができるようにしたかったので、バックアップ機から現用機にデータを取りに行く形態としました。このような通信形態にすると、現用サーバ側からクライアントゾーンへのsshアクセスを開放しなくてもいいため、セキュリティ上も効果があります。

rsyncをsshで使うとコマンド入力の度にsshのパスワードの入力を要求されるので、このままでは連続的なファイルのバックアップは難しいので、パスワード入力を省略する方法で対応することにしました。

パスワード入力を省略する方法はいくつかあるようで、公開鍵認証で行う方法やrootの鍵を空にして、PermitRootLogin fourced-command-onlyとして予め決められたコマンド以外実行できないようにする方法があったのですが、前者は自動化が面倒であり、後者はいろいろなディレクトリやファイルをバックアップするのには向かないため、今回はホストベース認証で予めパスワード無しでのログインを許可するホスト名とユーザ名を、リモートホスト(おやじのバックアップ方法では現用サーバ機)の~/.shostsに登録しておく方法を採用しました。

◆だいやまーく現用サーバ機での設定

まず、/etc/ssh/sshd_configの設定を下記のように変更します。ここでは、今回の使用方法に関係する部分とデフォルトから修正したもの(赤字)だけを上げています。

# rootでのログインを許容
PermitRootLogin yes
# RSAバージョン1での認証は不許可
RSAAuthentication ~~(削除) yes (削除ここまで)~~ no
# 公開鍵による認証を不許可
PubkeyAuthentication ~~(削除) yes (削除ここまで)~~ no
# rhosts認証は不許可
RhostsAuthentication no
# ~/.shostsを有効とする
IgnoreRhosts ~~(削除) yes (削除ここまで)~~ no
# SSH1 プロトコル認証は不許可
RhostsRSAAuthentication no
# hostbased認証を許可(SSH2 プロトコル)
HostbasedAuthentication ~~(削除) no (削除ここまで)~~ yes
# パスワード認証は不許可
PasswordAuthentication ~~(削除) yes (削除ここまで)~~ no
# パスワードが設定されていないアカウントは拒否
PermitEmptyPasswords no
# チャレンジレスポンス認証は不許可
ChallengeResponseAuthentication ~~(削除) yes (削除ここまで)~~ no
# PAMチャレンジレスポンス認証は不許可
PAMAuthenticationViaKbdInt ~~(削除) yes (削除ここまで)~~ no

続いて /root/.shosts にログインを許可するホスト名とユーザ名(root)を間をスペースで区切って記述します。

backup.aconus.com root

最後に、known_hosts(/root/.ssh/known_hosts) にログインを許可したホストのホスト鍵を登録します。これは、現用機からバックアップ機へssh でログインすれば、そのときに下記のようにyesと操作すれば登録できます。

# slogin backup.aconus.com
The authenticity of host 'backup.aconus.com (192.168.1.101)' can't be established.
RSA key fingerprint is 3f:c9:28:87:d8:4b:17:0a:ca:55:46:74:36:fb:3f:bb.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'backup.aconus.com,192.168.0.101' (RSA) to the list of known hosts.
root@backup.aconus.com's password: xxxxxx
Last login: Fri May 23 21:30:53 2003 from host.aconus.com

◆だいやまーくバックアップ機での設定

バックアップ機の /etc/ssh/ssh_config を下記のように変更します。ここでは、今回の使用方法に関係する部分とデフォルトから修正したもの(赤字)だけを上げています。

# RSAバージョン1での認証は不許可
RSAAuthentication ~~(削除) yes (削除ここまで)~~ no
# 公開鍵による認証を不許可
PubkeyAuthentication ~~(削除) yes (削除ここまで)~~ no
# rhosts認証は不許可
RhostsAuthentication no
# SSH1 プロトコル認証は不許可
RhostsRSAAuthentication no
# hostbased認証を許可(SSH2 プロトコル)
HostbasedAuthentication yes
# パスワード認証は不許可
PasswordAuthentication ~~(削除) yes (削除ここまで)~~ no
# 認証の優先順位指定(Keyboad入力は不要)
preferredAuthentications hostbased,publickey,password

◆だいやまーく自動バックアップの設定

バックアップ機で、パスワード入力無しでデータがバックアップできるか確認する。先にも述べてように--deleteオプションを使ったり、転送方向を間違えると、現用サーバ機の重要なデータを破壊することにもなりかねないので、ここではtestユーザを作成し、適当なデータを置いてテストする。バックアップ機で以下のようにして、現用機のtestユーザのwebデータがバックアップ機に取り込めるかテストする。テストは、rootで行うこと。

# rsync -avz -e ssh aconus.com:/home/test/public_html/ /home/test/public_html/
上記で、問題なくバックアップできることが確認できたら、いちいちコマンドを入力するわけには行かないので、スクリプトで対象となるディレクトリやファイルをバックアップするように書いて、適当な名前(backup.sh等)で適当なディレクトリ(/usr/local/baim/backup/等)に保存する。
```
#!/bin/sh
#
# backup script
#
# rsync command pass & option
RSYNC='rsync -avz -e ssh'
#
# main host name or IP address
HOST='aconus.com'
#
### End configuration section ###
#
$RSYNC $HOST:/home/oyaji/public_html/ /home/oyaji/public_html/
$RSYNC $HOST:/home/akirin/public_html/ /home/akirin/public_html/
 :
 :
 :
```
ここで、保存したファイルに実行権を与え、連続的にバックアップできるかテストしてみる。

# chmod 700 /usr/local/bin/backup/backup.sh
# /usr/local/bin/backup/backup.sh

コピーされたファイルが出力される。
上記のテストで問題なければ、バックアップ機の立ち上げで自動実行されるようにcrontabに追加しておく。なるべく最新のデータがバックアップできるよう、10分毎にバックアップするようにした。これで、バックアップ機でデバック中も意識することなくバックアップされる。

# vi /etc/crontab
0,10,20,30,40,50 * * * * root /usr/local/bin/backup/backup.sh

Top Pageへ