DPM 記憶域の重複除去
System Center Data Protection Manager (DPM) では、データ重複除去を使用できます。
データ重複除去 (重複除去) では、ボリューム内の重複データを検出し、データの正確性と完全性を維持しながら、削除します。 詳細については、 重複除去計画を参照してください。
重複除去により、ストレージの消費量が削減されます。 一連のデータの冗長性の量はワークロードとデータの種類によって異なりますが、通常、バックアップ データは重複除去の使用時に強力な節約を示します。
同様の種類のデータをバックアップし、ワークロードを一緒に処理すると、重複除去によってデータの冗長性をさらに削減できます。
重複除去は、サーバー上のプライマリ ワークロードに影響を与えないように、追加の専用ハードウェアなしでプライマリ データ ボリュームにインストールされるように設計されています。 既定の設定は、特定のファイルを処理する前にデータを 5 日間保存でき、既定の最小ファイル サイズは 32 KB であるため、非侵入型です。 実装はメモリと CPU の使用量が少なくなるように設計されています。
重複除去は、次のワークロードに実装できます。
一般的なファイル共有: グループ コンテンツの公開および共有、ユーザー ホーム フォルダー、フォルダー リダイレクト/オフライン ファイル
ソフトウェア展開共有: ソフトウェア バイナリ、イメージ、更新プログラム
VHD ライブラリ: ハイパーバイザーへのプロビジョニング用の仮想ハード ディスク (VHD) ファイル記憶域
VDI の展開 (Windows Server 2012 R2 のみ): Hyper-V を用いた仮想デスクトップ インフラストラクチャ (VDI) の展開
仮想化バックアップ: バックアップ データを Windows ファイル サーバー上の VHD/VHDX ファイルに保存するバックアップ ソリューション (Hyper-V 仮想マシンで実行されている DPM など)
DPM と重複除去
DPM で重複除去を使用すると、大幅な節約につながる可能性があります。 DPM バックアップ データを最適化するときに重複除去によって保存される領域の量は、バックアップするデータの種類によって異なります。 たとえば、暗号化されたデータベース サーバーのバックアップでは、暗号化プロセスによって重複するデータが隠蔽されるため、削減量は最も少なくなります。 ただし、大規模な Virtual Desktop Infrastructure (VDI) デプロイをバックアップすると、通常、仮想デスクトップ環境間で大量のデータ重複が発生するため、70 ~ 90% の範囲で大幅に節約される可能性があります。 この記事で説明する構成では、さまざまなテスト ワークロードを実行し、50% から 90% の間の節約を確認しました。
DPM 記憶域に重複除去を使用するには、DPM が Hyper-V 仮想マシンで実行され、データ重複除去が有効になっている共有フォルダーの VHD にバックアップ データを格納する必要があります。
推奨される展開
データを dedupl ボリュームにバックアップする仮想マシンとして DPM を展開するには、次の展開トポロジをお勧めします。
Hyper-V ホスト クラスターの仮想マシンで実行する DPM。
ファイル サーバーの SMB 3.0 共有に格納される VHD/VHDX ファイルを使用する DPM 記憶域。
このテスト例では、直接接続されている SAS ドライブを使用して構築された記憶域スペース プールから構成されている記憶域ボリュームを使用して展開されたスケールアウト ファイル サーバー (SOFS) として、ファイル サーバーを構成しました。 このデプロイにより、大規模なパフォーマンスが保証されます。
以下の点に注意してください。
この展開は、DPM 2012 R2 以降、および DPM 2012 R2 以降でバックアップできるすべてのワークロード データでサポートされています。
DPM 仮想ハード ディスクが存在し、重複除去が有効になるすべての Windows ファイル サーバー ノードで、windows Server 2012 R2 と Update Rollup November 2014 以降が実行されている必要があります。
シナリオのデプロイに関する一般的な推奨事項と手順について説明します。 ハードウェア固有の例を示すときは常に、Microsoft クラウド プラットフォーム システム (CPS) に展開されているハードウェアを参照用に使用します。
この例ではリモート SMB 3.0 共有を使用してバックアップ データを格納するので、主要なハードウェア要件は Hyper-V ノードではなくファイル サーバー ノードが基になります。 次のハードウェア構成は、バックアップおよび運用ストレージ用の CPS で使用されます。 全体的なハードウェアはバックアップストレージと実稼働ストレージの両方に使用されますが、ドライブエンクロージャに記載されているドライブの数はバックアップに使用されるドライブのみです。
4 ノードの Scale Out File Server クラスター
ノードごとの構成
2x Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00 GHz、2001 MHz、8 コア、16 論理プロセッサ
128 GB 1333 MHz RDIMM メモリ
ストレージ接続: 2 ポートの SAS、10 GbE iWarp/RDMA の 1 ポート
4 つの JBOD ドライブエンクロージャ
各 JBOD に 18 個のディスク - 16 x 4 TB HDD + 2 x 800 GB SSD
各ドライブへのデュアル パス - フェールオーバーのみに設定されたマルチパス I/O 負荷分散ポリシー
ライトバック キャッシュ (WBC) 用に構成された SSD と、専用ジャーナル ドライブ用のその他
重複除去ボリュームを設定する
DPM データを含む重複除去された VHDX ファイルをサポートするために必要なボリュームの大きさを考えてみましょう。 CPS では、それぞれ 7.2 TB のボリュームを作成しました。 最適なボリュームのサイズは、ボリュームのデータが変更される量と頻度、およびディスク記憶域サブシステムのデータ アクセス スループットによって決まります。 重複除去処理が毎日のデータ変更率 (チャーン) に対応できない場合、処理が完了するまで節約率は低下します。 詳細については、「 データ重複除去のためのボリュームのサイズ設定」を参照してください。 重複除去ボリュームには、次の一般的なガイドラインが推奨されます。
回復性とディスク使用率向上のため、格納装置対応のパリティ記憶域スペースを使用します。
64 KB の割り当て単位と大きなファイル レコード セグメントを使用して NTFS をフォーマットし、スパース ファイルの重複除去の使用を改善します。
推奨される 7.2 TB ボリュームのボリューム サイズを超えるハードウェア構成では、ボリュームは次のように構成されます。
エンクロージャ対応デュアル パリティ 7.2 TB + 1 GB ライトバック キャッシュ
ResiliencySettingName == Parity
PhysicalDiskRedundancy == 2
NumberOfColumns == 7
インターリーブ == 256 KB (64 KB インターリーブでのデュアル パリティ パフォーマンスは、既定の 256 KB インターリーブよりもはるかに低い)
IsEnclosureAware == $true
AllocationUnitSize=64 KB
大規模な FRS
指定した記憶域プールの新しい仮想ディスクを次のように設定します。
New-VirtualDisk -Size 7.2TB -PhysicalDiskRedundancy 2 -ResiliencySettingName Parity -StoragePoolFriendlyName BackupPool -FriendlyName BackupStorage -NumberOfColumns 7 -IsEnclosureAware $true
これらの各ボリュームを次のようにフォーマットする必要があります。
Format-Volume -Partition <volume> -FileSystem NTFS -AllocationUnitSize 64 KB -UseLargeFRS -Force
CPS の展開では、これらは CSV として構成されます。
これらのボリューム内では、DPM はバックアップ データを保持する一連の VHDX ファイルを格納します。 次のようにフォーマットした後、ボリュームの重複除去を有効にします。
Enable-DedupVolume -Volume <volume> -UsageType HyperV Set-DedupVolume -Volume <volume> -MinimumFileAgeDays 0 -OptimizePartialFiles:$false
このコマンドは、次のボリューム レベルの重複除去設定も変更します。
UsageType を HyperV に設定します。これにより、開いているファイルの重複除去処理が行われます。これは、DPM によってバックアップ ストレージに使用される VHDX ファイルが、その仮想マシンで実行されている DPM で開いたままであるために必要です。
PartialFileOptimization を無効にする: これにより、重複除去によって、最小経過期間の変更されたセクションをスキャンするのではなく、開いているファイルのすべてのセクションが最適化されます。
MinFileAgeDays パラメーターを 0 に設定する: PartialFileOptimization を無効にすると、MinFileAgeDays は動作を変更し、重複除去ではその日数で変更されていないファイルのみが考慮されるようにします。 すべての DPM VHDX ファイル内のバックアップ データの処理がすぐに開始されるようにするので、MinFileAgeDays を 0 に設定する必要があります。
重複除去の設定の詳細については、「 データ重複のインストールと構成を参照してください。
DPM 記憶域を設定する
断片化の問題を回避し、効率性を維持するため、重複除去されたボリュームに存在する VHDX ファイルを使用して DPM 記憶域を割り当てます。 各ボリュームに 1 TB の 10 個の動的 VHDX ファイルが作成され、DPM に接続されます。 また、重複除去によって生成されるストレージの節約を利用するために、ストレージの 3 TB のオーバープロビジョニングが行われます。 重複除去によって記憶域の節約が増えるので、これらのボリュームに新しい VHDX ファイルを作成して、保存された領域を使用できます。 最大 30 個の VHDX ファイルがアタッチされた DPM サーバーをテストしました。
次のコマンドを実行して仮想ハード ディスクを作成し、後で DPM サーバーに追加します。
New-SCVirtualDiskDrive -Dynamic -SCSI -Bus $Bus -LUN $Lun -JobGroup $JobGroupId -VirtualHardDiskSizeMB 1048576 -Path $Using:Path -FileName <VHDName>
作成された仮想ハード ディスクを次のようにして DPM サーバーに追加します。
Import-Module "DataProtectionManager" Set-StorageSetting -NewDiskPolicy OnlineAll $dpmdisks = @() $dpmdisks = Get-DPMDisk -DPMServerName $env:computername | ? {$_.CanAddToStoragePool - eq $true -and $_.IsInStoragePool -eq $false -and $_.HasData -eq $false} Add-DPMDisk $dpmdisks
この手順では、DPM が保護されたデータのレプリカと回復ポイントを格納するディスクとして記憶域プールを構成します。 このプールは DPM 構成の一部であり、前のセクションで説明したデータ ボリュームの作成に使用される記憶域スペース プールとは別のものです。 DPM 記憶域プールの詳細については、「 ディスク 記憶域プールと記憶域プールの構成を参照してください。
Windows ファイル サーバー クラスターを設定する
データのスケールおよび個々のファイルのサイズにより、重複除去では、仮想化される DPM 記憶域をサポートするために特別な構成オプションのセットが必要です。 これらのオプションは、クラスターまたはクラスター ノード全体に適用されます。 重複除去を有効にする必要があり、クラスターの各ノードでクラスター設定を個別に構成する必要があります。
Windows File Server ストレージで重複除去を有効にする- 重複除去ロールは、Windows ファイル サーバー クラスターのすべてのノードにインストールする必要があります。 これを行うには、クラスターの各ノードで次の PowerShell コマンドを実行します。
Install-WindowsFeature -Name FileAndStorage-Services,FS-Data-Deduplication -ComputerName <node name>
バックアップ データ ファイルの重複除去処理を調整する- 次の PowerShell コマンドを実行して、遅延なく最適化を開始し、部分的なファイル書き込みを最適化しないように設定します。 既定では、ガベージ コレクション (GC) ジョブは毎週スケジュールされ、4 週間おきに GC ジョブは "ディープ GC" モードで実行され、削除するデータをより包括的かつ時間のかかる検索に使用します。 DPM ワークロードの場合、この "ディープ GC" モードでは効果が向上せず、重複除去でデータを最適化できる時間が短縮されます。 したがって、この詳細モードを無効にします。
Set-ItemProperty -Path HKLM:\Cluster\Dedup -Name DeepGCInterval -Value 0xFFFFFFFF
大規模な操作のパフォーマンスを調整する- 次の PowerShell スクリプトを実行して次の操作を行います。
詳細ガベージ コレクション実行時の追加の処理と I/O を無効にします。
ハッシュ処理用に追加メモリを確保します。
優先順位の最適化を有効にして大きいファイルの即時最適化を可能にします。
Set-ItemProperty -Path HKLM:\Cluster\Dedup -Name HashIndexFullKeyReservationPercent -Value 70 Set-ItemProperty -Path HKLM:\Cluster\Dedup -Name EnablePriorityOptimization -Value 1
これらの設定により以下の値が変更されます。
HashIndexFullKeyReservationPercent: この値は、既存のチャンク ハッシュと新しいチャンク ハッシュに使用される最適化ジョブ メモリの量を制御します。 規模が大きい場合、既定の 50% より 70% の方が最適化スループットが向上します。
EnablePriorityOptimization: ファイルが 1 TB に近づくと、1 つのファイルの断片化によって、ファイルごとの制限に近づくのに十分なフラグメントが蓄積される可能性があります。 最適化処理はこれらの断片化をまとめて、この制限に達しないようにします。 このレジストリ キーを設定すると、重複除去に断片化が進んでいるファイルを優先的に重複除去する処理が追加されます。
DPM と重複除去のスケジュール設定を設定する
バックアップと重複除去の操作はどちらも大量の I/O を実行します。 両方を同時に実行すると、操作を切り替えるオーバーヘッドのコストが増加し、1 日あたりのバックアップまたは重複除去されるデータ量が減る場合があります。 重複除去ウィンドウとバックアップ ウィンドウを分けてそれぞれの専用として構成することをお勧めします。 これにより、各操作の I/O トラフィックが 1 日のシステム操作に効率的に分散されるようになります。 スケジュールに関する推奨ガイドラインは次のとおりです。
バックアップ ウィンドウと重複除去ウィンドウを重ならないように分割します。
カスタム バックアップ スケジュールを設定します。
カスタム重複除去スケジュールを設定します。
毎日の重複除去ウィンドウに最適化をスケジュールします。
週末の重複除去スケジュールを別に設定し、その時間を使用してガベージ コレクション ジョブとスクラブ ジョブを実行します。
次の PowerShell コマンドを使用して DPM のスケジュールを設定できます。
Set-DPMConsistencyCheckWindow -ProtectionGroup $mpg -StartTime $startTime -
DurationInHours $duration
Set-DPMBackupWindow -ProtectionGroup $mpg -StartTime $startTime -DurationInHours
$duration
この構成では、DPM は午後 10 時 ~ 午前 6 時の間に仮想マシンをバックアップするように構成されます。 重複除去は、残りの 16 時間にスケジュールされます。 構成する実際の重複除去時間は、ボリューム サイズによって異なります。 詳細については、「 データ重複除去のためのボリュームのサイズ設定」を参照してください。 バックアップ ウィンドウの終了後の午前 6 時から始まる 16 時間の重複除去ウィンドウは、個々のクラスター ノードから次のように構成されます。
#disable default schedule
Set-DedupSchedule * -Enabled:$false
#Remainder of the day after an 8 hour backup window starting at 10pm $dedupDuration = 16
$dedupStart = "6:00am"
#On weekends GC and scrubbing start one hour earlier than optimization job.
# Once GC/scrubbing jobs complete, the remaining time is used for weekend
# optimization.
$shortenedDuration = $dedupDuration - 1
$dedupShortenedStart = "7:00am"
#if the previous command disabled priority optimization schedule
#reenable it
if ((Get-DedupSchedule -name PriorityOptimization -ErrorAction SilentlyContinue) -ne $null)
{
Set-DedupSchedule -Name PriorityOptimization -Enabled:$true
}
#set weekday and weekend optimization schedules
New-DedupSchedule -Name DailyOptimization -Type Optimization -DurationHours $dedupDuration -Memory 50 -Priority Normal -InputOutputThrottleLevel None -Start $dedupStart -Days Monday,Tuesday,Wednesday,Thursday,Friday
New-DedupSchedule -Name WeekendOptimization -Type Optimization -DurationHours $shortenedDuration -Memory 50 -Priority Normal -InputOutputThrottleLevel None -Start $dedupShortenedStart -Days Saturday,Sunday
#re-enable and modify scrubbing and garbage collection schedules
Set-DedupSchedule -Name WeeklyScrubbing -Enabled:$true -Memory 50 -DurationHours $dedupDuration -Priority Normal -InputOutputThrottleLevel None -Start $dedupStart -StopWhenSystemBusy:$false -Days Sunday
Set-DedupSchedule -Name WeeklyGarbageCollection -Enabled:$true -Memory 50 -DurationHours $dedupDuration -Priority Normal -InputOutputThrottleLevel None -Start $dedupStart -StopWhenSystemBusy:$false -Days Saturday
#disable background optimization
if ((Get-DedupSchedule -name BackgroundOptimization -ErrorAction SilentlyContinue) -ne $null)
{
Set-DedupSchedule -Name BackgroundOptimization -Enabled:$false
}
バックアップ ウィンドウが変更されるたびに、重複除去ウィンドウが重複しないように、重複除去ウィンドウと共に変更することが重要です。 重複除去とバックアップの期間は、1 日の完全な 24 時間を埋める必要はありません。ただし、ワークロードとデータチャーンの毎日の変化が予想されるため、処理時間の変動を許容することを強くお勧めします。
バックアップのパフォーマンスへの影響
一連のファイルが重複除去された後は、ファイルにアクセスするときにわずかなパフォーマンス コストが発生する可能性があります。 これは、重複除去されたファイルによって使用されているファイル形式へのアクセスに必要な追加処理のためです。 このシナリオでは、ファイルは一連の VHDX ファイルであり、バックアップ ウィンドウの間も DPM によって継続的に使用されます。 これらのファイルを重複除去する効果は、バックアップ操作と回復操作が重複除去を行わない場合よりも少し遅くなる可能性があることを意味します。 他のバックアップ製品と同様に、DPM は書き込みの量が多いワークロードで、復元操作中は読み取り操作が最も重要です。 重複除去によるバックアップのパフォーマンスに対する影響を解決するための推奨事項は次のとおりです。
読み取り/復元操作: 重複除去機能では重複除去されたチャンクがキャッシュされるため、読み取り操作への影響は通常ごくわずかであり、特別な配慮は必要ありません。
書き込み/バックアップ操作: バックアップ期間を定義するときに、バックアップ時間を 5 ~ 10% 増加させる計画を立てる。 (これは、重複除去されていないボリュームに書き込むときに予想されるバックアップ時間と比較したときの増加です)。
監視
DPM とデータ重複除去を監視して次のことを確認できます。
バックアップ データを格納するのに十分なディスク領域がプロビジョニングされている
DPM バックアップ ジョブが正常に完了している
バックアップ ボリュームで重複除去が有効になっている
重複除去スケジュールが正しく設定されている
重複除去の処理が毎日正常に完了している
重複除去の削減率がシステム構成に対する予想と一致している
重複除去が成功するかどうかは、システムの全体的なハードウェア機能 (CPU 処理速度、I/O 帯域幅、記憶域の容量など)、適切なシステム構成、システムの平均負荷、および 1 日あたりのデータ変更量によって決まります。
DPM 中央コンソールを使用して DPM を監視できます。 「 中央コンソールのインストール」をご覧ください。
次の PowerShell コマンドを使用して、重複除去を監視して、重複除去の状態、保存率、スケジュールの状態を確認できます。
状態の取得:
PS C:\> Get-DedupStatus
FreeSpace SavedSpace OptimizedFiles InPolicyFiles Volume
-------------- ---------- -------------- ------------- ------
280.26 GB 529.94 GB 36124 36125 X:
151.26 GB 84.19 GB 43017 43017 Z:
削減率の取得:
PS C:\> Get-DedupVolume
Enabled SavedSpace SavingsRate Volume
------- ---------- ----------- ------
True 529.94 GB 74 % X:
スケジュールの状態を取得するには Get-DedupSchedule コマンドレットを使用します。
イベントの監視
イベント ログを監視することにより、重複除去のイベントと状態を把握できます。
重複除去イベントを表示するには、エクスプローラーで アプリケーションとサービス ログ>Microsoft>Windows>Deduplication に移動します。
Get-DedupStatus |fl Windows PowerShell の結果として値 LastOptimizationResult = 0x00000000 が表示される場合は、データセット全体が前回の最適化ジョブによって処理されています。 それ以外の値の場合は、システムは重複除去処理を完了できなかったので、ボリューム サイズなどの構成設定の確認が必要かもしれません。
コマンドレットの詳細な例については、「 Monitor and Report for Data Deduplication (データ重複除去の監視とレポート)」をご覧ください。
バックアップ ストレージの監視
この構成例では、7.2 TB のボリュームには、10 TB の "論理" データ (重複除去されていない場合のデータのサイズ) が 10 x 1 TB の動的 VHDX ファイルに格納されます。 これらのファイルが追加のバックアップ データを蓄積すると、ボリュームがいっぱいになります。 重複除去による削減率が十分に高い場合、10 個のファイルすべてが最大論理サイズに達し、7.2 TB のボリュームに収まります (DPM サーバーで使用する追加の VHDX ファイルを割り当てるための領域が追加される可能性もあります)。 ただし、重複除去によるサイズの節約が十分でない場合は、VHDX ファイルが完全な論理サイズに達し、ボリュームがいっぱいになる前に、ボリューム上の領域が不足する可能性があります。 ボリュームがいっぱいにならないように、次のことをお勧めします。
ボリューム サイズの要件はできるだけ控えめにして、記憶域の過剰プロビジョニングを可能にします。 重複除去の削減とデータチャーンの予想される変動を可能にするために、バックアップ ストレージの使用を計画するときは、少なくとも 10% のバッファーを許可することをお勧めします。
バックアップ記憶域に使用されるボリュームを監視し、領域の使用率と重複除去の削減率が予想されるレベルであることを確認します。
ボリュームがいっぱいになると、次の現象が発生します。
DPM の仮想マシンが一時停止で重大な状態になり、その VM ではそれ以上バックアップ ジョブを発行できなくなります。
いっぱいになったボリュームの VHDX ファイルを使用するすべてのバックアップ ジョブが失敗します。
この状態から回復し、システムを通常の操作に復元するには、追加の記憶域をプロビジョニングし、DPM 仮想マシンまたはその VHDX の記憶域の移行を実行して領域を解放できます。
完全バックアップ共有の VHDX ファイルを所有している DPM サーバーを停止します。
NTFS と重複除去の設定など、既存の共有に使用したものと同じ構成および設定を使用して、追加のボリュームおよびバックアップ共有を作成します。
DPM サーバー仮想マシンの記憶域 を移行し、少なくとも 1 つの VHDX ファイルを完全バックアップ共有から、手順 2 で作成した新しいバックアップ共有に移行します。
いっぱいになったソース バックアップ共有でデータ重複除去ガベージ コレクション (GC) ジョブを実行します。 GC ジョブが成功すると、空き領域が回収されます。
DPM サーバーの仮想マシンを再起動します。
DPM 整合性チェック ジョブは、以前に失敗したすべてのデータ ソースの次のバックアップ 期間中にトリガーされます。
すべてのバックアップ ジョブが成功するようになります。
まとめ
重複除去と DPM を組み合わせることで、かなりの領域を節約できます。 これにより、DPM の展開に対して高い保持率、高頻度のバックアップ、優れた TCO を実現できます。 このドキュメントのガイダンスと推奨事項では、ユーザー自身の展開の DPM 記憶域用に重複除去を構成し、そのメリットを確認できるツールと情報を提供しました。
一般的な質問
Q: DPM VHDX ファイルのサイズは 1 TB である必要があります。 これは、DPM が 1 TB のサイズの VM または SharePoint または SQL DB またはファイル ボリューム > バックアップできないことを意味しますか?
A: いいえ。 DPM は、複数のボリュームを 1 つに集約してバックアップを格納します。 そのため、1 TB のファイル サイズは、DPM がバックアップできるデータ ソース サイズには影響しません。
Q: DPM 記憶域の VHDX ファイルはリモート SMB ファイル共有のみに展開する必要があるようですが、 DPM の仮想マシンが実行しているのと同じシステムの重複除去を有効にしたボリュームにバックアップの VHDX ファイルを格納するとどうなりますか。
A: 前述のように、DPM、Hyper-V、および重複除去は、ストレージとコンピューティング集中型の操作です。 これら 3 つすべてを 1 つのシステムに組み合わせると、Hyper-V とその VM を不足させる I/O とプロセス集中型の操作が発生する可能性があります。 同じコンピューター上のバックアップ ストレージ ボリュームを使用して VM で DPM を構成する実験を行う場合は、パフォーマンスを注意深く監視して、同じコンピューター上で 3 つの操作すべてを維持するのに十分な I/O 帯域幅とコンピューティング容量があることを確認する必要があります。
Q: 重複除去ウィンドウとバックアップ ウィンドウを分けてそれぞれの専用にすることが推奨されました。 DPM のバックアップ中に重複除去を有効にできないのはなぜですか? SQL DB を 15 分ごとにバックアップする必要があります。
A: Dedup と DPM は記憶域を集中的に使用する操作であり、両方を同時に実行することは非効率的であり、I/O 不足につながる可能性があります。 そのため、ワークロードを 1 日に 1 回以上 (15 分ごとに SQL Server など) 保護し、重複除去を同時に有効にするには、リソースの不足を避けるために十分な I/O 帯域幅とコンピューター容量があることを確認します。
Q: 説明されている構成に基づくと、DPM は仮想マシンで実行する必要があります。 VHDX ファイルではなく、レプリカ ボリュームとシャドウ コピー ボリュームで重複除去を直接有効にできないのはなぜですか?
A: 重複除去は、個別のファイルで動作しているボリュームごとに行われます。 重複除去はファイル レベルで最適化されるため、DPM がバックアップ データの格納に使用する VolSnap テクノロジをサポートするようには設計されていません。 VM で DPM を実行すると、Hyper-V が DPM のボリューム操作を VHDX ファイル レベルにマップするので、重複除去はバックアップ データを最適化し、より大きな記憶域削減を提供できます。
Q: 上記のサンプル構成では、7.2 TB のボリュームのみが作成されています。 これより大きい、または小さいボリュームを作成できますか。
A: 重複除去は、ボリュームごとに 1 つのスレッドで実行します。 ボリュームのサイズを大きくすると、重複除去が最適化の完了に要する時間が長くなります。 一方、ボリュームが小さい場合は、重複するチャンクを見つけるデータが少なくなり、削減につながる可能性があります。 そのため、最適な節約のために、総チャーンとシステム ハードウェア機能に基づいてボリューム サイズを微調整することをお勧めします。 重複除去で使用するボリューム サイズの決定に関する詳細については、 重複除去で使用されるボリューム サイズの決定の詳細については、「 データ重複除去用のボリュームのサイズ調整」を参照してください。