バックアップとリカバリ

バックアップとリカバリとは

バックアップはデータの複製を別の場所に保存しておくこと、リカバリはそこから元の状態に復元することです。ハードウェア故障、誤操作(DROP TABLE!)、ランサムウェアなど、データを失う原因は必ず起こる前提で備えます。

重要なのは「リカバリできて初めてバックアップに意味がある」という点です。取っているだけで一度も復元テストをしていないバックアップは、いざという時に使えないことが珍しくありません。

バックアップの種類

実務では「週1フル+毎日差分(または増分)」のような組み合わせが定番です。

取り方でも二分でき、データファイルをそのままコピーするのが物理バックアップ、中身を SQL テキストとして書き出すのが論理バックアップです。後者は取得も復元も遅い代わりに、別バージョンや別サーバーへ移しやすく、テーブル単位でも取り出せます。具体的な手順は [[データベースのダンプとリストア]] にまとめています。

PITR — 特定時点への復元

データベース特有の強力な手法が PITR(Point-In-Time Recovery、特定時点復元)です。フルバックアップに加えて、[[トランザクションとACID]] を支える [トランザクションログとWAL]を保存し続けることで、「誤削除の直前」のような任意の時点まで復元できます。

クラウドのマネージドデータベースでは、この仕組みが「自動バックアップ+保持期間内の任意時点への復元」として最初から提供されていることが多いです。

初学者向けポイント

• 3-2-1ルール — コピーを3つ、2種類の媒体([[ストレージの種類]] を分ける)、1つはオフサイト(別拠点)に。バックアップ保管の合言葉
• [[レプリケーション]] はバックアップの代わりにならない — 誤操作も即座に複製されるため、「過去に戻る」にはバックアップが必要
• スナップショットもバックアップではない — [[仮想マシンとハイパーバイザ]] やストレージのスナップショットは数十秒で戻せる強力な手段ですが、元データと同じホスト上に置かれるためホストごと壊れれば一緒に失われます。世代を分けて別拠点にも置く、という 3-2-1 ルールの代わりにはなりません
• 復元の目標値を RPO(どこまでのデータ喪失を許容するか)と RTO(復旧までの時間)で決めてから方式を選ぶ — この考え方は [[災害復旧(DR)]] と共通
• 定期的なリストア訓練(復元テスト)を運用に組み込む — これが最も忘れられがちで最も重要

関連技術とのつながり

• [[レプリケーション]] — 可用性は高めるが「過去に戻る」役割は担えない
• [[災害復旧(DR)]] — RPO / RTO に基づく復旧計画の全体像
• [[トランザクションとACID]] — トランザクションログが PITR を可能にする
• [[ストレージの種類]] — 保管先の媒体を分けるのが 3-2-1 ルール
• [[データベースのダンプとリストア]] — 論理バックアップの具体的な取り方
• [[仮想マシンとハイパーバイザ]] — スナップショットは高速に戻せるがバックアップの代替にはならない

Q: 「フル+最新の1つで復元できる」バックアップの組み合わせはどれ?
- [x] フルバックアップ+差分バックアップ
- [ ] 増分バックアップのみ
- [ ] トランザクションログのみ
解説: 差分は「前回フル以降の変更分」を毎回含むため、フルと最新差分の2つで復元できます。増分は全部を順に適用します。

Q: PITR(特定時点復元)を可能にするために保存し続けるものはどれ?
- [ ] テーブルのインデックス
- [x] トランザクションログ(変更履歴)
- [ ] データベースの接続設定
解説: フルバックアップにトランザクションログを組み合わせることで、誤削除の直前など任意の時点へ復元できます。

Q: 3-2-1ルールの内容として正しいのはどれ?
- [ ] 3日ごとに2時間かけて1人でバックアップする
- [x] コピーを3つ、2種類の媒体で、1つは別拠点に保管する
- [ ] 3年間、2世代分を、1つの媒体に保管する
解説: コピー数3・媒体2種類・オフサイト1つがバックアップ保管の基本ルールです。