本記事では、初めに「リスク管理」という観点から「バックアップ」を見て、バックアップが対処するリスク、次にそのリスクへの対処法としてバックアップの設計の概要について述べます。その後、バックアップの種類、それらのトレードオフ、バックアップ対象といったバックアップの基本事項について説明し、最後にリスク事象である「データ消失」の具体例を原因別に挙げて説明します。 次回の記事では、具体的なバックアップ及びリカバリー方法について説明していきます。 なお、本記事内では適宜用語の説明などは行いますが、読者の方は運用関連の基本的な用語などに関してある程度の知識があることを前提とします。
バックアップ及びリカバリーとリスク管理
過去2回の記事で、「監視」及び「ログ・メトリクス」について扱ってきました。今回扱う「バックアップ」と「リカバリー」も、これらの記事で何度か話題に挙げた「リスク管理」という大きな枠組みの中に位置づけられるでしょう。
バックアップが扱うリスクと対処方法
バックアップの目的とは何でしょうか。当たり前のように聞こえると思いますが、簡単に言えば「データ消失に備える」ことです。
リスク管理という観点からもう少し細かく書くと、バックアップが対処するリスク事象は「データ消失」です。また、そのリスク事象が発生した際に、
- 簡単に、短い時間で
- 失ったデータを出来れば完全に近い状態で元に戻す（リカバリー）
ことでリスク事象発生時の損害を緩和することが目的です。
また、「元に戻す」の定義ですが、主に以下の2通りがあります。
- 最新のデータに戻す
- 過去のデータに戻す
前者は説明不要だと思いますので、後者に関して少し説明します。
後者のケースの例として、データが改竄された、あるいは誤ったデータを投入してしまった場合などが挙げられます。こうしたケースに対応するために、最新のバックアップデータだけでなく、過去一定期間のデータを保持しておく必要があります。
バックアップ・リストアの設計に関する概要
以前も少し触れましたが、リスク管理の大雑把な流れは以下の通りです。
- リスク事象の洗い出し
- リスクの分析・評価
- リスクへの対処
1については、後ほど「データ消失」の具体例をいくつか取り上げて説明します。2に関してですが、各リスク事象について、
- 発生頻度
- 発生時の影響
を出していきます。これらを掛け合わせたものが、そのリスク事象への対応の優先度になります。まず最初に、発生頻度が高く発生時の影響が大きいリスク事象に対応する必要があります。
最後に「データ消失」というリスクへの対処方法ですが、だいたい以下の3つに分類できます。
- 予防
- 発生時の損害を少なくする
- （何もしない）
データ消失の「予防」の例としては、RAID、クラスター等を使ったストレージの冗長化が挙げられます。
今回扱うバックアップは、「発生時の損害を少なくする」対策の一つに位置づけられます。このタイプのその他の方法に、構成管理ツールなどを含めてもいいかもしれません。サーバーの設定ファイル等の構成情報を構成管理ツールに保管しておいて、設定データ消失(やその他障害)発生時に素早くサーバーを再構築出来るようにして損害を最小限に抑えます。
重要度の少ないデータ、他から取得・生成可能なデータに関しては「何もしない」という選択肢もありえます。例えばRettyの場合、Webサーバーのログはバックアップを取っていません。
バックアップの基本知識
バックアップの種類
一口に「バックアップ」と言っても、色々な種類があります。ここではバックアップの一般的な分類をいくつか挙げます。
| 分類 | 実例 |
|---|---|
| デバイス別 | ローカルディスク、テープ、リモート |
| バックアップ手法別 | フル、差分 |
| バックアップデータの可用性別 | オンライン、オフライン |
| バックアップ対象別 | ファイル、ファイルシステム |
「バックアップ対象」に関しては、この後少し触れますが、それ以外についてここでは説明しませんので、各種情報を参照して下さい。
トレードオフ
各種バックアップ方法を列挙しました。運用に携わっている方であればお分かりかと思いますが、万能なバックアップ手法というものは存在しません。必ず以下のような項目間のトレードオフが存在します。
- 使用する資源の量
- リストアに要する時間
- バックアップ時間、ダウンタイム
- バックアップ、リストア手順の複雑さ
これらのトレードオフは、結局のところバックアップにかかる直接・間接的なコストとリスク事象発生時（リストア時）のコスト及び損害額のトレードオフと言い換えられると思います。各項目それぞれについて簡単に説明します。
まず「使用する資源の量」ですが、バックアップ手法によって使用するバックアップメディアの量やネットワーク帯域幅が異なってきます。前者はコストに直接影響し、後者はシステムのパフォーマンス低下による間接的な利益損失、あるいはネットワークインフラに対する必要な投資額の増加につながります。
次に「リストアに要する時間」では、データ消失が発生してリストアに時間がかかると、その間に得られるはずだった利益（売上や会員獲得など）が得られないという機会損失が増加します。
3の「バックアップ時間」ですが、バックアップ時間が長くなると他の処理に影響を与える場合があります（例えば後続のバッチの処理など）。また、サービス停止を伴うバックアップ手法の場合、その間の機会損失が発生します。
最後に「バックアップ、リストア手順の複雑さ」ですが、バックアップ・リストア手順が複雑な場合、それらの手順の実装に時間（つまりコスト）がかかります。「実装」にはシステム的な実装以外に、作業手順の作成、テストの設計や実施、運用者教育といったプロセスの整備なども含まれます。また、高度で複雑なバックアップ・リストア手法の場合、高価な機器・ソフトウェアが必要かもしれません。
実際のプロジェクトでは、これらのトレードオフやその他の制約などを考慮して、バックアップ手法を選択することになります。
バックアップ対象
バックアップ対象について、簡単に説明します。
一般的なWebシステムの場合、バックアップ対象としては以下のものが挙げられます。これらのバックアップ対象は、それぞれ特性が異なります。
- システムファイル（OS、サーバー、ミドルウェア）
- Webコンテンツ（html、php、warなど）
- データベース
- ログ
- その他
システムファイル
一番目のシステムファイルですが、更新される頻度が低いためバックアップは比較的容易です。OSのセキュリティアップデート等のパッケージの更新や設定内容変更といったイベントの後にバックアップを実施するのが一般的です。
Webコンテンツ
次にWebコンテンツですが、これはシステムファイルに比べれば更新の頻度は高いのですが、通常は多くても一日一回位だと思います。また、Webコンテンツの場合、通常はソース管理されていると思いますので、Webサーバー上のコンテンツを直接バックアップする必要は少ないです。
データベース
Webシステムにおけるデータベースの重要性は説明不要だと思いますが、当然バックアップも重要です。データベースをバックアップ対象としてみた時には、更新頻度が高い、データ整合性に配慮が必要、といった特徴があります。
ログ
次にログですが、特徴として「量が多い」点が挙げられます。また、前回の記事を読まれた方はログ取得の目的について把握されていると思いますが、そうした目的を鑑みると、ほとんどの場合、生のログを全て完全な形でバックアップする必要はないだろうと思います。先ほども書いた通り、Rettyでは生のログファイルのバックアップを取ってはいません（ログの集計・解析結果はDBに保管されているのでバックアップ対象となっています）。
その他
最後に「その他」と書きましたが、ここまでのバックアップ対象ではカバーできていないもの、例えば「ハードディスクの構成情報」などのメタデータがあります。これらに関しては、前の方で少し触れた構成管理ツールなどを使って管理する必要があります。この項目については、別の機会にご紹介できればと考えています。
データ消失を引き起こす主な事象
ここまで、バックアップの目的、種類、対象について説明してきました。ここでは「バックアップ」が対処するリスクである「データ消失」を引き起こす事象・原因について、主なものを挙げていきます。
データ消失、バックアップなどを扱った各種の調査を見ると、データ消失の原因として最も多く挙げられているのは、誤操作等の人的ミスか、ハードウェア障害です。
人的ミス
このうち「人的ミス」には以下のようなものがあります（これらに限りません）。
- 開発者がSQLの条件を誤ってテーブルのデータを削除
- 開発機と本番機を間違えて、テーブルを初期化
- ディスク追加の際、既にあるパーティションをフォーマット
社内での人的ミスだけでなく、データセンター等、ベンダーの人的ミスによるデータ消失の可能性もゼロではありません。先日、大きく話題になったファーストサーバー社でのデータ障害ですが、複数あった原因の一つが人的ミスだったようです。
それ以外にも、ユーザーが誤ってデータを削除してしまう場合もあります。主なものとして以下のものが挙げられます（これらに対応すべきかどうかはサービスの内容にもよると思います）。
- サービスから退会
- 投稿データを削除
ハードウェア障害
データ消失を起こすハードウェアの故障のほとんどが、HDDの故障だと思います。通常はRAID等の冗長化によってデータ消失が起こらないようにしているはずですが、
- HDDが2台同時に故障
- RAIDコントローラーの不具合
といった場合には、データ消失が起こることも考えられます。
ソフトウェア障害
ソフトウェアの障害によるデータ消失の例には、以下のようなものがあります。
- 古いレコードを削除するプログラムのバグで、新しいレコードも削除してしまった
- DBの接続情報が誤っていて、本番機に対して不要なデータ削除処理を走らせてしまった
- SQLインジェクションをつかれて、テーブルが丸ごと削除された
- ファイルシステムのバグでDBファイルが破損した
災害
ここまで挙げた例に比べると発生頻度は低いですが、地震、火事等の災害によるデータ消失も考慮するべきでしょう。
まとめ
バックアップは「データ消失」というリスク事象が発生した際の影響を小さくするために行うものです。
バックアップの方法にはさまざまなものがあり、それらの間には直接的・間接的なコスト、および損害発生時のコスト・損害額のトレードオフが存在します。また、バックアップ対象となるデータはそれぞれ特性、重要度が異なります。さらには、データ消失の原因となる事象にも色々な種類があり、それぞれ発生頻度は異なります。
バックアップ・リストア方法を設計する際には、それらの要素、各種制約を考慮して、各バックアップ対象毎に最適な方法を選択する必要があります。 次回は各バックアップ対象ごとに、代表的なバックアップ・リストア方法を具体的に説明していきます。
執筆者紹介
鹿島和郎
ソーシャルグルメサイト「Retty」の開発・インフラ全般を担当。過去には米企業でのオフショア開発拠点の立ち上げから国内SIerでの運用保守業務まで、広く浅く経験している何でも屋。
Rettyは、「行った」お店の投稿・共有、友達・趣味嗜好の合う人のオススメから「行きたい」お店をリスト化、スマートフォンで現在地周辺のお店をリストから検索などできるサービスで、Facebook、Twitterアカウントがあれば無料で使用可能。PC、iPhone、Androidに対応。