はじめに
データベースのバックアップは、データ管理において最も重要なルーティンの一つです。データは組織が管理する上で最も重要な資産の一つであることが多く、誤った削除、破損、ハードウェアの故障、その他の災害から復旧できることは優先順位の高い事項です。
信頼性の高いバックアップの価値を認識することは難しくありませんが、詳細を理解することは必ずしも簡単ではありません。バックアップのメカニズム、媒体、スケジュール、忠実度、セキュリティを決定することは、すべて考慮すべき事項であり、適切な組み合わせはプロジェクトごとに異なることがよくあります。
このガイドでは、データベースのバックアップ戦略を決定する際に下す必要のある重要な決定事項について説明します。さまざまなバックアップ方法、ライフサイクルのさまざまな段階でデータを保存する場所、およびセキュリティがバックアップ設計とさまざまな方法でどのように交差するかについて説明します。
The Prisma Data Platformは、本番環境でのデータベースへのアクセスを簡素化するのに役立ちます。Prisma Clientを使用してデータベース接続を管理している場合、Prisma Data Platformは本番環境のワークロードをより簡単に管理するのに役立つ可能性があります。
なぜデータベースバックアップは重要なのか？
先に進む前に、適切なバックアップがチームにもたらす価値を強調しておくと役立つかもしれません。主な利点には、次のものがあります。
- ハードウェア故障後の再構築：ハードウェアの故障はどのシステムにも影響を与える可能性があり、予測不可能なことがよくあります。包括的なバックアップがあれば、故障したコンポーネントを交換した後、データを復元できます。
- 破損後のファイルの復元：データ破損は、ソフトウェアのエラー、ハードウェアの問題、または環境要因によって発生する可能性のあるもう1つの事象です。複数のレイヤーのバックアップにより、破損したデータをバックアップセット内の正常なバージョンに置き換えることができます。
- 誤った削除からの復旧：ユーザーエラーによって、データベースから貴重なデータが削除されることもあります。バックアップがあれば、そのデータを復旧して、永久的な損失を回避できます。
- 監査とコンプライアンス：多くの業界では、コンプライアンス上の理由から、特定のバックアップおよび監査証跡の基準があります。さまざまな立場でユーザーデータを処理する契約の一環として、堅牢なバックアップルーティンを実装することを義務付けられる場合があります。
- 変更を加える際の安心感：信頼性の高いバックアップがあれば、ソフトウェア、環境、または運用を変更する際の危険性が少なくなります。何か問題が発生した場合でも、組織のデータを危険にさらすことはないと安心して変更を加えることができます。
バックアップの種類
検討したいバックアップの種類はたくさんあります。このセクションでは、実行できるさまざまなバックアップと、それらがより包括的なシステムにどのように組み込まれるかについて説明します。
フルバックアップ
フルバックアップは、元の場所からデータセット全体を複製するバックアップです。ソースからターゲットにすべてのデータを読み書きするため、あらゆるバックアップの中で最も範囲が広くなります。
フルバックアップは、失われたデータを部分的または完全に復元するために使用できるデータセットの完全なコピーを提供するため、重要です。すべての戦略には、ルーティンのコアコンポーネントとしてフルバックアップを含める必要があります。
フルバックアップは必要であり、ほとんどのバックアップ戦略の基礎を提供しますが、いくつかの大きな欠点もあります。データセット全体を読み書きする必要があるため、完了に時間がかかり、その時間全体にわたってシステムに負荷がかかる可能性があります。さらに、データベースの完全なコピーを長期間にわたって多数維持すると、大量のストレージ容量を消費する可能性があります。
差分バックアップ
差分バックアップは、最新のフルバックアップ以降に変更されたすべてのデータをコピーします。これにより、バックアップサイクルごとに1回、コストのかかるフルバックアップを実行し、その後、フルバックアップを開始点として使用するより小さなバックアップでそれ以降の変更を記録できます。
差分バックアップは、頻繁なフルバックアップに伴うコアな問題のいくつかを解決します。フルバックアップよりも小さいため、ストレージスペースの使用量が少なく、実行が高速です。
差分バックアップはフルバックアップよりも改善されていますが、まだいくつかの欠点があります。最新のフルバックアップからの経過時間が長くなるほど、差分バックアップは大きくなります。さらに、複数の差分バックアップがあると、さまざまな時点を構築できますが、本質的に同じ変更を複数回バックアップするというコストがかかります。
増分バックアップ
増分バックアップは、差分バックアップで使用される戦略の修正版です。差分バックアップは常に最後のフルバックアップからの差分を記録しますが、増分バックアップは最後のフルバックアップまたは増分バックアップからの差分を記録します。これは、増分バックアップは常にフルバックアップにレイヤー化するのではなく、フルバックアップから開始し、複数の増分バックアップを復元することでデータを復元できることを意味します。
このシステムを使用すると、システム内の各変更を1回だけ記録しながら、頻繁にバックアップできます。各バックアップには、最後にバックアップが実行されてから発生した変更のみが含まれます。これにより、各増分バックアップのサイズを管理しやすくし、最新のフルバックアップとさまざまな数の増分バックアップを組み合わせることで、さまざまな時点を構築できます。
増分バックアップの欠点の1つは、データの復元が少し複雑になる可能性があることです。フルバックアップからの時間が長ければ長いほど、最近の変更を取得するために適用する必要がある増分バックアップが多くなります。これは、単一のフルバックアップと（最大で）単一の差分バックアップを復元するよりも時間がかかる場合があります。
先行書き込みまたはトランザクションログバックアップ
データベースは、システムのクラッシュや安全でないシャットダウンから復旧するのに役立つ安全メカニズムを頻繁に実装します。システムによっては、これらは先行書き込みログ（WAL）またはトランザクションログと呼ばれる場合があります。これらは主にクラッシュリカバリの目的で使用されますが、より柔軟なアーカイブを可能にするバックアップ戦略のコンポーネントとして使用できます。
WALベースのバックアップの基本的な考え方は、データベースのファイルシステムの定期的なバックアップを作成し、WALを使用してデータベースの一貫性のある状態を復元し、バックアップ後に発生した変更を再生することです。これは増分バックアップに似ていますが、いくつかの重要な違いがあります。
最初の重要な違いは、2つのコンポーネントが異なる媒体を使用することです。このインスタンスのフルバックアップは、レコードが一貫性のある状態でロックされているかどうかに関係なく、データベースファイルのバックアップです。次に、WALはデータ状態を修正し、復元する時点までデータ状態をキャッチアップする責任があります。
このシステムは、単一のWALをさまざまな時点に再生できるため、従来の増分バックアップよりも柔軟性も高くなっています。これにより、復元するデータの量を選択できます。このスタイルのバックアップの1つの欠点は、データベースシステム全体に影響を与えることです。データベースの一部のみを復元し、他の部分をそのままにすることはできません。このため、個々のテーブルやその他のデータベースオブジェクトの復元には適していません。
オンラインバックアップ vs オフラインバックアップ
バックアップ戦略を決定する際に留意すべきことの1つは、特定のバックアップメカニズムをライブシステムで実行できないことです。
システムをオフラインにする必要があるバックアップ方法は、通常、ツールが特定の時点でのデータベースの一貫性のあるビューをキャプチャできるようにするための制限があります。バックアップの実行中にシステムが更新され、レコードが変更されている場合、プロセスの完了までに開始時からのデータが有効でなくなる可能性があります。
ただし、オフラインバックアップにはいくつかの利点があります。データベースを停止すると、アクティブなユーザーとリソースを共有する必要がなくなり、完了までの時間が短縮される可能性があります。また、データをアクティブに変更するプロセスがないため、バックアッププロセス自体もそれほど複雑ではありません。
とはいえ、すべてのバックアップでプライマリデータベースを停止することは、多くのシナリオでは受け入れられません。幸いなことに、ライブシステムで使用するように設計されたバックアップ方法があります。一般に、これにはユーティリティを使用してデータベースシステムに直接クエリを実行し、データベース構造とデータをファイルシステムにコピーすることが含まれます。必要な権限は別として、これはテーブル構造情報とその中に含まれるデータを要求する通常のクライアントとそれほど違いはありません。
これらの「論理的な」（生のファイルを扱う物理的なツールとは対照的に）バックアップツールの主な利点の1つは、特定の時点でのデータの統合された一貫性のあるスナップショットを提示するデータベース自体の機能に依存できることです。このコンテキストでのバックアッププロセスはデータベースユーザーとして動作するため、この機能のコストは、他のクライアントとの限られたデータベースリソースの競合になることです。
レプリケーションはバックアップか？
一部のユーザーにとっての混乱点の1つは、レプリケーションが構成されている場合に、データベースにバックアップがまったく必要な理由です。
データベースレプリケーションは、あるサーバーから別のサーバーに変更ログをストリーミングして、別のシステムで変更をミラーリングする方法です。バックアップと同様に、これもシステムのデータの複製を作成します。ただし、レプリケーションは、いくつかの重要な理由から、安全なバックアップ戦略とは見なすべきではありません。
レプリケーションは、多数の障害シナリオにおいて、バックアップほどデータを保護しません。すべての変更がセカンダリサーバーにコピーされるようにする同じメカニズムは、プライマリデータベースのすべての問題も複製します。たとえば、プライマリデータベースでレコードが誤って削除された場合、その変更はダウンストリームレプリカでも実行されます。この同じプロセスは、破損したデータも拡散することを意味します。
レプリケーションがバックアップではないもう1つの理由は、データを復元する明白な機能がないことです。サーバー間で変更を双方向にレプリケートできますが、レプリケーションはデータの以前のバージョンを保持することに関係がなく、ログがローテーションされると、データの履歴ビューは失われる可能性があります。この「欠陥」は、レプリケーションが主にデータ保存ツールとしてではなく、組織が可用性とパフォーマンスを向上させるのに役立つように設計されていることを思い出させます。
とはいえ、レプリケーションはバックアップおよび災害復旧計画の重要なコンポーネントになる可能性があります。たとえば、レプリケーションは、プライマリデータベースでハードウェア障害が発生した場合に役立ちます。この場合、管理者はレプリケーションフォロワーをリーダーロールにすばやく昇格させ、クライアントリクエストへのサービスを継続して、時間のかかる復元手順を回避できます。一部の組織は、「遅延」レプリカも設定します。これは、一定期間が経過した後にのみ変更を適用するため、必要に応じてレプリカに切り替えることでデータベース状態をすばやく「ロールバック」できます。
レプリケーションがバックアッププロセスに関与することが多いもう1つのケースは、バックアップ操作のターゲットとしてです。多くの場合、プライマリサーバーよりもレプリカをバックアップする方が簡単です。たとえば、一貫性のあるファイルレベルのバックアップを取得するには、セカンダリデータベースを本番データベースのレプリカとして構成できます。データベースが同期されたら、レプリケーションを一時的にオフにして、本番トラフィックに影響を与えることなくレプリカのバックアップを実行できます。バックアップが完了したら、レプリケーションを再度オンにして、バックアップウィンドウ中に発生した変更でサーバーを再同期できます。
バックアップはセキュリティにどのように影響するか？
バックアップ戦略は、いくつかの異なる方法でセキュリティの考慮事項と交差します。
バックアップは、ランサムウェア攻撃のような特定のセキュリティインシデントから保護するのに役立ちます。たとえば、侵入者がプライマリデータベースの内容にアクセスして暗号化できる場合、過去のスナップショットにアクセスできると、状況に対処するためのより多くのオプションが得られる可能性があります。これがオプションになるためには、バックアップの宛先がソースデータとは異なるセキュリティコンテキストにある必要があり、攻撃者がバックアップにも影響を与えるのを防ぐ必要があります。
セキュリティポリシーをバックアップ戦略に反映させる必要があることを理解することが重要です。そうしないと、データをバックアップするときに機密情報を誤って公開する可能性があります。たとえば、本番システムが個人識別情報（PII）に関するセキュリティを実装している場合、バックアップは、そのレベルのセキュリティを維持する方法で構造化する必要があります。これは、異なるタイプのデータに異なる暗号化を使用したり、異なるタイプのデータに異なるバックアップ場所を使用したりすることを意味する場合があります。特定の状況によって、バックアップ戦略に組み込む必要のある保護の種類が決まります。
収集後、長期間にわたって価値がなくなる機密データの場合、そのデータをバックアップしないことを検討する価値があります。システムによって収集または生成された特定のタイプのデータは、その瞬間には役立つ可能性がありますが、長期的に保存するとリスクが高まる可能性があります。データから得られる価値がその最新性に密接に関連している場合は、バックアップセットから除外することをお勧めします。
バックアップの保存場所
バックアップ戦略を設計する際に決定する必要があることの1つは、実際のバックアップデータをどこに保存するかです。多くの異なる要因が、最適なバックアップ宛先のタイプに影響を与える可能性があります。
多くの場合、バックアップ宛先を選択することは、アクセスの容易さ、コスト、セキュリティ、および利便性の間のバランスを取ることです。オンサイトバックアップがあると、バックアップをすばやく実行できますが、物理ディスクの管理は、管理したくない以上のものになる可能性があります。さらに、オンサイトバックアップは、火災、洪水、盗難などのサイト固有の災害から保護しません。一方、クラウドベースのバックアップは便利ですが、特定のプロバイダーに縛られたり、コストがかかったり、復旧に時間がかかる可能性があります。
ほとんどの場合、リスクと利点のバランスを取り、データ損失に対する追加の保護を得るために、複数のストレージロケーションと媒体を使用することをお勧めします。例として、プライマリバックアップローテーションのターゲットとしてAmazon S3のようなオブジェクトストレージプロバイダーを使用できます。月に1回程度、これらのバックアップの一部をAmazon S3 Glacierのようなアーカイブストレージに長期間保管するために移動する場合があります。また、本番インフラストラクチャに使用しているプロバイダーとは異なるプロバイダーにデータをバックアップすることもできます。
バックアップのヒント
堅牢なバックアップ戦略の多くのコンポーネントについて説明したので、検討したい一般的なアドバイスをいくつか見てみましょう。
バックアップローテーション戦略を確立する
最初に把握したいことの1つは、バックアップをどのくらいの頻度で実行し、どの組み合わせのバックアップタイプが最も役立つかです。これを行うには、ストレージを不必要に使用せずに必要な頻度でバックアップできるように、バックアップローテーションを確立する必要があります。
バックアップローテーションは、基本的に、どの間隔でどのタイプのバックアップを実行するかを決定するスケジュールです。一般に、組織は、多数の最新のバックアップを保持しながら、アーカイブとして役立つ量の履歴バックアップを保持できるようにローテーションを実装します。スケジュールは、バックアップメカニズムのパフォーマンスへの影響、実行する必要のあるバックアップのタイプ、バックアップストレージの容量、およびコストに基づいて作成されることがよくあります。
かなり従来のバックアップ戦略の例として、データベースのフルバックアップを週に1回実行することから始めることができます。週の他の日には、増分バックアップをスケジュールして、特定の日付に復元できるようにすることができます。いつでも2つのフルバックアップと、その間のすべての増分バックアップを保持することをお勧めします。また、毎日のWALデータを継続的にアーカイブして、その日の特定の時点に復元できるようにすることもできます。
新しいバックアップが発生すると、最も古いバックアップは削除されるか、場合によっては長期ストレージに転送されます。これにより、必要な場合に履歴データにアクセスできますが、アーカイブは通常のバックアップローテーションには残りません。このようなシステムは、復旧のオプションを提供しながら、時間の経過に伴う総ストレージの増加を最小限に抑えるのに役立ちます。
バックアッププロセスをスケジュールして自動化する
バックアップローテーションを決定したら、プロセスの可能な限り多くをスケジュールして自動化することが重要です。バックアップが監督なしで発生するようにすることは、データを安全に保つための重要な部分です。
ほとんどのバックアップメカニズムにはスケジュールコンポーネントが含まれているため、ほとんどの場合、特別な労力は必要ありません。ただし、スケジュールされたバックアップが発生しない場合にアラートを出すメカニズムが整っていることを確認することが重要です。これは、バックアップが失敗した場合の電子メールアラート、または組織が監視するチャットチャネルへのpingである可能性があります。
バックアッププロセスを自動化するには、セキュリティ要件とアクセス要件を実装する最適な方法について検討する必要がある場合もあります。バックアップターゲットが本番システムからデータをプルするプルベースのバックアップシステムは理にかなっていますか？バックアッププロセスにはシステムへのどのようなタイプのアクセスが必要ですか？バックアップアカウントの範囲と影響を制限するために削除できるアクセス許可は何ですか？これらは、バックアップシステムを実装する際、特にプロセスを自動化する際に自問する必要のある質問の種類です。
バックアップを頻繁にテストする
堅牢なバックアップシステムにおいて最も重要であり、頻繁に無視される活動の一つがテストです。バックアップファイルがデータを正常に復元するために使用できることを定期的にテストする必要があります。バックアップが有効であることを保証できない場合、プロセス全体の価値は限定的であるか、または無価値です。
バックアップのテストには、バックアップされたデータをクリーンなシステム、または部分的または異なるデータを持つシステムに適用することが含まれます。これらのシナリオで復元できること、および復旧するために実行する必要がある正確なプロセスを知ることが重要です。これはバックアップアーカイブの整合性を検証するだけでなく、組織がストレスの高いシナリオでシステムを復元するために実行する必要がある手順を知ることを保証します。また、さまざまなタイプのデータ復旧にどれくらいの時間がかかるかについての貴重なデータも得られます。
バックアップは時々手動でテストされる場合がありますが、理想的には、復旧プロセスは残りのバックアップのために実装する自動化の一部であるべきです。バックアップはテスト環境に復元でき、データが期待どおりの値と構造を持っていることを確認するためにテストスイートを実行できます。バックアップテストを自動化する場合は、復元が失敗した場合にアラートを設定することを忘れないでください。
結論
このガイドでは、データベースのバックアップがなぜ非常に重要なのかを説明し、バックアップを実装する際に考慮する必要があるいくつかの事項を紹介しました。バックアップの利点、さまざまな種類と範囲のバックアップ、オンラインバックアップとオフラインバックアップの違い、レプリケーションがバックアップ戦略ではない理由などについて説明しました。
組織としてどのような選択肢があり、異なる決定がパフォーマンス、セキュリティ、可用性にどのように影響するかを理解しておくことは不可欠です。すべてのプロジェクトのバックアップニーズは異なりますが、データの問題から回復するために永続的で信頼できる長期ストレージが必要であるという共通点があります。要件を整理し、包括的な計画を策定する時間を取ることで、より少ない危険で安全かつ自信を持って前進することができます。
The Prisma Data Platformは、本番環境でのデータベースへのアクセスを簡素化するのに役立ちます。Prisma Clientを使用してデータベース接続を管理している場合、Prisma Data Platformは本番環境のワークロードをより簡単に管理するのに役立つ可能性があります。
