ファイルメーカーシステム開発と改良

データベースのバックアップは、システムやサーバのバックアップとは一線を画して考えなければなりません。 なぜなら、バックアップの目的が違うからです。バックアップというのは、稼働中のシステムの予備で、万が一稼働中のシステムに障害が発生した場合、本番環境に代わってサービスを提供するいわば補欠のようなものです。 これが、単純なプリントサーバなどであれば、絶好調の状態を保存しておいて、本番環境が 壊れたら入替えるという作業でいいのですが、データベースの場合そんな単純ではないのです。 バックアップには大きく分けて二つの目的があります。
一つは障害時に、障害直前の状態を復元できればOKというもの
もう一つは、今現在システムは正常に稼動しているが、システム内のデータに誤りがある場合、
正常な状態まで遡って復元し、処理をやり直すことができればOKというもの。

一般的にデータベースのバックアップに求められるバックアップは上記二つの用途の両方であり、
どちらか一方でよければよいというものではありません。

一般的にベンダーが設置するサーバのバックアップはテープドライブに毎日上書きで、障害時に
前日の深夜の状態になら復旧できます。というものがほとんどです。

しかし、実際にデータベースのバックアップに求められるものは、
「今現在のこの伝票のデータは間違っている、しかし、一週間前は正確だった。この一週間で書き込まれている他の
データに誤りはない」という状態で、この伝票だけ一週間前に戻して欲しい。というもの。

まず、毎日上書きであれば、昨日の状態には戻せても、一週間前は無理だし、残りの正しく処理されたデータを残すことも無理である。
そのため、私は次のようなバックアップを取るようにお勧めしている。

<
上記の方法であれば、一週間以内ならどの曜日にも戻せるし、週単位であれば、８週間戻ることもできる
更に月単位であれば６ヶ月戻ることもできる。
バックアップの容量は本番環境の２０倍必要になるが、安定した運用ができるし、現在はHDDの金額も
安くなってきているので上記の方法でも無理なく投入できるようになりました。

次に障害直前にもどせるかどうかになりますが、こちらは危機管理をどこまでするかということになります。
同一サーバ上にバックアップを取っている。・・・というのはナンセンスです。
障害に備えるものな訳ですから、最低でも別のサーバに退避させておきたいところです。

理想形としては、別の建物や地方の支店などにもバックアップを取ることです。
上記方法なら、火事や地震などが発生しても復旧が可能です

また、運用中のバックアップ頻度ですが、何百人ものユーザーで常に書き込みをするようなデータベースなら
たった1時間の運用でも大きく内容が変わっています。
FileMakerServerでは運用しながら1時間おきでも10分おきでもバックアップを取れるので、業務内容に合わせて
バックアップの頻度を決める必要があります。