CRCの使い方、mysqldumpについて

質問

先日、社内DBのcronによる定期バックアップのデータが圧縮により破損したらしく、
顧客データを数日前まで戻さなくてはいけなくなりました。

私の所属している部署ではなかったのですが、同様の問題が発生するかもしれないので、
cronで毎日取っているバックアップデータをチェックするなどの方法を求められました。
ただ、私は経験もないため何をどうすればいいのか分かりません。
CRCでチェックすればいいのでは？と言われたのでCRCについて調べたのですが、
ググってみたのですが、CRCエラーの対処法や、CRCの解説がほとんどで、実際の使い方が見つかりません。

どのようにすれば、CRCでチェックサムを付加することができるのでしょうか？
付加したデータは専用の通信をするのでしょうか？
scpやrsyncのようなコマンドがあると思っていたのですが、見つかりません…

CRCでやりたいことは以下になります。
「DBサーバ 」と「DBバックアップサーバ」があり、
OSは「DBサーバ」が　CentOS release 6.3 (Final)　で、
「DBバックアップサーバ」が　CentOS release 6.5 (Final)　です。

「DBバックアップサーバ」上で
mysqldump {「DBサーバ 」} {DB名} > {hoge.sql}
をcronで実行しています。

この {hoge.sql} が正常か異常かを確かめたいのです。
サーバ上で障害等ない場合、mysqldumpで異常なデータが出力されたりすることはあるのでしょうか？
HD上の空きには余裕がある状態で、他に特にサーバ上での問題もない場合、圧縮でデータが破損することはあるのでしょうか？
CRCでできないのであれば、他にどのような手法があるのでしょうか？

完全に丸投げの質問で申し訳ないのですが、どうぞご教示をお願いいたします。

回答No.3

hanabutako · ベストアンサー

> どのようにすれば、CRCでチェックサムを付加することができるのでしょうか？

gzipやzipなどの圧縮プログラムは自動でCRCでチェックサムを追加してくれると思います。
質問文にあるケースもそれで破損を見つけたのではないでしょうか。

ただ、CRCはデータの破損を検出できても、正しいデータに復元することはできません。
http://ja.wikipedia.org/wiki/%E5%B7%A1%E5%9B%9E%E5%86%97%E9%95%B7%E6%A4%9C%E6%9F%BB

> サーバ上で障害等ない場合、mysqldumpで異常なデータが出力されたりすることはあるのでしょうか？

障害がない場合は異常なデータが出ないと思いますが、サーバー上で障害がないことはどうやって保証しますか？
大方#2の回答にあるように2回同じデータを取得して、同じチェックサムが出ればOKというので良いのでしょうけれど、もう少し神経質にやるならdumpされたSQLがちゃんとロードできるか確認し、同じデータが入っているかを逐次比較することになるでしょうね。

> HD上の空きには余裕がある状態で、他に特にサーバ上での問題もない場合、圧縮でデータが破損することはあるのでしょうか？

ロスレス圧縮なら、圧縮でデータが壊れることはまずないと思いますが、ハードディスクのデータがこっそり壊れることはあります。そこに圧縮データが置いてあれば、それもまた壊れるでしょうね。
http://en.wikipedia.org/wiki/Data_corruption#Silent_data_corruption

> CRCでできないのであれば、他にどのような手法があるのでしょうか？

ZFSのように、ハードディスク上に幾つかコピーを持ち、読み出し時にチェックサムがあっているか調べるというファイルシステムを使えるなら、それを使うという手があるでしょう。
http://en.wikipedia.org/wiki/ZFS#Data_integrity
例えば、別々のハードディスクに複数のコピーを持つように設定していたら、それ全部が破損することはまず考えにくいでしょう。

あるいは、rarやlzipのように圧縮データの一部が破損しても復元できるような圧縮形式を使うという方法もあるかもしれません。

お礼

ありがとうございます。
お礼が遅くなり申し訳ありません。

やはり、複数バックアップを取る案が多いようですね。

mysqldumpや、圧縮でバグがあるとは思っていなかったのですが、
「ない」と自信を持って言えるほど仕様を理解していなかったので質問させていただきました。

ZFS、初めて聞く単語なので調べておきます。

ありがとうございました。

回答No.2

e3tatsu

同一静止点のDBバックアップを２つ取得し、それぞれのバックアップデータからハッシュ値を計算し、比較。
一致していれば続けて圧縮を行う。
一致していなければ一致するまでバックアップを取り直す(あるいはシステム管理者に異常発生を通知)。
さらに圧縮によるデータ破損が疑われるのであれば、バックアップ取得時と同様に２回圧縮を行って、はき出された圧縮済みファイルそれぞれのハッシュ値を比較すれば良いのではないかと。

あとは破損の仕方に規則性があるのであればハッシュ値も同一となる可能性があるので定期的なリストアの試験も行う必要がありますね。

お礼

ご回答ありがとうございます。

mysqkdumpで出力されたデータをチェックするなら、
もう一つ同じ条件でバックアップを取らないといけないのですね。

具体的なチェック方法を書いていただいてありがとうございます。
参考にさせていただきます。

回答No.1

kmee

cRCというのは、データを元に計算する値で、
　データA = データB ならば データAのCRC = データBのCRC
　データAのCRC ≠ データBのCRC ならば データA ≠ データB
となっています。
正し、「逆」は成立しません。
　データが違うのに同じCRC
ということがあります。

この性質を使って、ハードディスクや通信のチェックに使うことがあります。
ハードディスクの場合だと、ディスクにCRCを保存する領域が内蔵されていて、データ部とCRCの内容が違えばエラーを出す、といった具合です。

通信も同様、データとCRCを通信して、データから計算したCRCと通信されたCRCが違っていたらエラーにします。

これらは、そういうプロトコルでやっている場合に自動で付けるようにするもので、(通信用ドライバを作成するとかで無い場合は)ユーザー側でどうこうするものではありません。

ユーザーでCRCを使う場合は、データとは別にCRCの結果をテキストファイル等に書いて、一緒に置いておく、等します。

ファイルのCRCを求めるには、計算プログラムを用意します。
例えば cksum 等
http://kazmax.zpp.jp/cmd/c/cksum.1.html

> この {hoge.sql} が正常か異常かを確かめたいのです

それはできません。
できるのは、出力された hoge.sql と、それをコピーしたものとが、変化しているかどうか判定することだけです。
それも、CRCが同じでも変化している可能性がある、という条件付きです。

また、圧縮したファイルは、当然元のデータとは違うので、CRCが違うものになります。
よって、圧縮が正しいかどうかも判定できません。

お礼

データとCRCは別々に通信するのですね…。
IT用語辞書BINARYには、「余りを付加してデータを転送し～」とあったため、
同時に通信するものとばかり思っていました。

出力されたhoge.sql単体でのチェックは、できないのですね…。

ご回答、ありがとうございました。