「当たらなければ　どうと言うことはない」　先制攻撃7日間 - インフラエンジニアのトラブル防御策（前編）

「機器のランプ」「ディスクのミラーリング」「日々のバックアップ」の確認

着任三日目：日々のバックアップの確認

　二日目までで、現在のシステムが冗長構成を保っていることを確認できた。

　三日目では、その上で稼働しているデータが適切にバックアップされているかを確認する。

　バックアップは、いざという時に備え定期的に取得されるべきものであるが、トラブルプロジェクトの場合、開発の遅延をキャッチアップすることが何よりも優先されるため、追加で構築される開発環境への要求水準は自然と「動けばいい」という基準まで引き下げられ、疎通確認後すぐに開発者に提供される。その結果、開発用のシステムであるにもかかわらずバックアップの仕組みが構築されていないか、構築されていても正常に稼働しているかを日々チェックする作業が行われていないことが往々にしてある。

　まずは日々のバックアップの状態を確認することが肝要である。

　定期的にバックアップを取る仕組みがない場合は、夜中にでも一度システムを止めてフルバックアップを取ることが必要である。ただし、トラブルプロジェクトの場合、開発者が24時間泊まり込みで開発していることもよくある。もし環境のメンテナンス時間帯が明確に設定されていない場合、フルバックアップのためと言えども、システム停止をインフラエンジニアの一存により実施することはできないため、別途スケジュール調整が必要となるだろう。

　仮に定期的にバックアップを取る仕組みがある場合でも、ディスクフルになっていたり、差分バックアップの一部が失われていたり、正常にミドルウェアを停止していない状態でバックアップを取っていたりするケースがあるので、バックアップファイルの状態や、ログを確認することで、バックアップが正しく取得されていることをチェックする必要がある。

日々のバックアップで確認すべき内容リスト

1. バックアップの仕組みがあるか
2. バックアップの仕組みが定期的に実行されているか
3. バックアップの仕組みは毎日正常に終了しているか
4. バックアップ先は安全な場所であるか（同じサーバー内などでないか）
5. バックアップの手段は適切であるか（ミドル停止して取得しているなど）
6. バックアップ対象は適切であるか（意味のあるものを取っているか）
7. 過去にここからリストアした実績がどれくらいあるか
8. 差分バックアップの場合、フルバックアップからの履歴が適切に保管されているか
9. 差分バックアップの場合、最後のフルバックアップ取得から著しく時間が経っていないか
10. バックアップメディアは古くなっていないか
11. バックアップ時間は必要な時間内で収まっているか
12. バックアップに必要なリソースは将来にわたって十分確保されているか

　上記を確認することで、バックアップ関連でトラブルに見舞われる確率はかなり低くなるはずである。

　以上、トラブルプロジェクトに不幸にして着任してしまったインフラエンジニアが、更なるトラブルに巻き込まれないために、まず確認すべきシステムの健康状態について記載した。

　後編では、そのほかに確認すべき事項について記載する。