これも過去記事の焼き直しです。
サーバーのバックアップにいくつかの方法がありますよね。
ファイルをFTPで待避しておくところから始まり、定期的に圧縮して保存しておくとか。
でもいつでもサーバーが稼働できるようにしておく方法って結構面倒なんですよね。
私はというと、運用開始の2002年〜2004年暮までは、ミラーマシンを運用していました。
ミラーってかなり有効ですよ。どうせ３千円くらいのサーバーだから複数台用意しておいてそえｒをミラーリングしておけばいつでも故障時に切替えられるってーもんです。
現にそうやって故障時にも１〜２分のうちには何事もなく切替えてきたという事がそうですね・・・５回くらいあったでしょうか。
さすがに個人でそこまでやんなくてもいいんじゃない？って自問しておりましたので、そのあとはHDDをハードでRAID-1のミラーにして省略しておりますが。HDDが壊れる以外は想定して無いわけです。それはそうとして、ミラーリングの実施記録についてその当時の記事を以下に持ってきました。
この頃は Turbo Linux Server 6.5 から Turbo Linux 7 Server へのミラーだったのでコマンドが若干異なる訳ですが、それも記事に織り込んでいます。
rsyncという転送コマンドを使ってミラーを使う手順です。crontabに登録すれば数分後とのミラーリングなんてのも可能です。
ではどうぞ。

バックアップ：MYサーバーのバックアップ

BBSなどでも話題が上がっていたので書いていますがバックアップについて真剣に考え始めました。
といっても、元来、HDDが消耗品だという確信を持っているので、故障はHDDがNo1、これは確実。
だから、例えばいつも使っているWindowsのさまざまなデータは、必ず、２箇所のマシンに保存していて、許されるなら３箇所への分散、さらに業務に関する場合は日ごとに分けて１０日間の履歴バックアップと、１ヶ月前、２ヶ月前のデータはいつでも取り出せるように、保存しています。しかもテープでは取り出せない事があるのですべてをHDDで管理しています。WindowsではMS-DOSのバッチで行っております。

さて、MYサーバはというと、当初は作りなおせばいい、そう思っていました。
それは、FTPの送る元ファイルがあれば、ある程度は復活できる、と思っていたのですが、やっぱりBBSにて頂いた意見やメールデータなどのバックアップ、運用の連続性を重視しなくてはなりません。義務感というより、切断してはいけない、故障しても行けないそんな気がしてきます。
そろそろ本格的に対策を立てないとダメですね。とりあえずですが電源にはは簡易的にUPSをいれておき故障を防ぐ為の第一歩を踏み出しています。

さて、昨日までのバックアップはというと全くやってなかった訳ではありません。
スクリプトを

#!/bin/sh
rm /tmp/backup.home.tar.gz
tar cpzf /tmp/backup.home.tar.gz /home

こう書いて、WWWとメールスプールのある/homeだけは自動にcronで取っていました。朝６時に実行させて、これをFTPでWindows側に取り出していました。
あくまで簡易バックアップです。
これで、いざ、壊れた場合には、OSのインストールをして復帰作業を終えたら保存したものを解凍してあげなければなりません。ちょっと手間がかかりますね。

故障と言っても考えられる要因は、HDDの故障、ＰＣ本体の故障、いろいろありますので、対策を複雑にしてくれます。

ちょっと整理してみます。

重要度１　：　HDDの故障
この場合、RAIDといってデータを分散して保存する方法が有効です。RAID-1か5が有効でデータを複数のHDDに分散させて、１台の故障には影響されないようにします。これがベストです。RAID-1はミラーといって２台のHDDに同じ内容のものが書込まれます。逆にRAID-0という似て非なるものがありますが、これはデータを単に２台に分散しているだけで内容が切り分けられて復帰の手助けにはなりませんのでお間違え無く。RAID-5は３台以上のHDDにデータが分散して書込まれますが、どのドライブのデータも他のものを寄せ集めると造り出せるという情報の分け方です。１台分のデータは常に別のHDDが持っているという安全性があり、１台分は保存データの為に消費されてしまいますが、復帰や再構築がとても楽です。
そのRAIDはハードウェアが管理してくれるものとソフト（OS）がやってくれるものがあります。OSのソフトレイドの場合は復旧作業は簡単ですが、HDDを入れ換えて再度RAIDを組みなおそうとすると、構成をよく考えてセットしなくてはならずまたOSもセットするのにちょっと手間取ります。こういう保守は忘れた頃にしかやらないので、できたら簡単な方が良いのです。だからあまり良いとは言えないかもしれません、また、当然CPUの資源を使います。
ハードレイドの場合は文字どおりハードがやってくれるので復旧と再構成がとっても楽です。（ただBIOSレベルでの復帰作業になるので英語の画面が多少読めなくてはいけません）。ときどき「同じ容量のドライブが必要なので調達が難しい」との意見も見られますが、その様な事はありません。大きいドライブを付けてあげれば大丈夫、小さい容量のものに合わせて復帰できます。できればこの方法を採用しておきたいところです、が、このカードをOSが対応しているかどうか？　　Turbo Linux Server 6.5ではサポートされるRAIDカードが無いまたは少なく、それが手に入らない、又は非常に高価であります。MYサーバーはTurbo6.5までしか動作できない状態で結局RAIDは採用できません。
そうすると、あとは、HDD丸ごとコピーする方法、Symantec Norton Ghost などはFDDから起動させユーティリティでBOOTエリアごとクローンを作る方法がとれます。でもいったん停止させて、HDDを２台並べて（master & slaveなど）コピーするのを考えるとちょっと躊躇してしまいます。
という訳で、部分的に必要なところをコピーをとっておく方法しか選択できない様です。

重要度その次　：　サーバーＰＣの故障
私も数年に渡る２桁の中盤になろうというＰＣの台数の管理経験でも、自然故障はあまり経験がありません。ただ、ほこりがたまってくると、湿度でやられます。
この場合ドライブの制御回路が故障したのでなければHDDは生きている事になります。ドライブを別のマシンに移すことで使える可能性、それが同じマシン構成の場合だけ。M/Bのチップ、LANカードのチップ、これらの違いをLinuxが吸収してドライバを差し替えられなければ動作できません。
余談ですがWindowsではXP以前はIntel以外のチップセット（CPUではありません、M/Bの主要回路で、今ではIntelかVIAがほとんどです）はデフォルトで動作してくれなかったのでM/Bの入れ換えは各種ドライバの調達が大変でした。でもXPからはVIAのチップセットにも対応していて比較的簡単にM/Bの入れ換えに対応してくれたりします。LinuxではPlug & Playでドライバが入れ代わらないはずですので、できるだけ全く同じPCを調達しておきたいところです。

以上の考えのもと、対策を考えました。

プラン
　その１　HDDが死んだ時を考えて、サーバーそのものの影武者を立てる。
　　　　　 独立して動作させておくが、設定や情報はミラーリングとする
　その２　ＰＣそのものが死んだ時は、影武者にが代行する。が、
　　　　　影武者も完全にデビュー体制でいられるかわからない。
　　　　　まずはもとのHDDを生かすために影武者は同じ構成のＰＣを準備しておく。
　　　　　ダメなら影武者が代行。
　その３　影武者も完璧に動作しないときは、作りなおす。
　　　　　データはオリジナルHDDまたは影武者のHDDから取得。
　補足　ミラーリング操作は手動。影武者は常時起動させない。節約のため。
　　　　　
では実際の手順です。

●対策その１
同じマシンを用意します。
現在、MYサーバは
　DELL OptiPlex Gn MMX133 430チップセット。NICは3Com。
同じ仕様のものを揃えれば良いのです。そこで購入したのは
　DELL OptiPlex Gx MMX 166 NICは3Comで同じ。
　チップは430かどうか今はまだ未チェックですが年代的に他のチップはありません。
これで本体の故障の場合にHDDの載せかえだけで動くはずという状態を確保しました。
実は今の時点で３台めを手配中です。

●対策その２
さて、今度はHDDの故障の為に、稼動可能なバックアップを作らなくてはなりません。
Linuxが稼動するマシンを作って、ミラーリングしてみることにします。

マシンは、先のDELL Gxでいきます。
そうすれば本体故障の時のHDD入れ換え用、及びHDD故障時の身代わりとして一石二鳥です。

では身代わりマシンの手配を長々と説明することにいたします。

(1)初代MYサーバーと同じ様にTurboLinuxServer6.5をインストールします。
（せっかくだから７を入れてみましたが、よく考えると、/etc以下をミラーした時に支障が出るので6.5に戻しました）
(2)インストール時に同じアドレスは使えません。転送できないからです。だから
　　　オリジナル　10.0.0.100
　　　影武者 　 10.0.0.101
　　　自宅サーバーは１ＩＰの為ルータの設定だけで切替えられます。
(3) telnetが使えるユーザーを作成ました。のこりはミラーで実施するので大丈夫です。
(4)telnetを起動させます。
(5)telnetが使えたらあとはqmailをインストールさせます。
　qmaiは/varを転送させるだけで大丈夫だと思いますが、ユーティリティのrelay-ctrlなどはインストールする必要があります。従って、qmailだけは真面目に最初からインストールさせておきました。
　qmailのインストール全体は別記事を参照してね。
　手順の中に出てくるFTPなどでgetしてくる手順はすでに取り込んであるのでオリジナルからもってきます。
　持ってくる手順はミラーする手順をそのまま使います。
　フライングになりますがオリジナルの「MYサーバー」から転送する手順はこんな感じです。必要なものを/tmpあたりに置いておいて
　　/tmpをコピーする場合
　　　　　rsync -avz -e ssh /tmp/ 10.0.0.101:/tmp
　　あと起動スクリプトも
　　/etc/rc.d/init.d/qmailの３つのスクリプトをコピー
　　　　　rsync -avz -e ssh /etc/rc.d/init.d/qmail*　10.0.0.101:/etc/rc.d/init.d/
　　/etc/rc.d/init.d/qmailの３つのスクリプトのシンボリックをコピー（番号にあわせて）
　　　　　rsync -avz -e ssh /etc/rc.d/rc3.d/Sxxxx　10.0.0.101:/etc/rc.d/rc3.d/
　　この -e ssh　というオプションがsshを使って転送する設定です。が、、、、、このままでは実行できないのでした。
　sshは相手のホストに対するリモートシェルであり、ログインしなければなりません。ここで起動させるとパスワードを聞いてきますが、rootではログインできません。それはServerパッケージなのでデフォルトでrootのログインを制限しているからです。だからパスワードを入れると Permission denied, please try again.というエラーが出ます。影武者はLAN内でしかパケットを受信できないので安全であるという前提があります。だから
/etc/ssh/sshd_config で
　PermitRootLogin no
を
　PermitRootLogin yes
にして、/etc/rc.d/init.d/sshd restart
でrootのログインを可能にしてあげます。あくまで影武者だけです。影武者がデビューする時にはこれを止めておかないと危険過ぎるのでちゃんと覚えておくことにします。
(6)qmail用にtcpserverのインストール、pop before smtpのインストール、これも別紙よりインストールしておきます。
(7)インストールが終わるとサーバーはセット完了であります。通常に動作しています。
但し、この時点ではＤＮＳが本稼動させるわけにはいきません。
だからメールの配信テストはローカルだけしか出来ません。

このあとのミラーリングは　rsync　を利用して行うことにします。結構便利なコマンドです。すでにqmailの関連ファイルを移すのに使いましたが、ほんとはここからがその手順です。
転送そのものはrshかsshを利用できる様ですがsshで転送させる事にします。
(8)rsh と rsyncの確認
　which rsh
　which rsync
の２つの確認でインストールされている事をみておきます。

「注意」
上のところで書いたことと繰返しになりますが、
いざrsync と sshで転送させようとすると、相手先（バックアップサーバー）へのログインパスワードを聞いてきます。これは当然です。ログインしようとするとルートでのログインがはねられますPermission denied, please try again.という表示。サーバー仕様なので（telmetなども同じで）rootでのログインが禁じられているのであります。
ではユーザーアカウントでコマンドを実行すると？これもダメ。ファイルの所有者がちゃんと移りません。
そこでrootでのログインの許可を付けてあげますが、影武者はこの時点ではinternetからのパケットを受信出来ない状態であるという限定の条件があるので、それを可能に出来ます。

影武者の方の
/etc/ssh/sshd_config で
　PermitRootLogin no
を
　PermitRootLogin yes
にかえてから/etc/rc.d/init.d/sshd restartさせることでこれは大丈夫になります。危険なので影武者が本運用になったらこれを止めてあげるのを忘れない事にして、ＯＫです。

これで rsyncが使える準備が整いました。次のスクリプトを作ってオリジナルサーバーから実施します。

#!/bin/sh
rsync -avz -e ssh --delete /tmp/ 10.0.0.101:/tmp
rsync -avz -e ssh --delete /home/ 10.0.0.101:/home
rsync -avz -e ssh --delete /var/ 10.0.0.101:/var
rsync -avz -e ssh --exclude ifcfg* --exclude sshd_config --delete /etc/ 10.0.0.101:/etc

-a : -rlptgoDという意味(r:サブディレクトリ対象、 l:シンボリックもそのまま、p:パーミッションをそのまま、t:タイムスタンプそのまま、g:グループ属性そのまま、o:所有者そのまま、D:デバイスファイルをそのまま)
-v : 同期中ファイル表示
-z : 圧縮をします
-e ssh: sshを指定
--delete : 元ファイルが消されていたら、先のファイルを消す
--exclude xxxx : xxxxの条件のものは対象外
最後の行の --exclude ifcfg* ですが、マシン特有のネットワーク情報　/etc/sysconfig/network-scripts/ifcfg-eth0 などなどが上書きされないようにしておます。上書きすると同じIPになって、メインとの競合によりアクセス不能になります。
で、もう一つ列挙して --exclude sshd_config と書いてあります。列挙していいのかどうか書いてありませんのでわからないのですが、ためしに列挙したらちゃんと両方読んでくれていますので使っています。この意味は/etc/sshd/sshd_confでrootログインがメインサーバーの情報で書き換えされてnoになってしまい、起動しなおすごとにログインできなくなるのを防ぐためです。

これはcronで自動実行することはしていません。それは、あくまで影武者であるＰＣはバックアップ以外には使うことが無いので常時稼動している必要が無いからです。
で、一行ごとにパスワードを聞いてきますが、今はその都度入れています。
事項目でこの対策をとりますが、いまはちょっとわずらわしいです。

本当は、日常的にバックアップを取るのは次の/homeだけで大丈夫です。
メールスプールとWEBのあるのは/homeなので。
rsync -avz -e ssh --delete /home/ 10.0.0.101:/home

バックアップ：rsyncのパスワードを無くす

上のミラー項目でrsyncによるファイル転送を説明しましたが、そのコマンドが出てくるごとに相手先のログインパスワードを聞いてきます。これは非常にわずらわしい事です。
だからこれを解決します。
この件でいろいろなサイトの方の設定事例を参考にさせて頂こうと思ったのですが、みさなんいろいろな運用条件のもと、それぞれに合わせたアプローチで対策をたてていらっしゃいまして、正直なところどういう方法がベストというか王道なのか、ちょっとわかりませんでした。結果として自分の条件でうまく動作した手順を記載いたします。

※2002.7.3 追記
TL7Sどうしで上記をやろうとするとなぜだかパスフレーズが省略できない。
そして、TCS6.5においても一通りのアップデートをかけたらパスフレーズが省略出来なくなった。
それらの理由と対策はこうだ。
sshのprotocol virsionにおいてTLS6.5以降では2を標準にしているらしい。（でも6.5の時は１だった気がする）。
/etc/ssh/sshd_conf に Protocol 2,1という風に優先順序が記載されているので確認できる。
で、最初に記載した記事はすべてprotocol virsion 1を対象にしてある。
virsion 2を使う場合には次のところを読み替えれば対応できる。

というわけで赤い字でカッコに入れたのがviesion2です。

＊＊＊あくまで受けとり側がインターネットに公開されていない状態での接続許可ですので、公開サーバーではrootでのログイン許可は絶対にしないで下さい。＊＊＊

最初にログインする方のサーバーで
ssh-keygen
を実行します。初めての場合は yes/no を聞いてくるので yesを返します。次からは以下の通り。
※但し、目的はrootでの設定です。が、すでにルートの設定は済ませてしまったのでログを取る為に再度実施したくありません。そこで例としてuser1というユーザーで実施する状況を書きます。
[user1@ns user1]$ssh-keygen ( ssh-keygen -t dsa )
Generating RSA keys: Key generation complete.
Enter file in which to save the key (/home/user1/.ssh/identity): <----場所を指定するのでそのままenter
/home/user1/.ssh/identity already exists.
Enter passphrase (empty for no passphrase):<----パスフレーズはそのままenter。これにより入力操作を省く
Enter same passphrase again:<----そのままenter
Your identification has been saved in /home/user1/.ssh/identity.
Your public key has been saved in /home/user1/.ssh/identity.pub.
The key fingerprint is:
51:6e:bc:dc:1e:ac:53:63:a1:0d:f2:95:2c:b6:dd:17 user1@ns.ayamizu.com
[user1@ns user1]$
これで公開鍵・秘密鍵のセットが作成されます。
秘密鍵　：　$HOME/.ssh/identity
公開鍵　：　$HOME/.ssh/identity.pub
この公開鍵の方をログインされるホストの $HOME/.ssh/authorized_keys に、なければ新規に作り、付け加えておきます。
その手順としてscpが良いみたいですね。
$ scp ~/.ssh/identity.pub 10.0.0.101:.　　( scp ~/.ssh/id_dsa 10.0.0.101:. )
相手 10.0.0.101 に移ってから
$ cat identity.pub >> ~/.ssh/authorized_keys ( cat id_dsa.pub >> ~/.ssh/authorized_keys2 )
でセットが動作できるようになります。

これでパスワードを入れずにrsyncは使えるようになりました。TL7SとTLS6.5で使えました。