リポジトリーの独自バックアップって意味があるのでしょうか?

FastBackのリポジトリーは極論すればNTFS上の単純なファイル群にすぎません。
なので何らかの方法(※1)で別の媒体にバックアップしておけばリポジトリーが失われた時等に使えそうな気がします。
とはいえFastBackのリポジトリーのLocations.iniにはディスクのシグニチャー情報なども持っているようですし、
そのまま別のディスクにコピーして使えるのかどうか、ちょっと確信がもてません。
で、どうなのか？(コピっておけば後で何らかの方法で使えるのか？)を実験してみましたので、結果をご報告します。

※1...XCOPYなりエクスプローラでの手動コピーなり、TSMやAxxServeなり。。

以下の結果は正式なリポジトリーのリカバリー手段をガイドするものではありません。(InfoCenterに書いてません!)
ですのでお試しになる場合は自己責任でお願いします。そういう意味で「実験」と言っています。

今回の実験はフォルダー型のリポジトリーを使用しています　2009-10-01追記 FastBackのリポジトリーを初めに定義するときは　①ディスク②フォルダーの２種類の定義の仕方があります。 (①ディスク型②フォルダー型って何のこと？という方はこちらの記事をご参照ください。) 当記事はフォルダー型を前提に実験を行いました。 その後の調査によると①ディスク型の場合には、他にもややこしい考慮点があるようなので、 別途調査を進めてからご報告します。 フォルダーとして定義されたリポジトリーであることを前提に以下を読んで頂けますと有難く存じます。

イメージバックアップ系の製品にご注意を！　2009-09-29追記 そういえば、ある方から伺ったトラブル話を思い出したので追記します。 どの製品とは申しませんが、イメージ・バックアップ系のソフトには、ディスクのシグニチャーを元のディスクの値で上書きする仕様のものがあります。 以前こちらに記載しましたが、FastBackは導入時点でディスクの情報を自身のレジストリーに記憶しており、 導入後、新規ディスクへの書き込みを原則禁止します。(DiskOpenで解除) FastBackサーバーに対してイメージ・バックアップ系のソフトでディスクをリストアすると、ディスクのシグニチャーが変更されます。 当該バックアップソフトはOSのレベルでは辻褄を合わせてくれますが、当然ながらFastBackの保持するレジストリー情報までメンテしてくれません。 ゆえにリストア後のディスクはFastBackの認識していないディスク＝新規のディスクとなりDiskOpenしないと書き込みができなくなります。 (更にこの方の場合はリストアしたドライブがレジストリーが存在するC:\だったために、DiskOpenしてもレジストリーが更新できず、 エライ目にあったとのことでした。) 上記のようなこともありますので、トラブル予防の観点で、当記事にある「コピー」を行う場合はTSM/ARCServe/BackupExecなどの (ディスクのシグニチャーを書き換えない)ファイル・レベルでのバックアップ・ソフトのご利用をお勧めさせていただきます。

「細かい話はイラン。結果だけ知りたい！」という方のために

まずは結論だけ示します。

リポジトリーの(ユーザーによる）独自コピーがあれば、後で色々と使い道がありそうです。(コピーは、使える) 　FOLDER型で定義されたリポジトリーの場合、 FastBackサーバーやリポジトリーが破損したときには、FastBack再導入&「リポジトリーの要求」で状態を復元できる。 但し、Locations.iniと辻褄を合わせるためにオリジナルのドライブと同じドライブ名の場所にコピーすること。 FastBackマウントやBMRでは、コピーをリストアしたものに直接アクセス可能。ゆえに業務データの回復ができる。 Locations.iniと辻褄を合わせは不要。異なるドライブ名にコピーしてもアクセスできる。

実験環境

実験内容と結果

1. FastBackサーバーのリポジトリーを別サーバー上で復元するシナリオ(ＦＢサーバー自身の復元)

no	シナリオ	結果	コメント
1	元のドライブ名と同じドライブ名に戻した場合 (1) FB2上のE:\とF:\をFB1上のE:\とF:\に手でコピー (2) FB1上にFBサーバーを新規導入 (3)「リポジトリーの要求」操作	「リポジトリーの要求」は成功	メッセージやログはこちら
2	元のドライブ名と異なるドライブ名に戻した場合 (1) FB2上のE:\とF:\をFB1上のO:\とP:\に手でコピー (2) FB1上にFBサーバーを新規導入 (3)「リポジトリーの要求」操作	「リポジトリーの要求」は失敗	Locations.ini内のドライブの記述と不一致のため メッセージやログはこちら
3	コピー先でLocations.iniを直接編集して辻褄を合わせた場合 (1) FB2上のE:\とF:\をFB1上のO:\とP:\に手でコピー (2) FB1上のLocations.iniの中身をO:\とP:\に書き換え (3) FB1上にFBサーバーを新規導入 (4)「リポジトリーの要求」操作	「リポジトリーの要求」は失敗	エディターによるLocations.iniの書き換えで ファイルのシグニチャーと不一致のため メッセージやログはこちら

• 「リポジトリーの要求」って何？という方はこちらへ。
• Locations.iniの中身の例はこちらへ。

【Lessons Learned】

• 異なるディスクから丸ごとコピーしたリポジトリーは、オリジナルのドライブ文字と同じドライブにリストアすれば 「リポジトリーの要求」は成功し、
  正しいリポジトリーとして認識させることができます。
  現在リポジトリの存在するディスクの物理的なディスクのシグニチャーとlocations.iniの中のシグニチャーが異なっていても、問題はないようです。
• 複数ディスクから成るリポジトリの場合は、各々、オリジナルと同じドライブ文字の場所に置く必要があります。
• 複数ディスクから成るリポジトリの場合、「リポジトリーの要求」ではどれか一つのLocations.iniを指定すれば、残りは自動的に登録されます。
  個別に何度も同じ操作をする必要はありません。
• 「リポジトリーの要求」が失敗した場合の問題判別には 以下の場所のログ(*.sf)が有用です。
  C:\Documents and Settings\All Users\Application Data\Tivoli\TSM\FastBack\server\FAST_BACK_SERVERxxx.sf

2. コピーしたリポジトリーをFastBackマウントやBMRで使用するシナリオ(データの復元)

no	シナリオ	結果
1	元のドライブ名と同じドライブ名に戻した場合 (1) FB2上のE:\とF:\をFB1上のE:\とF:\に手でコピー (2) E:\とF:\に対してWindows共用別名(FB_REP_OF_X等)を定義 (3) FB2上でFastBackマウントによる参照 (4) FB3上でBMRによる参照	FastBackマウント&BMRとも利用できた
2	元のドライブ名と異なるドライブ名に戻した場合 (1) FB2上のE:\とF:\をFB1上のO:\とP:\に手でコピー (2) O:\とP:\に対してWindows共用別名(FB_REP_OF_X等)を定義 (3) FB2上でFastBackマウントによる参照 (4) FB3上でBMRによる参照	FastBackマウント&BMRとも利用できた

【Lessons Learned】

• FastBackマウントとBMRについてはLocations.iniを意識する必要はないようです。
  　基本的にWindows共用などを使って何らかの形でアクセスできればよい、ということでしょう。
• 実は、災害対策(DR)機能で作成したDRサイト側のリポジトリーにはLocations.iniはありません。
  　でもFastBackマウントやBMRでは直接、データの回復を行うことができます。
  　このことからもLocations.iniを意識する必要はない、ということが言えそうです。

実験結果のログとコメント

「リポジトリーの要求」って？

導入直後のFastBack Serverに新規の（今回は別の場所からコピーした）リポジトリーを認識させるための操作です。
FastBackマネージャー上で下記のように「リポジトリーの要求」を行います。
ちなみに、再導入せずにFastBackの状態を初期化するには下記のディレクトリーを削除すればよいです。
(但しFastBacl/clientディレクトリは残すか、コピーバック。でないと定義ファイルがないので起動しなくなる)
C:\Documents and Settings\All Users\Application Data\Tivoli\TSM\FastBack

この画面は「キャンセル」でスキップして

こちらから「リポジトリーの要求」を行い、locations.iniを指定します。

戻る

Locations.iniって?

FastBackのリポジトリーの直下にあるLocations.iniの中には自分のドライブ名、共用名、IPアドレス、
物理的なディスクのシグニチャー、(複数ディスクから成るリポジトリの場合) グループとなる
リポジトリーの情報、など様々な物理的な情報をテキスト形式で保持しています。
たとえば、こんな感じです。

戻る

1-(1)　同一ドライブ名で「リポジトリーの要求」成功

REP_DISPATCHER_S_ClaimRepository: Claim Started
WinUtils_S_GetUNCPathIfExists: look for UNC path for e:\.
WinUtils_S_GetUNCPathIfExists: look for UNC path for f:\.
REP_DISPATCHER_S_ClaimRepository: Copy C:/Documents and Settings/All Users/Application Data/Tivoli/TSM/FastBack/server/Locations.ini to C:/Documents and Settings/All Users/Application Data/Tivoli/..
..TSM/FastBack/server/Mirror/Locations.ini
REP_DISPATCHER_S_ClaimRepository: Copy C:/Documents and Settings/All Users/Application Data/Tivoli/TSM/FastBack/server/Locations.ini.sig to C:/Documents and Settings/All Users/Application Data/Tiv..
..oli/TSM/FastBack/server/Mirror/Locations.ini.sig
REP_DISPATCHER_S_ClaimRepository: Start spread New Locations.ini file
REP_DISPATCHER_S_ClaimRepository: Copy C:/Documents and Settings/All Users/Application Data/Tivoli/TSM/FastBack/server/Locations.ini to e:\Locations.ini
REP_DISPATCHER_S_ClaimRepository: Copy C:/Documents and Settings/All Users/Application Data/Tivoli/TSM/FastBack/server/Locations.ini.sig to e:\Locations.ini.sig
REP_DISPATCHER_S_ClaimRepository: Copy C:/Documents and Settings/All Users/Application Data/Tivoli/TSM/FastBack/server/Locations.ini to f:\Locations.ini
REP_DISPATCHER_S_ClaimRepository: Copy C:/Documents and Settings/All Users/Application Data/Tivoli/TSM/FastBack/server/Locations.ini.sig to f:\Locations.ini.sig
REP_DISPATCHER_S_ClaimRepository: Claim finished (status = OK)

「リポジトリーの要求」が成功すると、Locations.iniの内容は当該サーバーの環境に合わせて書き換えられます。
以下は「リポジトリーの要求」の実施前後のLocations.iniの内容を一部比較してみたものです。

戻る

1-(2)　異なるドライブ名で「リポジトリーの要求」失敗

オリジナルのドライブ文字と異なるドライブにリストアした場合は「リポジトリーの要求」は下記のメッセージで失敗します。

当実験ではコピー先のドライブをO:\にしたのですがログを見るとE:\の上にFXSignature.txtが無いよ、と言っています。
確かに、O:\上のLications.iniの中では自分はE:\だ、と書いてあるので辻褄が合っていません。

CHAIN_MGR_S_CheckSanityStatusAfterReset: Sanity status is [2], waiting for change is status
CONF_S_OpenFile: Can't open file [e:\FXSignature.txt] for [32770]. Retry failed
REP_MGR_S_ClaimRepository: Claim is denied since the following repository object "e:\" .Can't find FXSignature.txt in repository on folder.
REP_MGR_S_ClaimRepository: Claim is denied since the following repository object "e:\" .Can't find FXSignature.txt in repository on folder
CHAIN_MGR_S_CheckSanityStatusAfterReset: Sanity status is [2], waiting for change is status

ちなみに始めにオリジナルと異なるドライブ文字のドライブにコピーしても、「コンピュータの管理」－「ディスクの管理」で
ドライブ文字をオリジナルと同じに変更してから「リポジトリーの要求」をすれば、同様に正しく認識されます。
(あたりまえですが)

戻る

1-(3)　異なるドライブ名でLocations.iniの直接編集後に「リポジトリーの要求」失敗

1-(2)ではLocations.iniの実際の場所と中の記述が不一致だったので失敗したわけです。
じゃ、Locations.iniを書き換えて辻褄を合わせたらどうか、ということなのですが、やはり下記のエラーで失敗します。

エディターを使って手で書き換えたのが良くないようで、ログを見ると「ファイルのシグニチャーが違う」と言ってます。

REP_DISPATCHER_S_ClaimRepository: Sorry, new Locations.ini file is not signatured. ClaimRepository process FAILED.

下記のようにFastBackのリポジトリーのファイル群は各々シグニチャーファイル(*.sig)をペアで持っており、
外部からの変更を検出できるようになってます。ちゃんとチェックしてるんですね。

戻る

実際に計画するときの注意点など

リポジトリーのコピーがなぜ必要なのでしょうか?

目的は大きく２つあると思われます。
1) (データのアーカイブ的な目的で)ある時点のバックアップ自体を別の媒体に持っておきたい
2) FastBackサーバー自体を破壊から保護したい（壊れたら、どうする)

1)の場合は、確かに何らかの方法で別の媒体にコピーするのも一理ありますね。
FastBackでは指定した世代を超えた部分はどんどん自動削除＆自動メンテされていってしまいますから。。。
ただ、その場合でもリポジトリー全体のコピーの頻度は、月次などで行い、間違っても毎日などにはしないほうがよいように思います。
リポジトリーは容量が大きいのでバックアップにえらく時間がかかりますし、さらに毎日のコピー用に別のバックアップソフトを入れてテープに保管して、
なんて始めたらコストも上がりますし余計な運用の手間も発生してしまいます。
せっかくFastBackで日々のバックアップを軽量化・短時間化したのに、その利点が失われてしまう、本末転倒、のように思うのです。
（まあ、リカバリー機能の利点は残りますが）

2) の場合、まず 正式にはリポジトリ自体を保護したい場合はDR(Disaster Recovery)機能のご利用がお勧め 、となっています。
が、必ずしもすべてのお客様がリモートの災害対策サイトへのデータ退避をご希望されるとも限りませんよね..でコピーの話が出てくるわけです。
OSやプログラムは再導入すればよいとして、リポジトリー・ディスクの破壊に備えるためには、まずはディスクのRAID機能を利用するのが第一であって、
それに補助的に今回のようなコピーを組み合わせるべきかと思います。
また、変な主張かもしれませんが、万が一FastBackサーバーが失われたとしても本番の業務には支障を与えません。
保護対象のサーバーが生きているなら、またバックアップを取ればよいではないか、という考え方もあると思います。
「完全な復旧対策」を目指して、却ってコストや日々の運用の手間が増えてしまっては、つまりません。
要はご要件に照らしての「コストと効果のバランス」かと思われます。

Locations.iniはデフォルトでは隠しファイルになっています

エクスプローラーでコピーする場合は表示されませんので、
「保護されたオペレーティング･システムファイルを表示しない」のチェックボックスを解除して
コピー漏れがないようにしましょう。

DiskOpenを忘れずに

5.5.4～ Read-Only属性をRead-Writeに一括変更するオプションが 2009/11/10追記 SAN環境でない場合、FastBack5.5.4で追加された-DisableSANProtection オプションを使用すれば 当記事に書かれている課題をよりスマートに解決できるようになっています。 DiskOpenに書き込みを許可するオプションが！(5.5.4～)も併せてご参照ください。 当記事は技術面で有用な情報を含むと思うので、そのまま残します。

移行の目的など、リポジトリーを新しい外部USBディスクなどに一時的にコピーする場合は、
「コピーしたつもりがされてなかった！」みたいな悲劇が起こらぬよう、DiskOpenを忘れずに行いましょう。
詳しくはこちら

可能ならFastBackのサービス停止も

コピーする前にFastBackのサービスは停止しておいたほうがよいでしょう。
例えばコピーを実施している最中にクリーンアップ処理やスナップショットが動いたりすると
リポジトリーの内容が仕掛かり状態でコピーすることになり、あとで利用するときに
使えなくなってしまう可能性が考えられるので。