DR process, step by step, on-going protection?

[lando_uk]

Hi

I'm just going through DR plans to make sure they are correct, ultimately leading to lab testing before getting signed off.

2 sites, active/active - 65/35% split in VMs/Storage
Site1 primary, vcenter 6.0 appliance, physical VBR server, replication jobs for Site2 to Site1, physical proxies/repositories
Site2, 2nd VBR VM for replicating Site1 VM's to Site2, physical proxies/repositories

So we lose Site1

Recovery procedure:
vCenter is replicated to Site2, so we use 2nd VBR instance to bring that online (and after that, the other VM's replicated from Site1)
For VM's that aren't replicated, we import all offsite folders in the 2nd VBR VM and start restoring.

Once all production VMs are running and everyone is happy, on-going protection is where I need some help.

The configuration DB from the original (toasted) VBR Site1 is stored on Site2 repositories.
I now need to backup the original Site2 VMs and also the newly restored Site1 VMs for on-going protection.

I want to use the existing good Site2 reps and just continue the backup chains and use the old jobs as I don't have enough storage (or backup window) to run a Full on everything.

Do I need a 3rd VBR cold server ready, so I can restore the configuration from the dead Site1 VBR server? I then setup new backup jobs for the newly restored Site1 VM's on this server?

I read lots of stuff on how easy it is to restore / replicated in the event of a disaster, but on-going protection/fail-back information is always very sketchy. I would love to see someone's actual DR plan with regards to using Veeam...

Thanks

[lando_uk]

EDIT: Can the Veeam replication engine actually change the IP address of a vcenter appliance 6.0 like it can with Windows VMs??

[PTide]

Hi,

I want to use the existing good Site2 reps and just continue the backup chains and use the old jobs as I don't have enough storage (or backup window) to run a Full on everything.

Why not to use backup mapping for that?

Do I need a 3rd VBR cold server ready, so I can restore the configuration from the dead Site1 VBR server? I then setup new backup jobs for the newly restored Site1 VM's on this server?

Basically you just want to switch VBR1 and VBR2 roles so VBR2 (Site2) becomes primary and VBR1 (Site1) becomes secondary, did I get it right? If so then you can restore Site1-VBR from the configuration DB backup, then edit/recreate job so the replication/backup continues in the reversed direction from Site2 to Site1. Is that what you need?

Thanks.

[lando_uk]

if I restored the config DB from dead VBR1 into rep-only VBR2, I would lose the replication jobs and have to fire up those rep-vm's manually from esxi?

When restoring the config DB, I'm presuming I can use a different server name/IP than the original and it'll still work fine?

Config DB restores seem very messy, (if)when the primary site comes back - if I've destroyed the Rep-only VBR2 by overwriting it with the VBR1 DB, I can no longer cleanly fail back using CBT - I basically have to scrap everything and re-seed/restore.

[PTide]

if I restored the config DB from dead VBR1 into rep-only VBR2, I would lose the replication jobs and have to fire up those rep-vm's manually from esxi?

I'm not sure that I follow you. You've mentioned that you lost Site1, is that correct? Please describe your scenario - is it 100% lost including ESXi host or just Veeam infrastructure? Sorry for confusion.

Can the Veeam replication engine actually change the IP address of a vcenter appliance 6.0 like it can with Windows VMs??

No, it can't do that out of the box, however you might want to check this topic.

Thanks

[foggy]

The configuration DB from the original (toasted) VBR Site1 is stored on Site2 repositories.
I now need to backup the original Site2 VMs and also the newly restored Site1 VMs for on-going protection.

I want to use the existing good Site2 reps and just continue the backup chains and use the old jobs as I don't have enough storage (or backup window) to run a Full on everything.

Do I need a 3rd VBR cold server ready, so I can restore the configuration from the dead Site1 VBR server? I then setup new backup jobs for the newly restored Site1 VM's on this server?

You can either use the third cold Veeam B&R instance or just create jobs on existing site 2's instance. Anyway, newly restored VMs have different IDs and need to be backed up from scratch even if you map the jobs to existing backups (in case of reverse incremental, they will get deduped though).

[lando_uk]

Hi

I'm guessing any DR plan should have various different scenarios. Decent DR plans require you to test failover and then fail-back - At the moment, my failover processes seems almost one way, especially if we have to import config DB's and have VBR instances that don't know about each other.

I guess without metro-cluster type infrastructure, stretched VLANS and storage that has synchronous replication built in, there's always going to be trouble designing a fool-proof and solid DR process.

[foggy]

At the moment, my failover processes seems almost one way, especially if we have to import config DB's and have VBR instances that don't know about each other.

Why do you think so? You have the target side Veeam B&R instance responsible for replication jobs, so you will be able failover and failback using it, once you lose the source side. After restoring the source site, you will be able to proceed with its Veeam B&R instance. There's some manual work on creating additional jobs and re-adding VMs to existing ones, but not a one way process.

[lando_uk]

Back to the issue of replicating and re-IP'ing vcenter appliance... I spoke to VMware and you cant actually change the IP/VLAN on the VCSA 6.0. So unless you have stretched VLANS, replicating VCSA to somewhere else isn't possible.

From the issue description,I understand that you are would like to change the ip address of the vcenter server appliance,correct me if I am wrong.
Please note that by design ,changing the IP address of the appliance is not supported as of now.
You could refer the below links to the kb articles which discusses the issues that you may encounter in case you change the IP address of the appliance:
https://kb.vmware.com/kb/2130599 > The vCenter Server or PSC services fails to start when the IP address or hostname is changed in vCenter Server or Platform Service Controller (PSC).
http://kb.vmware.com/kb/2124422 > Attempting to change the IP address of the VMware vCenter Server Appliance 6.0 fails with the error: IPv4 configuration for nic0 of this node cannot be edited post deployment
Therefore,in case you have to migrate the VCSA to use a different VLAN,I would recommend to do a fresh install of the appliance.

[PTide]

I think that in case you managed to change VCSA IP somehow, you'd have to regenerate SSL certificates. I assume that VCSA redeployment must be an easier thing to do.

Thanks

[lando_uk]

VCSA redeployment in the event of a DR is something I could do without, it would mean potential distributed vswitch issues. TBH, the SSL can use FQDN, there doesn't seem any technical reason why you cant change IP address - I think they just want people to buy more vcenters and use linked mode and vsphere replication for DR rather than Veeam replication/re-IP'ing.

Plan B is now to bring up identical VLANS at the DR site should the production site go up in flames so a vcenter restore/replication will work...