とりあえず、週 1回は blog を書こうと思ったのもつかの間。
前回からあっという間に 1ヶ月がすぎてしまった。
とりあえず、gmail にログインしたら Buzz という物ができて、
Python についても少しずつ分かってきて、
書きたい事は盛りだくさん。
もうすぐ、東京 Ruby 会議 03 もあるし。
そんな事はさておき、本日は rsync の話。
rsync と言えば、linux の差分バックアップコマンド。
主な特徴は以下
1. ssh を通して、リモートのマシンにもバックアップ (コピー) 可能
2. 以前のバックアップ結果と比較して、新しいファイルのみコピーする事が可能
当然、前回のバックアップ時から消されたファイルを削除する事も出来る
3. Linux のハードリンクを使用することで、複数のバージョンの
バックアップをとっても、更新されていないファイルは HDD 上に 1個だけに
する事が可能
(ディスク容量が少なくて済む)
4. ファイルのバイナリ差分を取ることで、大きいファイルの更新された部分だけ
差分バックアップを取ることが可能
端的に言うと、scp と cp コマンドに差分とハードリンク機能を加えたような物。
詳しい事は、rsync で検索してください。
この 2個の記事なんかが詳しい
▼ はじめてrsyncを使う方が知っておきたい6つのルール
http://www.itmedia.co.jp/enterprise/articles/0804/21/news013.html
▼ rsyncで差分バックアップを行うための「--link-dest」オプション
http://www.itmedia.co.jp/enterprise/articles/0804/25/news034.html
さて、上記の特徴だけ見ると良いことだらけに思えるかもしれない。
実際、悪い評判は聞いたことがない。
でも、私は今までこのコマンドを毛嫌いしていた。
そもそも、rsync を使うのはどんな時だろう。
このコマンドは shell に手入力するような物ではない。
そんな時は、scp と cp だけで十分だ。
では、運用中のサーバーで定期的にバックアップを取る時はどうだろう。
これには、信頼性が低い。
rsync は、しょせん shell のコマンドだ。
サーバーやネットワークに異常があれば、すぐにエラーとなる。
堅牢性のためにはストレージ等のハードウェアの機能や、DRBD のような
信頼性の高い機能を使うべき。
費用面で難しければ、詳細なログを書き出すバックアップスクリプトを
作成すればよい。
信頼性が足りない分、せめて詳細なログを残したい。
バイナリ差分についてはハードルが高いかもしれないが、それ以外は
誰でも十分に実装する事が可能だろう。
要は、rsync とは、バックアップという重要な場面において信頼性と利便性が
中途半端なコマンドと認識していた。
ところが、先日、自分の意思には反しつつも rsync を使用した
shell スクリプトを作成する事があった。
スクリプトを作成したら、その後はテスト。
異常発生時の挙動を調べるため、プロセスを kill したくて
ps コマンドにて rsync のプロセス ID を調べた。
すると、複数の rsync プロセスが存在するではないか。
もちろん、rsync は 1回しか実行していない。
おそらく、バックアップ速度を上げるために fork して複数プロセスが
立ち上がったのだろう。
これは便利。
子プロセスの数をどうやって決定しているのかは知らないが、
ほとんどの場面で、バックアップの速度が上がるだろう。
スクリプトで同様の実装をすることも可能だが、自前で fork をすると
テスト工数が極端に増える。
その点、rsync ならば十分にテストされているはずなので、rsync 自体の
テストは不要だろう。
「rsync の利便性が低い」というのは、実は私の勘違いだったのだ。
やっぱり、世間の評判が高い事にはそれなりの理由が有ったのだ。
あと、信頼性はやっぱり低い。
特定の子プロセスを kill したりすると、失敗した。
差分バックアップは 1 回の失敗がその後の全てのバックアップに
影響与えるので、十分に注意する必要はある。
前回からあっという間に 1ヶ月がすぎてしまった。
とりあえず、gmail にログインしたら Buzz という物ができて、
Python についても少しずつ分かってきて、
書きたい事は盛りだくさん。
もうすぐ、東京 Ruby 会議 03 もあるし。
そんな事はさておき、本日は rsync の話。
rsync と言えば、linux の差分バックアップコマンド。
主な特徴は以下
1. ssh を通して、リモートのマシンにもバックアップ (コピー) 可能
2. 以前のバックアップ結果と比較して、新しいファイルのみコピーする事が可能
当然、前回のバックアップ時から消されたファイルを削除する事も出来る
3. Linux のハードリンクを使用することで、複数のバージョンの
バックアップをとっても、更新されていないファイルは HDD 上に 1個だけに
する事が可能
(ディスク容量が少なくて済む)
4. ファイルのバイナリ差分を取ることで、大きいファイルの更新された部分だけ
差分バックアップを取ることが可能
端的に言うと、scp と cp コマンドに差分とハードリンク機能を加えたような物。
詳しい事は、rsync で検索してください。
この 2個の記事なんかが詳しい
▼ はじめてrsyncを使う方が知っておきたい6つのルール
http://www.itmedia.co.jp/enterprise/articles/0804/21/news013.html
▼ rsyncで差分バックアップを行うための「--link-dest」オプション
http://www.itmedia.co.jp/enterprise/articles/0804/25/news034.html
さて、上記の特徴だけ見ると良いことだらけに思えるかもしれない。
実際、悪い評判は聞いたことがない。
でも、私は今までこのコマンドを毛嫌いしていた。
そもそも、rsync を使うのはどんな時だろう。
このコマンドは shell に手入力するような物ではない。
そんな時は、scp と cp だけで十分だ。
では、運用中のサーバーで定期的にバックアップを取る時はどうだろう。
これには、信頼性が低い。
rsync は、しょせん shell のコマンドだ。
サーバーやネットワークに異常があれば、すぐにエラーとなる。
堅牢性のためにはストレージ等のハードウェアの機能や、DRBD のような
信頼性の高い機能を使うべき。
費用面で難しければ、詳細なログを書き出すバックアップスクリプトを
作成すればよい。
信頼性が足りない分、せめて詳細なログを残したい。
バイナリ差分についてはハードルが高いかもしれないが、それ以外は
誰でも十分に実装する事が可能だろう。
要は、rsync とは、バックアップという重要な場面において信頼性と利便性が
中途半端なコマンドと認識していた。
ところが、先日、自分の意思には反しつつも rsync を使用した
shell スクリプトを作成する事があった。
スクリプトを作成したら、その後はテスト。
異常発生時の挙動を調べるため、プロセスを kill したくて
ps コマンドにて rsync のプロセス ID を調べた。
すると、複数の rsync プロセスが存在するではないか。
もちろん、rsync は 1回しか実行していない。
おそらく、バックアップ速度を上げるために fork して複数プロセスが
立ち上がったのだろう。
これは便利。
子プロセスの数をどうやって決定しているのかは知らないが、
ほとんどの場面で、バックアップの速度が上がるだろう。
スクリプトで同様の実装をすることも可能だが、自前で fork をすると
テスト工数が極端に増える。
その点、rsync ならば十分にテストされているはずなので、rsync 自体の
テストは不要だろう。
「rsync の利便性が低い」というのは、実は私の勘違いだったのだ。
やっぱり、世間の評判が高い事にはそれなりの理由が有ったのだ。
あと、信頼性はやっぱり低い。
特定の子プロセスを kill したりすると、失敗した。
差分バックアップは 1 回の失敗がその後の全てのバックアップに
影響与えるので、十分に注意する必要はある。