Windowsサーバ入門(89) 重要だから再点検! サーバ・バックアップの超基本情報

バックアップはサーバに限った課題ではない。しかし、対象となるユーザーが1人だけの(のことが多い)クライアントPCと、多数のユーザーに対してサービスを提供したりデータを保存したりするサーバでは、クライアントPC以上にバックアップの重要性が高い。

またバックアップというと、サーバで動作しているOSやアプリケーションソフト、データ以上に、それらの設定に関する情報も重要である。

というわけで、今回はバックアップの概論について説明した後、次回にWindows Server 2008の[Windows Serverバックアップ]を取り上げることにしたい。

バックアップが必要になる理由

セキュリティ上の理由、あるいは管理や業務効率の観点からすると、データはできるだけサーバにまとめるほうが好ましい。重要なデータがクライアントPCに分散していると、バックアップの手間がかかるだけでなく、どこにどんなデータがあるかを把握することが難しくなるからだ。

ましてや、リモートデスクトップサービス(ターミナルサービス)、あるいは移動ユーザープロファイルといった機能を使用していると、ますますサーバへの集中度が高まる。そうなると、サーバが使えなくなった時の被害も大きくなるので、迅速な復旧を可能にするためにもバックアップは欠かせない。

バックアップというと、「RAIDを利用しているから必要ない」と勘違いしている人がいる。しかし、RAIDはHDDの故障に対処する役には立つが、それも1台だけの故障に限られており、同時に複数台のHDDが故障したらアウトだ。また、RAID頼みではハードウェアの故障やOSの不具合といった事態に対処する手段としては不十分である。

また、RAIDコントローラの故障、あるいはコンピュータ本体の故障や破壊が起きる可能性もある。このほか、容量が足りなくなったHDDを大容量のものと交換する場面でも、バックアップを必要とすることが多いだろう。そして、事故や火災、あるいは天災によってサーバが、あるいはサーバが置かれている建物が破壊される可能性も考慮しなければならない。

こうした事情があるため、RAIDを使用しているか否かに関係なく、データや設定などのバックアップは必要である(RAID5であれば、ディスクI/Oの高速化というメリットもあるが)。

ただし、バックアップが必須だからといっても、かけられる人手・資金・手間には限りがある。手間と費用を抑制しつつ、バックアップによるデータの冗長化を図らなければならない。

最適なバックアップ手段の検討

では、バックアップすることは決まったとして、次の課題は「何にデータをバックアップするか」である。

ここで、すぐに連想されるのが、DATやDLTのようなテープデバイスだろう。しかし、HDDの大容量化が急激に進んでしまったため、テープデバイスは容量の面で追いつけていない。そうした状況に対処するにはDATチェンジャー、別名ライブラリが必要である。これは、複数のテープをマガジンに仕掛けておいて、テープが一杯になったら自動的にテープを交換してバックアップするものである。しかし、大掛かりになる分だけ、導入費用が一気に嵩んでしまう。

また、DATチェンジャーは専用のバックアップ用ソフトウェアとワンセットで動作することが多いため、これも費用を押し上げる原因になる。しかもアクセス性能の関係から、バックアップには相応の時間がかかる。

そうしたバックアップツールは、スケジュールを指定して自動的にバックアップを行う機能も持っているのが通例なので、その点ではありがたいが、費用がかかりすぎたのではメリットが帳消しになりかねない。

こうした事情から、テープデバイスを導入しても引き合うのはバックアップ対象のサーバが多い場合に限られるのではないか。それらに対してバックアップ作業線用のコンピュータを設置して、自動的にバックアップしていくわけだ。対象となるサーバが少ないと、バックアップ用の機材にかかる経費をサーバの台数で割ったときの数字が押し上げられて、経済性が落ちる。

ましてや、せいぜい数十GBの容量しかない光学メディアによるバックアップが現実的なのは、クライアントPCで一部のデータだけを書き出して保存するケースぐらいだろう。ただし、特定のプロジェクトに関連するデータだけを抽出して保存する、といった場面では有用かもしれない。

こうした事情から、現実的な手段はHDD同士のバックアップぐらいである。単体のHDDをサーバに複数台接続して、片方を実働用、他方をバックアップ用とするわけだ。また、バックアップ用を単体のHDDではなくNASあるいはSANにする方法もあり得る。

ただし、HDDということもあり、バックアップのほうが壊れる可能性もある。バックアップ用のHDDは必要な時だけ稼働させるとか、日常的なバックアップはHDD、時々はテープドライブでフルバックアップといったハイブリッド方式も考えられる。

データ以外のバックアップ

バックアップする必要があるのは、OSやアプリケーションソフトといったファイル群、あるいはデータだけではない。設定情報のバックアップも必要である。ユーザーアカウント、ネットワークの構成や設定、アクセス権の設定など、バックアップしておきたい設定情報はたくさんある。こうした設定情報の中には、HDDの中身をまるごとバックアップすることで保全できるものもあるし、そうならないものもある。

Active Directoryでドメインコントローラを複数台設置すると、アカウント情報をはじめとしてActive Directoryが扱う情報は冗長化できるから、それぞれのドメインコントローラについてHDDをまるごとバックアップすればよいという種類のものもある。しかし、サーバ単体の設定情報はそれでよいとしても、ネットワーク全体の構成情報までは面倒を見てくれない。

したがって、まずはHDDをまるごとバックアップする体制を作ったうえで、そこからこぼれる項目を洗い出して、それらについてどのように対処するかを検討する必要がある。例えば、文書の形で残しておく必要がある情報もある。具体例を以下に示すが、これらはバックアップの見地だけでなく、管理者が交代して前任者から後任者に申し送りを行うような場面でも役立つはずだ。