Reconfigure storage systems after a disaster recovery failback
After failing over to a secondary storage system, SnapManager for Hyper-V completes disaster recovery by failing back to the original primary storage system. Failing back restores primary storage function to the original primary storage site after its storage systems are reenabled or replaced.
-
Depending on the condition of the primary storage system, take one of the following actions:
If the primary storage system is… Then… Recoverable
Move the data from the secondary host back to the primary storage system.
Completely destroyed
Provision a new storage system.
-
Manage the SnapMirror relationship:
-
Initialize the SnapMirror relationship from the secondary storage system to the primary storage system to recover the data.
-
Resynchronize the existing SnapMirror relationship from the secondary storage system to the primary storage system.
-
Using SnapDrive on the secondary storage system, initiate a SnapMirror update for each of the LUNs or SMB shares on the secondary storage system.
-
-
Depending on your configuration, take one of the following actions:
If the primary storage system is… Then… A stand-alone host (SAN)
Connect to all the mount points and LUNs on the primary storage system of the same type.
A clustered host (SAN)
From the node where the cluster group is online, connect to all the mount points and LUNs in the cluster.
Data ONTAP 8.1.x configured with a single LUN hosting VMs on a source FlexVol volume (SAN)
For SnapMirror updates to succeed, you must create a second, smaller LUN (10 MB to 100 MB) on the source FlexVol volume before initiating a backup job. From the node where the cluster group is online, connect to all the mount points and LUNs in the cluster.
A stand-alone or clustered host (NAS)
Unmount the Data Protection (DP) volume, mount the DP volume as rewriteable, verify that the volume has RWX permissions, and then create CIFS shares for the different volumes.
-
Reconfigure SnapInfo based on your environment:
If your configuration is… Then… SAN
Restore the SnapInfo LUN from its last Snapshot copy.
NAS
Mount the SnapInfo directory.
For NAS, if an access is denied error occurs, or if you cannot browse to the exposed SMB share location, you might need to reset the ACL on the share.
-
Add the primary host or cluster in SnapManager for Hyper-V MMC and configure it with the SnapInfo path.
-
Enter the following cmdlets:
-
Retrieve the list of VMs present in the backup metadata by using the Get-VMsFromBackup cmdlet.
-
Get the backup copies for each VM by using the Get-Backup cmdlet to get the backup copies for each VM.
-
-
To restore, use
Restore-Backup
with the VM GUID and the backup copy with the following parameters:To restore from… Enter this command… An alternate host
Restore-Backup -Server
Secondary_host_system_or_cluster_name -DisableVerifySnapshot -RestoreToAlternateHost
A listed backup copy
Restore-Backup -Server -VirtualMachinePath -SnapShotFilePath @VHD
For
@VHD
, a VM might have multiple VHDs; you must enter both a source and a destination path pair specified for each VHD. -
If the secondary host system is a cluster, complete the following steps:
-
Ensure that the LUNs on which the VMs reside are online on the cluster node that owns the cluster group.
-
Use the failover PowerShell cmdlets to make the VMs highly available.
For NAS, after the VMs are exposed as SMB shares from one cluster node, the VMs are accessible to all hosts configured to use the storage system cluster.
-
Failback examples
The following example shows a two-cluster setup in which smhv-cluster-01 is the primary site and hv-19-cluster is the secondary site:
PS C:\> Get-VMsFromBackup -Server smhv-cluster-01 winxp-x64c-135 593ABA72-B323-4AF7-9AC6-9514F64C0178 csv1-xp-3 59B85C68-BAFA-4A49-8E85-A201045843F7 vm-w2k8r2sp1 5A248757-872B-4FE7-8282-91C8E9D45CF9 um10_11_dr 5AC1B2A8-6603-4F90-98F5-4F2F435AB0C2 winxp-x64c-30 5B47D3CF-5D96-495D-9BAB-FB394392CF31 winxp-x64c-126 5B57EED1-B4F1-45A3-A649-24C6947CB79C winxp-x64c-118 5B5D417B-70DC-427C-94BB-97FF81C5B92B winxp-x64c-122 5BEE26B8-BE57-4879-A28E-9250A6A5EEFC csv4-w2k3-19 5D0613E5-B193-4293-8AAD-F8B94A5D851F PS C:\> Get-Backup -Server smhv-cluster-01 -ResourceName um10_11_dr BackupName : smhv-ccb-ds_04-10-2012_10.37.58 RetentionType : hourly DatasetName : smhv-ccb-ds BackupId : smhv-ccb-ds_04-10-2012_10.37.58 BackupTime : 4/10/2012 10:37:58 AM BackupType : Application consistent BackedupVMs : {um10_11_dr} PS C:\> Restore-Backup -Server smhv-cluster-01 -ResourceName um10_11_dr -BackupName smhv-ccb-ds_04-10-2012_10.37.58 -DisableVerifySnapshot -RestoreToAlternateHost
The following example shows a SAN restore operation to an alternate path for which N:\ is the destination and I:\ is the source LUN path:
PS C:\> Restore-Backup -Resourcename dr-san-ded1 -RestoreToAlternateHost -DisableVerifySnapshot -BackupName san_dr_09-11-2013_10.57.31 -Verbose -VirtualMachinePath "N:\dr-san-ded1" -SnapshotFilePath "N:\dr-san-ded1" -VHDs @(@{"SourceFilePath" = "I:\dr-san-ded1\Virtual Hard Disks\dr-san-ded1.vhdx"; "DestinationFilePath" = "N:\dr-san-ded1\Virtual Hard Disks\dr-san-ded1"})
The following example shows a NAS restore operation to an alternate path for which \\172.17.162.174\ is the source SMB share path and \\172.17.175.82\ is the destination SMB share path:
PS C:\> Restore-Backup -Resourcename vm_claba87_cifs1 -RestoreToAlternateHost -DisableVerifySnapshot -BackupName ag-DR_09-09-2013_16.59.16 -Verbose -VirtualMachinePath "\\172.17.175.82\vol_new_dest_share\ag-vm1" -SnapshotFilePath "\\172.17.175.82\vol_new_dest_share\ag-vm1" -VHDs @(@{"SourceFilePath" = "\\172.17.162.174\vol_test_src_share\ag-vm1\Virtual Hard Disks\ag-vm1.vhdx"; "DestinationFilePath" = "\\172.17.175.82\vol_new_dest_share\ag-vm1\Virtual Hard Disks\ag-vm1.vhdx"})
Related information