IBM developerWorks: Wikis - FastBack Japan Wiki

TSM FastBackは魅力的な機能をたくさん備えていますが、「できないこと」「向いていないこと」も勿論存在します。「思っていたことができなかった」ではお客様にご迷惑をかけてしまいますので、そのあたりを率直にご紹介します。（因みに、筆者は「なんでもできます」という「万能ナイフ」を目指していないところがかえって良いと考えています）

FastBackではできないこと

フォルダー、ディレクトリー、ファイルなどの細かい単位でのバックアップの指定

FastBackのバックアップの指定はディスクのボリューム（要はc:ドライブとかd:ドライブとかのことです）単位に指定します。
あるドライブ中の特定のディレクトリー、ファイル、といった細かい単位でバックアップする指定はできません。
上記は「バックアップ」の際の指定の話です。 リストアする時は、FastBack MountのGUIツールを使えばディレクトリー、ファイルなどの細かい単位での戻しが可能です。 また、FastBack for MS Exchangeを使えばExchangeのオブジェクト単位の戻しが可能です。

テープへのバックアップの書き出し

FastBackはテープへのバックアップの書き出しはできません。
TSM等の他のバックアップ・ソフトと連携することで可能になります。

本部・センターからWAN経由での支店・店舗サーバーの直接的なバックアップ

FastBackでは本部・センターから支店・店舗のWAN経由で直接的にバックアップを採取する構成はサポートされていません。(技術的にはFastBackはTCP/IPのアプリケーションなので品質の良いネットワーク環境であれば稼動しますが、WAN環境に特有のネットワーク遅延に伴うリトライやパケットのロスなどへの対応まではできていないので正式サポートとはしていないと聞いています）
支店・店舗サーバーの運用管理の面では本部・センターから一元管理・設定ができますので運用負荷を軽減できます。
支店・店舗にあるFastBackサーバーのリポジトリー・データを自動的に本部・センター側のDRサーバーに転送することは可能ですし、サポートもされています。
この形態はサポートされています。支店・店舗から管理可能です。
この形態はサポートされていません。

FastBackのリポジトリー制御情報のバックアップをFastBack自身で採取すること

FastBackのバックアップはDisk to Disk to Diskの方式で別のFastBackにて行ってください。
　自分自身をバックアップすることはできません。

CDPで取ったバックアップからのファイルやディレクトリー単位のリストア

CDPで採取したバックアップをリストアする時は(時刻指定での)ボリューム単位のリストアとなります。(リストアする先は元のドライブでなくても可です。)
CDPで採取したバックアップをFastBack Mountで仮想的にマウントして、特定のファイルやディレクトリーのみをコピーバックして回復する、ようなことはできません。

RAID-5、ミラーリング、ストライピング指定された「ダイナミック・ディスク」へのCDPの適用

ダイナミック・ディスクでRAID-5、ミラーリング、ストライピングなどを使用している場合には当該ボリュームへのCDP適用はサポートされていません。(V5.5.1レベルでは）

補足ですが、一般的な「ベーシック・ディスク」を利用の場合はRAID-5、ミラーリング、ストライピングなどを利用してもCDPを適用できます。また、ダイナミック・ディスクでRAID-5、ミラーリング、ストライピングなどを使用している場合でもCDPができないだけで、通常のバックアップは可能です。

Useful Information
ダイナミック・ディスクとは、WINDOWS2000から新たに追加されたディスク管理方式で、後からパーティション・サイズが変更できたりします。これに対比して従来のものは「ベーシック・ディスク」と呼びます。通常は「ベーシック・ディスク」をお使いかと思うので、その場合には上記制限はあてまりません。ダイナミック・ディスクについて詳しくはネットを検索してください。

2009/1/09追加

5.5.2～のダイナミック・ディスクのサポート

Fastback 5.5.2からWindowsのダイナミック・ディスクのサポートが追加されました。
ダイナミック・ディスクには下記のような種類があり、従来はsimple Dynamicのみがサポートされていましたが、
5.5.2からはいずれもオーケーです。

Simple volumes
Spanned volumes
Mirrored volumes
Striped volumes
RAID-5 volumes

ただし、一部の種類ではスナップショット中の更新が多すぎるとジョブが失敗する、戻すときにはいったんベーシック・ディスクとしてリストアしてからダイナミック・ディスクに手で変換する必要がある、などの考慮点があります。今はダイナミック・ディスク自体それほど使われていないと思いますが、もしFastbackと共にご利用の際は下記のInformation Centerの記述をじっくりご確認ください。

Fastback 5.5 Information Center - Dynamic Disk Support

なお、前述のダイナミック・ディスクにはCDPを適用できない、という制限は5.5.2でも変わっておりません。

ディスクのレプリケーションや高可用性の提供(ミッション・クリティカル領域）

2009/5/26

エンタープライズ系の製品ではビジネス保護のためにディスクのレプリケーションとサーバー二重化を
　組み合わせて１－２分で切り替えて最新のデータで業務を継続する、という分野の製品があります。
FastBackはあくまでバックアップ・ソフトなので、必ず「リストア」が発生します。
「直前までのデータは一切失わず、切り替えて１分以内にすぐ復旧せよ！」のような高いRPO(Recovery Point Objective)やRTO(Recovery Time Objective)が求められる業務には向いていないと思います。

もちろんFastbackは以下のような利点を持っていますが、前述のような構成を代替するものではありません。
ご要件やご予算に合わせてご検討いただければと思います。
- インスタント・リストアやFastbackマウントのようなユニークなリカバリー機能があるので数分で業務が復旧することも可能
- サーバー等の機器の２重化投資が不要
- とにかく価格的に安い（１０万前後ではじめられます。前記のようなシステムは普通、数百万はしますから。。）

（たとえばファイル・サーバーなら、「そこまで厳しい要件ではないよ、それよりコストを抑えて構築してよ」ということもありますでしょう？）

FastBackには向いていないこと

向き・不向きは筆者の個人的な所見・意見として見ていただければと思います。

ディスクのデータ・ブロックのレベルでの更新が非常に多い処理

FastBackはディスクのデータ・ブロック単位での増分をバックアップします。
以下のような処理は本来のデータ変更が無いにもかかわらず、ディスクのデータ・ブロックとしては大量の変更と見做されます。結果、バックアップ量が増えたり時間がかかったりしますので、ご注意ください。（もちろん量や頻度によります）
- ディスクのデフラグ
- OSのスワップ・ファイルや（サーバーなので無いとは思いますが）ハイバネーション・ファイル→別のボリュームに移す
- データベースの再編成

大容量のストレージを扱い、定期的なリブートを伴うシステム

4/30
サーバーをリブートすると、Fastbackがメモリ上で記憶していたディスク上の変更ブロックのデータが失われます。
結果、次回のスナップショット時は前回スナップショットから変更されたブロックを特定するために
対象ディスクを全なめします。（これをデルタ・スナップショットと呼びます。(詳しくはこちらを。)

つまり、通常時はディスクのブロック増分だけをとるのでバックアップ時間が非常に短くて済むのですが、
リブート直後のバックアップ処理では非常に時間がかかる可能性があります。
特に、大容量のファイルを扱うシステムではこのスキャンが長時間になることも考えられます。（容量によります）
別に時間がかかってもかまわないシステムもあるでしょうし、月曜朝ではなく金曜の夜にリブートする、など運用で回避できる場合もあるでしょう。しかし、場合によっては本番業務中にIOが大量に出るのが困るシステムもあると思います。現時点ではこの動きを回避する手段はありませんので、そういう場合は、向いていないように思います。

クライアントのバックアップ