バックアップとディザスタリカバリ

1）定義と目的

バックアップ-その後のリカバリのためのデータ/構成の一貫したコピー（偶発的な削除、バグ、暗号ロッカー、災害から）。
DR （Disaster Recovery）-大事故（火災、地域の喪失、大規模な妥協）の後、インフラストラクチャ/サービスを作業SLOに復元するプロセス。
RPO （Recovery Point Objective）-時間内の最大許容データ損失（例：15分）。
RTO （Recovery Time Objective）-サービスリカバリタイムターゲット（例えば、30分）。

主な原則：レプリケーション≠バックアップ。レプリケーションは、すべてのコピーでエラーと暗号化をすばやく防ぎます。バックアップは、孤立した、検証された、潜在的に変更できないコピーです。

2）データの分類と批評性のレベル

アセットをクラスに分割する：

Tier-0（重要）：取引データベース、決済、貸借対照表の会計、秘密/PKI。
階層1（クリティカル）：サービス構成、キュー、CI/CDアーティファクト、コンテナレジスタ。
Tier-2（重要）：分析、レポート、セカンダリインデックス、ログアーカイブ。
Tier-3（補助）：キャッシュ、タイムデータ（再構築によって復元することができます）。

各クラスについて、RPO/RTO、保持期間、不変性要件、および場所を定義します。

3）保持戦略： ルール3-2-1-1-0

データの3コピー（prod+2バックアップ）。
2種類のメディア/ストレージタイプ。
1オフサイトコピー（異なる地域/クラウド）。
1不変/エアギャップ（WORM/オブジェクトロック/テープ）。
0リカバリチェックのエラー（通常のテスト）。

4）バックアップの種類

フル-フルコピー。遅い/高価ですが、すべての戦略のベース。
増分-最後のバックアップとの違い。ボリュームに最適です。
差分-最後のフルとの違い。より速い回復、より多くのスペース。
スナップショット-ボリューム/ディスク（EBS/ZFS/LVM）のスナップショット。app-consistentスナップショット（quiesce）が必要です。
PITR （Point-in-Time Recovery）-正確な時刻/LSNにロールバックするための基本的なバックアップ+ログ（WAL/binlog）。
オブジェクト/ファイル/比喩-特定のデータ型（VMイメージ、S3オブジェクト、DBダンプ）。

5）バックアップの一貫性

クラッシュコンシステント：突然のシャットダウンの後のように-ステートレス/ジャーナル化されたFSに適しています。
App-consistent：アプリケーションの「フリーズ」操作（fsfreeze/pre-postスクリプト）→保証された整合性。
データベースの整合性：バックアップツールのAPI （pgBackRest、 XtraBackup）、ホットバックアップモード、フリーズするチェックポイント。

6）暗号化、キーおよびアクセス

すべてのコピーのAt-restおよびin-transit暗号化。
KMS/HSMのキー、ポリシーによる回転（90/180日）、環境によってキーを分離します。
職務の分離：誰がバックアップを作成/削除するか≠誰がそれらを復号/読み取ることができます。
ターゲットコピーと同じ信頼ドメインに復号キーを保持しないでください。

7）変更不可能なコピーとランサムウェアの保護

オブジェクトロック/WORM（コンプライアンス/ガバナンス）保持および法的保持。
エアギャップ：孤立/オフラインストレージ（フィード、オフラインクラウド/アカウント）。
「遅延アクティベーション」削除ポリシー、MFA-Delete、バックアップバケットの個別アカウント、パブリックアクセスの禁止。
マウント前にマルウェア/妥協の指標の検証。

8）頻度、スケジュールおよび保持

GFS （Grandfather-Father-Son）：毎日の増分、毎週のfull/diff、毎月のフルと長いストレージ。
RPOは、増分とWAL/binlogアーカイブの頻度を決定します（例えば、5〜15分ごと）。
ストレージ：重要-≥ 35-90日+毎月12-36ヶ月（法的要件）。
季節のピークは個別のコントロールポイントです（プロモーション/リリース前）。

9） DRモデルとシナリオ

アクティブ-アクティブ：両方のリージョンがトラフィックを提供します。最小限のRTO、データの崩壊は厳密な紛争ポリシーを必要とします。
アクティブパッシブ（ホット/ウォーム）：ホット-展開と同期（RTO分）、暖かい-部分的に準備ができて（RTO時間）。
Cold：ストアコピーとTerraform/Ansible/images、オンデマンドで調達（RTO day+）。
DRaaS：別ゾーンのVM/ネットワーク/アドレスのプロバイダ・オーケストレーション。

10） Feiloverのオーケストレーションと回復の優先順位

起動優先度：ネットワーク/VPN/DNS→シークレット/KMS→データベース/クラスタ→キュー/キャッシュ→アプリケーション→周辺/CDN→分析。
自動化：スクリプト/runbookアクション、DR環境用のTerraform/Ansible/Helm/ArgoCDプロファイル。
データ：DB PITR→reindex/replica→warm cache→スキーマ互換性フラグを使用したサービスの起動。
DNS/GSLB：事前にTTLをダウングレードし、検証とシナリオを切り替えます。

11）バックアップ検証テスト

スケジュールでテストを復元：バックアップのN％サンプリング、サンドボックス展開、自動スキーマ/不変量チェック。
完全なDRドリル（ゲームデー）：リージョン/AZを無効にし、ライブトラフィック（またはトラフィックシャドウ）でRTO/RPOをチェックします。
整合性テスト：ハッシュディレクトリ、チェックサム、すべてのレイヤー（フル+チェーン）を読み込もうとします。
ドキュメントレポート：時間、ステップ、異常、目標からのギャップサイズ、修正。

12）コア技術の実践

データベース

PostgreSQL：ベースバックアップ+WALアーカイブ（PITR）、 pgBackRest/Barmanツール；レプリケーションスロット、監視'lsn'。
MySQL/MariaDB： Percona XtraBackup/Enterprise Backup、 binlog archiving。
MongoDB： 'mongodump'（論理コピー用）+大きなセットのスナップショット；PITRのためのOplog。
Redis：重要なRDB/AOF （Redisがキャッシュだけではない場合）、より頻繁に-事故のためのソース+スナップショットからの論理的な再構築。
Kafka/Pulsar：メタデータバックアップ（ZK/Kraft/BookKeeper）、ディスクスナップショット、トピック/ログミラーリング。

Kubernetes

リソース/ボリューム（CSIスナップショット）のetcdスナップショット+Velero).

バックアップの秘密/PKIを個別に（Vaultスナップショット）。
画像の個別のレジスタ：不変タグ。

VMとファイルシステム

ZFS： 'zfs snapshot'+'zfsは| zstd | send-recv'の増分を送信し、'scrub'をチェックします。
LVM/EBSスナップショットとプリスクリプト/ポストスクリプト（app-consistent）。
オブジェクトストア-バージョン+オブジェクトロック。

13）バックアップのカタログ作成とバージョン管理

ディレクトリ（メタデータカタログ）：what、 where、 when、 then、 than then、 hashes、 KMS key、 owner、 retention period。
'env=prod' stage'、'system=db 'k8s' vm'、'tier=0|1|2'、'retention=35d|1y'。
ゴールドチェックポイント：移行前/DDL/大規模リリース。

14）観測可能性と指標

ジョブ成功率：％成功/失敗、理由。
バックアップ/リストア時間、ウィンドウ幅。
RPO-actual：ログ・アーカイブ・ログ（WAL/binlog） p95。
整合性：テストされたチェーンの割合、ハッシュ和解エラー。
コスト：クラス別のストレージ容量、重複排除/圧縮比。
DR-readiness：演習の頻度と結果（合格/失敗）。

15）アクセスおよびコンプライアンスポリシー

バックアップストレージのための別々のアカウント/プロジェクト；NaCの原則に従ってアクセス（本番アカウントからの削除/暗号化は許可されていません）。
アクセス/変更のログ（監査証跡）、大量削除/retshnの変更のアラート。
コンプライアンス：GDPR（アーカイブと削除する権利）、PCI DSS（暗号化、キー、セグメンテーション）、ローカルレギュレータ。

16）アンチパターン

「レプリカがあります。つまり、バックアップは必要ありません。」

不変/エアギャップなし：1つのエラー/マルウェアがすべてを消去します。
prodと同じアカウント/リージョンのバックアップ。
リカバリをチェックしないでください（バックアップ「チェック前に死んでいます」）。
カタログ化とバージョン管理→事故の混乱なし。
すべての環境で共有された暗号化キー。
データベース用のapp-consistentモードなしのスナップショット。
バックアップウィンドウはピークと交差します（p99とSLOに影響します）。

17）実装チェックリスト（0-60日）

0-10日

システム/データのインベントリ、criticalityクラス。
クラスごとにRPO/RTOターゲットを設定します。
Tier-0/1、 WAL/binlogアーカイブに対してfull+incrementalを有効にします。
ポストバックアップ：別の地域/アカウント+KMS暗号化を有効にします。

11-30日

クリティカルコピーの不変（Object Lock/WORM）を設定します。
カタログ、タグ、レポートを入力します。失敗および遅れの雑誌への警報。
最初のDR-drill：隔離された環境でバックアップから別のサービスを復元します。

31-60日

runbookを自動化：Terraform/Ansible/HelmプロファイルDRR。
定期的な復元テスト（週/月）+四半期ごとに完全なDRシナリオ。
コスト重複排除/圧縮/ストレージライフサイクルの最適化。

18）成熟度の指標

テストの復元：≥（選択的）、Tier-0 1/月-フルシナリオの≥ 1/週。
不変カバレッジTier-0/1=100％。
RPO実際のp95 ≤ターゲット（例：≤ 15分）。
DR演習のRTO-actual ≤ターゲット（例≤ 30分）。
ディレクトリの完全性=100％（各バックアップは説明され、チェックされます）。
インシデント・ツー・リストア-検出からリカバリの開始までの時間。

19）例（スニペット）

PostgreSQL-PITRポリシー（アイデア）：

bash base backup once a day pgbackrest --stanza = prod --type = full backup archive WAL every 5 minutes pgbackrest --stanza = prod archive-push restore to time pgbackrest --stanza = prod restore --type = time --target =" 2025-11-03 14:00:00 + 02"

MySQL-増分ループ：

bash xtrabackup --backup --target-dir=/backup/full-2025-11-01 xtrabackup --backup --incremental-basedir=/backup/full-2025-11-01 --target-dir=/backup/inc-2025-11-02 xtrabackup --prepare --apply-log-only --target-dir=/backup/full-2025-11-01 xtrabackup --prepare --target-dir=/backup/full-2025-11-01 --incremental-dir=/backup/inc-2025-11-02

Kubernetes-Velero（マニフェストのアイデア）：

yaml apiVersion: velero. io/v1 kind: Backup metadata: { name: prod-daily }
spec:
includedNamespaces: ["prod-"]
ttl: 720h storageLocation: s3-immutable

S3オブジェクトロック（サンプルライフサイクルポリシー）：

json
{
"Rules": [{
"ID": "prod-immutable",
"Status": "Enabled",
"NoncurrentVersionExpiration": { "NoncurrentDays": 365 }
}]
}

20）コミュニケーションおよび運用上の役割

インシデントコマンダー、Comms Lead、 Ops Lead、 DB Lead、 Security。
ステークホルダー/レギュレータ/ユーザーのためのメッセージテンプレート。
アクションを伴う死後：彼らは数分を失った場所、自動化を改善する場所。

21）結論

バックアップとDRの信頼性の高いループは「コピーを作成」ではなく、サイクルです。分類→目標RPO/RTO→マルチレベルおよび不変コピー→自動化されたランブック'および→定期的な復元と演習。3-2-1-1-0に準拠し、バックアップからレプリケーションを分離し、キーの暗号化と分離、文書化と検証を行います。「ブラックスワン」でも、予測可能なダウンタイムと最小限のデータ損失で管理可能なプロセスに変わります。

バックアップとディザスタリカバリ