数十TBのデータベースのバックアップと災害復旧

Question

IT Interview Practice · Accepted Answer

**定期スナップショットと継続的なWALアーカイブを組み合わせてポイントインタイムリカバリを実現し、オフサイト/クロスリージョンにレプリケートし、明示的なRPO/RTO目標に対する定期的なリストア訓練でそれを証明します。** リストアしたことのないバックアップは計画ではなく願望です。

## アーキテクチャ

```text
Primary DB ──snapshot (daily)──▶ Object store (S3) ──cross-region replicate──▶ DR region
     │                               ▲
     └── WAL/binlog stream ──────────┘   (continuous, PITR to any second)
                                          │
                          restore drill ──┴──▶ verified restore ─▶ measure RTO, checksum RPO
```

## 仕組み

- **スナップショット**はボリューム/クラスタの完全コピーです（例：日次EBSスナップショットや `pg_basebackup`）。リストアの*基点*ですが、昨夜までしか戻せないと1日分の書き込みを失います。
- **WAL / binlogアーカイブ**は最後のスナップショット以降のすべての変更を継続的にオブジェクトストアへストリームします。リストア = スナップショット + 選んだ任意の秒までのWALリプレイ。これが**PITR（ポイントインタイムリカバリ）**です。10:32:04、不正な `DELETE` の直前の瞬間まで復旧します。
- **オフサイト / クロスリージョン。** DBと同じリージョンのバックアップはリージョンとともに死にます。第2リージョンにレプリケート（S3クロスリージョンレプリケーション）し、リージョン障害やランサムウェアが両方を奪わないようにします。
- **リストア訓練。** 定期的にスクラッチ環境へリストアし、所要時間（**RTO**）と失われうるデータ量（**RPO**）を測定し、本番とチェックサム照合します。

## RPO対RTO

- **RPO（目標復旧地点）** = 許容できるデータ損失量。WALを5分ごとにアーカイブ → RPO ≈ 5分。同期レプリカ → RPO ≈ 0。
- **RTO（目標復旧時間）** = 復旧までの速さ。S3から20TBのリストアは数時間かかりえます。ウォームスタンバイレプリカはRTOを数分に短縮します。

## 面接での観点

面接官は、あなたが**スナップショット単体では不十分**（その間のデータ損失）だと知っているか、**RPO/RTOを数値で定義**できるか、**リストアをテスト**するかを探ります。優れた回答は、テストされていないバックアップは必要なときにこそ失敗すると強調し、便宜ではなく*ビジネス*のRPO/RTOから戦略を選びます。罠：リードレプリカをバックアップと見なすこと。レプリケーションは `DROP TABLE` も忠実にコピーします。

## トレードオフと障害

- **コスト対RTO。** ウォームなクロスリージョンスタンバイは数分のRTOを与えますがインフラコストが倍増します。コールドなS3リストアは安いが遅いです。ビジネスが実際に必要とする層を買います。
- **バックアップ負荷。** ホットな20TB DBのスナップショットはI/Oを追加します。レプリカからスナップショットを取ります。
- **サイレントな破損。** WALは破損ページをアーカイブしうる。定期的なフルリストア + チェックサムがそれを捕らえます。
- **保持とコンプライアンス。** 法的要件のため十分な履歴を保つ（例：35日のPITR + 月次アーカイブ）。安価な長期保管にはGlacier。
- **不要な場合：** 小さなDBは夜間の `pg_dump` をS3へで十分です。データ損失が実際の金額で測られるまで、フルWAL + クロスリージョンスタンバイは過剰です。

アーキテクチャ

仕組み

RPO対RTO

面接での観点

トレードオフと障害

関連する質問