Disaster Recovery of SnapCenter Server with IP Address Change

Assuming your SnapCenter server is replicated to a DR site, then recovery of SnapCenter including an IP change is very straightforward! (Even more straightforward if you have stretched VLAN and don’t need to re-ip.)

The SnapCenter IP address is not hardcoded anywhere, so once you’ve done the below, everything should just work!
- brought up the replicated SnapCenter in the DR site (not in this blog post)
- re-IP-ed SnapCenter
- updated DNS (make sure all the plugin hosts resolve SnapCenter to the correct IP)
- rebooted the SnapCenter server after re-IP

You would need to check your backups jobs are not trying to backup servers that aren’t available (because of the DR situation). We’d only need to recover from repository backup if there was something wrong with the database.

In the walkthrough below, we run through the steps and show DR of SnapCenter with IP change is nothing to be afraid of. We backup the repository as it is best practice to do so, but don’t use the repository backup (something I’ll blog about later.)

Note: SnapCenter version here is 4.1.

i: A little bit of setup:

Creating the SnapCenter repository backup LUN:


volume create -vserver svm1 -volume SC_REPO_BKUP -size 10G -space-guarantee none -aggregate aggr1_cluster1_01

lun create -vserver svm1 -volume SC_REPO_BKUP -lun LUN101 -size 50G -ostype windows_2008 -space-reserve disabled -space-allocation enabled

igroup create -vserver svm1 -igroup snapctr -protocol iscsi -ostype windows -initiator iqn.1991-05.com.microsoft:snapctr.demo.corp.com

lun map -vserver svm1 -volume SC_REPO_BKUP -lun LUN101 -igroup snapctr -lun-id 101

ii: Replicating the SnapCenter repository backup LUN:


volume create -vserver svm2 -volume SC_REPO_BKUP_DR -size 10G -type DP -aggregate aggr1_cluster2_01

snapmirror create -source-path svm1:SC_REPO_BKUP -destination-path svm2:SC_REPO_BKUP_DR -type XDP -policy MirrorAllSnapshots -schedule hourly

snapmirror initialize -destination-path svm2:SC_REPO_BKUP_DR

iii: Configuring SnapCenter Repository Backup:

PS> Open-SmConnection -SMSbaseURL https://snapctr.demo.corp.com:8146

PS> Add-SmHost -HostName snapctr.demo.corp.com -OSType Windows -DiscoverPlugins -RunAsName SCAdmin

PS> Get-SmResources -HostName snapctr.demo.netapp.com -PlugInCode SCW

Completed Discovering Resouces: Job Id [193]

HostResource: R:\
StorageSystemResource: svm1:/vol/SC_REPO_BKUP/LUN101

PS> Protect-SmRepository -HostName snapctr.demo.corp.com -Path R:\BACKUP -RetentionCount 24 -Schedule @{"ScheduleType"="hourly";"StartTime"="7/26/2019 8:33 AM"}

Successfully protected the SnapCenter respository.

0: Proof we have hosts with good status:

Image: SnapCenter host and DAG hosts with green statuses

1: Shut down SnapCenter services prior to Re-IP:

net stop SnapManagerCoreService

net stop MySQL57

2: Get the IP, change it (here we change from to .175) and update DNS as required:

PS> (Get-NetIPAddress | Where-Object {$_.AddressFamily -eq "IPv4"}) | FT IPAddress,InterfaceAlias,InterfaceIndex -AutoSize

IPAddress    InterfaceAlias   InterfaceIndex
---------    --------------   -------------- DEMO             12

PS> New-NetIPAddress -InterfaceIndex 12 -IPAddress -PrefixLength 24

PS> Remove-NetIPAddress -InterfaceIndex 12 -IPAddress -PrefixLength 24

3: Restart SnapCenter server after re-IP

4: Verify that SnapCenter Plug-In Hosts DNS has updated:

Pinging snapctr.demo.corp.com [] with 32 bytes of data:

Reply from bytes=32 time<1ms ttl="128<o:p">

5: Verify SnapCenter Plug-In hosts connectivity is good, and verify that backup jobs are running as expected (except can’t backup hosts caught up in the DR situation)

APPENDIX: SnapCenter Config Files

The IP Address is not hardcoded into any of the below.

C:\Program Files\NetApp\SMCore

C:\Program Files\NetApp\SnapCenter\SnapCenter Plug-in for Microsoft Exchange Server

C:\Program Files\NetApp\SnapCenter\SnapCenter Plug-in for Microsoft Windows

C:\Program Files\NetApp\SnapCenter WebApp