さてバックアップ設計の第2回の記事です。今回は、バックアップ方式について纏めます。目的を記載した第１回目は以下のリンクからたどってください。
バックアップ方式設計
バックアップの方式を決定します。ここが一番具体的な機能的な設計です。
検討が必要な要素を簡単に言えば、「どうやって、どこに、どのくらい」保存するのか決めることです。
どやってバックアップするのかを決めるがバックアップ処理方式です。代表的な方式をご紹介します。
ファイルデータバックアップ
イメージとしてはWordなどのファイルを一つ一つコピーしてバックアップを取得する方式です。簡単にできますし、復旧時間も容易で簡単です。
一点注意が必要なのは、ファイルのアクセス権限が変わってしまうケースも想定されますので、必ず確認が必要です。元のファイルのアクセス権が継続されているのか必ず確認が必要です。
ドライブ（DISK単位）バックアップ
ファイル単位ではなく、ドライブやDISK単位でバックアップを取得する方式です。ＯＳなどのシステム領域のバックアップで主に使われる方法です。
昔は、オフラインバックアップが主流でしたが、最近ではスナップショットを用いたオンラインバックアップの利用もかなり広がっています。
スナップショットを用いて仮想サーバを丸ごとバックアップを取得することも可能です。ただし、スナップショットは元データベースの変更点をバックアップし、元データにそれを反映させる機能のため、元データが物理的に壊れた場合には対応不可です。
こういった面では、オフラインでドライブのイメージを丸ごとバックアップさせた方が時間はかかり、サービス停止も必要ですがDISK障害にも耐えられ優位性があります。当然ながらバックアップの単位が非常に大きいため、データの復旧には時間がかかってしまいます。
バックアップというか違和感があるかもしれませんが、別サーバにデータをリアルタイム同期させる方法もあります。この方法を用いればＤＩＳＫ障害時でもデータの欠損は発生しません。ただし、リアルタイムコピーのためデータの誤更新・誤更新するとバックアップ先も壊れてしまうため、論理的障害を想定したバックアップにはなりません。
このようにバックアップもやり方により一長一短あるので、バックアップの目的により選択、または複合して対応することが求められます。
バックアップ先の設計
バックアップ先は大きく５つあります。
- 同一HDD（サーバ）内に論理的にバクアップ
- 媒体(DVD,磁気テープなど）
- 別サーバにレプリケーション（リアルタイム同期コピー）
- オンプレミスからクラウド上にデータバックアップ
- クラウド内で別サービスにコピー（AWSであればS3へコピーなど）
ここでもバックアップ処理方式と同じように、どんな事象からの復旧を目的にするかにより選択が変わります。例えば、1.は同一のHDDにデータをコピーするため、そのHDDの故障に耐えることができません。それ以外の方法は別にＨＤＤにコピーするので、当たり前ですがＨＤＤ障害に耐えることができます。
一方で、3.はリアルタイムで他サーバにデータをコピーしてしまうので、論理障害（データ誤削除など）した場合には、バックアップ先のサーバでも同一データが消失します。ただし元サーバのHDD障害など物理故障には耐えれます。
要するに、バックアップ先により守れるところと、守れないところが異なります。そのため、目的に合わせて処理方式とバックアップ先を選択してください。
バックアップ処理と試験と運用
最後にバックアップ処理の試験と運用に関して触れます。
バックアップ処理の試験
試験は、必ずバックアップ～リストア（復旧）まで通した試験をしてください。バックアップをいくらしても復旧できなければ意味がありません。
また処理時間も測定してください。サービス停止を伴うバックアップ処理では処理時間がサービス時間に直接影響してきます。想定される最大データ量で行うのが理想で、難しい場合でも机上で最大データ量の処理時間を予測しておきましょう。
バックアップ処理の運用
バックアップ処理は基本的に自動実行することも思いますが、想定処理時間に終わらなかったら、バックアップ処理を打ち切り後続に入るのか、バックアップを優先させるか事前に決めましょう。当然ながら判断時間も事前整理が必要です。また打ち切りする場合は、事前に手順を整備しておきましょう。
また自動処理ですが、ちゃんとバックアップが取得されているかは確認可能なようにしておいて方が良いです。気づいたら処理が停止していた・・・なんてことはたまにあります。人の目で確認するタイミングを設けた方が良いと考えています。