8.2. バックアップ
バックアップには 2 つの主要な目的があります。
各自のファイルを復元できるようにする
ファイルシステム全体を大量復元できるようにする
最初の目的は一般的なファイル復元依頼を基準としています。ユーザーが偶然ファイルを削除してしまい最新のバックアップからの復元を頼んできたときなど。状況の詳細はその都度多少異なりますが、これが最も一般的なバックアップの日常的な用途になります。
2 番目の状況はシステム管理者にとって頭の痛い状況です。理由はどうであれ、データセンタの実稼働部分であったけれど、今はスチールとシリコンの塊と成り果てたハードウェアから開始することになります。失ったものは何年もかけてシステム管理者やユーザーが作り上げてきたソフトウェアとデータすべてです。恐らくすべてバックアップされているはずです。ここで気になってくるのは本当にバックアップされているかということです。
また、バックアップされていたとして、それを復元することができるでしょうか。
8.2.1. 異なるデータ — 異なるバックアップのニーズ
一般的なコンピュータシステムで処理、保存されたデータ[1] の種類を見てみます。変更が困難なデータもあれば、頻繁に変更されているデータもあるのがわかります。
データが変更されるペースはバックアップ手順を計画するための決定的な重要事項となります。次にその理由をあげておきます。
バックアップとはバックアップするデータのスナップショットにすぎません。特定の瞬間におけるデータの反映です。
たまにしか変更されないデータはたまに変更すればよく、頻繁に変更されるデータはその頻度に合わせて頻繁に行なう必要があります。
システム、ユーザー、アプリケーションをよく理解しているシステム管理者はシステム上のデータを迅速にグループ化してそれぞれのカテゴリに分けることができるはずです。次に、スタートポイントの例をあげておきます。
- オペレーティングシステム
このデータは通常、アップグレード、バグ修正のインストール、サイト固有の修正時にしか変更されません。
ヒント オペレーティングシステムのバックアップに困ったことがありますか。多くの管理者が長年思案している点です。一方、インストール工程が比較的簡単でバグ修正とカスタマイズのアプリケーションが適切に文書化され間単に再生できるのであれば、オペレーティングシステムの再インストールは現実的なオプションかもしれません。
一方で、新規のインストールが完全にオリジナルのシステム環境を再現することができないかもしれない可能性が少しでもあれば、実稼働データのバックアップに比べバックアップの実行があまり頻繁に行なわれない場合でも、オペレーティングシステムをバックアップしておくのが最適な選択です。いくつかのシステムファイルだけを復元しなければならないときに、時々、オペレーティングシステムをバックアップしておくと便利です(例、間違ってファイルを削除)。
- アプリケーションソフトウェア
このデータはアプリケーションがインストール、アップグレード、削除されるときは常に変更されます。
- アプリケーションデータ
このデータは関連するアプリケーションが実行される頻度で変更されます。特定のアプリケーション及び企業により、秒単位で変更されることもあれば会計年度末だけに変更されることもあるということです。
- ユーザーのデータ
このデータはユーザーの使用パターンに応じて変更されます。ほとんどの企業では、常に変更が行なわれているということになります。
これらのカテゴリー(また、加えて企業に固有のカテゴリー)に基づいて、データを保護するために必要となるそれぞれのバックアップの性質についてよく理解しておく必要があります。
 | 注記 |
|---|---|
ほとんどのバックアップソフトウェアはディレクトリまたはファイルシステムレベルでのデータを処理するので留意してください。つまり、システムのディレクトリ構成がバックアップ動作方法の役割の一部を果たします。新しいシステムのディレクトリについては最適な構成になるよう配慮すること、ファイルやディレクトリの使用用途を先を見越してグループ化することなどが常に役に立つのはこのためでもあります。 |
8.2.2. バックアップソフトウェア - 購入と構築
バックアップを行なうためには、まず適切なソフトウェアが必要となります。このソフトウェアはバックアップメディアにコピーを作成する基本的な作業を行なう機能だけではなく、社員や企業ニーズに的確に調和するものでなければなりません。バックアップソフトウェアを考慮する際には次のような機能を考慮にいれます。
バックアップの予定を組み適切な時間に実行する
バックアップメディアの使用量、交換、保管場所を管理する
オペレータ(または、メディア交換ロボット)が適切なメディアを使用できるようになっているか確認できるようにする
オペレータが特定ファイルの特殊なバックアップを含むメディアを検索できるよう支援する
ご存知のように、現実的なバックアップソリューションとはバックアップメディアに単に何かを書き込むだけではありません。
ほとんどのシステム管理者が次のような 2 つのソリューションのうちどちらかを選択します。
商用向けに開発されたソリューションを購入する
社内でバックアップシステムを開発、作成する(オープンソース技術をいくつか統合させる場合もある)
どちらの方法にも長所と短所があります。その作業が複雑であるため、社内で開発するソリューションはある側面では不都合が生じる可能性があります(メディア管理、総合的なガイドやテクニカルサポートなど)。しかし、いくつかの企業にとってはこれが短所とはならないことがあるかもしれません。
商用向けに開発されたソリューションは非常に機能的であることが多いのですが、企業の現在のニーズには複雑すぎることがあるかもしれません。ということは、その複雑性ゆえに、その企業が成長していっても 1 つのソリューションを使い続けることができる場合があります。
このように、バックアップシステムを決定する方法に明確なものはありません。提案できるガイダンスは次の点を考慮にいれた方がいいだろうということだけです。
バックアップソフトウェアの変更は難しいので、実装したら長期間そのバックアップソフトウェアを使い続けることになります。結局、読み込みできなければならない長期のアーカイブバックアップを持つことになります。バックアップソフトウェアを変更するということは、オリジナルのソフトウェアを手近に保持しておくか(アーカイブバックアップにアクセスするため)、またはアーカイブバックアップが新しいソフトウェアと互換性を持つように変換する必要があります。
バックアップソフトウェアにより、アーカイブバックアップの変換に関連する作業は既存の変換プログラムでバックアップを実行するだけといった簡単なものであるかもしれませんし、またはバックアップ形式をリバースエンジニアリングしてからその作業を行なうようカスタムメイドのソフトウェアを記述する必要があるかもしれません。
ソフトウェアは 100% の信頼性がなければなりません。必要なものを必要なときにバックアップしなければなりません。
後日いずれかのデータを復元する必要性が生じた場合も — 1 ファイルの場合もファイルシステム全体の場合も — バックアップソフトウェアは 100% の信頼性がなければなりません。
8.2.3. バックアップの種類
コンピュータのバックアップをよく知らない人に尋ねたら、ほとんどの人がバックアップとは単純にコンピュータ上のすべてのデータの同一コピーだと考えているでしょう。つまり、バックアップを火曜日の夜に作成してから翌水曜日は何も変更がなかった場合、水曜日の夜に作成したバックアップは火曜日に作成したものと同一のものだということになります。
この方法でバックアップを構成することもできますが、システム管理者はあまり行なわないでしょう。これについてもう少し理解するために、まず作成できるバックアップのいろいろな種類を理解していきます。
フルバックアップ
インクリメンタルバックアップ
ディファレンシャルバックアップ
8.2.3.1. フルバックアップ
このセクションの冒頭で触れたバックアップの種類はフルバックアップと呼ばれています。フルバックアップはすべてのファイルがバックアップメディアに書き込まれるバックアップのことです。先のように、バックアップされるデータにまったく変更が行なわれない場合は、作成されるすべてのフルバックアップが同じになります。
この類似点とは、実際にフルバックアップはファイルが最終バックアップから変更されているかどうかをチェックしないということです。フルバックアップは変更があろうがなかろうがただ単にすべてをバックアップメディアに書き込むだけです。
フルバックアップが常に行なわれないのはこのためです — すべてのファイルがバックアップメディアに書き込まれる。つまり、何も変更されていなくてもかなりのバックアップメディア量が使用されるということです。毎晩、100 ギガバイトのデータをバックアップしているけれど変更されているデータはほぼ 10 メガバイト程度であれば、これは合理的な方法とは言えません。このためインクリメンタルバックアップが行なわれます。
8.2.3.2. インクリメンタルバックアップ
フルバックアップとは異なり、インクリメンタルバックアップはまずファイルの変更時間が最終バックアップ時間より最近のものであるかを調べます。ファイルの変更時間が最近のものでなければ、そのファイルは最終バックアップ以降変更されていないので今回のバックアップからは省略できます。一方、変更時間が最終バックアップの日付より新しいものであれば、このファイルは変更されているのでバックアップする必要があります。
インクリメンタルバックアップは定期的なフルバックアップと共に使用します(例、毎週のフルバックアップに対してインクリメンタルバックアップは毎日など)。
インクリメンタルバックアップの使用に伴う主な利点はフルバックアップよりも素早く行なえることです。主な短所は、特定のファイルを復元するためには複数のインクリメンタルバックアップを検索してそのファイルをさがすことになる場合があると言うことです。完全なファイルシステムの復元の際は、最終のフルバックアップとその直後のすべてのインクリメンタルバックアップが必要になります。
すべてのインクリメンタルバックアップを検索しなければならない必要性を軽減するために、幾分異なる手段が実装されます。ディファレンシャルバックアップと呼ばれるものです。
8.2.3.3. ディファレンシャルバックアップ
ディファレンシャルバックアップはインクリメンタルバックアップに似ています。いずれのバックアップもファイルは部分変更されるだけです。しかし、ディファレンシャルバックアップは累積していきます。言い換えると、ディファレンシャルバックアップでは、ファイルが変更されるとそれ以降のすべてのディファレンシャルバックアップに含まれていきます(当然、次のフルバックアップまで)。
各ディファレンシャルバックアップには最終フルバックアップ以降に変更されたすべてのファイルが含まれるため、最終フルバックアップと最終ディファレンシャルバックアップのみで完全な復元作業が可能になります。
インクリメンタルバックアップでのバックアップ対策と同様、ディファレンシャルバックアップは通常、定期的なフルバックアップ 1 回ごとに複数回のディファレンシャルバックアップを行なうという同様の方法に従っています。
この方法でディファレンシャルバックアップを使用する影響はディファレンシャルバックアップは時間が経つにつれ大きくなっていく傾向があることです(フルバックアップから次のフルバックアップまでの間、いろいろなファイルが変更されると仮定した場合)。ここからディファレンシャルバックアップはバックアップメディアの使用量とバックアップ速度の観点からするとインクリメンタルバックアップとフルバックアップの中間に位置し、単一ファイルによる高速な完全復元を実現します(検索/復元するバックアップが少ないため)。
こうした性質を考慮にいれると、ディファレンシャルバックアップは入念に検討する価値があります。
8.2.4. バックアップメディア
これまでのセクションを通して"バックアップメディア"という用語の使い方については十分に注意してきました。これには理由があります。経験豊富なシステム管理者のほとんどは通常、バックアップを読み込みテープと書き込みテープの意味で考えていますが、最近は他のオプションも存在するようになっています。
かつては、バックアップの目的で合理的に使用できるリムーバブルなメディアデバイスはテープデバイスしかありませんでした。しかし、状況が変化しています。次のセクションでは最もポピュラーなバックアップメディアを見ていき、その長所や短所について検討してみます。
8.2.4.1. テープ
テープは初めて広く使われるようになったリムーバブルのデータ記憶媒体でした。低価格なメディアコストと適度な記憶容量を持つという長所を持っています。しかし、テープは摩耗しやすく、テープ上のデータアクセスは性質上連続しているのが短所となります。
こうした要素が示す所は、テープ使用量の記録を付けておく必要があること(耐用年数に達したら廃棄する)、また、テープ上にある特定ファイルを検索するには長時間が要されるということです。
一方、テープは最も低価格な大容量記憶メディアのひとつであり、その高い信頼性には長い歴史があります。適度なサイズのテープライブラリを組み立てるのに予算をそれほどかける必要がなく、また現在だけでなく将来的にも使用可能であると考えることができます。
8.2.4.2. ディスク
数年前まではディスクドライブがバックアップ媒体として使用されることは考えられませんでした。しかし、ストレージ価格が低下してきて、場合によってはバックアップストレージにディスクドライブを使用するのが合理的になってきました。
バックアップ媒体としてディスクドライブを使用する主要な理由は速度でしょう。ディスクドライブより高速な記憶媒体は他にありません。データセンターのバックアップのための時間枠が短くバックアップするデータ量が大きい場合には、速度が非常に重要な要素になり得ます。
しかし、ディスクストレージは次のような理由で理想的なバックアップ媒体とは言えません。
ディスクドライブは通常、リムーバブルではありません。効果的なバックアップ対策に対する重要事項のひとつにデータセンターからバックアップを取り出して別の場所にあるストレージに入れることがあります。データベース自体から 2 フィートしか離れていない場所にあるディスクドライブ上の実稼働データベースのバックアップはバックアップとは言えず、コピーに過ぎません。データセンター及びセンター内にあったもの(コピーも含む)が不運にも破損または破壊された場合にはコピーはあまり役に立ちません。
ディスクドライブは高価なバックアップ媒体になります(少なくとも他のバックアップ媒体と比べると)。金額がそれほど重要事項とはならない状況があるかもしれませんが、その他すべての状況においてバックアップにディスクドライブを使用することに関連する経費とは、バックアップコピー数を少なくしてバックアップ全体にかかる経費を抑えるということです。何らかの理由でバックアップが読み取りできなくなった場合にバックアップコピー数が少なければそれだけ冗長性に劣ります。
ディスクドライブは壊れやすく、リムーバブルディスクドライブに余分に経費をかけてもこの問題は解決できません。ディスクドライブを落してしまったらバックアップが消失してしまいます。こうした偶発性を軽減する(完全に防ぐことはできませんが)特殊なケースを購入することはできます。しかし、ディスクドライブが高価である上さらに経費がかかることになります。
ディスクドライブはアーカイブ構成の媒体ではありません。ディスクドライブへのバックアップに関連するさまざまな問題を解決できたとしても、次の点について考慮しなければなりません。ほとんどの企業には特定期間中の記録保存に関してさまざまな法的条件があります。20 年前のデータが使用できる可能性はディスクドライブ保存に比べテープ保存の方が数段確率が高くなります。例えば、システムに接続するために必要なハードウェアをいまだに保持しているかどうか。また、ディスクドライブはテープカートリッジに比べかなり複雑な仕組みになっています。20 年前のモータが 20 年前のディスクプラッタを回転させるということは、20 年前の読み込み/書き込みヘッドがそのプラッタの表面に浮くことになります。20 年のあいだ動かしていないコンポーネントが完璧に動作する可能性はどうでしょうか。
注記 データセンターの中にはディスクドライブへバックアップしてから、そのバックアップが終了すると今度はアーカイブの目的でテープに書き出すところがあります。これにより、バックアップ時間枠内で最も早くバックアップすることが可能になります。そのバックアップをテープに書き出すのは時間枠外の残りの通常業務時間帯に行なうことができます。"テープへの書き出し"が翌日のバックアップ前に終了してさえいれば時間は問題になりません。
ここで述べた以外にもディスクドライブへのバックアップが合理的である場合がいくつかあります。次のセクションでは現実的なソリューション(高価ですが)のひとつとなるネットワークとの組合せ方について見ていきます。
8.2.4.3. ネットワーク
ネットワークだけではバックアップ媒体として役にたちません。しかし、大容量ストレージ技術と組み合わせることで十分にバックアップとして成り立ちます。例えば、大量のディスクストレージがある遠隔のデータセンターにリンクする高速ネットワークを組み合わせると、前の説明にあるディスクへのバックアップ関連の短所が短所ではなくなってしまいます。
ネットワーク経由でバックアップを行なうことにより、すでに別の場所にある壊れやすいディスクドライブをどこへも移動する必要がなくなります。十分なネットワークバンド幅があれば、ディスクドライブへのバックアップによる速度の利点を活かすことができます。
しかし、この方法はアーカイブストレージ関連の問題点については何も対処していません(先に述べた"バックアップ後のテープへの書き出し"の方法が使えます)。また、この方法だとデータセンター本部へリンクする高速の遠隔データセンターの維持費が非常に高くなります。しかし、この種の機能を必要とする企業には必要経費として出費できればこの方法を実施することができます。
8.2.5. バックアップの保存
バックアップが終了したらどうなるのでしょうか。バックアップを保存する必要があります。しかし、何を、そしてどこへ保存するかという点が明確になっていません。
明確にするためにはまずバックアップが使用される状況を考えます。主に 3 タイプの状況があります。
小規模、ユーザーからの臨時的な復元のリクエスト
大規模、災害からの復旧に要される復元
アーカイブ保存、再度使用する可能性が少ないもの
残念ながら 1 と 2 には対立する違いがあります。ユーザーが偶発的にあるファイルを削除してしまうと、そのユーザーは迅速な復元を希望します。これはデータが保存されるべきバックアップメディアがシステムから数歩の距離であることを意味します。
データセンターにあるコンピュータの完全復元を必要とする災害が生じた場合、災害が物理的な性質のものであれば、何にせよコンピュータを破壊する災害はそのコンピュータから少ししか離れていないバックアップも破壊してしまうでしょう。こうなると最悪な問題となります。
アーカイブ保存はその点問題が少なく、いずれの目的にせよ使用する確率はかなり低いため、バックアップメディアがデータセンターから離れた場所にあればまったく問題はありません。
このような違いを解決する方法は企業などのニーズによって異なります。可能性のある方法のひとつとして、数日分のバックアップをその場に保存し、新しい日毎のバックアップが作成された時点で安全性の高い離れた場所のストレージに移動します。
別の方法として、別々のメディアプールを 2 つ管理する方法があります。
臨時の復元リクエスト専用のデータセンタープール
離れた場所での保存及び災害発生時の復旧用のオフサイトプール
当然、プールを 2 つ用意すると言うことはすべてのバックアップを 2 回実行するかバックアップのコピーをとる必要が生じてきます。実現可能ですが、2 重バックアップは時間がかかりすぎ、コピー作成にはコピーを処理するための複数のバックアップドライブ(及び、恐らく実際にコピーを行なうための専用システム)が必要になります。
システム管理者にとっての難問は、全員のニーズに十分に合うようバランスを保ちながら、最悪の事態に備えてバックアップが利用できるようにしておくことです。
8.2.6. 復元についての問題点
バックアップが日常的に行なうものであれば、通常、復元はそれほど頻繁に起こるものではありません。しかし、復元作業は避けられない事項であり、準備しておくのが最適であるため必要事項となります。
重要なことはこのセクションで詳しく説明している各種の復元例を検討し、対策を判別して実際に復元作業を行なえるようシステム管理者としての能力を試してみることです。最も難しいものは最も重要となる点に留意してください。
8.2.6.1. ベアメタルからの復元
"bare metal からの復元"という言い回しは、まったく何の種類のデータもない(オペレーティングシステム、アプリケーション、その他何も入っていない)コンピュータに完全なシステムバックアップを復元するプロセスのことを指すためにシステム管理者が使っています。
全般的に、ベアメタル復元には 2 種類の基本的な手段があります。
- 再インストールしてから復元する
この場合、真新しいコンピュータを初めてセットアップするかのように基本オペレーティングシステムをまずインストールします。オペレーティングシステムが入り正しく設定したら、他のディスクドライブをパーティション設定してフォーマット化し、バックアップメディアからすべてのバックアップを復元できるようになります。
- システムリカバリディスク
システムリカバリディスクとはある種の起動可能なメディアであり (CD-ROM であることが多い)、最小限のシステム環境が入っているので最も基本的なシステム管理作業を行なうことができます。リカバリ環境にはディスクドライブのパーティション設定とフォーマット化を行なうユーティリティ、バックアップデバイスへのアクセスに必要なデバイスドライバ、バックアップメディアからのデータ復元に必要なソフトウェアが入っています。
| 注記 |
|---|---|
起動可能なバックアップテープを作成して実際にそこから復元プロセスを開始する機能を備えたコンピュータもあります。しかし、この機能がすべてのコンピュータにあるわけではありません。特に、PC アーキテクチャをベースとしたコンピュータのほとんどがこの方法は役に立ちません。 |