Skip to main content
SnapManager for Hyper-V

Recover and restore from a disaster recovery failover

Contributors

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.

About this task

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.

Steps
  1. 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.

  2. 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.

  3. 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.

  4. 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.

    Note This is typical when using the System Center Virtual Machine Manager (SCVMM) Console and Data ONTAP SMI-S Agent.
  5. Add the secondary storage system or cluster in the SnapManager for Hyper-V MMC, and then configure it with the SnapInfo path.

  6. Enter the following cmdlets:

    1. Enter Get-VMsFromBackup to retrieve the list of VMs present in the backup metadata.

    2. Enter Get-Backup to get the backup copies for each VM.

  7. 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.

  8. If the secondary host system is a cluster, complete the following steps:

    1. Ensure that the LUNs on which the VMs reside are online on the cluster node that owns the cluster group.

    2. 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