本ページでは、本環境におけるバックアップデータからの復旧手順をまとめる。
バックアップは NAS に集約されており、OS、ファイル、データベースを分けて復旧する構成としている。
障害の内容に応じて必要な範囲だけを切り分けて復元できるようにしておくことで、復旧時間の短縮と影響範囲の最小化を両立する。
本手順は、確認、復旧、確認の流れに沿って整理しており、実運用で再現できることを前提とする。
なお、復旧手順は本番環境で初めて実施するのではなく、事前に検証環境で確認しておくことが重要である。
本環境では、バックアップからの復旧を次の考え方で実施する。
バックアップ元は NAS に統一し、常に同じ場所から復旧できるようにする。
OS、ファイル、データベースは分離して扱い、障害の内容に応じて必要な範囲のみを復旧する。
ファイル復元は差分バックアップを前提とし、過剰な上書きを避けながら復旧する。
また、影響範囲を最小限に抑えるため、必要以上の復旧は行わない。
| サーバー名(仮称) | 役割 |
|---|---|
| WEBサーバー(仮称) | Apache / Wiki.js |
| 監視サーバー(仮称) | Zabbix |
| NAS(仮称) | バックアップ保存先 |
障害の種類を切り分けたうえで、必要な工程のみを実施する。
すべてを一度に戻すのではなく、影響範囲に応じて段階的に復旧することが重要となる。
復旧処理の前に、バックアップデータへアクセスできる状態であることを確認する。
mount | grep backup
NAS のマウントポイントが表示されればよい。
表示されない場合は、復旧処理を進めずに接続状態を確認する。
OS 障害が発生している場合は、ReaR によりシステム全体を復旧する。
rear recover
ディスク構成、ブート設定、OS 環境がバックアップ時点の状態に復元される。
OS 復旧のみではアプリケーションデータやデータベースは完全に戻らないため、続けてファイルおよびデータベースの復元を行う。
必要なディレクトリを選択し、バックアップから復元する。
rsync -av /backup/web/ /var/www/
rsync -av /backup/etc/ /etc/
rsync -av /backup/varlib/ /var/lib/
差分バックアップを元に復元する
必要なディレクトリのみを選択して復元できる
バックアップ時点の状態にファイルが復元される。
すべてを一括で戻すのではなく、障害箇所に応じて対象を限定することで影響を抑えやすくなる。
バックアップからデータベースを復元する。
mysql -u root -p wiki < /backup/db/wiki.sql
データベースがバックアップ取得時点の状態に復元される。
既存データが残っている場合は、事前に退避を行うことが望ましい。
また、整合性を保つため、可能であればサービス停止状態で実施する。
復旧後にサービスを起動する。
systemctl start httpd
systemctl start mariadb
systemctl start wikijs
各サービスが起動し、利用可能な状態になる。
サービスの状態を確認する。
systemctl status httpd
systemctl status mariadb
systemctl status wikijs
すべて active (running) となっていることを確認する。
journalctl -xe
エラーが発生していないことを確認する。
問題がある場合は、ログをもとに原因を切り分けて対応する。
バックアップは取得しているだけでは不十分であり、実際に復元できることを確認して初めて意味を持つ。
そのため、定期的に検証環境で以下を確認する。
バックアップデータが正常に保存されていること
復元手順が問題なく実行できること
復旧後にサービスが正常に起動すること
本番障害時に慌てないためにも、あらかじめ手順を検証しておくことが重要である。
NAS に障害が発生している場合、バックアップデータへアクセスできず復旧が行えない。
そのため、バックアップ基盤自体の健全性もあわせて管理する必要がある。
また、差分バックアップを前提とする場合は、世代管理が適切に行われていることが前提となる。
データベースについては、復元後に整合性の確認を行うことが重要である。
本構成では、バックアップを NAS に集約し、差分バックアップを前提とした復旧を行う。
OS、ファイル、データベースを分離することで、障害の内容に応じた柔軟な復旧が可能となる。
バックアップは取得するだけではなく、復旧できることを確認して初めて有効となる。
日常的に検証を行い、実際に使える状態を維持することが重要である。