¶ 💾 Backup Design
¶ 🧭 このページについて
本ページでは、Linux サーバーにおけるバックアップ構成の考え方を整理する。
サーバー運用では、ハードウェア障害、設定ミス、データ破損、誤操作など、さまざまな要因でサービスが停止する可能性がある。
そのため、バックアップは単に取得して終わりにするのではなく、障害が発生した際に確実に復旧へつなげられる状態を維持することを前提に設計しておく必要がある。
本環境では、バックアップ対象、取得方式、保存先、取得頻度、保持世代、削除方針、復旧の考え方までを一体として整理し、日常運用の中で継続して扱える構成を目指す。
¶ 🖥 サーバー一覧
本ページで扱うサーバーは以下のとおりである。
Web サーバー（仮称）（WEB-SRV01）
Web アプリケーションを提供する Linux サーバーであり、設定ファイル、アプリケーションデータ、ログなどを主なバックアップ対象とする。
監視サーバー（仮称）（MON-SRV01）
監視システムを構成する Linux サーバーであり、監視設定やデータベースを主なバックアップ対象とする。
NAS（仮称）（NAS01）
各サーバーから取得したバックアップデータを集約して保存するストレージであり、バックアップ保存先として利用する。
¶ 🏗 バックアップ構成
本環境では、バックアップ対象を「ファイル」「データベース」「OS」の 3 つに分けて取得する。
こうしておくことで、障害の種類に応じて必要な範囲だけを切り分けて復旧しやすくなる。
バックアップデータはすべて NAS に保存し、サーバー本体とは分離して管理する。
この構成にしておくことで、サーバー側に障害が起きた場合でも、バックアップデータそのものを保護しやすくなる。
¶ 💾 バックアップ方式
バックアップ対象ごとに、取得方法を使い分ける。
| 対象 | 方式 | 目的 |
|---|---|---|
| ファイル | rsync | 差分転送により効率的にバックアップを取得する |
| データベース | ダンプ（mysqldump 等） | データの整合性を保った状態で保存する |
| OS | ReaR | システム全体を復旧可能な状態で保存する |
ファイルは差分転送を用いることで、バックアップ時間とネットワーク負荷を抑えやすくなる。
データベースは単純なファイルコピーではなく、ダンプとして取得することで整合性を保ちやすくする。
OS は専用ツールを使い、障害発生時にシステム全体を復旧できる形で保存する。
¶ 📂 保存構成（NAS）
バックアップデータは、サーバーごと、用途ごとに分けて保存する。
/backup
├ WEB-SRV01
│ ├ file
│ ├ db
│ ├ os
│ └ archive
└ MON-SRV01
├ file
├ db
├ os
└ archive
このようにディレクトリを分けておくことで、どのサーバーのどの種類のバックアップなのかを判別しやすくなり、復旧時にも迷わず必要なデータを取り出しやすくなる。
¶ 📁 バックアップ対象
ファイルバックアップでは、OS を再構築したあとに戻す必要がある領域を対象とする。
/etc
/var/lib
/var/www
/opt
/home
これらのディレクトリは、システム設定、アプリケーション動作、ユーザーデータに関わるため、優先的に保護しておきたい領域である。
データベースについては、システムごとに適したダンプを取得する。
OS については、システム全体を対象としてバックアップを取得する。
¶ ⏰ バックアップスケジュール（例）
バックアップは対象ごとに取得頻度を分けて運用する。
日々更新される設定ファイルやデータベースは日次で保護し、OS バックアップは週次で取得する。
さらに、長めに保持したいデータは月次保管として分けて扱うことで、運用負荷と復旧性のバランスを取りやすくする。
¶ 🗂 世代管理（例）
バックアップは取得するだけではなく、どの程度の期間保持するかを決めて管理する必要がある。
| 種別 | 頻度 | 世代 | 目的 |
|---|---|---|---|
| ファイル | 日次 | 7世代 | 直近の障害への対応 |
| データベース | 日次 | 7世代 | データ復旧 |
| OS | 週次 | 4世代 | システム復旧 |
| 長期保管 | 月次 | 12世代 | 長期間の保管 |
日次バックアップは、直近の誤操作や設定変更による障害へ対応するために利用する。
週次バックアップは、OS 障害への対応を目的として保持する。
月次バックアップは、一定期間をさかのぼって参照したい場合に備えて長めに残す。
¶ 🧹 世代管理（ローテーション）
バックアップは、保持世代を超えたものを削除しながら管理する。
無制限に保存し続けるとストレージ容量を圧迫し、運用そのものが続けにくくなる。
そのため本環境では、バックアップ種別ごとに保持世代を決め、一定数を超えたデータを削除するローテーション方式を採用する。
また、バックアップは日次、週次、月次で取得頻度が異なるため、それぞれを独立した処理として扱う。
こうしておくことで、各バックアップは個別のスケジュールで実行され、互いに影響を与えずに運用しやすくなる。
ローテーションは、「バックアップ取得 → 世代確認 → 古いデータの削除」という流れで実行する。
この処理をバックアップ単位で完結させることで、常に一定の世代数を保ちやすくなる。
¶ 🚑 復旧の考え方
障害が発生した場合は、その内容に応じて使うバックアップを選ぶ。
設定ファイルの破損や誤操作による障害であれば、ファイルバックアップまたはデータベースバックアップから必要な範囲を復元する。
OS に起因する障害が発生した場合は、まず OS を復旧し、そのあとでファイルやデータベースを戻す。
このようにバックアップを用途ごとに分けておくことで、障害の規模に応じた柔軟な復旧につなげやすくなる。