Protect, Unprotect, Protect, Unprotect – Understanding how DPM 2010 retention works

Published Feb 15 2019 04:17 AM 143 Views
First published on TECHNET on Nov 03, 2010

UPDATE 11/20/2013: The script below has been updated to work with all current versions of DPM 2012.


With special thanks to Fahd Kamal for the backgrounder content.

Imagine that you are experimenting with DPM 2010.  You protect some data, and then you remove that protection group.  Then, showing DPM to one of your friends, you protect the data again, and later unprotect it.  Later that same day, you try to protect the data again to show some other friends, and it breaks.   The reason is that if you attempt to [re]protect the same data source for the 3rd time before the retention of previous protection expired (or remove those recovery points) DPM will fail. A similar condition may arise when migrating data sources. We will explain why and how this could be mitigated.

Whilst not very common, similar scenarios have occurred and hence this blog.

When protection is stopped with retaining data and protected again DPM will re-associate the now inactive protected data (and recovery points) with the new protection, great, exactly what you want. But what really happens under the hoods changed with DPM2010 on behalf of collocating  data source with SQL, Hyper-V and Client protection.

Skipping the details of combinations; we can no longer assume that the inactive replica allocation is appropriate or efficient for the new protection. To deal with that DPM creates a second allocation according the new protection parameters. DPM2010 is designed to handle only 2 allocations per data source, the “previous” and “current”, say R1 and R2 respectively. Remember the aim is to reduce the number of volumes as much as possible and maintaining more ‘previous’ allocations would be working in the wrong direction, hence only the 2 allocations we truly need to accommodate a change.
From a recovery perspective; recovery points relating to both R1 and R2 are available and is transparent.

If we repeat a change sequence or migrate the same data source a 2nd time (=3rd protection) and retain formerly protected data, there is no ‘slot’ to designate current R2 into R1 and create a new R2 without dropping the current R1. This is not done automatically because that would remove data you may still need and instead reported as a failure. What to do next?

To execute the protection change or data source migration, all recovery points relating to the current R1 need to be removed first. R1 disappears on the next pruning run (midnight) if the latest R1 recovery point expires or all R1 recovery points are removed for that data source, not the entire protection group of non-collocated data sources and not R2 recovery points which is the most recent protected data!

However, if the current R1 (to be removed) already belongs to a collocated group, removing recovery points affects all collocated data sources! Remember, the goal of collocation is that multiple data sources use a single allocation, if that (R1) needs to go it applies to all replicas and recovery points associated with that allocation (not with the current R2 allocation that is to become the new R1 after the change or migration we want to execute).

Shortening the retention period overnight to expire recovery points is not a good idea because this also applies to all non-collocated data sources in that group and you still need to know up to what point in time recovery points are associated with the R1 to be removed. Therefore the following script can be used to remove recovery points for the data source we want to change or migrate. This script removes all recovery points for the selected data source that are older than the newest replica (R2) creation time. As a result the oldest replica (R1) will be automatically deleted.

#begin script


$dss = @(Get-ProtectionGroup (&hostname) | foreach {Get-Datasource $_})

$dss += Get-Datasource -Inactive

for ($i=0; $i -lt $dss.Count; $i++) {Write-Host "[$i] $($dss[$i].name) on $($dss[$i].productionservername)"}

$ds = $dss[(Read-Host "Select index " )]

$DPMInstallPath= (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Microsoft Data Protection Manager\setup').InstallPath

$paths = @(Get-ChildItem ($DPMInstallPath + "Volumes\Replica") -Recurse -Filter "*$($*" | ? {$_.PsIscontainer})

if ($paths.Count -lt 2) {Write-Host "No multiple replicas found, aborting...";exit 0}

$cutoff = ($paths | sort creationtime -Descending)[0].creationtime

$rp = @(Get-RecoveryPoint $ds | ? {$_.representedpointintime -lt $cutoff})

$resp = @(Read-Host "Confirm deleting [$($rp.count)] recovery points from `"$($ _on_ $($ds.productionservername)`" y/N")

if ($resp[0] -ne "y") {write-host "Aborting..."; exit 0}

$rp | foreach {    Remove-RecoveryPoint $_ -ForceDeletion }

#end script

Get the latest System Center news on Facebook and Twitter :

System Center All Up:
System Center – Configuration Manager Support Team blog:
System Center – Data Protection Manager Team blog:
System Center – Orchestrator Support Team blog:
System Center – Operations Manager Team blog:
System Center – Service Manager Team blog:
System Center – Virtual Machine Manager Team blog:

Windows Intune:
WSUS Support Team blog:
The AD RMS blog:

App-V Team blog:
MED-V Team blog:
Server App-V Team blog:

The Forefront Endpoint Protection blog :
The Forefront Identity Manager blog :
The Forefront TMG blog:
The Forefront UAG blog:

Version history
Last update:
‎Mar 11 2019 08:35 AM
Updated by: