バックアップとは手段であって目的ではありません!

システム構築における「バックアップ」とは超重要な要素でありバックアップを取得しないシステムはありません。ただし『バックアップの取得』が目的となっており、いざバックアップの復元をしようとした場合、『うまく復元できない』『データが欠落する』といった事象もありますので、バックアップの考え方について説明します。

 

バックアップを取る目的とは?

ここではシステム構築におけるデータベース(以下、DB)のバックアップを指します。

システムにおいてバックアップを取得する目的はシステムエラーによりデータ復元を行うためとなります。

バックアップは通常、日次や週次・月次で取得することが多いです。

先ほど挙げましたが、バックアップはデータ復元をすることが目的となります。反対に言うとデータ復元ができないバックアップは意味がありません。

よくバックアップを定期的に取得することで安心感がうまれ、その先の復元について考えられていないことが多いですが、バックアップは取得することではなく、データ復元できることまたその先の復元後の業務が正常動作することが目的となります。

 

バックアップ計画は重要!

取得タイミング

取得サイクル

バックアップ対象データによって、日次・月次・年次でバックアップサイクルを決めます。

バックアップ取得タイミングとしてはデータが更新されない時間帯が望ましいので、オンライン処理・バッチ処理が動かない時間帯にバックアップ処理を仕掛けましょう!

ローテーション

バックアップを何世代まで保有する必要があるのか。法定義務としてデータ保有期間が定められているデータはそれに従ってデータを保管しておく必要があります。

そうでない場合はバックアップは基本的に直近1世代を利用することが多いとしても、3世代または5世代くらいまで保有しておくと安心です。ただし5世代前に戻すことはほとんど考えられないので、実用的に考えると直近及び2世代前くらいが妥当と思います。

また古くなったバックアップファイルはしっかり削除しないとディスク容量を逼迫しバックアップ処理が正常に動作しない(空き容量不足エラー)こともありますのでご注意ください。

復元方法

バックアップの復元方法は基本的にDBを纏めて復元という形が多いです。ただしDBの構造によりデータを戻したいユーザやテーブルが異なるとまとめて復元することは難しく、一度テンポラリ領域に復元した後必要なデータを抽出し復元する必要があります。

ここで言う必要なデータというのが整理されていないと有事の際にどのデータを戻したらいいのかわからず復旧まで時間を多く費やします。

復元テスト

バックアップ計画・復元方法が明確になった時点でしっかりテストをすることが重要です。

何度も言う通りバックアップ取得は目的ではなく手段です。バックアップを復元し正しく業務を実行することが目的となっていますので、想定するトラブルを数パターン準備し、パターンごとにどこのデータをどのように復元すればいいのか手順書とともにテストを実施します。

データ復元されたことをテスト完了とするわけではなく、復元後しっかりオンライン打鍵ができること・バッチ処理が実行されること・1日の業務が問題なく終了することまで確認しましょう。