【連載】

Windowsサーバ入門

【第89回】重要だから再点検! サーバ・バックアップの超基本情報

[2012/06/20 09:00]井上孝司 ブックマーク ブックマーク

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

  • ネットワークの物理構成図と論理構成図
  • 個々の機器の配置場所
  • IPアドレスの配分
  • DHCPのスコープ情報
  • 固定IPアドレスを使用しているコンピュータと割り当てているIPアドレスの一覧
  • ルータやレイヤー3スイッチの設定情報
  • Active DirectoryにおけるドメインとOUの構成
  • Active Directoryでフォレストルートドメインになっているドメイン
  • Active Directoryで操作マスタになっているドメインコントローラ
  • Active Directoryのセキュリティ設定内容
  • グループポリシーのうち、既定値から変更した内容
  • OUの管理を誰かに委任している場合の委任先と委任内容
  • ユーザー名とユーザーごとの設定情報の一覧
  • グループのメンバー一覧
  • 共有フォルダ、共有プリンタの場所、名称、アクセス権の設定

※ 本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。予めご了承ください。

一覧はこちら

連載目次

この記事に興味を持ったら"いいね!"を Click
Facebook で IT Search+ の人気記事をお届けします
注目の特集/連載
[解説動画] Googleアナリティクス分析&活用講座 - Webサイト改善の正しい考え方
[解説動画] 個人の業務効率化術 - 短時間集中はこうして作る
ミッションステートメント
教えてカナコさん! これならわかるAI入門
AWSではじめる機械学習 ~サービスを知り、実装を学ぶ~
対話システムをつくろう! Python超入門
Kubernetes入門
SAFeでつくる「DXに強い組織」~企業の課題を解決する13のアプローチ~
PowerShell Core入門
AWSで作るマイクロサービス
マイナビニュース スペシャルセミナー 講演レポート/当日講演資料 まとめ
セキュリティアワード特設ページ

一覧はこちら

今注目のIT用語の意味を事典でチェック!

一覧はこちら

会員登録(無料)

ページの先頭に戻る