1. バックアップは何のため？（目的とゴール）
- 誤操作・論理障害（削除・上書き・マルウェア）からの復旧
- 物理障害（ディスク故障、筐体故障、災害）への備え
- 監査・証跡・法令対応（一定期間のデータ保全）
- テスト/検証（本番相当のデータを用いた再現/検証）
バックアップのゴールは「求める時点のデータを、求める時間内に、安全に戻せる」状態を作ることです。
2. 復旧目標（RPO/RTO）の決め方
- RPO（Recovery Point Objective）：どこまでのデータを諦められるか（例：最大15分の欠損まで許容）
- RTO（Recovery Time Objective）：どれくらいの時間で復旧できれば業務に耐えられるか（例：2時間以内）
目標設定のコツ： 重要システムは「短いRPO/RTO」を設定し、低重要度はコストとリスクのバランスで緩める。RPO/RTOは監視・復旧テストの実測で定期的に見直す。
3. 方式の種類（サーバー/ファイル/DB/スナップショット）
3.1 サーバー全体/イメージ系
- OS・ミドルウェア含めたベアメタル復旧（BMR）が可能。障害時にサーバー丸ごと復旧が早い。
- 容量が大きくなりがち。重複排除/圧縮・増分永続（Forever-Incremental）採用が一般的。
3.2 ファイル/ディレクトリ単位
- 必要なファイルのみ高速に復旧可能。日次運用の事故対応に強い。
- アプリケーション整合性は別途配慮（停止やVSS/プリ/ポストスクリプト）。
3.3 バックアップレベル
- フル：全データ。復旧は簡単だが時間/容量コスト大。
- 差分：最後のフル以降の変更分。復旧はフル＋差分。
- 増分：前回バックアップ以降の変更分。転送量小、復旧はチェーン管理が重要。
3.4 スナップショット（ストレージ/ハイパーバイザ/クラウド）
- 瞬時取得、整合性確保に注意（アプリ整合スナップショット推奨）。
- 同一装置内のみだと災害に弱い。別リージョン/別媒体への複製で堅牢化。
3.5 データベース（DB）
- 物理バックアップ（例：RMAN、xtrabackup）：高速・PITR対応しやすい。
- 論理バックアップ（例：mysqldump、pg_dump）：移行や部分復旧に便利だが容量/時間が増えやすい。
- トランザクションログ/アーカイブログでPITR（ポイントインタイム復旧）を実現。
4. 整合性の確保（アプリ整合/トランザクション整合）
- アプリ整合（Application-Consistent）：DBやサービスを一時クエイセス/フリーズして整合点を作る（例：WindowsのVSS、Linuxはプリ/ポストでフリーズ）。
- クラッシュ整合（Crash-Consistent）：電源断相当。ジャーナルで戻せる設計なら可だが、DBは原則アプリ整合推奨。
- トランザクション整合：ログバックアップ＋チェックポイントでPITR前提の設計に。
5. 設計の原則（3-2-1・暗号化・Immutable など）
- 3-2-1原則：3つのコピーを、2種類の媒体に、1つはオフサイト/クラウドに。
- 暗号化：保存時/転送時（At-Rest/In-Transit）双方。鍵管理（KMS/HSM）とアクセス権限の最小化。
- イミュータブル（WORM）/オブジェクトロック：ランサム被害時の最後の砦。
- ゼロトラスト/分離：バックアップ管理プレーンを本番から分離、MFA・特権アカウント管理。
- タグ/ポリシー化：重要度別にテンプレ化（例：Gold/Silver/Bronze）。
6. スケジュールと保持（世代管理・ライフサイクル）
- 例：金曜フル＋平日増分、ログは15分〜1時間ごと。
- 保持例：日次30世代、週次8世代、月次12世代、年次7世代（会計・監査要件に合わせ調整）。
- ライフサイクル：高性能ストレージ→低コストアーカイブへ自動階層化。
- バックアップウィンドウ：業務影響を避ける時間帯に設定、スロットリング活用。
7. 日々の運用チェックリスト
- 前日ジョブの結果確認（成功/失敗/警告、成功率のトレンド）
- 失敗原因の切り分け（ネットワーク、権限、VSS/スクリプト、容量不足）
- バックアップ先の使用率（重複排除率、圧縮率、アーカイブ移行の進捗）
- ログ・アラート監視（過剰リトライ、長時間化の検知）
- 重要サーバーの整合性（アプリ整合で取れているか）
- PITR前提のシステムはログ断絶がないか（チェーン健全性）
- オフサイト/クラウド複製の到達確認
- 復旧演習の計画/実施（毎月ミニ演習、四半期で全体演習）
- 変更管理（サーバー追加・移行時のポリシー適用漏れ防止）
8. 復旧手順とテスト（DR/BCPを意識）
- 復旧ランブック（役割分担、連絡系統、優先順位、RTO/RPO、手順書リンク）を整備。
- テストの種類：単一ファイル復旧、アプリ単体復旧、サーバーBMR、サイト全体DR切替。
- 評価指標：実測RTO/RPO、失敗原因、改善アクション、再発防止。
9. 性能・容量・ネットワークの勘所
- ボトルネック可視化：ソース/ネットワーク/ターゲット/重複排除装置のどこで詰まるか。
- 増分永続＋合成フルでウィンドウ短縮。可能なら変更ブロック追跡（CBT）を活用。
- 帯域制御/並列度のチューニング、遠隔地はWAN最適化や圧縮を検討。
- 容量見積り：初回フル＋日次変更率×保持期間−重複排除効果。
10. 現場で使う具体例（Windows/Linux/DB）
10.1 Windows Server（VSS）
- VSS対応のバックアップでアプリ整合（SQL Server/Exchange等）。
- サービス停止が難しい場合はVSSフリーズ、ログバックアップ併用でPITR。
- 例：
SQL Serverは FULL/DIFF/LOG で運用、COPY_ONLYで一時フル取得しチェーン影響を回避。
10.2 Linux（LVM/スクリプト）
- LVMスナップショット→ファイル/ブロック転送で整合点を確保。
- プリ/ポストスクリプトでアプリをクエイセス（例：
systemctl stop app→ 取得 →start）。
10.3 Oracle
- RMANで物理バックアップ＋アーカイブログ。PITR、表領域単位復旧、ブロックメディアリカバリ。
- 2台構成/共有ディスク（SEHA等）の場合は整合スナップ＋RMANの組み合わせが有効。
10.4 MySQL/MariaDB
- 論理：
mysqldump --single-transaction（InnoDB想定）で整合取得。 - 物理：xtrabackupで無停止・差分・PITR対応。
- バイナリログでポイントインタイム復旧。
10.5 PostgreSQL
- ベースバックアップ＋WALでPITR。
pg_basebackupやバックアップ製品のプラグインを利用。
11. ドキュメントとガバナンス
- 資産台帳：バックアップ対象一覧（役割、重要度、RPO/RTO、担当、ポリシー名）。
- 命名規則：ジョブ/ポリシー/保存先/タグの規則統一。
- 変更管理：新規サーバーは自動で「標準ポリシー」が当たる仕組み（タグ/OU連動）。
- 監査ログ：取得・復旧・削除・鍵操作の履歴保存。
- 教育/演習：新人向けオンボーディング資料と年次演習。
12. よくある質問（FAQ）
Q. スナップショットはバックアップの代わりになりますか？
A. 同一装置内のみのスナップショットは災害や装置故障に弱く、代替にはなりません。別媒体/別リージョンへの複製やエクスポートと組み合わせて使いましょう。
Q. どの程度の頻度で復旧テストをすべき？
A. 重要システムは月次で部分復旧、四半期でBMR/DRテスト、年次で全体演習を推奨。実測でRTO/RPOを確認し、改善します。
Q. ランサム対策の要点は？
A. イミュータブル/WORM、管理プレーン分離、最小権限、ネット分離（エアギャップ/隔離アカウント）、検知連携（EDR/SIEM）です。
まとめ
バックアップは「方式」よりも「復旧できるか」が本質です。RPO/RTOを起点に、3-2-1と整合性、運用監視、定期的な復旧テストまでを一気通貫で設計・運用しましょう。
