株式会社エスロジカル
株式会社エスロジカル
SSL証明書(DV、OV、EV)、セキュリティ、Web開発、Linux開発、Go言語

HOME > 技術ドキュメント > Webシステムのバックアップ設計入門

Webシステムのバックアップ設計入門

執筆:株式会社エスロジカル(Webシステム受託開発・インフラ構築・運用改善)


「バックアップはある」と言いながら、実際には復元できなかった——という事例は珍しくありません。 バックアップ設計で重要なのは「取得すること」だけでなく、「正しく復元できること」を定期的に確認することです。
本記事では、Webシステムのバックアップ設計で押さえるべき考え方と具体的な実装方針を解説します。

バックアップ設計の前に、ビジネス要件として次の 2 つを確認します。

指標 定義 設計への影響
RTO
(Recovery Time Objective)
障害発生から復旧完了までの目標時間 RTO が短いほどホットスタンバイ・自動フェイルオーバーが必要になる
RPO
(Recovery Point Objective)
許容できるデータ損失の最大時間 RPO が短いほどバックアップ頻度を上げる必要がある

例えば「最大 1 時間のデータ損失は許容できる(RPO=1h)」「4 時間以内に復旧する(RTO=4h)」という要件であれば、 1 時間ごとの自動バックアップと、4 時間以内に復旧できるリストア手順の準備が必要です。

3-2-1 原則:バックアップデータは「3 か所」に保存し、「2 種類のメディア」を使い、「1 か所はオフサイト(別拠点・クラウド)」に置く。

実務的な解釈として:

対象 方法 頻度の目安
データベース(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証明書の一覧・購入はこちら

「バックアップが存在する」と「バックアップから復元できる」は別の話です。
少なくとも四半期に 1 回はリストア手順を実際に試し、手順書を最新状態に保ちます。

リストアテストで確認するポイント:


バックアップ設計・インフラ運用のご相談はエスロジカルへ
バックアップ設計から自動化・監視設定まで、インフラ運用改善を一貫してサポートします。
お問い合わせはこちら
関連:SSL証明書 / SSL証明書 FAQ

← 技術ドキュメント一覧へ戻る