LVMによる自動バックアップ・システムの構築：Linux管理者への道（6）（1/3 ページ）

バックアップ計画の立案

　前回は、バックアップを実施するために必要なバックアップデバイスやツールの基本的な操作について説明しました。では、バックアップを行うための計画を立案する際に、どのような点を考慮すればいいのでしょうか？

バックアップに際して考慮すべき項目は多数存在し、当然ながらシステム環境や要件によって異なります。

バックアップ計画の検討事項

●リストアが最終目的

　バックアップ計画を検討する場合、リストアするときのことを第一に考えるべきです。バックアップの最終的な目的はデータを複製することではなく、何らかの障害が発生した際に「迅速に正しいデータをリストアすること」にあります。これを念頭に置きつつ、「どのデータを」「いつ」「どこに」「どのような方法で」バックアップするのか、そしてそのバックアップは「どれくらいの期間保存するのか」を考える必要があります。

●どのデータをバックアップするのか

　システムにはさまざまなデータが存在します。バックアップをより効率的に行うには、バックアップ対象のデータが変更される頻度や重要度によって分類し、バックアップの方法を詳細に検討する必要があります。

　例えば、システムを動作させるために必要なプログラムや設定ファイルなどのシステムデータの場合、最悪バックアップデータが存在しない場合でも、構築時、ソフトウェアのアップグレード時、あるいは設定変更時などの際のドキュメントをしっかり残していれば、同じシステムを構築することは可能です。また、更新もそれほど頻繁でないため、バックアップを取る頻度も少なくて済みます。

　しかし、ファイルサーバやデータベースシステムなどでユーザーが作成したデータは、常に更新され続けるため、頻繁にバックアップする必要があります。

　ログやアクセス統計記録なども更新され続けますが、システムを動作させることだけを考えるなら、必須ではありません。もちろん、システム要件によっては優先的にバックアップされるべきデータになることもあります。

　これらのデータが失われた場合の被害の大きさ、システムリソース、バックアップ時間、障害発生からリストアが完了するまでに許される時間などのバランスを詳細に検討する必要があります。

●いつバックアップをするべきか

　バックアップを行う時間帯は、多くの場合システムへのアクセスが少ない夜中になります。これは、バックアップの最中にデータの更新が起こる可能性を低くするとともに、提供しているサービスのパフォーマンスに悪影響を及ぼさないようにするためです。

　すべてのサービスを停止してバックアップするのであれば、前回に説明したdumpコマンドなどで簡単に実施できます。ただし、バックアップデータが大きくなってくると、サービスの停止中にバックアップが完了しないという事態も起こり得ます。バックアップ時間が不足するようになったときのこともバックアップ計画に含める必要があります。

　また、24時間365日の運用を求められるようなシステムも最近では多くなっています。この場合は、システムへの影響が少ない時間を見計らってバックアップを取らなければなりません。

●どこにバックアップするのか

　バックアップデータの保管場所も検討事項の1つです。システムのデータが非常に大切なもので、このデータがなくなるとすべての業務がストップしてしまう場合もあるでしょう。クリティカルなデータは、できるだけ大切に扱う必要があります。例えば、災害などによってシステムが物理的な損傷を受けたとしても、別サイトにバックアップデータを保存していれば、すぐにサービスを再開できます。その場合、バックアップテープを別サイトに保管する、あるいはネットワーク経由でリモートサイトとデータ同期を行うなどの方法があります。

●バックアップツールの選択

　前回、さまざまなバックアップツールを紹介しました。これらは小規模なシステム構成であれば十分に機能しますが、システムが大規模／複雑になると、処理手順や計画も非常に複雑になります。機材や管理ツールのコストを抑えたとしても、管理のための人的コストが膨れ上がり、トータルで見ると不必要に大きなコストが掛かる可能性があります。また、複雑になればなるほど人的なミスが起きる可能性も多くなります。ある程度の規模を超えた要件になった場合は、商用バックアップツールの使用も検討する必要があるでしょう。

●バックアップのタイプと頻度

　どれくらいの頻度でデータが更新されるのかによって、あるいは障害発生時にどの時点のデータまで復旧できればよいのかによって、バックアップの方法や頻度は異なります。

　リストアが最も簡単なのは、毎日すべてのデータをバックアップするフルバックアップです。この方法なら、1つのアーカイブ（複数のテープにまたがる場合もある）をディスクに書き出せばリストアを完了できます。ただし、変化することのないデータも毎回バックアップすることになるため効率的ではありません。大量のバックアップメディアが必要になるほか、毎日のバックアップ時間が非常に長くなります。

　多くのケースで適切だと思われるのは、週に1度フルバックアップを取り、残りの日は増分バックアップにすることでしょう。例えば、dumpを利用するなら日曜日にダンプレベル0でバックアップし、ほかの曜日はダンプレベル1にします。cronに登録して自動実行させる場合、ダンプレベル0用とダンプレベル1用のスクリプトを用意し、以下のように設定すれば実現できます。

　さらに複雑で、リソースの使用効率の良いスケジュールの仕方もあります。ただし、複雑にし過ぎると、リストアの際に混乱して操作ミスしてしまう可能性が増えてしまいます。管理性の良いバックアップツールを使用する場合を除き、あまりお勧めできません。

●世代管理

　例えば、ユーザーの操作ミスによってデータを削除してしまったり、ウイルスによってデータが破壊されたり、何らかの障害でバックアップが正常に取れていないことに気付くのが遅れたという場合は、何日かさかのぼったバックアップデータが必要になります。そのため、最悪の状況を想定し、バックアップしたデータをいつまで残しておくのかも考慮すべきです。

●バックアップの自動化とルーチンワークの策定

　バックアップ計画を決定したら、次はバックアップが確実に実行されるように、できるだけ処理を自動化できるようにしましょう。

　例えば、複数の処理をまとめたスクリプトを作ることによって、バックアップ手順の操作ミスを防ぐことが可能になります。cronを利用して、そのスクリプトを定期的に実行すれば、作業漏れが防げます。また、管理コストも軽減できます。

　バックアップのような、ミスや抜けの許されない作業を行う場合は、手順書などのドキュメント整備なども必要です。手順書は、バックアップを取る場合よりも、リストアの手順に重点を置きましょう。迅速にリストアが完了できるように、システムの運用前に何度も検証してリストアの手順を確立すべきです。

　また、バックアップメディアの管理方法もあらかじめ定めておき、作業が決まった流れでできるようにしておきましょう。

• ダンプレベル0のデータは必ず1つのテープに保存する
• バックアップテープには必要事項を記載したラベルを貼り、xxに保存する

といったことを決定します。

　必要に応じて管理方法は柔軟に変更していく必要もありますが、変更が多過ぎると作業漏れが発生する可能性も高くなります。

　また、システム構築の案件がある場合、ここで挙げたようなバックアップの観点から、システムをもう一度確認することをお勧めします。システムが現在どのような状態なのか、どのようなデータがどこに保存されるのか。これらを正確に把握したうえでディスク構成などを決定しないと、後で困ったことになる場合があるからです。