rsyncのリスクについて

2015年8月28日

コマンド サーバー テクノロジー トラブル

サーバー管理をしていると運用管理と同時にバックアップ管理も行うケースが一般的です。 もちろん仕事の形態により、作業分割される場合もあるが、サーバーを管理する側としても、作業時にミスがあった時にリカバリできるバックアップがあるととても安心できます。 そんなわけで、みんなが安心できるバックアップ環境を構築する為に「rsync」コマンドは欠かせません。 ちなみに、今回の記事は当然ながらWindowsサーバーは対象外なので、あしからず。

rsyncのメリット

市販のアプリケーションなどでバックアップをとってももちろんOKなのですが、WEBコンテンツや特定のログデータ、 動的データなど、さまざまな細かい箇所まで手が届くrsyncを使ってcronでバッチ処理を組み上げた方が、 作業効率も早く、柔軟性もあるので、こういった思考の管理者も多いのではないでしょうか? なにより、市販アプリは有料という場合もあるので、無料でできるrsyncは、知ってさえいれば、 タダで、かなり複雑なことが可能になるという、エンジニア必見の機能なのです。

rsyncのデメリット

もちろん、rsyncを使うからといってメリットばかりではありません。 以下の様なデメリットもあるので、熟知するようにしましょう。
・そもそもcronやらrsyncというものが分からないと使用できない。 ・bashレベルで最低1行でもプログラムをしなければいけない。(cronに直書きしてもいいですが、オススメできません) ・オプションの使い方を熟知していないと、意図していない不具合に見舞われる。

基本的な考え方

rsyncは本番データをバックアップ領域にコピーすることを前提としたツールであり、オプション設定を行うことで コピー後に削除をしたりするようなプログラムで行うとかなり面倒くさい事を一発で行うことが可能になります。 また、プライマリサーバーとセカンダリサーバー構成のような場合に、セカンダリにミラーリングを行うという使い方も よく使われる手段の為、サーバー構成の構築における注意点や、オプション機能の動作の注意点はよく理解しておきましょう。

トラブルあれこれ

--deleteオプション

--deleteオプションで泣かない為に このブログでも紹介されている通り、ミラーリング構成の際によく発生するトラブルで、
プライマリ ---> セカンダリ
という構成の時に、データやプログラム更新をプライマリのみで行う場合は問題ないのですが、セカンダリで更新が入ったり、 作業トラブルにより、セカンダリファイルのパスが変わったりした時に、--deleteオプションをつけていたプライマリのデータは 消されてしまいます。 基本的には、このオプションは使わないに越したことがないのですが、ミラーリングを行う際には、サイトの特性や データが消えないような構成を必ず考えましょう。

--remove-source-files

このオプションは、syslogなどのログデータをバックアップサーバーなどに移動させる時に使う場合が多く、 正常に移動できた場合に、元データを削除してくれるので、その後、サーバー間で、データの存在確認をして 削除するようなバッチを作る必要がない便利なオプションです。 が、 実は、頭の悪い動きを見つけてしまいました。 それは、バックアップ先を同一フォルダにした場合に、データが消されてしまうという事です。 おそらくこのオプションの動きとして
  1. バックアップ先にデータをコピー(同一データがあればコピーしない)
  2. バックアップ完了後に、元データを削除
この動作の時に、同一ファイルだったら・・・という判定が入っていないので、問い合わせもなく消されます。

必ずしも更新日付が最新のものが対象ではない

rsyncは更新日を無視して内容確認だけ行う--checksumオプションがありますが、 通常の-aオプションだけで、行なった場合に、rsyncは最新版という判断をしている訳ではなく、 元データ -> 対象先データ という風にデータ比較して、更新日付が違っていれば・・・ という判定を行なっているようです。 なので、必ず元データに更新が入るという構成の場合であれば問題ないのですが、バランシングサーバーなどを バックアップする場合に、同一ファイル名が存在するという事があれば要注意です。

安全性の確保の為に

管理者として安全性を追求するという事であれば、メインバックアップと運用系バックアップを用意することをオススメします。 バックアップをテープデバイスで行なっている場合は、テープ運用という作業が発生しますが、最近ではHDD単価の方が安いしテープはリカバリを行えるスピードではないため、最近の大容量データには向かないでしょう。 そしてHDDバックアップの場合は、HW故障という観点から、RAID、2箇所異常のバックアップという構成がオススメですが、 これも大規模データになるととてもリッチ構成な環境になってしまいます。 少なくとも、元データが削除されてしまっては、作り出す方法があれば別ですが、取り返しの付かない状態になってしまうことは間違いありません。 一旦何でも入れのような状態に全てのデータが放り込まれるような状態を作って管理するという事も悪くないかもしれませんね。 それか、HDDを保存しているが、まさかの時用に、テープ保存をするという事も悪いことではないかもしれませんね。 とりあえず、最悪の事態にそなえる努力をしましょう。

人気の投稿

このブログを検索

ごあいさつ

このWebサイトは、独自思考で我が道を行くユゲタの少し尖った思考のTechブログです。 毎日興味がどんどん切り替わるので、テーマはマルチになっています。 もしかしたらアイデアに困っている人の助けになるかもしれません。

ブログ アーカイブ