ネットワークファイルプロトコルの問題を解決する「P5クライアントプロトコル」

P5の「Backup」モジュール(P5 Backup)およびアーカイブモジュール(P5 Archive)はネットワークプロトコル経由でマウントされているボリュームに対して実行しないようにしてください。対策として、P5クライアントをボリュームを読み書きできるホストにインストールすることで、Archiware独自の「P5クライアントプロトコル」での通信ができるようにしておく必要があります。

本稿ではその理由を詳解します。

AFP(Apple ファイリングプロトコル)は、ACLやメタデータ等、重要なファイル属性への対応が不完全であるため、完全にサポートされていません。このような制約下でP5によるファイル転送をAFP経由で行った場合、各種属性が失われてしまいます。

代わりにNFSやSMBを使ってMacのファイルを転送した場合、MacのデータフォークやMacのみの補助情報(リソースフォークやファインダー情報等)は、物理的に2つの別々のファイルに分けられて保存されてしまいます。(Apple Double フォーマット)現在では、万一ファイルがP5により保存、リストア、コピーされた場合、1組になっている2つのファイルが関連性を失う場合に備えてファイルは常に2つの別個のファイルとして保存されます。
また、旧バージョンv3からはすべての非HFS(およびHFS+)ボリュームに対し、AppleDoubleフォーマットで操作されるべきものとみなし、自動的にAppleDouble変換を自動実行するように改善しています。

● ネットワークファイルプロトコル :

例:
あるホスト(A)側のボリュームが、ネットワーク経由で別のホスト(B)にマウントされている状態で、両者の接続に支障が出た場合、ホスト(B)にマウントされているボリュームにはアクセスできなくなります。
このような場合には、対象のボリュームにアクセスするP5を含むすべてのアプリケーションは、システムコールがハングし、ひいてはコーリングプロセスの停止を引き起こすことがあります。

また、AFPプロトコルは、通常のマウント方式で行われるアクセス権限を正常に発行できない場合が頻繁に発生します。P5サーバーはルートプロセスで動作し、さらに通常のマウントオプションを持つネットワークボリュームはguestアカウントにマップされます。その結果、P5がデータを保存したりリストアするのには不適切なアクセス権しか得られない事態となってしまします。

こうしたネットワークプロトコルに由来する諸問題への対策として、Archiware P5は独自開発の「P5クライアントプロトコル」(PresSTOREクライアントプロトコル)を実装しています。「P5クライアントプロトコル」は、すべてのファイルアクセス権限を正しく発行できるので、何らかの原因でネットワーク接続が失われるなどの障害が発生した場合でも、クライアントはその時点で保存され、取りこぼされたデータも次回のジョブ再実行時に処理される仕組みとなっています。

※ユーザーによる質問
Q : Avid ISISやQuantum StorNextファイルシステムなどのトンネリング方式のプロトコルによってマウントされていた場合はどうなりますか?
これらの方式では等通常のAFP/NFS/SMBプロトコルを使わないため、通常のTCP/IPプロトコルに関連した問題を回避しています。

回答 :
P5からはOSが持つ通常の手段でマウントされていなければなりません。
ボリュームをマウントするための特殊なクライアントソフトウェアが必要である場合、P5サーバーまたはP5クライアントからは正しく参照できないことがほとんどです。
バックアップやアーカイブ、シンクロナイズの対象としてAFPやSFB、NFS等でマウントされたボリュームを指定するのは適当ではありません。iSCSIで経由でリモートのボリュームをマウントして運用することをおすすめします。他の推奨手段としては、サーバーにローカル接続でマウントするか、P5ソフトウェアを対象のサーバーにインストールし、そのサーバーをP5クライアントとして設定することです。