Posted on

Veeam Backup & Replication – Part 2 – Recovery From Failover

Reading Time: 9 minutes

In my previous post (Veeam Backup & Replication – Part 1 – Building Replication Capabilities), we discussed offsite replication jobs using Veeam Backup & Replication v10. As per the Customer’s use case, we created a replication job to ensure a business-critical VM is replicated to a secondary site (Site B) in readiness for any unforeseen failures, planned maintenance, or downtime at the primary site (Site A).

This article discusses the failover and failback options available to us utilising Veeam Backup & Replication and, more importantly, when and where they should be used. We will then demo the failover process of our protected business-critical VM from Site A to Site B, and close by failing back live operations from Site B to Site A.

Continue reading → Veeam Backup & Replication – Part 2 – Recovery From Failover

Posted on

Veeam Backup & Replication – Part 1 – Building Replication Capabilities

Reading Time: 7 minutes

Just like the time I witnessed my first ever vMotion, seeing Veeam replication in the wild had a similar effect. As its name suggests, Veeam Backup & Replication is about more than just backups and offers customers rather neat replication functionality.

This article discusses Veeam Backup & Replication v10 offsite replication jobs. We also protect a business-critical virtual machine by replicating it to a secondary site. In Part 2 (Veeam Backup & Replication – Part 2 – Recovery From Failover), we will migrate the VM’s live operations to the secondary site before reviewing the available failback options.

Continue reading → Veeam Backup & Replication – Part 1 – Building Replication Capabilities

Posted on

VMware NSX-T Manager FQDN Registration

Reading Time: 3 minutes

By default, NSX-T transport nodes access NSX-T Manager nodes via their IP address, however, changing this behaviour so that the NSX-T Manager FQDN is used instead can be implemented easily via REST API call.

FQDN registration is an NSX-T Multisite requirement. As such, FQDN registration is not required for single-site deployments.

In the scenario whereby a customer needs to failover NSX-T operations to a secondary site (by deploying a new NSX-T Manager and restoring from backup), the NSX-T Manager(s) and Cluster VIP address will likely change unless they have implemented stretched-L2. As such, the NSX-T Manager(s)/Cluster FQDN needs to be registered with all NSX-T transport nodes, and once a new NSX-T Manager is deployed to the secondary site and restored from backup, DNS can be amended to point at the new NSX-T Manager(s)/Cluster FQDN, and management operations restored.

Continue reading → VMware NSX-T Manager FQDN Registration