データベースのバックアップに関する考慮事項の概要

はじめに

データベースのバックアップは、データ管理において最も重要なルーティンの一つです。データは組織が管理する資産の中でも最も重要なものの一つであることが多いため、偶発的な削除、破損、ハードウェア障害、その他の災害から復旧できることは最優先事項です。

信頼できるバックアップの価値を認識することは難しくありませんが、詳細を把握することは必ずしも容易ではありません。バックアップメカニズム、メディア、スケジュール、忠実度、セキュリティを決定することは、すべて考慮に入れる必要があり、適切な組み合わせはプロジェクトごとに異なることがよくあります。

このガイドでは、データベースのバックアップ戦略を決定する際に必要となる主要な決定事項について説明します。さまざまなバックアップ方法、データのライフサイクルにおけるさまざまな時点でのデータの保存場所、およびセキュリティがバックアップ設計とどのように交差するかについて議論します。

データベースのバックアップが重要な理由

続ける前に、適切なバックアップがチームにもたらす価値を強調することが役立つかもしれません。主な利点には以下が含まれます。

• ハードウェア障害からの再構築：ハードウェア障害はあらゆるシステムに影響を及ぼす可能性があり、しばしば予測不可能です。包括的なバックアップがあれば、障害が発生したコンポーネントを交換した後でもデータを復元できます。
• 破損後のファイルの復元：データ破損は、ソフトウェアエラー、ハードウェアの問題、または環境要因によって発生する可能性があるもう一つの事象です。複数層のバックアップがあれば、バックアップセット内で破損したデータを正常なバージョンに置き換えることができる場合があります。
• 誤削除からの復旧：ユーザーエラーによっても、データベースから貴重なデータが削除される可能性があります。バックアップがあれば、そのデータを復旧して永続的な損失を防ぐことができます。
• 監査とコンプライアンス：多くの業界では、コンプライアンス上の理由から、特定のバックアップおよび監査証跡の基準が定められています。さまざまな能力でユーザーデータを扱う合意の一部として、堅牢なバックアップルーチンを実装することを義務付けられる場合があります。
• 変更時の安心感：信頼できるバックアップがあれば、ソフトウェア、環境、または操作の変更が危険性が低くなります。何か問題が発生しても組織のデータを危険にさらすことはないと分かっているので、自信を持って変更を行うことができます。

バックアップの種類

検討すべきさまざまな*種類の*バックアップがあります。このセクションでは、実行できるいくつかの異なるバックアップと、それらがどのように組み合わさってより包括的なシステムになるかについて説明します。

オンラインバックアップ vs オフラインバックアップ

バックアップ戦略を決定する際に留意すべきことの一つは、一部のバックアップメカニズムはライブシステム上で実行できないということです。

システムがオフラインであることを必要とするバックアップ方法は、通常、ツールが特定の時点でのデータベースの一貫したビューをキャプチャできるようにするためにその制限があります。システムが更新されており、バックアップの実行中にレコードが変更されている場合、プロセスが完了するまでに開始時点のデータが無効になる可能性があります。

しかし、オフラインバックアップにはいくつかの利点があります。データベースを停止させることは、アクティブなユーザーとリソースを共有する必要がなくなることを意味し、完了が速くなる可能性があります。データがアクティブに変更されるプロセスがないため、バックアッププロセス自体もはるかに単純にできます。

とはいえ、あらゆるバックアップのためにプライマリデータベースを停止させることは、多くのシナリオで許容されません。幸いなことに、ライブシステムで使用するように設計されたバックアップ方法があります。一般に、これはユーティリティを使用してデータベースシステムに直接クエリを実行し、データベース構造とデータをファイルシステムにコピーすることを含みます。必要な権限を除けば、これは通常のクライアントがテーブル構造情報とそこに含まれるデータを要求するのと大差ありません。

これらの「論理」バックアップツール（生ファイルを扱う物理ツールとは対照的に）の主な利点の1つは、データベース自体が特定の時点でのデータの統一された一貫性のあるスナップショットを提示する能力に依存できることです。この文脈でのバックアッププロセスはデータベースユーザーとして動作するため、この機能の代償は、限られたデータベースリソースを他のクライアントと競合することになる点です。

レプリケーションはバックアップか？

一部のユーザーにとって混乱の元となるのは、レプリケーションが設定されているにもかかわらず、なぜデータベースにバックアップが必要なのかという点です。

データベースレプリケーションは、あるサーバーから別のサーバーへ変更のログをストリーミングし、別のシステムに変更をミラーリングする方法です。バックアップと同様に、これもシステムデータの複製を作成します。しかし、いくつかの重要な理由から、レプリケーションは安全なバックアップ戦略とみなすべきではありません。

レプリケーションは、多数の障害シナリオにおいてバックアップほどデータを保護しません。すべての変更がセカンダリサーバーにコピーされることを保証する同じメカニズムが、プライマリデータベースの問題も複製してしまいます。例えば、プライマリデータベースで誤ってレコードが削除された場合、その変更はダウンストリームのすべてのレプリカでも実行されます。この同じプロセスは、破損したデータも拡散されることを意味します。

レプリケーションがバックアップではないもう一つの理由は、データを復元する明確な能力がないことです。サーバー間で変更をレプリケートすることはできますが、レプリケーションはデータの以前のバージョンを保持することには関心がなく、ログがローテーションされるとデータの履歴ビューは失われる可能性が高いです。この「欠点」は、レプリケーションが主にデータ保全ツールとしてではなく、組織の可用性とパフォーマンスを向上させるために設計されていることを思い出させます。

そうは言っても、レプリケーションはバックアップおよび災害復旧計画の重要な要素になり得ます。例えば、プライマリデータベースでハードウェア障害が発生した場合にレプリケーションが役立つことがあります。この場合、管理者はレプリケーションフォロワーを迅速にリーダーロールに昇格させ、長時間の復元手順を避けてクライアント要求に応じ続けることができます。一部の組織では、「遅延」レプリカを設定し、一定期間が経過した後にのみ変更を適用することで、必要に応じてレプリカに切り替えることでデータベースの状態を迅速に「ロールバック」できるようにしています。

レプリケーションがバックアッププロセスに頻繁に関与するもう一つのケースは、バックアップ操作のターゲットとしてです。多くの場合、プライマリサーバーよりもレプリカをバックアップする方が簡単です。例えば、一貫したファイルレベルのバックアップを取得するために、セカンダリデータベースを本番データベースのレプリカとして構成できます。データベースが同期されたら、一時的にレプリケーションをオフにして、本番トラフィックに影響を与えることなくレプリカのバックアップを実行できます。バックアップが完了したら、レプリケーションを再度オンにして、バックアップ中に発生した変更でサーバーを再同期できます。

バックアップはセキュリティにどう影響するか？

バックアップ戦略は、いくつかの異なる方法でセキュリティ上の考慮事項と交差します。

バックアップは、ランサムウェア攻撃のようなシナリオで二次的なデータソースを提供することで、特定のセキュリティインシデントから保護するのに役立ちます。例えば、侵入者がプライマリデータベースのコンテンツにアクセスして暗号化できた場合、履歴スナップショットにアクセスできれば、状況に対処するためのより多くの選択肢が得られます。これが選択肢となるためには、攻撃者がバックアップにも影響を与えることを防ぐために、バックアップの保存先がソースデータとは別のセキュリティコンテキストにある必要があります。

バックアップ戦略にセキュリティポリシーを反映させる必要があることを理解することが重要です。そうしないと、データのバックアップ時に機密情報を意図せず公開してしまう可能性があります。例えば、本番システムが個人識別情報（PII）に関するセキュリティを実装している場合、バックアップはそのセキュリティレベルを維持するように構成されるべきです。これは、異なる種類のデータに異なる暗号化を使用したり、異なる種類のデータに異なるバックアップ場所を使用したりすることを意味するかもしれません。あなたの具体的な状況によって、バックアップ戦略に組み込むべき保護の種類が決まります。

収集後すぐに価値がなくなるような機密データの場合、そのデータをバックアップ*しない*ことを検討する価値があります。システムによって収集または生成される特定の種類のデータは、その時点では有用ですが、長期保存されるとリスクが増大する可能性があります。データから得られる価値がその鮮度と密接に結びついている場合、バックアップセットから除外する方が良いかもしれません。

バックアップの保存場所

バックアップ戦略を設計する際に決定しなければならないことの一つは、実際のバックアップデータをどこに保存するかです。さまざまな要因が、あなたにとって最適なバックアップ保存先の種類に影響を与える可能性があります。

多くの場合、バックアップ先の選択は、アクセス性、コスト、セキュリティ、利便性のバランスを取ることです。オンサイトバックアップは迅速なバックアップを可能にしますが、物理ディスクの管理はあなたにとって負担が大きいかもしれません。さらに、オンサイトバックアップは火災、洪水、盗難といったサイト固有の災害から保護できません。一方、クラウドベースのバックアップは便利ですが、特定のプロバイダーに縛られ、コストが高く、復旧に時間がかかる可能性があります。

ほとんどの場合、リスクとメリットのバランスを取り、データ損失に対する追加の保護を得るために、複数のストレージ場所と媒体を使用することが良い考えです。例えば、Amazon S3のようなオブジェクトストレージプロバイダーを主要なバックアップローテーションのターゲットとして使用できます。毎月、そのバックアップの一部をAmazon S3 Glacierのようなアーカイブストレージに長期保存のために移動する場合があります。また、本番インフラストラクチャで使用しているプロバイダーとは異なるプロバイダーにデータをバックアップすることも望ましいかもしれません。

バックアップのヒント

これまで、堅牢なバックアップ戦略の多くの構成要素について説明してきましたが、ここからは考慮すべき一般的なアドバイスをいくつか見ていきましょう。

まとめ

このガイドでは、データベースのバックアップがいかに重要であるか、そしてそれらを実装する際に考慮すべき点について説明しました。バックアップの利点、バックアップの種類と範囲、オンラインバックアップとオフラインバックアップの違い、レプリケーションがバックアップ戦略ではない理由などについて詳しく見ていきました。

組織としてどのような選択肢があるのか、そして異なる決定がパフォーマンス、セキュリティ、可用性にどのように影響するかを理解しておくことは不可欠です。すべてのプロジェクトのバックアップニーズは異なりますが、データの問題から回復するために永続的で信頼できる長期ストレージが必要であるという共通点があります。要件を整理し、包括的な計画を立てるのに時間をかけることで、より安全に、自信を持って、危険を少なくして前進することができます。