コンテンツへスキップ
HexaTransfer
ブログへ戻る
クラウドとストレージ

バックアップと復旧計画でファイルを守る

RTO、RPO目標、テスト手順、災害復旧戦略を含む包括的なバックアップと復旧計画を作成する方法を解説します。

バックアップと復旧計画は、2つの数値で定義されます。RPO(どれだけのデータ損失が許容できるか、時間で表す)とRTO(どれだけのダウンタイムが許容できるか)です。ワークロードごとにこの数値を決め、そこから逆算して設計します。RPO5分のデータベースにはWALの継続的シッピングが必要です。RPO24時間の週次マーケティングレポートには夜間バッチ1本で十分です。3-2-1ルール(3つのコピー、2種類のメディア、1つはオフサイト)と組み合わせ、復元テストを四半期ごとに実施してください。「バックアップはある」という話が最終的に破綻する理由のほとんどは、誰も実際に復元を練習していないことです。

RPOとRTO:出発点となる数値

RPO(目標復旧時点)=許容できる最大データ損失(時間)。RTO(目標復旧時間)=許容できる最大ダウンタイム。

ワークロード別の目安:

  • ECサイトの本番データベース:RPO 5分、RTO 1時間
  • 顧客向けファイルアップロード:RPO 15分、RTO 2時間
  • 社内ファイルサーバー:RPO 24時間、RTO 8時間
  • メールアーカイブ:RPO 24時間、RTO 48時間
  • マーケティング分析:RPO 24時間、RTO 72時間

RPO/RTOを厳しくするほどコストが上がります。RPO5分は継続的レプリケーション(インフラコスト大)を意味し、RPO24時間は夜間バッチ1本(安価)で済みます。すべてのワークロードにホットスタンバイは必要ありません。過剰設計は禁物です。

3-2-1ルールは今も有効

データの3つのコピーを、2種類の異なるストレージに保存し、そのうち1つはオフサイトに置く。3-2-1ルールはクラウド以前から存在し、今も有効です。

  • プライマリ:本番ストレージ(S3、EBS、PostgreSQLディスク)
  • セカンダリ:異なるメディアや別リージョンのバックアップ(別S3バケット+レプリケーション、Glacier)
  • ターシャリ:オフサイト、できれば別ベンダーまたはエアギャップ(Backblaze B2、オンプレテープ、金庫内の物理ディスク)

ベンダー分散は重要です。AWSのルートアカウントが侵害されると、AWS上のバックアップがすべて削除される可能性があります。Backblaze、Wasabi、またはオンプレへのセカンダリコピーがあればそのシナリオを回避できます。年商50億円以下の企業であれば、第2ベンダーのコピーを追加しても月5,000〜20,000円程度で、テナント全体に影響する障害への保険として十分な投資です。

フルバックアップ・増分バックアップ・合成フルバックアップ

3つのバックアップ戦略があります。

  • フルバックアップ:毎回すべてをコピー。シンプルで復元が速い(1ファイル)が、ストレージ消費が大きい。
  • 増分バックアップ:前回バックアップ以降の変更分のみコピー。ストレージ効率が高いが、復元にはフル+すべての増分が必要。
  • 合成フルバックアップ:サーバー側でフル+増分を新しい仮想フルにマージ。任意の時点から高速復元が可能。

現代のバックアップツール(Veeam、Rubrik、restic with prune、BorgBackup)は、内部的に増分永続+合成フルを使っています。標準パターンは夜間増分、週次合成フル、日次30件+月次12件+年次7件の保持(世代管理ローテーション)です。

日次変化率5%の2TBファイルサーバーの場合、増分永続で1年保持すると合計3〜5TB程度になります。毎晩フルバックアップを取ると700TB以上に達するのとは対照的です。

送信前に暗号化する

バックアップは暗号化されていない状態で転送・保存してはなりません。AES-256-GCMによるクライアントサイド暗号化(restic、Borg、Duplicacy、Veeamなどのデフォルト)により、バックアップホストは平文を一切見ません。

鍵管理はアルゴリズムの選択より重要です。バックアップと同じAWSアカウントに保存された鍵で暗号化されたバックアップは見かけだけの安全性です。IAMアクセスを持つ攻撃者は両方を手に入れます。鍵の保管先:

  • 別アカウントキーを使うAWS KMS(クロスアカウント復号)
  • 帯域外環境のHashiCorp Vault
  • ルートキー用のハードウェアセキュリティモジュール(YubiKey、HSM)
  • 特に重要な鍵は印刷して封入した紙のコピー

定期的に更新(年1回)し、すべての使用をログに残し、本番環境でローテーションが有効になる前に更新後の鍵で復元テストを行ってください。

不変性:ランサムウェアへの答え

2025年のランサムウェア攻撃は、まずバックアップを標的にすることが一般的です。本番データを暗号化した後、復旧を阻むためにバックアップを削除または暗号化します。不変バックアップがこれを防ぎます。

実装方法:

  • S3 Object Lock(Complianceモード):保持期間中はrootでも削除不可
  • Azure Blob不変ストレージ:同様の仕組み、コンテナレベルで適用
  • Veeam Hardened Linux Repository:追記専用、SSH限定、削除APIなし
  • 金庫保管の物理テープ:究極のエアギャップ

業務上重要なデータは、少なくとも1つのバックアップコピーを保持期間中は不変にすべきです。追加コストはほぼゼロです。どうせ保持するデータだからです。ランサムウェアが襲来したときの価値は計り知れません。

テスト:省略できない工程

一度も復元したことのないバックアップはバックアップではなく、希望です。優先度別のテストスケジュール:

  • Tier 1(ミッションクリティカル):四半期ごとにフル復元訓練、毎月ランダムファイル復元
  • Tier 2(業務上重要):半年ごとにフル復元訓練、四半期ごとにランダムファイル復元
  • Tier 3(標準):年1回フル復元訓練、四半期ごとにランダムファイル復元

テストで記録すべき内容:

  1. 復元にかかった時間(RTOと比較)
  2. データが本番状態と一致しているか(既知の時点のチェックサム照合)
  3. パーミッションや設定の復元に失敗しているものはないか
  4. 何が壊れていてどう修正したか

テストを怠る企業は実際のインシデント中に破損したバックアップを発見します。これは最もコストの高い学び方です。

データベースバックアップには専用の計画が必要

ファイルとデータベースではバックアップ方法が異なります。トランザクション途中の.pgdataディレクトリをコピーすると破損します。ネイティブツールを使ってください。

  • PostgreSQL:PITR用にpg_basebackup+WALアーカイブ、論理バックアップにpg_dump
  • MySQL:物理ホットバックアップにPercona XtraBackup、論理バックアップにmysqldump
  • MongoDBmongodump、遅延セカンダリを持つレプリカセット
  • Microsoft SQL ServerBACKUP DATABASEによるネイティブバックアップ、PITR用ログシッピング

RPO5分の500GB PostgreSQLデータベースの場合、夜間ベースバックアップ+S3への継続的WALアーカイブで過去30日間の任意の秒数への復元が可能です。復元時間:ベースバックアップの取得(30分)+目標時点までのWAL再生(5〜30分)。RTOを厳しくするには昇格待機中のウォームレプリカが必要です。

アプリケーション一貫性スナップショット

ファイルシステムスナップショット(ZFS、Btrfs、AWS EBS、Azureマネージドディスク、GCP永続ディスク)はブロックレベルで時点を固定します。データベースはアプリケーションのクワイエスと組み合わせます。

  1. pg_start_backup('label')(PostgreSQL)またはFLUSH TABLES WITH READ LOCK(MySQL)
  2. スナップショット取得
  3. pg_stop_backup()またはアンロック

このスナップショットはアプリケーション一貫性が保証されており、クラッシュリカバリなしで復元に使えます。AWS Backup、Azure Backup、Google Cloud Backupが主要データベースに対してこのパターンを自動化しています。

バックアップアーカイブの第三者への送付

バックアップを外部の監査人・規制当局・後継受託者へ送る場合、転送自体に注意が必要です。FTPは時代遅れ、メール添付はサイズ制限があり、USBドライブの受け渡しは手間がかかります。

エンドツーエンド暗号化ファイル転送はアドホックなバックアップ配布を安全に処理できます。HexaTransferはAES-256-GCMクライアントサイド暗号化とワンタイムリンクで最大10GBのファイルを転送します。S3バケットへのアクセスを付与せずに、データベーススナップショットを監査人に送るのに適しています。

ドキュメントはバックアップの一部

世界最高のバックアップも、復元できる担当者が休暇中で他の誰も方法を知らなければ意味がありません。以下を文書化してください。

  • バックアップ対象と対象外(明示的な除外リスト)
  • ワークロードごとのスケジュールと保持期間
  • 鍵管理とアクセス方法
  • ステップバイステップのコマンドを含む復元手順書
  • 連絡先リスト(ベンダーサポート、オンコール担当)
  • テスト結果と実施日

コピーを印刷して、緊急キーと一緒に物理金庫に保管してください。バックアップ手順書が、今しがたダウンしたインフラ上で動くConflueceページにしか存在しない場合、それは問題です。紙は何も動かないときでも機能します。

RPO/RTOを定義し、不変性を持つ3-2-1を実装し、クライアントサイドで暗号化し、四半期ごとにテストし、徹底的に文書化する。バックアップ成功の10%は技術で、残りの90%は規律です。

hexatransfer.com で今すぐ試せます — 無料、アカウント不要、最大10GB。

エンドツーエンド暗号化で大容量ファイルを安全に送信

エンドツーエンド暗号化で最大10GBのファイルを無料で転送。アカウント不要。ファイルはアップロード前にブラウザで暗号化されるため、他の誰にも読まれません。

ファイルを送信