backup-strategy

バックアップ戦略

ジョブをスケジュールしたり、世代バックアップを削除したりする前に、復元可能なデータと復旧目標を定義します。選択したディレクトリのアーカイブはマシン全体のイメージではありません。また、アップロードの成功や gzip のチェックは、アプリケーションの復元テストではありません。

計画を立てる

• 必要なファイル、アプリケーションのデータベース、シークレット、所有権／ACL、目標復旧時点と目標復旧時間、保持期間、暗号化キーの管理、独立した保存先を特定します。
• データベースの整合性を確保し、スキーマが安定した時間帯を設けます。稼働中のデータベースデータファイルを汎用の tar アーカイブにコピーして、整合性が取れていると見なしてはいけません。
• ファイルとデータベースの両方の成果物をリモートストレージに保存する方法を定めます。インシデントの想定に応じて、適切な範囲の認証情報と保持／バージョン管理／不変化を使用します。リモートストレージも、侵害された認証情報を通じて削除される可能性があります。
• 設定、スケジュール、アップロード、リモートポリシーの変更、保持データの削除は、それぞれ別個の承認済みアクションとして扱います。該当するアクションに対してすでに付与された承認を再利用してください。監査だけでは、これらのアクションは承認されません。

ストレージの判断、障害対応、スケジュール、安全な復元については、references/backup-locations.md をお読みください。

ファイルとデータベースの成果物を作成する

ヘルパーはデフォルトでプレビューを行い、明示的な入力を必須とし、アクセス制限付きの出力ファイルとチェックサムファイルを作成し、バックアップディレクトリ内でジョブを直列化して、検証済みの結果のみを公開します。オプションの GPG 暗号化では、事前に用意した公開鍵を使用します。暗号化に失敗した場合、検証済みの圧縮元データは保護された保留ファイルとして保持されます。

ファイルバックアップをプレビューします。

bash scripts/backup-full.sh --path /etc --path /var/www --backup-dir /backup/files --dry-run

データの範囲と保存先が承認されたら、--apply を使用します。選択した暗号化キーには --gpg-recipient を追加します。入力が不足または無効な場合、必要なデータを暗黙に除外せず、処理は失敗します。GNU tar は、選択したディレクトリのメタデータを取得します。復元先での復元権限、ACL、拡張属性を確認してください。

MySQL バックアップをプレビューします。

bash scripts/backup-mysql.sh --defaults-file /secure/mysql-backup.cnf --database application --backup-dir /backup/mysql --dry-run

オプションファイルは、実行ユーザーが所有し、アクセス制限が設定されている必要があります。パスワードは argv に渡されません。アプリケーションのデータベースごとに --database を繰り返し指定します。このヘルパーは、InnoDB 以外のテーブルがある場合、処理を拒否します。システムデータベースや他のエンジンについては、別途レビュー済みのスナップショット／ロック手順が必要です。--apply --maintenance-confirmed は、DDL が同時実行されない時間帯であることを確認します。インストール済みのデータベースバージョンで、ルーチン／イベントの権限と復元の成功を確認してください。

転送と保持

S3 ヘルパーは、明示的に指定した成果物のパスを受け取り、隣接するチェックサムを検証し、承認済みのプレフィックスにアップロードして、ダウンロードしたファイルとバイト単位で比較した後、チェックサムをアップロードします。ローカルのコピーは保持され、バケットのライフサイクルや認証情報は変更されません。

bash scripts/backup-to-s3.sh --s3-uri s3://approved-backups/server-a --file /backup/files/FILE_ARCHIVE --file /backup/mysql/DATABASE_ARCHIVE --dry-run

使用前に、実際に生成された成果物のパスに置き換えてください。--apply はアップロードと読み戻しを実行し、転送／ストレージ料金が発生します。承認済みでアクセス可能なキーを使用する場合に限り、--kms-key-id を指定してください。デフォルトのアップロードでは、S3 AES256 暗号化が使用されます。アップロードされた暗号文についても、秘密鍵を使った復元を独立してテストする必要があります。

--prune を明示的に選択しない限り、ローカルの保持データは削除されません。--dry-run --prune --retention-days 30 でプレビューしてください。--apply --prune は、新しいアーカイブが正常に公開された後にのみ削除を実行します。対象となるのは、専用バックアップディレクトリ直下にある、形式が一致する通常ファイルのうち、選択した期間より古く、有効なチェックサムを持つものだけです。以前のレガシー／未検証アーカイブは保持され、手動レビューの対象となります。スケジュールされたクリーンアップは、すでに承認された保持ポリシーの範囲内に限定し、復旧のニーズを満たすのに十分な数の、独立して検証済みの世代を保持してください。

ヘルパーは共通の scripts/backup-common.sh を使用します。スクリプトをコピーまたはインストールする際は、このファイルもヘルパーと同じ場所に置いてください。

復旧を検証する

• アーカイブの内容とチェックサム、出力権限、ジョブの終了ステータス、経過時間、リモートコピーを確認します。失敗や欠落・古いアーティファクトを明示的に監視します。
• まず隔離されたディレクトリまたはデータベースに復元します。必要なファイル、メタデータ、代表的なアプリケーションのクエリを比較し、別途保管したキーを使って暗号化されたデータの復元をテストします。
• レビュー済みの復旧作業中に、アプリケーションデータを選択的に復元します。通常のテストとして、/etc、/root、ユーザー、古い認証情報を実行中のシステムに直接展開しないでください。
• エンドツーエンドの実行と復元が成功してから、cron/systemd を設定します。アラート、想定所要時間、除外ポリシー、容量、必要な再起動の調整を定義します。

アーカイブの検証、リモート上のバイト単位の検証、アプリケーションの復旧は、それぞれ別の結果として報告します。ダンプ、暗号化、転送、復元の確認に失敗した後に、有用な世代のバックアップを削除しないでください。