データ保護の話では、「ストレージはミラー構成にする」「スナップショットを取得する」「バックアップジョブを実行する」といった言葉が出てきます。
私が技術に触れ始めた頃は、どれも 「データのコピーを作って残す仕組み」 だということは、なんとなく理解できていました。ただ、それぞれがどの障害に備えるもので、システムのどの部分を守り、どの時点へ戻すために使うのかという対応関係までは、うまく整理できていませんでした。
実際、ミラー、スナップショット、バックアップは、いずれもデータのコピーを扱います。しかし、想定している障害や、戻せる状態は同じではありません。現在の状態を維持する仕組みもあれば、過去の状態を残すもの、保存したデータから必要な状態を組み立て直すものもあります。
コピーが複数あるという情報だけでは、どの障害に対応でき、どの時点まで戻れるかは判断できません。
なお、データ保護にはレプリケーション、待機系、論理エクスポートなど、ほかにもさまざまな仕組みがありまが、この記事では、役割の違いをつかみやすい代表例として、ミラー、スナップショット、バックアップに絞って整理しながら、「データを守っている」と言える範囲を考えていきます。
なお、製品によって用語や機能の境界は異なります。
ここでは、個別製品の仕様ではなく、一般的な役割をもとに整理します。
ミラーは現在の状態を保つ
ストレージミラーは、同じデータを複数のディスクや装置に保持する技術です。
一方のディスクが故障しても、もう一方に同じデータが残っていれば、処理を継続したり、短い時間で復旧したりできます。ハードウェア障害に備えるうえで有効な仕組みです。
ただし、一般的な同期ミラーでは、正常な書き込みだけでなく、誤った書き込みも反映されてしまいます。
操作ミスでデータを削除した場合、その削除も複製先へ伝わります。
またアプリケーションの不具合によってデータが書き換えられた場合も、変更後の状態が両側に残る可能性があります。
ミラーが得意なのは、主に 「現在のデータを維持すること」 です。
つまり、過去の状態を長期間保存する役割とは分けて考える必要があります。
スナップショットは、ある時点の状態を残す
スナップショットは、特定の時点におけるストレージやボリュームの状態を保持する仕組みです。
スナップショットを保持しておくと、誤ってファイルを削除した場合や、変更前の状態を確認したい場合に、短時間で戻せることがあります。取得が速く、容量を効率よく使える実装も多いため、日常的な復旧手段として利用されています。
一方で、スナップショットが何から守ってくれるかは、保存場所や実装方式によって変わります。
元データと同じストレージ装置に依存している場合、装置全体が使えなくなると、元データとスナップショットを同時に失う可能性があります。保持期間が短ければ、しばらく発見されなかったデータ破損には対応できません。
データベースの稼働中に取得したスナップショットでは、データファイルだけでなく、更新履歴やアプリケーションとの整合性も考慮する必要があります。
スナップショットをバックアップ設計の一部として利用することはできます。ただし、スナップショットが存在するという事実だけで、独立した復旧手段が確保できたとは限りません。
バックアップは過去の状態から再構築する
バックアップは、障害や誤操作が起きたあとに、保存していたデータから必要な状態を再構築するために使います。
取得時点のデータを別の場所へ保存し、一定期間保持することで、現在の環境に問題が起きても過去の状態を利用できます。
元の装置とは異なる障害範囲へコピーを置けば、ストレージ装置全体の故障にも備えられます。
ただし、データベースの復旧では、バックアップファイルを書き戻すだけで作業が終わるとは限りません。
たとえば、午前0時にバックアップを取得し、午後3時に障害が発生したとします。午前0時のデータを書き戻すだけでは、その後15時間分の更新は反映されません。必要な時点まで戻すには、バックアップ取得後の更新履歴をログなどに残し、復旧時に適用する仕組みが必要になります。
データファイルを配置する作業と、データベースを整合した状態に戻す作業は、分けて考えた方が理解しやすくなります。
どの仕組みが必要かは、障害によって変わる
データ保護方式を考えるとき、先に製品名や機能名を並べても判断しづらいことがあります。
まずは、何が起きたときに、どの状態へ戻したいかを確認します。
ディスクの一部が故障した場合は、ミラーによって処理を継続できる可能性があります。誤ってデータを削除した場合は、削除前のスナップショットやバックアップが必要です。
ストレージ装置全体を失ったケースでは、同じ装置の中にあるコピーだけでは復旧できないかもしれません。データセンターやクラウドリージョン全体が利用できない場合は、データのコピーに加えて、別の場所でシステムを動かす準備も求められます。
同じ「データのコピー」でも、守っている範囲はそれぞれ異なります。
実際のシステムでは、一つの方式ですべてをカバーするより、想定する障害に合わせて複数の方式を組み合わせることが一般的です。
重要なのは、仕組みの数ではなく、それぞれがどの障害を担当しているかを説明できることです。
バックアップジョブの成功が示すもの
「昨夜のバックアップジョブは成功しています」という報告は、バックアップ処理が正常に終了したことを示します。
これは重要な確認結果です。一方で、復旧できることを確認するには、もう少し先まで見る必要があります。
保存先へアクセスできること、必要な権限や暗号鍵を利用できること、復旧先の容量や環境を用意できること、必要な更新履歴が残っていること。さらに、戻したデータを確認し、アプリケーションを起動して、業務を再開できる状態まで進める必要があります。
バックアップ処理に30分かかったとしても、復旧が30分で終わるとは限りません。大量のデータを書き戻し、その後の更新を反映し、データやアプリケーションを確認する時間も加わります。
復旧時間を把握するには、実際の手順を試し、業務再開までの所要時間を測る必要があります。
一つのシステムが戻っても、業務全体が戻るとは限らない
データベースが正常に起動すると、復旧作業は完了したように見えます。しかし、関連するシステムを異なる時点へ戻した場合、業務データに矛盾が残ることがあります。
たとえば、注文管理を15時、在庫管理を11時、請求管理を13時の状態へ戻したとします。それぞれのデータベースは正常でも、注文は存在するのに在庫が引き当てられておらず、請求状態とも一致しない、といった状況が起こり得ます。
この状態では、技術的にはシステムが動いていても、業務を安全に再開できませんよね。
どのシステムを、どの業務時点へ合わせるかは、バックアップ方式とは別に設計する必要があります。
システム横断の整合性は別の記事で詳しく扱います。ここでは、データベース単体の復旧と業務全体の復旧では、確認する範囲が異なることだけ押さえておきます。
バックアップ設計は、障害シナリオから考える
ミラー、スナップショット、バックアップには、それぞれ得意な範囲があることを話してきました。
どれもデータを複製して保持する技術ですが、ミラーがあるからバックアップが不要になるわけではなく、スナップショットがあるから装置全体の障害にも対応できるとも限りません。
反対に、バックアップがあっても、短時間で切り替えて処理を継続する用途には向かない場合があります。
設計するときは、製品や機能を選ぶ前に、想定する障害を整理した方が判断しやすくなります。
想定する障害、許容できるデータ損失、戻す時点、復旧先、業務再開の条件を先に決めると、必要なミラー、スナップショット、バックアップ、更新ログ、待機環境の組み合わせを検討しやすくなります。
バックアップジョブの成功は、データ保護を確認する一つの工程です。
復旧できる仕組みとして評価するには、コピーが存在することに加えて、必要な時点へ戻し、データや関連システムを確認し、業務を再開するまでの道筋を確かめておきましょう。