データベースを運用中に、こまめにバックアップを取り保全したいと思うのであれば、ジャーナルファイルを活用する方法があります。
4Dの運用中のデータファイルは、メモリ上のキャッシュとデータファイルの両方を合わせて１つのデータとして扱っています。 そのため、運用中のデータファイルだけに注目すると、不完全な状態であり、単純に見ると壊れた状態であるかもしれません。
例えば、運用中のデータファイルを単純にコピーしたものをMSCで検査すると壊れていると報告されることがあります。 これは最新のキャッシュの内容が、データファイルに保存される前のデータファイルであるようなときは、辻褄の合わないデータが存在するからです。 ４Ｄのバックアップ機能でフルバックアップを利用すると、キャッシュ内の情報はデータファイルに統合されて保存された後にバックアップされるので、こうした問題はありません。
しかし、運用中にこまめにフルバックアップを行うのは、現実的では無いかもしれません。 フルバックアップ中は、キャッシュが更新されないようにするため、データの参照はできますが更新することはできません。 フルバックアップに時間を要する場合には、フルバックアップの間、業務が停滞することになります。
そこで、ログファイルの活用になります。
ログファイルは、フルバックアップした後、次のフルバックアップまでの間にデータファイルを更新した履歴が記録されます。 ですので、運用中にこまめにバックアップを取りたいようなときには、ログファイルだけをバックアップする方法が有効です。
参考資料: ログファイル (.journal)
例えば次のようなケースを考えてみます。
1. 夜中の1時にフルバックアップが動作
2. On Backup Shutdownデータベースメソッドでネットワーク上の別ボリュームにバックアップファイルを転送
3. 自動処理で１時間おきにログファイルをネットワーク上の別ボリュームにバックアップファイルを転送
4. 朝9時に業務開始
5. 12時ごろにサーバー機が延焼(❗)し全ディスクがダメージを受ける
考えたくもない恐ろしい事態ですが、ネットワークボリュームに退避した最後のログファイルの時点のデータファイルの状態に復旧させることができます。 ログファイルが12時の時点のものがあれば12時の時点に復旧できますし、少なくとも11時の時点のログファイルがあるはずなので、11時の時点のデータファイルには復旧することが可能です。
参考資料: 複数のログファイルを連続して統合する
ログファイルだけのバックアップであれば、負荷の問題もありますが、１時間間隔よりも頻度を増すことも可能でしょう。 フルバックアップでは運用面からの問題で１時間間隔も難しいと思いますから、１時間おきのログファイルのバックアップは魅力的な方法であることは間違いないと言えそうです。
ログファイルのバックアップ方法ですが、New log fileコマンドを使用してログファイルを切り替えた上で、直前のログファイルをバックアップするのが転送コストを下げる上で理想です。
転送コストを考えないのであれば、少々乱暴ですが運用中のログファイルをバックアップ（コピー）してしまう方法もあります。
運用中のログファイルをコピーすると、最後のアクションが中途で書き込まれているような状態が考えられ、その場合、ログファイルとしては破損しているかもしれません。 そして、そのように破損したログファイルをデータファイル復元時に統合した結果、統合に失敗したというメッセージを見ることになります。 しかしデータファイルとは違い、ログファイルはシーケンシャルファイルなので、最後の壊れたアクションの直前までは問題なく復元できます。
ですが、こうした乱暴な方法ですと、予測される失敗と本当の失敗を区別できないので、New log fileコマンドを利用するのが正当な方法であると言えます。
運用を妨げること無くバックアップを考える上でも、ログファイルの活用は有効だと考えます。