Recover and restore from a disaster recovery failover
To recover from a disaster, SnapManager for Hyper-V must first fail over to a secondary storage system. Failing over involves a series of manual steps in PowerShell.
Most backups can be restored to an alternate host for both NAS and SAN; however, Windows Server 2008 R2 crash-consistent backups cannot be restored to an alternate host.
-
If you are running Data ONTAP 8.1.x, on the secondary site, enter the storage virtual machine (SVM) information to the Transport Protocol Setting (TPS) in the SnapDrive for Windows MMC.
-
From the secondary storage system, connect to all of the LUNs.
If the secondary storage system is clustered, go to the node where the cluster group, which is the available storage group owner node in the destination cluster, is online and then connect to all of the LUNs from that node in the cluster. Refer to the SnapDrive for Windows documentation for information about mapping LUNs.
-
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 of the mount points and LUNs of the same type on the primary storage system.
A clustered host (SAN)
From the node where the cluster group is online, connect to all of 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. From the node where the cluster group is online, connect to all of 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 access control list on the share.
This is typical when using the System Center Virtual Machine Manager (SCVMM) Console and Data ONTAP SMI-S Agent. -
Add the secondary storage system or cluster in the SnapManager for Hyper-V MMC, and then configure it with the SnapInfo path.
-
Enter the following cmdlets:
-
Enter
Get-VMsFromBackup
to retrieve the list of VMs present in the backup metadata. -
Enter
Get-Backup
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
Restore-Backup -Server -VirtualMachinePath -SnapShotFilePath @VHD
For
@VHD
, a VM might have multiple VHDs; make sure that you 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.
-
Failover 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 hv-19-cluster 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 hv-19-cluster -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 hv-19-cluster -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