バックアップを再確認したほうがいい

お客様のところに打合せに行きました。
 
訪問内容は、サーバー（データベースサーバー）の統合にかかわる移設作業の下調べです。
 
行う内容としては、
　　・データベースの移行全般
　　・クライアントからの接続先変更
　　・バックアップの保管先変更
などになるのですが、最後のバックアップの確認で愕然としました。
 
バックアップの要件としては、何かトラブルがあっても「確実に直近の状態に戻せること」です。
 
　・データベースソフトの異常からの復旧
　・データファイル破損からの復旧
　・OSクラッシュからの復旧
　・ディスククラッシュからの復旧
　・サーバー自体のクラッシュからの復旧
 
のように、どこまで復旧ができるかの定義が必要になるのですが、ここは前日までの状態に戻すことができればよいというレベルであったので、毎日バックアップを取得するという運用になっていました。
でも、まずかったのは、サーバー自体のクラッシュからの復旧が不完全だったのです。
 
というのは、バックアップを実行すると、サーバーの中のテンポラリにバックアップを作成します。
この場合は、一応、データベースソフトからデータを抜き出ししているのですが、サーバーの中に格納されているままなので、サーバー自体がクラッシュすれば結局データがなくなってしまいます。
 
大切なのは、サーバー本体以外へのバックアップの保管なのです。
 
このサーバーもそういうシェル（簡単なプログラムのこと）は作成されており、別サーバーにコピーする仕組みになっていましたが、コピー先のサーバーが既に整理（撤去）されて存在していませんでした。
 
安全のために毎日行っているバックアップが、実はきちんと取得できていなかったのです。
 
たまたま問題が発生していなかったからよかったものの、もし問題が発生していたらすべての今までのデータがなくなってしまいます。。
 
 
原因は、この会社にはシステムをいろいろな会社に依頼していて、それぞれが適当に（その場の思いつきで）こういう設定をしているようなのです。。
 
弊社としては、こういう問題点の指摘と今後の改善を提案しました。
 
でも、こういうケースは珍しくありません。　大手でもいざという時にデータが復旧できないという不具合が発生することがあるようです。
多いのはバックアップのテープが読めなかった。とか、　外部メディアの容量をオーバーしていた。というようなケースから、もともと復旧のテストをしたことがなく、意味のないバックアップを行っていたというケースまであるようです。
 
バックアップを取得する目的を再度明確にし、その要件を満たしているかのチェックは少なくとも年１回、または定期的に行うようにしたほうがよいと思います。