バックアップ・リストアについて知ろう
はじめに
みなさん、こんにちは。前回までの解説でインフラ入門編は終了となります。今回からは、皆さんの関心が高いと思われる技術に特化して解説をしていきたいと思います。
最初のテーマは「バックアップ・リストア」です。システム運用における大きなテーマとなるため、技術的な知識以外に運用の知識も多分に求められる分野です。
バックアップ対象のデータには様々な種類があり、バックアップ・リストア方法にも多くの選択肢があります。そこで今回はシステムにおいてよく利用されている技術を中心に紹介していきます。
バックアップ・リストアとは
1. バックアップとは
データ損失に備えてデータを複製しておくことを「バックアップ」といいます。システムは24時間365日動いているため、ハードウェア障害やソフトウェアバグ、人的ミスなどデータを損失する危険性は身近に多くあります。
個人のパソコンにあるデータであれば話は簡単なのですが、システム上のデータには「数が多い」「容量が大きい」「更新頻度が高い」といった特性があり、単純にバックアップするだけでも意外に大変な作業です。
- 数が多い
Webコンテンツやアプリケーション関連ファイル、日々蓄積されるログファイルなど、システムに関わるデータは数が多い。数が多いことでファイルごとにオープン・クローズが発生しオーバーヘッドも大きい - 容量が大きい
DBデータのようにテラバイト級のデータも珍しくない。容量が大きいことでネットワークや保存先メディアを多く消費し、バックアップ時間も長くなる - 更新頻度が高い
DBデータのように常に更新され続けているものも多い。基本的には更新途中のデータは複製できないため、どこかで静止点を確保する必要がある
ある程度のシステム規模になると専用のソフトウェアを使用してバックアップ運用している場合がほとんどです。また、バックアップ先にはストレージやテープ装置を使用します。業務システム用の製品は価格も高く触れる機会も少ないため、駆け出しのインフラエンジニアにはイメージしづらく敷居が高いものです。ソフトウェアであれば評価版として公開されている製品もあるため、まずは一度インストールして触ってみることをおすすめします。
2. リストアとは
データ損失に備えてデータを複製しておくことをバックアップと説明しましたが、データ損失が起きた際に複製しておいたデータから戻すことを「リストア」と言います。
リストアにも「24時間365日動いているシステムのデータ」という扱いの難しさがあり、単純に戻すだけでは終わらないケースも多々あります。また、スピードを求められることがさらに難しいところです。
システム構築中にもリストアテストを実施する機会がありますが、リストアテストについて考え抜いてきた人間でさえ「本当に戻るのか?」と一抹の不安を抱えながらテストを実施しています。それが運用中のシステムにおいて、実際のデータが入った状態で、スピードを求められながら実施しなければならない、と想像するとどうでしょうか。リストアにも様々な選択肢がありますが、可能な限りシンプルに設計することが基本となります。
3. リカバリとは
リストアとともに「リカバリ」という単語もよく聞くと思います。リストアはバックアップしたデータをバックアップした状態で戻すことを指しますが、リカバリは戻したバックアップデータに何らかの処理を加えてデータを正常化・最新化することを指します。
主にデータベースの復旧に使用されており、ベースとなるデータに更新ログを適用することで、障害発生直前の状態までデータを復旧することが可能です(図1)。ただし、ログファイルまで損失した場合は復旧できません。
バックアップ・リストアに必要な知識
1. ハードウェア
当たり前の話ですが、バックアップを取得するためにはバックアップデータの受け皿が必要となります。扱うデータ量が増大している現在のシステムにおいて多く採用されているのは、第2回でも紹介した「ストレージ装置」と「テープ装置」です(図2)。
それぞれメリット・デメリットがありますが、ストレージ装置のメリットは扱いやすさと処理速度です。大量のデータや頻繁にバックアップする必要があるデータを手軽に扱うことができます。最近ではテープ装置の速度も向上してきているため、一概にストレージ装置の処理速度に優位性があるとも言い切れませんが、オプションでディスク間の複製といった高速処理機能も備えており、バックアップ時間の短縮にもつながります(図3)。
テープ装置のメリットはバックアップデータの保管コストが低い点です。データベースなど大容量データの場合、バックアップを毎日取得し、過去のバックアップデータを一定期間保管するとなるとその保管コストは無視できません。数日前のデータベースのバックアップは相当なことがない限り不要ですが、保管しないわけにもいかない、というようなデータの保管にはテープ装置が向いています。また、記録媒体を持ち運べるといったメリットもあり、システムとは別の場所に外部保管する運用を行っているケースもあります(図4)。
ストレージ装置とテープ装置のいずれか、または両方を採用するかは、システムごとの要件に照らし合わせて判断する必要があります。様々な資料で紹介されている情報も、時代、バックアップデータ量や使用年数などの前提、発信者(ストレージメーカ、テープメーカ)、過去の運用体験によって異なってくるので注意が必要です。
2. ソフトウェア
先に、「ある程度のシステム規模になると専用のソフトウェアでバックアップを運用している」と記載しましたが、専用のソフトウェアではなくてもOSに含まれる複製、移動、削除といった基本機能やバックアップ関連ツールを駆使すればバックアップ・リストアは可能です。
しかしながら、多くのシステムでは専用ソフトウェアを利用したバックアップ運用を行っています。専用ソフトウェアが備える代表的な機能は下記の通りですが、運用を支援してくれる機能に期待して導入しているのです。
- 集中管理
システムの各サーバに対するバックアップ設定やバックアップ・リストア実行を管理サーバから集中管理することが可能 - バックアップデータの管理
バックアップ実行日やサーバごとにデータを参照したり、古いデータを削除したりなど、人間では管理が難しいところを補完 - 増分・差分バックアップ
データの更新部分だけをバックアップすることでバックアップ時間の短縮が可能 - バックアップ監視
バックアップ状況を監視し、失敗したジョブの把握、再実行等が容易 - スケジュール実行
あらかじめ設定した時間にバックアップを開始することが可能
3. 運用
運用においては、定期的に行う作業と不定期で行う作業が存在します。定期作業としては「監視」や「ジョブ管理」、不定期作業としては「障害復旧」などがあります。バックアップに焦点を絞ると、定期作業としてはデータやログのバックアップ、不定期作業としてはシステムのバックアップ(OSを含めたサーバ全体のバックアップ)などが該当します。
- 定期バックアップ
日次、週次、月次といった形で定期的に実行するバックアップ - 不定期バックアップ
何らかのイベントを契機に実行するバックアップ
また、バックアップ運用を考える上では「フルバックアップ」「差分バックアップ」「増分バックアップ」についても知っておく必要があります。差分と増分バックアップは単体では成立しないので、本記事では便宜上「フル+差分バックアップ」「フル+増分バックアップ」と表現します。
- フルバックアップ
対象データをまるごと取得 - 差分バックアップ(フル+差分バックアップ)
フルバックアップ後に追加されたデータを取得する。差分バックアップ後にさらに差分バックアップを実行した場合は、フルバックアップ後に追加されたすべてのデータを取得 - 増分バックアップ(フル+増分バックアップ)
フルバックアップ後に追加されたデータを取得する。増分バックアップ後にさらに増分バックアップを実行した場合は、前回の増分バックアップ後に追加されたデータのみを取得
このようにそれぞれ特徴がありますが、フル+差分バックアップ、フル+増分バックアップを選択することでバックアップ時間を短縮できます。ただし、リストアする際には逆に追加の手順が必要となるため注意が必要です(図5)。
連載を通して、インフラエンジニアが関わる「プロジェクト」に注目し、さまざまな側面から解説していく本コラム。今回からはプロジェクト後に訪れる「システム運用」に関わる内容を解説していきたいと思います。
今回のテーマは「運用」と「保守」ですが、何か違いがあるのでしょうか。普段はあまりその違いを意識することも少ないかもしれません。
運用とはシステムを止めずに動かすことであり、それに伴う作業を実施することです。監視をしてシステムが止まらないようにしたり、不慮のデータ損失に備えてバックアップを取得したりと、システムが提供するサービスに問題が起きないようにします。
一方の保守はシステムの改善や機能拡張をすることであり、システムに手を加えることです。パッチの適用やアプリケーションの機能追加、チューニングなどを実施します。
現在の日本においては、運用は運用専門会社や企業のシステム部門が実施し、保守はシステム開発の会社が実施しているケースが多いようです。
(第10回へ続く)
サーバごとのデータとバックアップ方法
システムには様々なデータが存在しています。Webコンテンツのような単純なものから、データベースのデータといった複雑かつ大容量なものまであります。以降ではWeb3層システムを軸に、サーバごとに存在するデータとそのバックアップ方法の例を紹介していきたいと思います。
1. Webサーバ
WebサーバにはWebコンテンツが存在します。データ容量も小さく更新されるタイミングも頻繁ではないため、アクセス数が少ない深夜帯やコンテンツ更新などのタイミングでバックアップすることになります。
また、容量の小さなデータが大量にあるという特性があるため、NAS(ストレージの一種)やバックアップサーバにネットワーク経由で転送するといった実装が多くなります。
なお、Webサーバでは大量のアクセスログが発生しますが、これらのログもバックアップ対象となります。
2. APサーバ
APサーバにはビジネスロジックを実装したアプリケーションが存在します。データの特性はWebサーバと似ているため、Webサーバと同様のバックアップ方式を採用することが多くなります。
また、アプリケーション関連のデータも多く存在するため、システムごとに対象データが千差万別なのが特徴で、インフラエンジニアからすると総量を見積もり辛いという側面があります。
なお、APサーバもWebサーバと同様にアクセスログが大量に出力されるため、これらのログもバックアップ対象となります。
3. DBサーバ
システムの中で最も難易度が高いのがDBサーバです。データ容量が大きく更新も頻繁に発生しています。バックアップ方法はデータベースミドルウェアに何を使用しているかに依存しますが、大別すると「オフラインバックアップ(コールドバックアップ)」と「オンラインバックアップ(ホットバックアップ)」に分けることができます。
オフラインバックアップはその名の通りデータベースを停止して、データが更新されない状態でバックアップを取得する方法です。データの整合性が取れた状態でバックアップを行うため実装も単純で、リストアも基本的にバックアップしたものを戻すだけで完了します。
対してオンラインバックアップはデータベースが動作しており、データが更新されている中でバックアップを取得する方法です。基本的にはデータベースの更新は変更内容がログファイルに書き込まれた後で反映される仕組みになっているため、バックアップ中のみデータファイルへの更新を停止してデータファイルをバックアップするというのが基本的な考え方です。
なお、オンラインバックアップは障害の発生状況(欠損したファイルの種類)によってリストア・リカバリの内容が変わってくるため、リストアも難易度が上がります。
4. その他サーバ>
その他のサーバに関しても、基本的にミドルウェアに関する管理データをバックアップします。製品ごとに管理情報を出力する機能があるので、そちらをバックアップしていくことになります。
おわりに
今回はバックアップ・リストアにフォーカスして解説しました。バックアップ・リストアの世界は奥が深く、今回紹介したものはその一部にすぎません。ただ、システムの運用設計書に記載されている基本的な要素については解説できたのではと思います。
次回は「セキュリティ」をキーワードに解説します。システム障害原因の大部分がセキュリティインシデントという昨今、ますますセキュリティの重要性は増してきています。次回も楽しみにしていてください!