バックアップ系の新商品がリリースできそうな形になってきたので、裏話を書きます。

もともとは、うちの会社のファイルサーバの体制不備が開発の発端です。
基本的に、担当者のPC内部に重要な情報が記録されるとき、ファイルサーバにも置くように徹底することで、PCがコケてもデータは残るというだけのファイルサーバだったのですが、これがイケてません。
ファイルサーバ自身のバックアップがないのは、貧乏な我が社でもあんまりの体制です。

退職者が出て、PCを初期化したりすると、データが2箇所に保存されていなくなってしまうし、そもそもどこにあるのかがわかりにくい。
で、退職者の扱ったデータの所在がわかりにくいのを解決するために生まれたのが、アイデクサーだったわけです。

ということで、今度の新商品は、ファイルサーバの丸ごとバックアップを以下に容易にするかという観点で作られました。ついでに、共有フォルダであれば、一般PCでもバックアップできちゃうようにと..
要は、我が社自身が便利に使いたいのが発端な訳ですね（汗）

さて、我が社では、開発・サポートを主業務とする関係上、グラフィック・音声・映像データなどの膨大な容量をファイルサーバに置くわけではありません。
このご時世のSATA-HDDは、1発で2TBもあるわけですから、なんとなれば、そこに全部収まるわけで、特段の開発をせずとも、バックアップそのものは出来ます。

しかし今後、ある程度の容量拡張が可能で、バックアップされた中身を容易に検索できるのであれば、それに超したことはありません。

そこで今回は、以下のようなものを開発したのです。

・Windowsファイル共有でアクセス可能な場所なら、どこでも、何台でも連続的にバックアップできる。
・バックアップ元PCにエージェント等を入れないでもバックアップできる
・Windowsファイル共有が可能であれば、バックアップ元のOSは問わない
・Webユーザインターフェースで、バックアップ元の登録やバックアップ時刻設定が簡単にできる
・あとからディスクを追加すれば、LVMでどんどん容量追加してバックアップ先の内蔵ディスクを増やせる
　　※今は1発で最大2TBだけど、将来もっと大きなディスクが出てくれば、もっと大きなバックアップが出来る
・LVMを使ったディスク拡張を、ボタン一発で自動実行するインターフェース搭載
・アイデクサーのエンジンを流用し、バックアップ内の検索をかんたんにできる
・バックアップが行われるたびに、自動的に検索インデックスを再作成する
・検索は、アイデクサー同様、ファイル名・フォルダ名・全文検索対応
・検索時に、オフィス系を含むサムネイル表示・サムネイル拡大が出来る
・アイデクサー同様にEXIF検索やPDF検索も搭載
・基本的にモニタ／キーボード無しで運用できるだけのWebインターフェースの充実
・モニタ無し時の利便性の一環で、Beep音で状況に即したメロディーを流す
・バックアップの終了や使用容量の通知をメールで出す
・もちろん、エラー系の通知も日本語で詳しいメールが出る
・通知は、エラー・警告・一般通知のレベルに分けられ、それぞれ通知先アドレスを変えられる

….どうです。てんこ盛りでしょ（笑）

バックアップ元登録時に、そのバックアップ元をマウントする際に使うユーザ名／パスワードを個別登録するんですけど、登録実行ボタンを押すと、実際にマウント可能かどうかを調査してから登録を受け付ける仕組みになっています。

これを作っているときに思ったのですけど、Windowsファイル共有を対象にするなら、nmblookupでアクセス可能な全マシンをリストして、片っ端からアクセスし、ユーザ名をAdministrator固定で、パスワードの総当たりハックを仕掛け、当たったら勝手にバックアップ元に登録しちゃう仕組みにしたら、そこらのPCの共有部分をみーんな勝手にバックアップできるかも..（汗）..とも思ったのですが、犯罪っぽい臭いがするのでやめました(^^;;

本当はMacのAFPを同様に扱えると、さらに良いなぁ..って思いもあるんですけど、まだ、LinuxからAFPで共有ボリュームをマウントしたりクライアントアクセスしたりする手法の確実性が疑問です。

まぁ、mount -t cifs並に便利なmount -t afp の登場とか、smbclientのように使えるafpclientの出現とかは期待できそうにないけど、暇を見て以下を試してみるのも良いかな..とも思っています。

http://alexthepuffin.googlepages.com/home
http://sourceforge.net/projects/afpfs-ng/

FedoraCore8用みたいですが、おそらく、実際に使うときは、CIFSでバックアップした内容との混在を避けなければならないのは間違いなさそうだし、これを今度はafpdでnetatalkから公開したときに、Mac側でまともに見えるものになるのか..と言う点が最低限クリアされなければいけないと考えています。

混在を避けなければならない理由を細かく書けばきりがないのですけど、Macが、UTF-8の扱いを他と違えていることがもっとも気に入らない点ですね。
MacのUTF-8って、内部的には全角ひらがなの「が」を、「か」＋「゛を示すコード」で示し、DVDなんかみたいな外部のメディアの場合は「が」のままで許すとか、よくわからない仕組みになっているんですよ。

他の仕事で、Macが作ったファイルでは相当苦労させられているので、やるときは経験を踏まえてしっかり作らなきゃ行けないと思うし、Mac対応は仮に出来たとしてもずっと先かなぁ(^^;;