Say you want to use the DPM “SAN recovery” option. This requires storage management steps for which it is useful to know which Windows disks (LUN’s) hold the associated DPM volumes for a given data source. First a generic recap of the potential ‘DPM SAN recovery’ advantages and steps;
- ‘SAN recovery’ is only beneficial when recovering large amount of replica data relative to effective bandwidth (typically xxxGB or more).
- ‘SAN recovery’ partially offloads the LAN (replica data only) and may reduce data transfer time. Usually the incremental size is ~10% of the replica size but there are huge exceptions.
-
‘SAN recovery’ only reduces transfer time if the SAN bandwidth is more than twice the LAN bandwidth.
Note that data travels the disk path twice, once to read from snapshot and again to write to target volume
.
- Stop or wait for completion of any ‘in progress’ synchronization job for the data source to recover.
- Create a recovery point without synchronization using the DPM UI or script (some storage vendors describe a script). This is to ensure DPM metadata is current and DPM has the same current ‘view’ on data as the hardware snapshot that is to be created.
- Create a hardware snapshot of the involved storage pool LUN’s and expose these to the production server. The snapshot LUNs must appear ‘Online’ on the production server to recover data on. You can use any kind of snapshot that can be exposed to the production server, the DPM agent will only read from it. See below to find which DPM storage pool disks or Windows volume ID’s are involved.
- Start recovery as desired using the DPM UI or script using the “SAN Recovery” option. DPM will instruct the agent to locate replica data on the exposed snapshot disks and copies the replica to the recovery target location. If the recovery point is an incremental DPM will subsequently transfer additional data (log files) across the LAN and ‘roll-forward’ as appropriate for the type of data source and recovery.
- On successful completion you can start using the recovered application or files and remove (unmask) the snapshot LUN’s from the production server. The hardware snapshots and provisioning are no longer needed by DPM but be careful in how to dispose these.
Note: during this operation DPM likely synchronized other (unrelated) data sources that happen to have protected data on the same DPM storage pool disks. Therefore we need be careful removing the hardware snapshot, let’s examine that a bit closer.
Suppose we are recovering a data source represented by “V2” in the illustration below which requires a hardware snapshot of “Disk-1”. Say we successfully complete the SAN recovery between T0 and T1 but in that time-span DPM may also execute protection jobs and apply changes to unrelated data sources represented by “V1” and “V3” also on “Disk-1”. For this discussion it does not really matter whether these volumes are replica or recovery point volumes or a combination.
Typically we want to release the hardware resources (reserved LUN’s) by removing the no longer needed hardware snapshot. This has 2 possible results;
- “Disk-1” keeps the current T1 situation and continues normally, this what you need to do! This matches DPM ‘knowledge’ for both content and status information. All blocks that belong to the T1 (current) hardware point in time should remain such that effectively nothing changed outside DPM awareness and control. Hardware snapshots vary in technical details; abilities, option naming and you have to select the appropriate actions for your storage implementation such that the intended behavior is realized.
-
“Disk-1” is changed back to the T0 situation and is
not
what you want to do.
This would cause 2 problems; DPM volumes change outside DPM control invalidating “V1+V3” protection and corrupts “V3” on the NTFS level because it spans onto “Disk-2” that is not part of the snapshot. We did not account for the “V3” volume span because that was not of interest for the “V2” recovery. DPM built-in integrity check will detect and alert that “V1” needs a consistency check (“V2” anyway due to recovery) but “V3” likely needs to be recreated from scratch. If the “V3” volume-span was accounted for and “Disk-2” included in the same snapshot then “V3” but also “V4” would become invalid and need a consistency check. Clearly this causes a much bigger consistency check impact then necessary or worse. Also note that in reality this typically involves dozens or more data sources.
DPM allocates replica and recovery point volumes on different disks (if possible) and DPM volumes may span disks like “V3” above. So, which disks do you need to snap? To help with this you can use the script posted below that reports for each data source which ‘NTdisks’ (as in Disk Manager) and Windows volume ID’s are involved. If a suitable hardware VSS provider is installed and configured on DPM and target server this can be used to automate the entire recovery (particularly step 3 and 4 above) but is outside the scope of this blog.
Cut & past the script text between “#begin script” and “#end script” into a Powershell script to run in the DPM Management Shell; say “MyScript,Ps1” as shown below.
If you run this script like:
.\Myscript.Ps1 | format-list
you get output for each data source similar to the screenshot below;
If you run this script like:
$mydata = .\Myscript.Ps1
$mydata will be an array each element of which has the following properties;
- Datasource : description of the data source
- NTdisks : comma separated list of disk manager numbers (3,2)
- Inactive : whether or not it is an inactive data source on disk
- Replica : Replica volume ID you could use with DISKSHADOW
- Diff : Recovery point volume ID you could use with DISKSHADOW
#begin script
function GetDpmMP {
param([string]$volumetype = "ShadowCopy" )
# Get DPM mount points by type: Diffarea or Replica or Shadowcopy, defaults to shadowcopy
# (parsing mountvol appreared most predictable across windows versions and conditions)
# builds $Vols array of $dpmmp structures
# <obj>.Target = volume ident in format \\?\Volume{guid} without trailing slash
# <obj>.Path = mount point path including trailing slash
switch ($volumetype) {
ShadowCopy {$paths = @(mountvol | ?{($_ -match "Microsoft DPM") -and ($_ -match "ShadowCopy") }) }
Replica {$paths = @(mountvol | ?{($_ -match "Microsoft DPM") -and ($_ -match "Replica") }) }
Diffarea {$paths = @(mountvol | ?{($_ -match "Microsoft DPM") -and ($_ -match "Diffarea") }) }
Default {$paths = @(mountvol | ?{($_ -match "Microsoft DPM") -and ($_ -match "ShadowCopy") }) }
}
$paths = $paths | ?{$_} #ensure no blanks
if ($paths.Count -lt 1) {
if ($skipdpmbackup) {Throw "No volume paths found, run at least once without -SkipDPMBackup switch"}
Throw "No $volumetype paths found!"
}
#Ensure we have unique paths to query volumes for
$paths = @($paths | sort -Unique)
#build array of target volumes and paths
$Vols = @()
foreach ($p in $paths) {
$dpmmp = "" | Select Target, Path
#retrieve volume for path
$dpmmp.Target=(mountvol ("`"{0}`" /L" -f , $p.trimend("\").trim())).trimend("\").trim()
$dpmmp.Path=$p.trim()
$Vols += $dpmmp
}
return $Vols
}
$dss = @(Get-ProtectionGroup (&hostname) | foreach {Get-Datasource $_})
$dss += Get-Datasource (&hostname) -Inactive
$disks = Get-DPMDisk (&hostname)
$dpmvols = GetDpmMp "Replica"
$dpmdiffs = GetDpmMp "Diffarea"
$list=@()
foreach ($ds in $dss) {
$item = "" | select Datasource, NTdisks, Inactive, Replica, Diff
$item.Replica = ($dpmvols | ? {$_.path -match $ds.AssociatedReplica.PhysicalReplicaId}).Target
$item.Diff = ($dpmdiffs | ? {$_.path -match $ds.AssociatedReplica.PhysicalReplicaId}).Target
$item.Inactive = $ds.IsDiskInactive
$item.Datasource = "$($ds.DisplayPath) on $($ds.ProductionServername)"
$item.NTdisks = (($disks | ?{ ($_.PgMember | select DatasourceId) -match $ds.Id}) | foreach {$_.NtdiskId}) -join ","
$list += $item
}
return $list
#end script