HOME > 技術ドキュメント > Webシステムのバックアップ設計入門
Webシステムのバックアップ設計入門
執筆:株式会社エスロジカル(Webシステム受託開発・インフラ構築・運用改善)
「バックアップはある」と言いながら、実際には復元できなかった——という事例は珍しくありません。
バックアップ設計で重要なのは「取得すること」だけでなく、「正しく復元できること」を定期的に確認することです。
本記事では、Webシステムのバックアップ設計で押さえるべき考え方と具体的な実装方針を解説します。
1. RTO と RPO:設計の前提を決める
バックアップ設計の前に、ビジネス要件として次の 2 つを確認します。
| 指標 | 定義 | 設計への影響 |
|---|---|---|
| RTO (Recovery Time Objective) |
障害発生から復旧完了までの目標時間 | RTO が短いほどホットスタンバイ・自動フェイルオーバーが必要になる |
| RPO (Recovery Point Objective) |
許容できるデータ損失の最大時間 | RPO が短いほどバックアップ頻度を上げる必要がある |
例えば「最大 1 時間のデータ損失は許容できる(RPO=1h)」「4 時間以内に復旧する(RTO=4h)」という要件であれば、 1 時間ごとの自動バックアップと、4 時間以内に復旧できるリストア手順の準備が必要です。
2. 3-2-1 バックアップ原則
3-2-1 原則:バックアップデータは「3 か所」に保存し、「2 種類のメディア」を使い、「1 か所はオフサイト(別拠点・クラウド)」に置く。
実務的な解釈として:
- 本番サーバー上のデータ(1か所目)
- 本番サーバー内の別ディレクトリへのバックアップ(2か所目):ただしサーバーごと障害になった場合に意味がない
- クラウドストレージ(AWS S3 / OCI Object Storage / GCS)への転送(3か所目・オフサイト):最重要。サーバー障害・ランサムウェアに対して有効
3. 何をバックアップするか
| 対象 | 方法 | 頻度の目安 |
|---|---|---|
| データベース(MySQL) | mysqldump --single-transaction(InnoDB) | 1 日 1 回以上。重要度が高ければ 1 時間ごと |
| データベース(PostgreSQL) | pg_dump / pg_basebackup | 同上 |
| アップロードファイル | rsync または aws s3 sync | 日次。変更頻度が高ければ時次 |
| アプリケーションコード | Git リポジトリで管理(バックアップ不要) | 常時(Git push 時点) |
| 設定ファイル(Nginx・systemd・cron) | Git または S3 に保存 | 変更のたびに |
| SSL 証明書・秘密鍵 | 暗号化して S3 に保存 | 取得・更新のたびに |
SSL 証明書と秘密鍵は失うと再取得が必要になります。
特に有料 SSL 証明書は再発行に時間がかかる場合があるため、確実にバックアップしてください。
SSL証明書 FAQ /
SSL証明書の一覧・購入はこちら
4. DB バックアップの実装ポイント
- mysqldump の --single-transaction:InnoDB テーブルに対してテーブルロックをかけずに整合性のあるバックアップを取得できます。MyISAM テーブルが混在する場合は --lock-tables を検討します。
- バックアップファイルの圧縮:dump した SQL は gzip で圧縮してサイズを削減します(例:
mysqldump ... | gzip > backup.sql.gz)。 - S3 への転送:AWS CLI の
aws s3 cpコマンドで圧縮済みファイルをアップロードします。IAM ロールまたは最小権限のアクセスキーを使用します。 - 古いバックアップの自動削除:S3 のライフサイクルポリシーで世代管理し、ストレージコストを抑えます(例:7 日分保持・90 日後に削除)。
- バックアップ実行の監視:cron または systemd timer でバックアップを実行し、失敗時にメール・Slack へアラートを送る。
5. ファイルバックアップの実装ポイント
- rsync の活用:差分転送なので高速かつ帯域を節約できます。リモートサーバーへの転送にも使えます(SSH 経由)。
- aws s3 sync:S3 との同期に便利。変更ファイルのみを転送します。
- 除外パスの設定:キャッシュディレクトリ・一時ファイル・ログファイルはバックアップから除外してサイズを削減します。
6. リストア手順の確認が最重要
「バックアップが存在する」と「バックアップから復元できる」は別の話です。
少なくとも四半期に 1 回はリストア手順を実際に試し、手順書を最新状態に保ちます。
少なくとも四半期に 1 回はリストア手順を実際に試し、手順書を最新状態に保ちます。
リストアテストで確認するポイント:
- S3 からファイルを取得できるか(認証情報・権限の確認)
- DB のリストア後にアプリケーションが正常起動するか
- データの整合性が取れているか(レコード数・最終更新日時などで確認)
- リストアにかかる実際の時間(RTO 要件を満たしているか)
7. バックアップ設計チェックリスト
- □ RTO・RPO の要件を関係者と合意している
- □ DB の日次バックアップが自動実行されている
- □ バックアップファイルがクラウドストレージ(S3 等)に転送されている
- □ バックアップ失敗時にアラートが来る
- □ アップロードファイルのバックアップが取れている
- □ 設定ファイル・SSL 証明書をバックアップしている
- □ リストア手順を文書化している
- □ 直近 3 ヶ月以内にリストアテストを実施した
- □ バックアップの世代管理(保持期間)を設定している
バックアップ設計・インフラ運用のご相談はエスロジカルへ
バックアップ設計から自動化・監視設定まで、インフラ運用改善を一貫してサポートします。
お問い合わせはこちら
関連:SSL証明書 / SSL証明書 FAQ
バックアップ設計から自動化・監視設定まで、インフラ運用改善を一貫してサポートします。
お問い合わせはこちら
関連:SSL証明書 / SSL証明書 FAQ
