データベース・バックアップ：種類、方法、ベストプラクティス

データベース・バックアップとは、データベースのデータ、構造、構成のリカバリ可能なコピーを作成し、損失、破損、不正な破壊から保護するプロセスです。トランザクションの実行、顧客へのサービス提供、ビジネスクリティカルな記録の保存をデータベースに依存している組織にとって、バックアップの失敗や欠落は、ダウンタイムや数百万ドルの収益損失につながります。

2024 年の ITIC の調査によると、企業の 41% が 1 時間のダウンタイムによる損失額を 100 万ドルから 500 万ドルを超えると見積もっています。ランサムウェアはリスクを高めます。Verizon社の 2025 Data Breach Investigations Report によると、分析対象となったデータ侵害の 44% でランサムウェアが確認され、前年比で 37% 増加しています。

適切に設計されたデータベース・バックアップ戦略により、これらの脅威にさらされるリスクを軽減します。この記事では、データベース・バックアップの仕組み、主要なバックアップ・タイプ、リカバリ目標に関する戦略の計画方法、信頼性の高いデータ保護とコストのかかるギャップを区別するベスト・プラクティスについて解説します。

データベース・バックアップの仕組み

データベース・バックアップは、データのポイントインタイム・コピーをキャプチャし、本番環境とは別に保存します。このプロセスでは、データ・ファイル、トランザクション・ログ、構成メタデータなどのデータベース・ファイルを読み取って、ローカル・ディスク、ネットワーク接続ストレージ（NAS）デバイス、ストレージ・エリア・ネットワーク（SAN）、クラウド・オブジェクト・ストレージなどのターゲット・ロケーションに書き込みます。

ほとんどのデータベース管理システム（DBMS）は、ネイティブなバックアップ・ユーティリティを提供します。SQL Server は、BACKUP DATABASE コマンドを使用します。PostgreSQL は、論理エクスポートには pg_dump、物理コピーには pg_basebackup に依存しています。Oracle は Recovery Manager (RMAN)を使用し、MySQL は物理バックアップ用に MySQL Enterprise Backup ツールと並行して mysqldump を提供します。

バックアップ・プロセスは、データベースがライブ・クエリを提供する間はオンライン（ホット）で実行できます。データベースがシャットダウンしている間はオフライン（コールド)で実行できます。ホット・バックアップは、継続的な可用性を必要とする本番環境の標準です。コールド・バックアップはシンプルかつ高速ですが、ダウンタイムを余儀なくされるため、SLA（サービスレベル・アグリーメント）が厳しいシステムでは実用的ではありません。

方法を問わず、バックアップは全て本番データベースとは別に保存する必要があります。ディスク障害、ランサムウェア攻撃、偶発的な削除によってプライマリ・データが破壊された場合、同じストレージ・システムに格納されたバックアップは保護されません。

データベース・バックアップの種類

適切なバックアップ・タイプの選択は、データベース・サイズ、データ変更の頻度、データ損失の許容度、リカバリの迅速さによって異なります。ほとんどのエンタープライズ環境は、複数のタイプをスケジュールされたローテーションに統合します。

フル・バックアップ

フル・バックアップは、全データ・ファイル、スキーマ・オブジェクト、ストアド・プロシージャを含むデータベース全体の完全なコピーを作成します。単一のバックアップ・セットをリストアするだけという、最もシンプルなリカバリ・パスを提供しますが、ストレージの消費も最も大きく、完了までには最も時間がかかります。フル・バックアップは通常、増分および差分戦略のベースラインとして機能します。

増分バックアップ

増分バックアップは、あらゆるタイプ（フルや増分）の最後のバックアップ以降に変更されたデータのみをキャプチャします。このアプローチは、ストレージの使用が少なく、フル・バックアップよりも高速に完了します。トレードオフとして、リストアには、最後のフル・バックアップに加えて、チェーン内の増分バックアップが順番に必要です。チェーン内のリンクが破損している場合、リストアは失敗します。

差分バックアップ

差分バックアップは、中間バックアップに関係なく、最後のフル・バックアップ以降の全ての変更を記録します。フルと増分の中間に位置する方式です。ストレージは増分よりも多く必要になりますが、最新のフル・バックアップと最新の差分だけが必要なため、リカバリはシンプルです。多くの組織は、週に 1 回フル・バックアップを実行し、毎日差分バックアップを実行するようスケジュールを設定しています。

物理バックアップと論理バックアップ

物理バックアップは、ファイル・システムまたはブロック・レベルで、データベース・ファイルをそのままコピーします。高速な作成とリストアにより、大規模データベースの標準となっています。論理バックアップは、データベースを SQL ステートメント（CREATE TABLE、INSERT）または構造化ダンプとしてエクスポートします。異なるデータベース・バージョンやプラットフォーム間での移植性に優れていますが、実行やリストアが遅くなります。堅実な戦略では、物理バックアップを毎日のリカバリに、論理バックアップを長期アーカイブやクロスプラットフォームの移行に使用することがよくあります。

データベース・バックアップとデータベース・レプリケーション

バックアップとレプリケーションにはさまざまな目的がありますが、混同されることがよくあります。レプリケーションは、データベースの同期コピーを別のサーバーに保持します。通常は高可用性と読み取りスケーリングを目的としています。プライマリ・サーバーに障害が発生した場合は、レプリカがほぼ即座に引き継がれます。

しかし、レプリケーションはバックアップではありません。破損したテーブル、偶発的な DROP DATABASE コマンド、ランサムウェアによる暗号化イベントは、正当な変更と同様に高速にスタンバイに複製されます。レプリケーションは、ハードウェアの障害から保護します。バックアップは、データ損失から保護します。エンタープライズ環境には両方が必要です。

RTO と RPO：データベース・バックアップ戦略を計画する

あらゆるバックアップ戦略の基盤となる指標が、目標復旧時間（RTO：Recovery Time Objective）と目標復旧時点（RPO：Recovery Point Objective）の 2 つです。

RTO は、障害発生後にデータベースをリストアし、操作を再開するための最大許容時間を定義します。RPO は、データ損失の最大許容量を定義し、時間単位で測定します。1 時間の RPO は、最大 1 時間のトランザクション損失に耐えることを意味します。

これらの 2 つの指標は、バックアップの頻度、種類、ストレージの場所に関するあらゆる決定を左右します。

• ほぼゼロの RPO では、トランザクション・ログの継続的なバックアップまたはストレージ・レベルのスナップショットを数分ごとに取得する必要があります。
• 標準的なディスクベースのリストアでは 4 時間の RTO を達成できますが、1 時間未満の RTO では、通常、事前ステージングされたレプリカまたはインスタント・リカバリ技術が必要です。
• 予算とインフラの制約が、現実的なものを決定します。同期レプリケーションにより RPO をゼロにすることは技術的に達成できますが、コストとレイテンシーの影響は、全てのワークロードに対してそれを正当化するものではありません。

データベースをビジネスの重要度に基づいて階層に分類し、RTO と RPO ターゲットを各階層に割り当てることから始めます。全てのデータベースが同じレベルの保護を保証するわけではありませんが、全てのデータベースに計画が必要です。

3-2-1-1-0 バックアップ・ルール

従来の 3-2-1 バックアップ・ルールはデータを 3 つコピーし、2 つの異なるメディア・タイプに保存し、そのうち 1 つをオフサイトに保管する方法で、長年にわたってゴールド・スタンダードでした。写真家のピーター・クロッグは、テープがまだプライマリ・バックアップ・ターゲットであり、ランサムウェアが主流の懸念ではなかった 2009 年にそれを普及させました。

最新の 3-2-1-1-0 ルールは、このフレームワークを拡張し、今日の脅威の状況にあわせて 2 つの要素が追加されています。

• 3 つのデータ・コピー（オリジナルと少なくとも 2 つのバックアップ）
• 2 種類のメディア・タイプ（ディスクやクラウド・オブジェクト・ストレージなど）
• 1 つのコピーをオフサイトに保管（プライマリ・データセンターとは地理的に分離）
• 1 つのコピーをオフラインまたは変更不能な状態で保管 （ランサムウェアによる暗号化や削除ができない、エアギャップまたは追記不可のストレージ）
• 0 エラー（定期的なリストア・テストで検証されるため、バックアップが実際に機能していることを確認）

最も重要な強化点は、「1 つの変更不能なコピー」です。最新の攻撃では、バックアップ・リポジトリをターゲットにし、本番データを暗号化する前にリカバリ・オプションを排除します。

データベース・バックアップのベストプラクティス

一貫した自動化とスケジュール

手動バックアップは信頼できません。DBMS の組み込まれたスケジューリング・ツール（SQL Server Agent、pg_dump を使用した cron ジョブ、RMAN スケジューリング）や集中バックアップ・プラットフォームを使用して、一貫したスケジュールを適用します。一般的な構成としては、週に 1 回フル・バックアップを実行し、毎日差分バックアップを実行するとともに、15～30 分間隔でトランザクション・ログをバックアップします。

テスト・リストアを定期的に実施

一度もリストアしたことのないバックアップは、信頼できないバックアップです。ミッションクリティカルなデータベースでは、少なくとも毎月リストア・テストをスケジュールします。別の環境にリストアし、データの整合性を検証し、RTO ターゲットに対する実際のリカバリ時間を記録します。

保存中および転送中のバックアップを暗号化

データベース・バックアップには、本番システムと同じ機密データが含まれています。保存中のバックアップ・ファイルには AES-256 暗号化を適用し、ネットワーク経由で転送されるバックアップ・データには TLS を使用します。暗号化は、HIPAA、GDPR、PCI DSS などの規制の下でコンプライアンス要件として求められることがよくあります。

障害の監視とアラート

バックアップ・ジョブは、多くのチームが認識している以上に、気付かれないまま失敗することがあります。バックアップ・ウィンドウの欠落、ジョブの失敗、バックアップ・サイズの予期しない変更を警告する監視を設定します。バックアップ・サイズが急激に低下すると、データ損失がまだ検出されていない可能性があります。

保持ポリシーの定義と実施

保持ポリシーは、バックアップ・コピーをリサイクルまたは削除するまでの保持期間を決定します。適切な保持期間は、コンプライアンス要件、ストレージ容量、未検出の問題から復旧する必要がある期間によって異なります。多くの組織は、30 日間毎日バックアップを行い、90 日間は毎週バックアップを行い、1 年間は毎月バックアップを行います。

バックアップ・ストレージを本番から分離

バックアップは、本番ストレージから物理的および論理的に分離されたインフラに格納します。これは、異なるストレージ・アレイ、異なるネットワーク・セグメント、理想的には異なる地理的位置を意味します。ランサムウェアが本番ストレージを暗号化し、バックアップが同じ SAN 上に存在すると、両者が侵害されます。

データベース・バックアップに関する一般的な課題

計画的なバックアップ戦略であっても、現実的な障害となります。これらの課題を事前に理解しておくことで、課題を解決する設計が可能になります。

• データベースの大容量化により、バックアップに要する時間が長くなる：マルチテラバイトのデータベースは、バックアップに数時間かかることがあります。特に、ネットワーク・ストレージを介した従来のフル・バックアップでは、そうです。ブロックレベルの増分バックアップ、ストレージレベルのスナップショット、並列バックアップ・チャネルは、バックアップ・ウィンドウを短縮するのに役立ちます。
• バックアップの無秩序な増加は、コストの増大を招く：明確な保持ポリシーと重複排除がなければ、バックアップ・ストレージのコストは本番データよりも速く増大します。重複排除と圧縮は、階層型ストレージ（高速ディスクでのホット・バックアップ、安価なオブジェクト・ストレージでの老朽化バックアップ）と組み合わせることで、支出の制御に役立ちます。
• マルチデータベース環境は複雑さが増す：ほとんどの企業は、SQL Server、Oracle、PostGreSQL、MySQL、MongoDB などの NoSQL システムを組み合わせて実行しています。それぞれに独自のバックアップ・ツールとリストア手順があります。複数のデータベース・エンジンをサポートする一元化されたバックアップ・プラットフォームは、運用を簡素化し、ギャップのリスクを低減します。
• クラウドネイティブなデータベースには、さまざまなアプローチが必要：Amazon RDS、Azure SQL Database、Google Cloud SQL などのマネージド・サービスは、自動バックアップを処理しますが、デフォルトの保持ウィンドウ、クロスリージョンのレプリケーション・オプション、特定の時点へのリカバリ方法を理解する必要があります。RPO や保持設定をカスタマイズすることなく、プロバイダのデフォルト設定に完全に依存することは、よくある見落としです。

データベース・バックアップの未来

データベース・バックアップは、ジョブベースのスケジュールされた運用から、ストレージに統合された継続的な保護に移行しています。継続的データ保護（CDP）は、データベースへの全ての変更をリアルタイムでキャプチャし、最後のスケジュールされたバックアップ・ウィンドウだけでなく、任意の秒単位の時点まで復旧できるようにします。

ストレージネイティブのスナップショットも、バックアップの経済性を変えています。スナップショット技術は、データセット全体をコピーする代わりに、変更されたブロックのみをキャプチャし、データベースのサイズに関係なく数秒で完了します。不変スナップショット・ポリシーと組み合わせることで、ランサムウェア対策を内蔵したほぼゼロの RPO を実現します。

AI 駆動の異常検知は、防御のもう 1 つの層として浮上しています。これらのシステムは、サイズ、期間、変更率などのバックアップ・メタデータ・パターンを分析することで、バックアップ・コピーに伝播する前に、異常なアクティビティ（ランサムウェアの暗号化イベントなど）にフラグを付けることができます。

まとめ

データベース・バックアップは、組織を恒久的なデータ損失から守る最後の防衛線です。完全バックアップ、増分バックアップ、差分バックアップを適切に組み合わせた強力なバックアップ戦略は、定義された RTO および RPO ターゲットに整合し、3-2-1-1-0 フレームワークで強化され、日常的な IT タスクからのバックアップを真の事業継続性機能に変換します。

対応を誤った場合のコストは、数時間に及ぶダウンタイム、収益の損失、規制上のリスクとして表れます。適切な対策にかかるコストは、復旧不能なインシデントが一度発生した場合の損失に比べれば、ほんの一部にすぎません。

Everpure の FlashArray と FlashBlade は、データセットのサイズにかかわらず、性能への影響なしで数秒で完了するストレージネイティブのスナップショットを提供します。ユーザー、管理者、攻撃者が削除または変更できない不変のコピーを作成する Everpure の SafeMode スナップショットと組み合わせることで、高速性とランサムウェア・レジリエンスの両方を考慮したバックアップ・アーキテクチャが得られます。Evergreen//One のストレージ・アズ・ア・サービスと組み合わせることで、バックアップ容量を初期のインフラ投資なしで拡張できます。