連載 究極ホーム・ネットワークへの道 −実例に学ぶホーム・ネットワーク・デザイン− 第12回 ワークグループ・ネットワークにおけるファイル・サーバ運用術（2） 渡邉利和 2002/01/19

　ネットワーク内に存在する共有フォルダは1つだけで、基幹サーバとなっているマシン「compaq」のローカル・ディスク上にある。共有名はそのものズバリの「share」としてある。この下にさらにフォルダが多数作られているわけだ。なお、古いアプリケーションなどからファイルを参照する場合、リモート・リソース名をUNCで直接指定できない場合があったため、ネットワーク・ドライブとしてマウントする場合もある。このときは、ドライブ・レターとして「H」を割り当てるようにしている。この文字にも特段の意味はない。実をいうと、なぜ「H」にしたのか、その由来もあやふやなほどだ。確かHomeの「H」だったような気がするが、ハードディスクのドライブ・レターと衝突しないように適当な間隔を空け、さらにほかの「M」や「R」といった文字と混同しないように、といったことを考えたのは間違いない。

ファイル・サーバ「compaq」のCドライブ

画面のように「share」のみを共有フォルダとして、LAN上に公開している。このフォルダの下に原稿や資料、デバイス・ドライバなどを分類して保存するようにしている。

ファイル・サーバ「compaq」上に「SHARE」というフォルダを作成し、これを共有フォルダとしている。

　このようにドライブ・レターを統一しておくと、そのときどきの状況に応じて異なるマシンで作業を行っても、一切混乱を生じることはないというメリットが生まれる。さらに、アプリケーションの設定などは、極端な場合レジストリをダンプ（エクスポート）してほかのPCに読み込ませる（インポート）だけで問題なく移行できることも多いので、その点でも便利だ。

共有フォルダの活用

　さて、共有フォルダを用意すること自体は特段難しい作業ではなく、むしろ極めて簡単なことだといってよい。問題は、運用面できちんとした方針を定めて活用することだ。

　小規模な事業所や部門などで陥りがちな状況として、「共有フォルダがゴミ・ファイルで埋まる」という問題がある。これは、共有フォルダをどう利用すべきか、というポリシーが定まっていないか、あるいはポリシーが形骸化していてユーザーに浸透していないことに原因がある。いわゆる「IT化」の一環としてファイル共有サービスを運用する場合であれば、それなりに真剣に考えることになるのだろうが、部門レベルで運用するIAサーバの場合、簡単に共有フォルダを作ってしまうため、用途の分からないファイルが山のように溜まってしまう結果を招きがちだ。共有フォルダ自体は単なるハードディスクと大差なく、単に存在するだけで有用なものになるわけではない。

　筆者の場合は、作業の性質からもPCのハードディスクのフォーマットやOSの再インストールといった作業が発生することは珍しくない。そのため、うっかりすると重要なデータ・ファイルを消してしまうといった事故も起こり得る。そこで、共有フォルダの最も重要な運用ポリシーとして、「なくなってほしくないファイルを置く」ことにしている。基本的には、原稿そのものや参考資料、デジタル・カメラで撮影した画像、ICレコーダで録音した音声データなどである。筆者の場合、原稿執筆の際に利用するのは特定の1台のデスクトップPC、またはノートPCと決めているので、合計2台しかないことになるが、この2台ともローカルのハードディスク上にはデータ・ファイルを一切置かないようにしている。執筆時は常に共有フォルダ上で作業を行うのだ。これは、バージョン管理の煩雑さを避けるための方策でもある。

　また、共有フォルダを「バックアップ・ストレージ」と考えることもできる。この場合、作業は基本的にローカル・ハードディスク上で行い、適当に区切りのよいところで共有フォルダにコピーしておく、という運用方法になる。もちろんこうしたやり方にもメリットはあるが、筆者の場合、生来の性格的な問題もあって、このやり方だと複数の異なるバージョンが散在してしまう結果に陥りがちだ。微妙に内容の異なる同名ファイルがいくつもできてしまい、どれが最新の正しいファイルか判断できなくなるのである。ローカルとリモートのファイルが自動的に同期するような仕掛けを別途用意しておけばよいのだが、手作業で実行する場合はどうしてもこうした問題が発生しがちだ。特に、あるPCで途中まで執筆し、翌日別のPCで作業を継続するといった場合、前日に作業したPCの最新ファイルのコピーを忘れ、ちょっと古いバージョンのコピーしかなかった場合には、面倒な状況が発生する。これを避ける手段として最も簡単なのは、ファイルを1つしか作らないことだ。つまり、自宅で作業する際には、常に共有フォルダ上のファイルを直接参照し、ローカルにコピーを作ることはしない、という方針になる。

　この場合、ネットワークを介したアクセスとなるため、遅延やアクセス断絶といった問題を心配するかもしれないが、現在一般的な100BASE-TXスイッチング・ハブで構成されたLANの場合、ローカル・ハードディスクと比べて遅いと感じることはない。むしろ、「ローカルのPCがクラッシュしてもデータが巻き添えになることはない」という安心感の方が勝っていると感じている。もちろん、ファイル・サーバとなるマシンがダウンしたりクラッシュしたりするようでは話にならないが、Windows 2000 ProfessionalというクライアントPC向けOSといえども、アプリケーションをほとんど稼働させない状態ではそうそう落ちたりはしない。その点でも、アプリケーション実行マシンとストレージを分離するのは有効なのではないだろうか。

ファイル共有でバックアップが容易に

　データの所在を一元化することで、バックアップの手間が大幅に減少しているのもメリットだ。筆者の場合、個々のPCのバックアップというのはまず行わない。もともとなくなっては困るデータはローカルには存在しないので、バックアップする必要もないというわけだ。クラッシュしたら基本的にはゼロから再インストールである。OSとアプリケーションを一から再インストールして環境を構築していくのは手間のかかる作業だが、それほど難しくはない。むしろテスト用途などでインストールしたアプリケーションの残骸などがきれいになくなるという効果もあるほどだ。

　反面、共有フォルダは極めて重要であり、これがクラッシュして完全に失われる、といった事態が生じた場合にはほとんど回復不能の重大なダメージを受けることになる。とはいえ、実のところここにあるのは基本的にはデータ・ファイルばかりであり、きちんとバックアップが存在してさえいれば復旧は容易なのだ。逆にいえば、共有フォルダをきちんとバックアップすることが重要になってくる。

　筆者の場合、あまりマメに整理を行う性格でもないため、この共有フォルダのサイズは現在6Gbytesを超えている。この量のデータをバックアップするのに適当なメディアが見あたらないという事情から、バックアップはときどき別のPCのハードディスクに丸ごとコピーする、という方法で行っている。差分バックアップといった技法を駆使すれば毎日バックアップを更新することも可能なはずだが、現状では毎回丸ごとコピーしているため、あまり頻繁に行っているわけではない。この点は筆者の環境における最大のリスク要因であり、改善の余地が多いのだが、いまだに「検討中」という状況から脱していない。一応言い訳をするなら、ファイル・サーバのOSをWindows 2000 ProfessionalからUNIX系OS＋Sambaに移行しようと考えているから、ということが挙げられる。そのため、現状の環境にあまり大がかりな改変を行う気になれないのだが、一方でUNIX系OSへの移行も1年ほどほったらかしになったままだ。

　最後に、共有フォルダにどのようなファイルが置かれているかを大まかに整理しておこう。まず、原稿や画像、音声といった筆者自身が作成したデータ・ファイルがある。これは、主として分散やバージョン競合を避ける目的で一元管理している。次に、デバイス・ドライバやオンラインで入手した各種プログラム・ファイルなどがある。これらは、さまざまなPCから参照するため、どのPCからもアクセスできる場所に置いておく、という理由で共有フォルダに集めてある。最後に、電子メールのフォルダがある。電子メールも記録として保存しておく必要性が高い重要なデータだが、更新頻度が極めて高く、かつマシンをまたがる共有もあまり容易ではないという面倒な要素がいくつかある。筆者は電子メールに関しても複数のマシンで同様に利用できるように環境を作っているが、その根本にあるのがファイル共有サービスということになる。ということで、次回は電子メール環境について紹介する。

INDEX
	ワークグループ・ネットワークにおけるファイル・サーバ運用術（1）
	ワークグループ・ネットワークにおけるファイル・サーバ運用術（2）

「連載：究極ホーム・ネットワークへの道」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）