2007年9月13日木曜日

ネットワークベースのバックアップソフト「Bacula」に深刻なバグ ~ バージョン2.0.x以降は、最新の2.2.3へアップグレードせよ、とのこと

Baculaは、ネットワーク上でクライアント・サーバ方式で動作するバックアップソフトで、何台ものコンピュータのファイルのバックアップを、全自動で、効率的に採ることができます。



私も、だいたい1年前から使い続けているのですが、とってもお世話になっています。一度、操作ミスで、PostgreSQLのデータ全部をふっとばしたときなど、バックアップがあってよかったと、感謝、感謝、でした。



似たような機能を提供する商用ソフトもあわせて使っているのですが、その値段が、もう、なんだこりゃ?!っていうくらいするのに、Baculaは機能面では遜色なく(ユーザーインターフェイスに難あり、という人もいますが、個人的には十分だと判断してます)、それなのに無料で使える。寄付を募っているので、なんかの協力したいとは思いますが。





FreeBSDで、portupgradeコマンドでいろんなソフトウェアをアップグレードしているときに、

おや、ここ数日で、Baculaが連続してバージョンアップしてない?!

と気がつきました。いったい何があったんだろう?と思って、BaculaのWebサイトを見たら、最新バージョンの2.2.3で深刻なバグ(Serious Bug)を修正したとのこと。

・・・そもそも、バージョンが変わって何が変更されているかも確認せずに、portupgradeでバージョンアップしちゃう私も悪くて、いーかげんなわけですが、まあそれはさておき・・・
 (いいのか?!それで)

その深刻なバグというのは、バックアップしたファイルをリストア(バックアップから取り出して復旧させる)できなくなることがある、という不具合だそうです。怖いですねぇ。



詳しい情報は、ここに出てました。Bug #935と呼ばれています。





Bacula-announceメーリングリストのアーカイブが、ここで見られます。





これは、必ず発生するバグではなくて、いくつもの条件が重なったときだけ発生するもので、だからこそ、これまで見つからなかったんだと思われます。バージョン2.2.3へアップグレードしたら、念のため、フルバックアップを実行するように、とのことです。





一応、bug-935.txtを少しだけ読んでみたので、Bug #935についての技術的な詳細を、要約してメモっておきます。



Bug #935の症状は、リストアしたとき、バックアップから取り出せないファイルが多数ある、というもの。



(1) バグが発生するのは、複数のバックアップ・ジョブを同時実行しているときだけ。しかも、ストレージ・デーモン(storage daemon)が、新しいボリュームへ切り替えようとしたときだけ発生する。つまり、複数のジョブが同じボリュームへ書き込んでいて、別の新ボリュームへまたがって書き込まれるときだけ。



(2) ハードディスクにボリュームを作っているときだけ、このバグが観測された。テープの場合は、観測されていない。



(3) ある特定のタイミングでは、おそらく、テープの場合でも発生する可能性はある。



(4) この不具合がおきるのはタイミング依存で、複数のクライアントが存在するとき。しかし、1つのクライアントで、複数のバックアップ・ジョブを同時実行しているなら、同様に発生するはず。



(5) 調査しているときにわかったが、クライアントの動作がのろいとき(インクリメンタル・バックアップをしているとき)に、この不具合が発生する確率が高い。



(6) このバグは、バージョン2.0.xと、2.2.xに存在する。



(7) バージョン1.3.8でも存在すると思われるが、再現できなかった。発生するかどうかは、タイミング依存であり、テスト環境ではfile daemonのバージョンが2.2.2だったせいで、再現できなかったのかもしれない。



(8) データは正しくボリュームへ書き込まれている。ただ、間違ったインデックス(JobMedia)が、データベースに書き込まれてしまっている。ボリュームが切り替わるときのJobMediaに、古いほうのボリュームではなく、新しいほうのボリュームが入っている。詳しくは後述。



(9) この不具合を回避するためには、複数のジョブが同時実行されないようにするか、複数のジョブが同時実行しているときに、新しいへボリュームへまたがらないようにすればよい。つまり、使用中のボリュームのサイズが十分大きくなってきたら、手動で、ボリュームにfullだとマークすればよい。



(10) 複数のジョブを同時実行していない場合は、このバグの影響を受けない。



(11) 複数のジョブを同時実行していて、テープに書き込んでいる場合で、ジョブが、別のテープにまたがるときに、このバグが発生する確率はそれなりにあると思われる。



(12) 複数のジョブを同時実行していて、ディスクに書き込んでいる場合で、ジョブが、別のテープにまたがるときに、このバグが発生する確率は、かなり高いと思われる。



(13) このバグはStorage daemonにのみ存在するので、クライアント(file daemon)をアップデートする必要はない。しかし、storage daemonをアップデートしたら、directorもアップデートすることを推奨する。



===============================



~~~この後、バグについての詳しい解説が書いてあるのですが、長くて、ややっこしいし、難しいので、省略します。興味があれば、bug-935.txtを読んでみてください。バグが発生したときのログメッセージなども示しています。



斜め読みした限りでは、マルチスレッドなプログラムで、グローバル変数の更新を適切に行っていなかった、というバグらしくて、ある特定のタイミングによっては、望ましくない順序で、グローバル変数の更新が行われて、おかしな(矛盾した)結果になってしまう、みたいなもののようです。



並列動作するプログラムを作ったことのある人なら、誰でも経験しそうな、あぁ~いかにもありがち!!っていうバグっぽいですね。



■ 過去記事



(あまり関係ないけど、Baculaについて少し触れています)





0 件のコメント:

コメントを投稿