※本記事はアフィリエイト広告を含みます。
バックアップの保存先を用意しても、必要な状態へ戻せなければ復旧には使えません。検証用サーバーであっても、集め直せない測定データや、何度も調整を重ねた設定があるなら、失ったときの影響を先に見積もっておきたいところです。
設計の出発点は、何を、いつの状態に、どのくらいの時間で戻すかです。本記事では、この要件から保存方法と復元試験を決める手順を説明します。サーバーの容量選定は小規模検証サーバーの容量見積もりで扱います。
失うと困るものと、作り直せるものを分ける
サーバーの中身をひとまとめに扱う前に、復旧に必要なものを分類します。プログラムが残っていても、設定やデータが欠けていれば、元の処理を再現できないことがあります。
| 対象 | 失った場合に確認すること | 保存・再構築の考え方 |
|---|---|---|
| プログラム | 同じ版を入手できるか | ソースや配布物、バージョンを管理 |
| 設定 | 接続先や処理条件を再現できるか | 設定項目と変更履歴を保持 |
| 認証情報・暗号鍵 | 復元したデータを開けるか | 秘密情報として別途アクセス管理 |
| データベース | 一貫した状態へ戻せるか | DBが対応するバックアップ方法を使用 |
| 取込み元ファイル | 再取得できるか | 再取得できない分の保存を優先 |
| ログ・集計結果 | 再計算や原因調査に必要か | 用途に応じて保存期間を決定 |
認証情報を通常の手順書へそのまま貼り付ける必要はありません。必要な人が復旧時に取り出せる管理方法を、別に定めておきます。暗号化したバックアップでは、鍵の管理も復旧手順の一部です。
戻す時点と、復旧までの時間を決める
取得の頻度を「毎日」と決める前に、どこまでのデータ損失を許容できるかを決めます。次の表は、要件を整理するための仮定例です。実際の用途にそのまま推奨する基準ではありません。
| 問い | 仮定例 | 設計に反映すること |
|---|---|---|
| どこまで戻れればよいか | 前日の作業終了時点 | その時点を復元できる取得タイミング |
| どれだけ停止できるか | 復旧作業を開始してから半日以内 | 再構築・転送・復元・確認に必要な時間 |
| 何が起きた状態から戻すか | 誤削除、サーバー故障 | 必要な世代と、元サーバーに依存しない保存先 |
| 誰が戻せるか | 担当者以外も手順を追える | 権限、鍵、構成情報、復元手順の整理 |
復旧作業にかかる時間には、バックアップをコピーする時間だけでなく、環境を用意し、データを戻し、動作を確認する時間も含めます。異常の検知や担当者への連絡にかかる時間を含めるかどうかも、要件として明記します。
バックアップを毎日取得していても、障害発生の直前までのデータがすべて残るわけではありません。取得そのものが失敗していた場合や、古い世代にも問題が含まれていた場合も想定し、取得結果と保存世代の状態を確認できるようにします。
コピー・同期と、過去の状態を残すバックアップを区別する
同期先があっても、誤削除や誤更新がそのまま同期されれば、直前の正常な状態へ戻せない場合があります。必要なのは、別の場所にあることだけでなく、戻したい時点の状態が残ることです。
設計時には、次の故障や操作を分けて考えます。
- ファイルの誤削除に備え、削除前の世代を残す。
- サーバーの故障に備え、元のサーバーがなくても読める場所に保存する。
- アカウントや権限の問題に備え、同じ権限で全世代が消せる構成になっていないか確認する。
- 保存領域の障害に備え、何が共通の障害要因になるかを確認する。
別ディスクや別サービスを使うこと自体が、あらゆる障害からの独立を意味するわけではありません。保存場所、アカウント、削除権限、暗号鍵の関係を確認し、どの事故を防ぐ設計なのかを記録に残します。
データベースは整合性を保てる方法で取得する
稼働中のデータベースのファイルを、通常のファイルと同じ感覚で順にコピーするだけでは、整合したバックアップになるとは限りません。取得中にもデータが更新されるためです。
PostgreSQL 18の公式資料は、SQLダンプ、ファイルシステムレベルのバックアップ、継続的アーカイブを挙げています。それぞれ復旧の単位や前提が異なるため、必要な復元時点と運用方法に合うものを選びます。
ファイルシステムレベルのバックアップの説明によれば、基本的なファイルコピーはサーバーを停止して行う必要があります。一方、整合したスナップショットを取得できる場合などには、別の条件が示されています。「稼働中の取得はすべて不可」とも、「ファイルをコピーすれば十分」とも一括りにせず、使用するDBとバージョンの手順を確認してください。
DBと、そのDBが参照するアップロードファイルを別々に取得する場合は、両者の対応がずれないかを確認します。バックアップ方式を決めただけで終わらせず、アプリが必要とする組合せを復元試験で確かめます。
復元試験は元の環境を壊さない場所で行う
取得の成功表示は、復元できた証拠ではありません。別の検証環境へ戻し、必要な状態になっているかを確認します。以下は試験の手順案で、本記事で実際に復元を実施した記録ではありません。
- 対象の世代、取得日時、元のソフトウェアのバージョンを確認する。
- 復元先を用意し、元のデータを上書きしないことを確認する。
- 認証情報と暗号鍵を、定めた管理方法で用意する。
- データと設定を復元し、アプリを起動する。
- 件数や代表的なデータ、画面表示、必要な処理を確認する。
- 所要時間と、手順どおりに進まなかった点を記録する。
試験環境から実際の通知送信や外部システムへの更新が走らないよう、接続先と定期処理の設定も確認します。復元した秘密情報やデータについては、試験終了後の扱いまで決めておきます。
記録には、試験した世代、構成、確認項目、所要時間、未確認の処理を残します。データ量やバージョン、保存先が変わったときは、その変更に影響する部分を再確認します。
追加ストレージを使う場合の確認例
さくらのVPSを使う構成では、NFS機能が追加の保存領域の候補になります。ただし、保存領域を契約しただけで、バックアップの取得、世代管理、復元試験が自動で完成するわけではありません。
公式マニュアルには、対応するLinux版VPS、ローカルスイッチ、NFSのゾーンなどの条件が示されています。同じゾーンに置く前提があるため、どの障害まで分離できるのかは別に検討します。解約時にはデータが削除されるため、契約を終える前に必要なデータの退避と読取り確認を行います。
NFSは保存先の一例です。外部の保存先も含め、失いたくないデータ、必要な世代、権限、復元時間の条件を満たせるかどうかで選びます。最後に復元試験まで通すことが、バックアップ設計を確かめる方法になります。
広告：さくらのVPSの公式案内
