Backup Exec のカタログフォルダーが多量のディスク領域を使用する理由

問題

Backup Exec はカタログフォルダーにバックアップされた内容の記録を保持します。デフォルトのインストールでは、カタログフォルダは以下のパスになります。

 デフォルトパス：C:\Program Files\Veritas\Backup Exec\Catalogs　

時間の経過とともに、このフォルダーのコンテンツが大きくなり、ディスク領域を消費する可能性があります。この記事では、その原因のいくつかと、影響を軽減するために考えられるオプションについて説明します。

原因

カタログフォルダー内には他のファイルタイプが存在する場合がありますが、カタログを構成する主要なファイルは .XML および .FH ファイルです。.XML ファイルには特定の .FH ファイルが付随していない場合がありますが、.FH ファイルが存在する場合は、名前が一致する .XML ファイルとペアになります。

.XML ファイルには、バックアップリソースの詳細、バックアップ日、バックアップタイプ、バックアップデバイス、使用するメディアなど、バックアップセットに関する情報が含まれています。また、ファイル数やバイト数など、セットに関する統計情報も含まれます。
通常、.XML ファイルは小さなファイルです。基本的なバックアップでは、バックアップセットごとに 1 つ作成されます。一つのバックアップジョブで同一サーバー内のリソースをバックアップする場合も、C:\、D:\、システム状態などのリソースは別々のバックアップセットなので、カタログフォルダー内に多数のファイルが存在する可能性があります。

.FH ファイル (File History Files、履歴ファイルとも呼ばれます) には、バックアップセット内で保護されたコンテンツの詳細情報が含まれています。これには、バックアップされる各オブジェクトのオブジェクト名、パス、およびその他の属性が含まれます。オブジェクトには、個々のファイルや電子メールメッセージなどが含まれます。特定のバックアップセットには、非常に多くのオブジェクト (ボリューム内の全ファイル、メールボックスデータベース内の全電子メールなど) が含まれる場合があり、これらは .FH ファイルサイズに直接影響します。非常に大きな .FH ファイルになる可能性があります。

バックアップしたバイト数が大きいからといって、バックアップしたオブジェクト数が多いとは限らないため、バックアップしたバイト数をカタログが大きい理由の 直接的な 指標として判断することはできません。例えば、平均 1 GB の 500 個のファイルを含むバックアップは、250 GB の 2 つのファイルを含むバックアップよりも大きな .FH ファイルを生成します。

.FH ファイルの存在およびそのサイズは、バックアップ対象のリソースの種類や、バックアップジョブのオプションによっても影響を受けます。特に、大規模な NDMP ファイラーのバックアップ、または大規模な Exchange GRT 対応のディスクデバイスへのバックアップがテープタイプのストレージに複製される場合に、各バックアップセットの .FH ファイルのサイズが GB 単位になる可能性があります。

注: GRT は Granular Recovery Technology の略です。Exchange GRT の場合は、Exchange メールボックスデータベースのバックアップから個々の電子メールメッセージのリストアを可能にします。テープへの複製時に作成される .FH ファイルについては、後述の インスタント GRT を参照してください。
 

カタログファイルは、バックアップセットと同じタイミングで削除されます。テープの場合は、上書きまたは消去された場合、ディスクベースのバックアップセットの場合は、有効期限が切れてバックアップセットが削除対象になった場合に削除されます。

注: テープを上書きまたは消去すると、そのテープに含まれるすべてのバックアップセットのカタログファイルが削除されます。

カタログフォルダー内の .XML および .FH ファイルの量は、次のような情報に依存しています。

• バックアップするリソースの数
• バックアップするリソース内のオブジェクトの数
• ディスクや重複排除デバイス、クラウドデバイスへのバックアップのバックアップセット保持設定
• 使用済みのテープが Backup Exec から上書き、消去、または削除されるスケジュール
  (オフサイト等に保管されているテープは、オンラインになるまで上書きまたは消去できません)
• 保持期限の切れたバックアップセットを含む RDX カートリッジ
  (RDX カートリッジは、そのカートリッジに対して次回のバックアップが開始した時に、保持期限の切れたバックアップセットが削除されます)
• カタログの切り捨てが有効になっているかどうか (デフォルトは無効)
• GRT (またはインスタント GRT) が使用されているかどうか

解決策

大きなカタログフォルダーが使用されるバックアップ環境で、ディスク領域への影響を管理するためのオプションは以下のようになります。

• カタログフォルダーが十分な大きさのボリュームに配置されていることを確認します。ベストプラクティスとして、オペレーティングシステムのシステムドライブ、ディスクへのバックアップ (B2D)、または重複排除ストレージに使用されるボリュームにカタログフォルダーを使用しないようにします。また、Backup Exec アプリケーション自体を含むボリュームと同じボリュームを使用しないことも考慮します。
  
  注: カタログパスの変更が必要な場合は、BEUTILITY.EXE を使用することをお勧めします。これにより、既存のカタログ情報の移動とサービスの再起動が自動で行われます。
   
• 通常のテープまたは RDX カートリッジベースのバックアップをオフサイトで長期間保管する場合は、カタログを切り捨てるオプションを有効にすることを検討します。このオプションにより、一定期間経過後にバックアップセットにリンクされた .FH ファイルを削除できるので、ディスク使用量を削減できます。ただし、カタログジョブを実行し、再度 .FH ファイルを生成するまで、カタログの検索機能と、リストア機能が制限されます。
  
  注: カタログを切り捨てるオプションは、オフサイトでの長期保存だけでなく、クラウドストレージなどで、保持期間を長く設定する場合にも有効です。
   
• テープや RDX カートリッジを長期間保管している場合やオフラインになっている場合は、必要に応じて返却して使用し、メディアの再利用時に Backup Exec が古いカタログファイルを自動的に削除できるように計画します。
   
• テープの場合は、[スクラッチメディアを上書きする前に、ターゲットメディアセット内の再利用可能メディアへ上書きする] 設定を有効にします。 これにより、新品や消去済みメディアよりも、古いバックアップセットを含むテープがより頻繁に選択されるため、古いカタログファイルの数が減ります。
  
  注: テープを消去せずにスクラッチにした場合は、テープ内にバックアップセットが含まれたままになるので、カタログファイルも残ります。この場合は、スクラッチメディアの使用を後回しにするオプションの利点は軽微です。
   
•  個々のコンテンツを復元する必要がない仮想マシン (VM) バックアップ操作では、GRT を無効にすることを検討します。(たとえば、フロントエンドの Web サーバーの障害回復は、多くの場合サーバー全体を復旧します。) 
  GRT を無効にすると、VM ディスクファイル (.VHD、.VMDK ファイル) の情報のみがカタログに記録され、VM 内に保持されるすべてのオブジェクト (そのVM内で稼働しているコンピューター名や全ファイルなど) を列挙しないので、カタログファイルの数およびディスク使用量を削減できます。
   
• GRT が必要な場合は、ディスクスベースのストレージへのバックアップとインスタント GRT 機能の使用を検討します。インスタント GRT では、リストア選択時に、完全なバックアップイメージ (VMディスクファイルや Exchange メールボックスデータベースファイルなど) をマウントすることによって、イメージ内に保持されているオブジェクトをブラウズします。これにより、すべてのオブジェクトを予め .FH ファイルに列挙する処理を省略され、ディスク使用量を削減できます。
  
  注:
  • インスタント GRT を使用している場合は、カタログの検索機能は使用できません。
  • テープやクラウドデバイスにバックアップしている場合は、リストア選択時のマウント処理ができないので、インスタント GRT を使用できません。
  • インスタント GRT が有効なディスクスベースのストレージへのバックアップをテープやクラウドデバイスに複製するときは、完全なバックアップイメージのマウントとオブジェクトの列挙処理が行われ .FH ファイルが生成されます。
     
• 保存しているバックアップセットは、ビジネス要件に対する全体的な保持期間を確認し、短縮することを検討します。