バックアップ／リストア基礎知識 – 可用性を高めてシステム安定稼働させるための方針検討

はじめに

システムに求められている要件の最たるものに「安定稼働」があります。
どれだけ最先端の技術を使い画期的な機能を提供しても、システムが安定稼働しないようでは業務運用としては使えません。

とはいえ、システムも機械なので突発的に故障することはあります。
環境がオンプレミスではなくクラウド環境だとしてもOS破損してシステム停止することもあります。
システムの可用性を高めるには冗長化と合わせてバックアップ／リストア運用が重要になります。

昔に比べて最近のサーバは故障が少ないらしく、サーバのリストア作業を経験をしたことがないエンジニアも結構います。
そのためかバックアップ／リストアの重要性が理解されず、十分に検討されないケースがあります。
それではトラブル発生時にシステム復旧できなくなるため、PMはバックアップ／リストア運用について十分に検討されているか気に掛ける必要があります。

そこでバックアップ／リストア運用の基本的な考え方について解説したいと思います。

リストアが必要になるタイミング

まずリストアが必要になるケースについて整理します。

サーバの全データリストア

OS破損や、ストレージ故障でデータ復旧できない場合、OS領域含めて全データをリストアします。
OS起動すらできない状態なので、必要あればディスク交換のうえバックアップデータから復旧します。
もしバックアップデータがなければ、OSセットアップからサーバ構築することになり、復旧するまで多くの時間を使います。
サーバが冗長化されていなければ、業務が完全に止まります。

このケースでよく利用されるのがサーバ全体のイメージを採取する方法です。
この方法はサーバのディスクを丸ごとバックアップするため、イメージデータがあれば復旧するのは簡単です。

ここで注意点なのが、イメージからリストアする場合、サーバの機器など変更されているとリストアできません。
例えばネットワークカードなどサーバの機材を変更した場合、ドライバが違うためイメージ復旧できない可能性があります。
サーバ機器を変更した場合、イメージの再取得が必要です。

データベース破損

DBデータやデータベースそのものが破損した場合、バックアップしていたＤＢデータをもとにリストアします。
例えばOracleの場合、登録されているDBデータを復旧させるためにはバックアップしていたDBダンプとアーカイブログを使用します。
必要あればデータベースの制御ファイルのバックアップも取得します。

どの時点までデータを復旧させるか（目標復旧時点 – RPO）、いつまでシステムを復旧させる必要があるか（目標復旧時間 – RTO）を考慮しながらバックアップ対象を検討します。

機器破損

サーバ機器だけではなくルータなど外部機器が故障した場合の考慮も必要です。
例えばスイッチングハブが物理的に故障した際、機器を交換したあとのルーティング設定をする必要があります。
この設定をバックアップしていれば、復旧時間は短くなります。
もちろんネットワーク機器以外にも導入する周辺機器がある場合は、それらのコンフィグをバックアップします。

リリース差し戻し

故障とは異なりますが、本番リリースした資材に問題があり差し戻すことがあります。
プログラムだけではなくサーバ設定などシステム構成を変更した場合、後から戻せるようにバックアップを取得します。

広域災害によるサーバ移転

地震や火災、大規模なネットワーク障害が発生することでシステム利用できない場合でも事業継続するための方法です。
いわゆる事業継続計画（BCP）のことですが、これは非機能要件で対策範囲を検討します。
多拠点を持たせる場合は相応のコストがかかるため、広域災害が発生しても稼働しなければいけないシステムの場合は西日本と東日本など拠点を分けてサーバ構築します。
もし通常稼働と待機用の環境に分ける場合、待機系にデータバックアップを渡す仕組みなど検討が必要です。

バックアップ方針

目的

何を復旧させなければいけないか、その目的を明確にします。
とりあえずサービスが立ち上がればよいのか、業務データの復旧が求められているか、などです。
システムでデータベースを使用していても、業務データは保持しておらず一時データしか保存していない場合、データはリストア対象外にすることもあります。

今回、システム障害を中心に考えていますが、それ以外でもリストアを考える場合があります。
例えば他システムの故障で不正データが送られた場合、データ復旧させる必要があるなどです。
目的によってリストアするパターンも出てくるため整理します。

バックアップ対象

バックアップで採取する対象機器（サーバ、ハブなど）と、採取する対象データを検討します。
対象機器については非機能要件で復旧すべき対象を選定します。
対象データについては、何を復旧させるのかによって検討します。

システムのイメージデータ

サーバが完全にクラッシュした場合を想定して、サーバのイメージデータを採取します。
このイメージデータを採取するタイミングは次が考えられます。

• 運用開始直前
• サーバ機器構成の変更
• アプリケーションの大型アップグレード

ちなみにコンテナ化されたサーバ環境の場合、コンテナ部分は不要ですがホストOSのイメージは採取します。

データベース

データベースを使用したシステムの場合、定期的にDBダンプを採取します。
DBダンプ出力ではフルバックアップと差分バックアップを使い分けることで、サーバ負荷やディスク容量の圧迫回避など考慮します。
また障害時点まで復旧させる必要があるならアーカイブログなどのバックアップも行います。

ちなみにシステムによっては僅かでも止められない高可用性を要求するシステムの場合はレプリケーションを利用することで、障害発生時もすぐに複製してあるデータベースを利用して復旧させることができます。

障害発生時点まで復旧しなければいけないか、または夜間に取ったバックアップのみ復旧することで、前営業日の終了時点まで復旧できれば良いのか、などの要求によって変わります。
これは復旧ポイントを障害発生時点までもっていくほど、バックアップ／リストアの方針が難しくなりコストがかかるので、それらのトレードオフになります。

リリース資材

プログラムのリリースなどシステム構成を変更する場合、リリース資材をバックアップ取得します。
また修正プログラムをリリースするのであれば、変更前のプログラムもバックアップします。
もちろんデータ変更する作業があるなら、対象データのバックアップも取得します。

作業で失敗やリリース資材に問題がある場合、差し戻しができるためのバックアップです。

ログファイル

これはリストアとは別ですが、システムが出力したログのバックアップを取得します。
目的は大きく2つあります。

１つ目は、システム障害が発生したときに原因究明するためです。
注意する点として、システム障害によりログファイルが消失しない場所にバックアップを取ります。
ディスク破損したときに、ログも消失しないよう注意が必要です。

２つ目はアクセスログを記録するためです。
システムによっては、不正アクセスや不正操作が行われていないか記録することが求められます。
法律で数年記録を保持することを義務付けられている場合もあります。
このログが消失しないこと、また肥大化してサーバのディスク容量を圧迫しないようにバックアップを取得します。

バックアップの実行スケジュール

バックアップは手動バックアップと自動バックアップがあります。
手動はサーバのメンテナンスやリリースといったイベントで採取します。
自動はバックアップツールやバックアップ取得用のスクリプトを使用して採取します。
この自動バックアップでは実行時間に注意する必要があります。
サービス提供時間や利用頻度を考えると一般的には夜間にバックアップ実行するのですが、他のバッチ処理と実行時間が重複しないように設定します。

そのような問題を回避するため、バッチジョブごとのタイムスケジュールをまとめた資料を作成することは有効です。

バックアップの世代数

バックアップしたファイルを何世代保管するのか検討します。
毎日バックアップを取得するとして、３日分のバックアップを保持する場合は「３世代管理」となります。
世代数を多く持たせると、それだけバックアップデータ量が増えディスク容量を圧迫します。
しかし世代数が少なすぎると、復旧したいタイミングのデータが消えている場合もあります。

もし世代管理をしていなかった場合、何が起きるでしょう。
例えば土曜日にデータ破損が発生し、月曜に出勤したらシステム障害に気づいたとします。
データを復旧させたくても、日曜にデータ破損した状態でバックアップを上書きしているので復旧させることができなくなります。

よくあるのが年末年始などの長期休暇を考慮すると、何世代のバックアップ取るべきか、という話が出てきます。
このあたりはシステム監視の仕組みと合わせて検討となります。

バックアップ取得の媒体

バックアップデータの保存方法は、バックアップ運用方針とデータ量によって変わってきます。
昔から使われているLTO（磁気テープ）は、長期間のデータ保持、容量、データ転送速度、低コストなど多くのメリットがあります。
ただテープ交換というデメリットがあります。

最近はクラウドのストレージサービスを活用する機会も多いです。
速度は速くないが安くて大容量のストレージを利用する方法もあります。

保管方法や媒体によって手配する機器が決まります。
サーバ機器の見積もりにも影響が出てくるので、早いタイミングで検討する必要があります。

リストア方針

リストア実施のトリガー

リストアが必要になる事態というのは障害など緊急事態だと考えられます。
しかしリストア作業というのは慎重に行わないと２次被害につながる可能性もあります。
またリストアするにしても、具体的にどのような方法でリストアするのか整理する必要があります。

例えばDBサーバでサーバ起動しなくなる障害が発生した場合、次のような流れでリストアすると考えられます。

1. イメージファイルからサーバ環境を復旧する
2. DBデータがイメージ取得時点まで戻っているので、DBダンプを使ってデータ復旧する
3. DBサーバに格納されている業務プログラムがイメージ取得時点まで戻っているので、最新ファイルを再リリースする

これらの流れを事前に整理することで、緊急事態でも迅速に対応することができます。

リストア手順

リストア作業を行うためのサーバ操作など手順書はあらかじめ用意すべきです。
そもそもリストアで行う作業はイレギュラーであるため、手順書がなければ突発的に作業できません。
慌てて調べながら対処しても、何かしら失敗します。

DBバックアップ方法について確認すると「データのバックアップはDBダンプとアーカイブログを取っています」と回答をもらうことが多いです。
そこで「アーカイブログから復旧させる方法を具体的に教えてください」と聞くと、「調べないとわかりません」と答えられることが少なくありません。
では手順書があるかと聞いたら、これもほとんど「ありません」と言われます。

じっくり腰を据えてリストア作業することが許されるなら良いです。
しかし早急に対処することが求められている中、ネット検索して調べ、本番環境で試行錯誤しながら作業を行うことは非常に危ういです。

そのような事態にならないよう、備えをしっかりするべきです。

リストア後の検証

リストア作業が完了した後、システムが正常に稼働するか検証します。
本番環境なのでできる範囲は限られているでしょうが、画面表示や検索、業務に影響ない範囲でのデータ更新などを確認します。
データ連携を行っている場合は、外部システムと連携できることを確認します。
少なくとも疎通確認レベルで検証します。

システム導入時などで作成したテスト仕様書などあれば、検証ポイントを探す参考として利用できるかもしれません。

障害発生時の対応については、別記事「システム障害発生時に対応する５つの手順」を参考にしてください。