DRリポジトリーについていくつかご質問を頂いたので、まとめてみました。
DRリポジトリーの構造
DRリポジトリーは例えば、以下のような構造です。
 |
- オレンジで囲んだR:\RepはFTPユーザー(下記例ではfastbackというユーザー)のRootDirであり、
C:\Program Files\Tivoli\TSM\FastBack\drhub\FastBackDRHubServer.iniで
[General]
ListenPath1 = R:\Rep
FTPRootPath1 = R:\Rep
と定義しています。(ルートのR:\でも何でもかまいません。)
- 緑色で囲んだREP_TokyoはFastBackマネージャのDRタブで定義した名前の前にREP_が付いたものであり、英数字である必要があります。
もし別のFastBackサーバー(例えばOsaka)からも同一ユーザーIDでDRする場合はE:\Repの下にREP_Osakaが作られることになります。
- REPOSITORYの下にディスクとしてDISK_E@0X09D6EC80がありますが、この下にデータが転送されています。
(ちなみに名前的には DISK_元のドライブ名@元のディスクのシグニチャーになるようです。
このケースではリポジトリのディスクは1つですが、複数ある場合はもうひとつDISK_X@0X????????ができます。)
|

スナップショット部分のデータ自体は通常のFastBackリポジトリーと殆ど同じですが、 以下のような違いがあります。
- 1リポジトリーで複数店舗をサポートするためにディテクトリー階層が深くなっている。
- ディレクトリー名にブランチ名が含まれる
- Locations.iniやFXSignature.txtなど一部のファイルが存在しない
(
DRリポジトリーにはLocation.iniがナイ!ということはDRリポジトリーのファイル群を元のリポジトリにコピーしても
「リポジトリーの要求」はできない=DRリポジトリは元のリポジトリーの復旧には使えない、ということです)

戻る
複数ブランチ、複数ディスクの場合の構成
上記はシンプルな1ブランチ、1ディスクの場合でした。
では複数のブランチ、複数のディスクをDRする場合はどのように考えたらよいでしょうか?
例として、2ブランチ(Tokyo/Osaka)で各々のリポジトリが2ドライブになる場合を考えてみましょう。

大きくは下記のようにa) FTPRootは同じにするパターン b) FTPRootを分離するパターン があると思います。
( b)分離パターンは下記の例ではドライブから分離しましたが、X:\REP1, X:\REP2でもいいと思います)

実はこの検討には正解は、ありません。
が以下のような点を考慮してディレクトリー構造を決める必要があると思われます。
DRサイト側では必ず元のリポジトリーのドライブ毎に、対応するディレクトリー(DISK_X@0X????????)が作られます。
元のリポジトリーの複数のドライブをDRサイト側で1つのディレクトリーにまとめる、などの工夫の余地がありません。
元のリポジトリーではFastBackマネージャーを使用して簡単に複数ドライブからなるリポジトリーを構成できます。
DRサイトではそのようなツールがありませんので、2TB超えの大容量の場合には後述するような検討が必要になります。
| no |
考慮の観点 |
コメント |
| 1 |
ディスクの最大容量 |
もしDRの各ドライブがベーシック・ディスクの場合は最大でも2TBです
パターンa)の場合は不足する可能性があります。 |
| 2 |
ファイル転送の帯域制御 |
ROOTdir(=FTPユーザー)を別にしたほうがやりやすいでしょう。
そういう意味ではパターン b)が有利です。 |
| 3 |
ドライブの文字 |
パターン b)でドライブで分離した場合はブランチ数が多い場合に
ドライブ文字が枯渇する可能性があります。 |
戻る
2TB超えのDRリポジトリーの作成方法
前述のように、ベーシックディスク上のドライブ1つでは最大2TBまでしか確保できません。
DRリポジトリーでこの制限を越えるにはどうしたらよいでしょうか?
1) Windowsの提供する機能としてのダイナミック・ディスクやGPTの機能を使う。
11/16 
当記事をアップした時点(2009/09/29)ではDR側のリポジトリーのファイルシステムとしてダイナミックディスクやGPTをサポートするかどうか(2TB超え)、を「現在確認中です」としましたが、2009/11時点で 確認が取れました。
多分、これが一番簡単な方法です。下記のWeb記事が参考になります。
大規模な論理装置のサポートと Windows Server 2003 SP1
第 1 章 - 記憶域の計画
↓↓↓↓DR側のリポジトリーのファイルシステムとしてダイナミックディスクやGPTをサポートしていますので下記のジャンクション機能は「ご参考」ということで。↓↓↓↓
2)ベーシック・ディスクでも「超大規模」でなければWindowsのジャンクション機能が利用できます。
ジャンクションとはUnix/LinuxでのNFSのようなもので、ディレクトリーの一部を他のディスク上に連結するようなイメージの機能です。
ジャンクション機能については下記のWeb記事が参考になります。
@IT-ジャンクション機能を使ってディスク・ボリュームをマウントする
@IT-ジャンクション機能を使ってフォルダをマウントする
)
以下、サンプル的にWindos2003上での手順をお示しします。
(本当は実際に2TB超えのパターンでテストしたかったのですが、VMWare環境で2TBのディスクをいくつも
用意できませんでしたので小規模な環境でDRリポジトリーに対するジャンクション機能を
確認する結果となっています。今回は上記の「フォルダをマウントする」パターンで行いました。)
【環境】
下記のようなフォルダー構造の場合で、G:\ドライブの最大は2TBです。
もっと大きい容量にしたいので、赤で囲んだ2つめのドライブ(DISK_F@0X0B9052D9)を別のドライブに割り当てます。

【手順】
1) まずはオリジナルのリポジトリと整合性の取れた正しいディレクトリー構造を構築するために
DRのレプリケーションを行います。ディレクトリ構造が作れたらキャンセルします。 (勿論、手でディレクトリーを作成してもかまいません)
2) DISK_F@0X0B9052D9の下のディレクトリーは不要なので削除します。

3) Windows2003のリソースキットをここからダウンロード
し、導入します。私は@ITのこの記事
を参考にしました。
4) linkdコマンドを実行します。( linkd △リンク元△リンク先 )
下記の例ではG:\Rep\REP_Tokyo\REPOSITORY\DISK_F@0X0B9052D9をH:\ドライブのルートに結び付けています。
G:\Rep\REP_Tokyo\REPOSITORY\DISK_F@0X0B9052D9>linkd G:\Rep\REP_Tokyo\REPOSITORY\DISK_F@0X0B9052D9 H: Link created at: G:\Rep\REP_Tokyo\REPOSITORY\DISK_F@0X0B9052D9 G:\Rep\REP_Tokyo\REPOSITORY\DISK_F@0X0B9052D9>CD ..
G:\Rep\REP_Tokyo\REPOSITORY>DIR
ドライブ G のボリューム ラベルは ボリューム です
ボリューム シリアル番号は CC39-7CB0 です
G:\Rep\REP_Tokyo\REPOSITORY のディレクトリ
2009/09/17 18:21 <DIR> .
2009/09/17 18:21 <DIR> ..
2009/09/17 18:54 <DIR> DISK_E@0X09D6EC80
2009/09/18 23:19 <JUNCTION> DISK_F@0X0B9052D9
0 個のファイル 0 バイト
4 個のディレクトリ 1,491,783,680 バイトの空き領域
G:\Rep\REP_Tokyo\REPOSITORY> |
5) エクスプローラーで見ると、確かにH:\の下がDISK_F@0X0B9052D9に見えています。

6) あとは通常のレプリケーションを行います。
戻る