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 記憶域に重複除去を使用するには、Hyper-V 仮想マシンで DPM を実行し、データ重複除去が有効になっている共有フォルダーの VHD にバックアップ データを格納します。
推奨される展開
重複除去ボリュームにデータをバックアップする仮想マシンとして DPM を展開するには、次の展開トポロジを使用します。
Hyper-V ホスト クラスターの仮想マシンで実行する DPM。
ファイル サーバー上の SMB 3.0 共有に格納されている VHD ファイルと VHDX ファイルを使用する DPM ストレージ。
テスト例では、ファイル サーバーは、直接接続された SAS ドライブを使用して構築された記憶域スペース プールから構成された記憶域ボリュームを使用して展開されるスケールアウト ファイル サーバー (SOFS) として構成されます。 このデプロイにより、大規模なパフォーマンスが保証されます。
次の情報をメモしておきます。
DPM は、DPM 2012 R2 以降と、DPM 2012 R2 以降でバックアップできるすべてのワークロード データに対して、この展開をサポートしています。
DPM 仮想ハード ディスクが存在し、重複除去が有効になっているすべての Windows ファイル サーバー ノードでは、Windows Server 2012 R2 と 更新プログラムロールアップ 2014 年 11 月以降を 実行する必要があります。
この記事では、シナリオのデプロイに関する一般的な推奨事項と手順について説明します。 ハードウェア固有の例を示すときは常に、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 と、残りが専用ジャーナルドライブ用になっている SSD
重複除去ボリュームを設定する
DPM データを含む重複除去された VHDX ファイルをサポートするために、ボリュームの大きさを検討します。 CPS では、それぞれ 7.2 TB のボリュームを作成します。 最適なボリュームのサイズは、ボリュームのデータが変更される量と頻度、およびディスク記憶域サブシステムのデータ アクセス スループットによって決まります。 重複除去処理が日次データ変更率 (チャーン) に対応できない場合、処理が完了するまで節約率は低下します。 詳細については、「 データ重複除去のためのボリュームのサイズ設定」を参照してください。 重複除去ボリュームについては、以下の一般的なガイドラインをお勧めします。
耐障害性とディスク使用率向上のため、筐体対応のパリティ記憶域スペースを使用します。
64 KB の割り当て単位と大きなファイル レコード セグメントを使用して NTFS をフォーマットし、スパース ファイルの重複除去使用とよりうまく連携するようにします。
7.2 TB ボリュームの推奨ボリューム サイズを超えるハードウェア構成で、次のようにボリュームを構成します。
エンクロージャ対応デュアル パリティ 7.2 TB + 1 GB ライトバック キャッシュ
ResiliencySettingName == パリティ
PhysicalDiskRedundancy == 2
NumberOfColumns == 7
インターリーブ == 256 KB (64 KB インターリーブでのデュアル パリティ パフォーマンスは、既定の 256 KB インターリーブよりもはるかに低い)
IsEnclosureAware == $true # エンクロージャを認識している場合は$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 -ForceCPS デプロイで、これらのボリュームを 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 を実行します。 同時に実行すると、操作を切り替える余分なオーバーヘッドが発生する可能性があります。 毎日バックアップまたは重複除去するデータが少なくなる場合があります。 専用の重複除去ウィンドウとバックアップ ウィンドウを構成します。 この構成は、これらの各操作の I/O トラフィックが、毎日のシステム操作中に効率的に分散されるようにするのに役立ちます。 スケジュールに関する推奨ガイドラインは次のとおりです。
日を重複しないバックアップウィンドウと重複除去ウィンドウに分割します。
カスタム バックアップ スケジュールを設定します。
カスタム重複除去スケジュールを設定します。
毎日の重複除去ウィンドウで最適化をスケジュールします。
週末の重複除去スケジュールを個別に設定します。 この時間は、ガベージ コレクションとスクラブ ジョブに使用します。
次の 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 帯域幅、ストレージ容量など、システム ハードウェアの全体的な機能によって異なります。 また、正しいシステム構成、システムの平均負荷、変更されたデータの日単位の量にも依存します。
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 に移動します。
Windows PowerShell の結果に
Get-DedupStatus |fl値が表示された場合、以前の最適化ジョブによってデータセット全体が処理されました。 値が表示されない場合、システムは重複除去処理を完了できませんでした。 ボリューム サイズなどの構成設定を確認できます。
コマンドレットの詳細な例については、「 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 仮想マシンは一時停止クリティカルな状態になり、それ以上のバックアップ ジョブを発行することはできません。
ボリューム全体で 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 ファイルを格納するとどうなりますか?
ある: 前に説明したように、DPM、Hyper-V、および重複除去は、ストレージとコンピューティング集中型の操作です。 これら 3 つすべてを 1 つのシステムに組み合わせると、I/O とプロセス集中型の操作が発生し、Hyper-V とその VM が不足する可能性があります。 同じマシン上のバックアップ ストレージ ボリュームを使用して VM で DPM を構成する場合は、パフォーマンスを注意深く監視して、同じコンピューター上で 3 つの操作すべてを維持するのに十分な I/O 帯域幅とコンピューティング容量があることを確認します。
Q: 重複除去ウィンドウとバックアップ ウィンドウを分けてそれぞれの専用にすることが推奨されました。 DPM のバックアップ中に重複除去を有効にできないのはなぜですか? SQL DB を 15 分ごとにバックアップする必要があります。
ある: 重複除去と DPM は、記憶域を集中的に使用する操作です。 両方を同時に実行すると、非効率的になり、I/O 不足につながる可能性があります。 ワークロードを 1 日に 1 回以上保護し (15 分ごとに SQL Server など)、重複除去を同時に有効にするには、リソースの不足を避けるために十分な I/O 帯域幅とコンピューター容量があることを確認します。
Q: 説明されている構成に基づくと、DPM は仮想マシンで実行する必要があります。 VHDX ファイルではなく、レプリカ ボリュームとシャドウ コピー ボリュームで重複除去を直接有効にできないのはなぜですか?
ある: 重複除去はボリュームごとに機能し、個々のファイルで動作します。 重複除去はファイル レベルで最適化されるため、DPM がバックアップ データの格納に使用する VolSnap テクノロジをサポートするようには設計されていません。 VM で DPM を実行すると、Hyper-V は DPM ボリューム操作を VHDX ファイル レベルにマップします。これにより、重複除去によってバックアップ データが最適化され、記憶域の節約が大きくなります。
Q: 上記のサンプル構成では、7.2 TB のボリュームのみが作成されます。 これより大きい、または小さいボリュームを作成できますか。
A: 重複除去プロセスはボリュームごとに1つのスレッドで実行されます。 ボリューム サイズが大きくなると、重複除去の最適化が完了するまでの時間が長くなります。 一方、ボリュームが小さい場合は、重複するチャンクを見つけるデータが少なくなり、削減につながる可能性があります。 そのため、合計チャーンとシステム ハードウェア機能に基づいてボリューム サイズを微調整し、最適な節約を実現します。 重複除去で使用されるボリューム サイズの決定の詳細については、「 データ重複除去用のボリュームのサイズ調整」を参照してください。