*リモートバックアップ [#v2cbf32b] ここに書かれたことを実行して、「おいた」にあっても責任は持ちません。あしからず。 **目的:サーバのファイルをバックアップする [#zffcfda3] ネットワークでつながれたサーバをバックアップしたい。 バックアップすべきサーバにはルート権限はない。 バックアップすべきサーバに対してssh、sftp、scpなどは使える。 anonymous ftpディレクトリに置けるようなデータではない。 バックアップデータを保存するサーバのルート権限はある。 というもの。どちらのサーバもLinuxマシン。 **解決方法 [#he9963ab] ssh-agentとkeychainを利用し、cronにより自動でscpする 以下、 -バックアップすべきサーバを「ホスト」 -バックアップデータを保存するサーバを「クライアント」 と表記する。 --------- #contents --------- ** 手順 [#feead4c5] *** クライアントでdsa暗号鍵をつくる [#v57d4fe1] $ cd $ ssh-keygen -t dsa パスフレーズを尋ねられるので、入力する。 なお、下のほうの設定で、--clearオプションでkeychainを起動するようにします。 そうするとログインする度に尋ねられます。 このことも念頭においてパスフレーズを決めるたらいかがでしょう。 これで、「~/.ssh」に id_dsa と id_dsa.pub ができる。 $ ls -l .ssh で確認できる。 *** ホストにdsa暗号鍵をインストールする [#x011e2a6] ホストにログイン $ sftp hohehohe@client.hoge.jp $ get .ssh/id_dsa.pub offsite.pub $ cat offsite.pub >> .ssh/authorized_keys $ chmod 700 .ssh $ chmod 600 .ssh/authorized_keys $ rm offsite.pub ここまでは[[Linuxでのバックアップを自動化する>http://www-06.ibm.com/jp/developerworks/linux/040723/j_l-backup.html]]に 従った。 しかし、これ以降は[[Linuxでのバックアップを自動化する>http://www-06.ibm.com/jp/developerworks/linux/040723/j_l-backup.html]]に 書かれたとおりに実行すると ssh-agentのプロセスが消えなかったりするなどの弊害があるので従わないほうがいい。 *** クライアントに keychain をインストールする(ルート権限が必要) [#z2bb939e] http://www.gentoo.org/proj/en/keychain.xml から、 keychain-2.6.8-1.noarch.rpm をいただく $ su # gpg --keyserver subkeys.pgp.net --recv-key 20104eb0 # gpg --fingerprint 20104eb0 # gpg --export --armor 20104eb0 > /tmp/20104eb0.pub # rpm --import /tmp/20104eb0.pub # rm /tmp/20104eb0.pub # rpm -K keychain-2.6.8-1.noarch.rpm # rpm -Uvh keychain-2.6.8-1.noarch.rpm インストール方法も http://www.gentoo.org/proj/en/keychain.xml に従う *** クライアントで ssh-agent、keychain が動くように設定する [#c89835d2] .bash_profile に以下を追加する # .bash_profile 〜〜 略 〜〜 /usr/bin/keychain --clear ~/.ssh/id_dsa source ~/.keychain/$HOSTNAME-sh source ~/.bashrc ポイント - ''--clear''を入れておく。これによりログインのときに私有鍵がフラッシュされる。[ログアウトのときには私有鍵はフラッシュされないので、cronは動いているssh-agentを使ってリモートホストにログインできる] -''--clear''がないと、そのユーザとしてログインすれば、リモートホストに自由に入れてしまうので、セキュリティ上あまりよろしくない。パスフレーズを知らなくてもssh-agentが知っているから。[とはいえ、ログアウトしてもssh-agentは動き続けているので安全じゃなかろうという批判もできる] -下の紹介記事では、~/.keychain/$HOSTNAME-sh ではなく、~/.ssh-agentとなっているのですが、今回インストールしたkeychainは違うようです[このために時間がかかってしまった……] [[共通テーマ: OpenSSHキー(鍵)の管理 第2回>http://www-06.ibm.com/jp/developerworks/linux/011130/j_l-keyc2.html]] を参考にした。 こんな批判的な記事[[〇〇とssh-agentは使いよう>http://www.vicus-oryzae.com/gorua/agent.html]]もあります *** 一度ログインしなおす [#iec03f8f] ログインしたあとにパスフレーズが尋ねられるので、答える - これで、ssh-agentが動き、プロセスIDなどが./keychain/$HOSTNAME-sh に記録される - ログインするたびにパスフレーズを尋ねられる(''--clear''オプションのため)のでわずらわしいのですが(パスワードがふたつに増えた気分になる……)、仕方がないとあきらめる なお、これで、リモートホストにログインせずに入れます たとえば $ ssh -l hogehoge host.hoge.jp であっという間にホストの中 *** ホストからファイルを scp によりクライアント上に複製するバックアップスクリプトをつくる [#e0b3431b] これはお好みで。たとえば、こんな感じのスクリプト(backup.sh)をつくる。 #!/bin/sh source /home/hohehohe/.keychain/$HOSTNAME-sh cd /home/hohehohe scp -r hogehoge@host.hoge.jp:backup ./ cd /home/hohehohe/backup/kyoto find ./ -type f -mtime '+14' -exec rm -f {} \; $ chomod 700 backup.sh ポイント - ''source ~/.keychain/$HOSTNAME-sh'' を入れる。 入れておかないと、cronから起動されたプロセスがちゃんとssh-agentを使えない(パスフレーズがわからん、という。プロセスIDがわからないとcronはssh-agentを使えない) 念のためのbackup.shの説明 - ホストの''~/backup''ディレクトリをそっくり、クライアントのホームディレクトリにコピー - ''~/backup/kyoto''にコピーしたファイルのうち、14日以上古いものを削除 --[[ある日付より以前に作成されたファイルを削除したい>http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=33090&forum=10]] を参考にした *** クライアント上でバックアップスクリプトをcronで定期的に動かす [#q6e63584] $ crontab -e 下のように書く 24 1 * * * /home/hohehohe/backup.sh 確認は $ crontab -l - 毎日1時24分に、''backup.sh''が動く RIGHT:13 December 2006 ** 追記 [#m8f515ff] - マシンをリスタートすると、(考えてみれば当然なのですが)./keychain/$HOSTNAME-sh にはプロセスIDなどが記録されていません。そこで、ログインしないでいると、サーバのファイルをバックアップすることができません。リモートサーバにログインできなくなってしまうためです。停電などでマシンがリスタートするような事態になったときは、ログインをお忘れなく。 RIGHT:18 July 2007 |Today:&counter(today); |Yesterday:&counter(yesterday); |Total:&counter(); since 13 December 2006|