DPM 記憶域の重複除去
重要
このバージョンの Data Protection Manager (DPM) はサポート終了に達しました。 DPM 2022 にアップグレードすることをお勧めします。
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 バックアップ データを最適化するときに重複除去によって削減される領域の量は、バックアップされるデータの種類によって異なります。 たとえば、暗号化されたデータベース サーバーのバックアップでは、暗号化プロセスによって重複するデータが隠蔽されるため、削減量は最も少なくなります。 ただし、大規模な仮想デスクトップ インフラストラクチャ (VDI) デプロイをバックアップすると、通常は仮想デスクトップ環境間で大量のデータ重複が発生するため、70 ~ 90% の範囲で大幅に節約される可能性があります。 この記事で説明する構成では、さまざまなテスト ワークロードを実行し、50% から 90% の間の節約を確認しました。
DPM 記憶域に重複除去を使用するには、HYPER-V 仮想マシンで DPM が実行され、データ重複除去が有効になっている共有フォルダーの VHD にバックアップ データを格納する必要があります。
推奨される展開
重複除去されたボリュームにデータをバックアップする仮想マシンとして DPM を展開する場合は、次の展開トポロジをお勧めします。
Hyper-V ホスト クラスターの仮想マシンで実行する DPM。
ファイル サーバーの SMB 3.0 共有に格納される VHD/VHDX ファイルを使用する DPM 記憶域。
このテスト例では、直接接続されている SAS ドライブを使用して構築された記憶域スペース プールから構成されている記憶域ボリュームを使用して展開されたスケールアウト ファイル サーバー (SOFS) として、ファイル サーバーを構成しました。 このデプロイにより、大規模なパフォーマンスが保証されます。
以下の点に注意してください。
この展開は、DPM 2012 R2 以降と、DPM 2012 R2 以降でバックアップできるすべてのワークロード データでサポートされています。
DPM 仮想ハード ディスクが存在し、重複除去が有効にされる、すべての Windows ファイル サーバー ノードで、2014 年 11 月付け更新プログラムのロールアップ以降を適用した Windows Server 2012 R2 を実行している必要があります。
このシナリオの展開についての一般的な推奨事項と手順について説明します。 ハードウェア固有の例を示すときは常に、Microsoft クラウド プラットフォーム システム (CPS) に展開されているハードウェアを参照用に使用します。
この例ではリモート SMB 3.0 共有を使用してバックアップ データを格納するので、主要なハードウェア要件は Hyper-V ノードではなくファイル サーバー ノードが基になります。 バックアップおよび運用記憶域用の CPS では、次のハードウェア構成を使用します。 全体的なハードウェアはバックアップ ストレージと運用ストレージの両方に使用されますが、ドライブ エンクロージャに一覧表示されているドライブの数は、バックアップに使用されるドライブの数のみです。
4 ノードのスケール アウト ファイル サーバー クラスター
ノードごとの構成
2x Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00 GHz、2001 MHz、8 コア、16 論理プロセッサ
128 GB で 1333 MHz の RDIMM メモリ
ストレージ接続: SAS の 2 つのポート、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 ファイルを作成して、保存された領域を使用できます。 DPM サーバーに最大 30 個の VHDX ファイルをアタッチしてテストしました。
次のコマンドを実行して仮想ハード ディスクを作成し、後で 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 ファイル サーバー記憶域で重複除去を有効にする - 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 コマンドレットを使用します。
イベントの監視
イベント ログを監視することにより、重複除去のイベントと状態を把握できます。
重複除去のイベントを表示するには、 {14}ファイル エクスプ ローラー{15}で、 {16}[アプリケーションとサービス ログ]{17}{18}{19}[Microsoft]{20}{21}{22}[Windows]{23}{24}{25}[重複除去]{26}」をご覧ください。
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 が VM または SharePoint または SQL DB またはサイズ > 1 TB のファイル ボリュームをバックアップできないことを意味しますか?
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 のバックアップ中に重複除去を有効にできないのはなぜですか。 15 分ごとに SQL DB をバックアップする必要があります。
A: 重複除去と 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 つのスレッドで実行します。 ボリュームのサイズを大きくすると、重複除去が最適化の完了に要する時間が長くなります。 一方、ボリュームが少ない場合は、重複するチャンクを見つけるデータが少なくなり、節約が削減される可能性があります。 そのため、最適な節約のために、チャーンの合計とシステム ハードウェアの機能に基づいてボリューム サイズを微調整することをお勧めします。 重複除去で使用するボリューム サイズの決定に関する詳細については、 重複除去で使用されるボリューム サイズの決定の詳細については、「データ重複除去 のボリュームのサイズ設定」を参照してください。