データベースシステムは、運用中いつでも必要なときに、関連データを保存して一貫した可用性を確保する責任があります。ほとんどの企業は、データベース障害、セキュリティブリッジ、人為的エラー、または本番環境のオペレーティングノードを完全に破壊する可能性のある壊滅的な障害の結果としてデータが失われた後、ビジネスを継続できません。データベースを同じデータセンターに保持すると、これらの暴動が発生した場合にすべてのデータが失われるリスクが高くなります。
レプリケーションとバックアップは、データの高可用性を確保するために一般的に使用される方法です。 2つのどちらを選択するかは、データが変更される頻度によって異なります。データが頻繁に変更されておらず、バックアップファイルがそれほど多くないことが予想される場合は、バックアップが最適です。一方、レプリケーションは、リクエストのレイテンシーを減らすことで特定の場所にデータを提供するなど、関連する他のメリットに加えて、頻繁にデータを変更する場合に適しています。ただし、レプリケーションとバックアップの両方を使用して、障害が発生した場合の復元中のデータの整合性と一貫性を最大限に高めることができます。
データベースのバックアップは、本番環境で調整することなく、開発、オープンアクセス、およびステージングのための新しい環境を作成するための基本を提供するための復元ポイントを提供するだけでなく、より多くの利点をもたらします。開発チームは、新しく統合された機能をすばやく簡単にテストして、開発を加速できます。結果のデータに一貫性がない場合は、コードエラーのチェックポイントにバックアップを使用することもできます。
バックアップは特定の時点で作成され、その時点でデータベースがホストしているデータを反映します（データベースのスナップショットとして機能します）。特定の時点でデータベースに障害が発生した場合、最後のバックアップファイルを使用して、障害が発生する前の時点にDBをロールバックできます。ただし、回復を行う前にいくつかの要因を考慮する必要があり、それらには次のものが含まれます。
これは、バックアップおよび復元プロセス中に失う準備ができているデータの量を判別するために実行されます。たとえば、ユーザーデータとクリックストリームデータがある場合、クリックストリーム分析よりもユーザーデータが優先されます。クリックストリーム分析は、復元後にアプリケーションの操作を監視することで再生成できるためです。銀行情報、生産業界データ、通信システム情報などの重要なデータには継続的なバックアップが推奨され、短い間隔で実行する必要があります。データが頻繁に変更されない場合、たとえば6か月または1年前に復元されたスナップショットを作成すると、データの多くを失う方が費用がかからない可能性があります。
これは、復元操作を実行できる速度を分析および決定するためのものです。リカバリ中、アプリケーションにはダウンタイムが発生します。これは、リカバリする必要のあるデータの量にも正比例します。大量のデータを復元する場合は、時間がかかります。
分離は、論理構成および物理的に、プライマリデータベースサーバーからのバックアップスナップショットがどれだけ近いかを示す尺度です。それらがたまたま十分に接近している場合、データベースが破壊されると同時に破壊される可能性が高くなるという犠牲を払って、回復時間が短縮されます。サーバーの中断がバックアップに影響を与えないようにするために、バックアップと本番環境を同じシステムでホストすることはお勧めできません。
シャーディングによる分散データベースシステムの場合、バックアップがいくらか複雑になり、システム全体で書き込みアクティビティを一時停止する必要がある場合があります。シャードが異なれば、異なるタイプのバックアップが異なる時間に終了します。論理バックアップとスナップショットバックアップを検討する
- シャードはサイズが異なるため、異なる時間に終了します
- MongoDBベースのダンプは--oplogを無視するため、各シャードで一貫性がありません。
- 一部のシャードが復元プロセスを完了していない可能性があるという理由だけで、バランサーがオンになっているはずのときに、バランサーがオフになっている可能性があります
一部の人々は、復元の場合に機能するかどうかをテストせずにバックアップを実行します。本質的にバックアップは、復元機能を提供することです。そうしないと、役に立たなくなります。常に異なるテストサーバーでバックアップを実行して、それらが機能しているかどうかを確認する必要があります。
バックアップは、データベース自体からのデータとして多くのサイズをとる傾向があり、システムの全体的なストレージリソースを削減する可能性のある多くの不要なスペースを占有しないように十分に圧縮する必要があります。それらはzipファイルにアーカイブできるため、全体のサイズが小さくなります。さらに、前述のように、データベース自体からさまざまなデータセンターにバックアップをアーカイブできます。
バックアップによって、データベースのパフォーマンスが低下する可能性があるという点で、データベースのパフォーマンスが異なる場合があります。その場合、継続的なバックアップはある程度の後退をもたらすため、メンテナンスウィンドウの枯渇を回避するためにスケジュールされたバックアップに変換する必要があります。ほとんどの場合、バックアップをサポートするためにセカンダリサーバーが展開されます。この場合：
- mongodbはmongodumpコマンドを使用するときにoplogなしでread-uncommittedを使用するため、単一ノードを一貫してバックアップできません。その場合、バックアップは安全ではありません。
- 関連するデータの量に応じてプロセス自体に時間がかかり、接続されているアプリケーションでダウンタイムが発生するため、バックアップにセカンダリノードを使用します。 Oplogも更新する必要があるプライマリを使用する場合、そのダウンタイム中に一部のデータが失われる可能性があります
- 復元プロセスには時間がかかりますが、割り当てられるストレージリソースはごくわずかです。
多くの場合、バックアップ中に一部のデータが必要ない場合があります。たとえば、目標復旧時点の例では、目標復旧を実行して、ユーザーがクリックしたデータを除外する必要があります。そのためには、関心のないデータを柔軟に除外できる部分バックアップ戦略が必要です。これにより、リカバリ期間と無駄になるリソースを削減できます。増分バックアップは、スナップショットごとに完全バックアップを作成するのではなく、変更されたデータ部分のみが最後のスナップショットからバックアップされるようにする場合にも役立ちます。
バックアップ戦略は、時間の経過とともに簡単に設定および維持できる必要があります。バックアップをスケジュールして、必要なときに手動でバックアップを実行する必要がないようにすることもできます。
データベースシステムは、十分に確立されたバックアップシステムが設置されている場合にのみ、「死後の世界」を保証します。データベースは、データの損失または破損につながる可能性のある壊滅的な要因、人為的エラー、またはセキュリティ攻撃によって破壊される可能性があります。バックアップを実行する前に、サイズと重要性の観点からデータの種類を検討する必要があります。バックアップが同時に破棄される可能性を減らすために、データベースと同じデータセンターにバックアップを保持することは常にお勧めできません。バックアップによってデータベースのパフォーマンスが変わる可能性があるため、使用する戦略とバックアップを実行するタイミングに注意する必要があります。プライマリノードでバックアップを実行しないでください。バックアップ中にシステムのダウンタイムが発生し、重要なデータが失われる可能性があります。