Building on some of my previous blogs on Veeam cloud backup, I’d now like to provide an overview of Veeam DRaaS. Increasing cybersecurity threats from hackers, viruses and ransomware are prompting many IT teams to move beyond cloud backup to a cloud-based disaster recovery strategy.
DRaaS with Veeam allows customers to use their existing Veeam infrastructure to replicate servers offsite to the iland Veeam Cloud Connect service. The only change to the customer’s Veeam infrastructure will be to add iland as a VCC Service Provider. Once that is complete, customers will be able to replicate and failover their servers in the iland Secure Cloud.
The Basics of Veeam DRaaS Replication
DRaaS with Veeam replicates to the iland Cloud Connect infrastructure in the same manner as Veeam Cloud Connect Backups. After adding iland as a Service Provider, you will have access to your Veeam Hardware Plan created by iland. When creating a replica job, you can now select to choose a Cloud Host for the replica destination and you will select the Hardware Plan. This Hardware Plan is the resource pool your servers will replicate to containing your CPU, RAM and storage limits as well as the failover networks. After replicating servers, the replicas appear in your Veeam console and are ready to be tested or used for a failover. Replicas can be failed over individually but you also can create Veeam Failover Plans. The failover plan is a useful tool for controlling how a failover works for your servers. You are able to set a boot order between the servers in the failover plan as well as set up NAT rules to allow public access to your servers.
Veeam has also simplified the ability to conduct partial failovers, if the situation ever arises. For instance, if you come into work one day and find that your exchange or webserver has become corrupted or infected by malware, you can failover just this one server. In this case, Veeam creates a pseudo Layer 2 point-to-point connection between the replica and your source environment. Typically, partially failing over an environment comes with extra difficulties in allowing communication between the production and failed over servers. This is because the two sites will have the same IP subnet, for instance 192.168.10.0/24, causing a conflict in routing. However, Veeam uses a Network Extension Appliance (NEA) that allows this connection, as if it is stretching he same network across the production environment to the failover environment. This allows for quick recovery times with minimal changes required to bring a failed server back into production.
RPO and RTO Considerations with Veeam DRaaS
Veeam uses image based replication with the help of hypervisor level snapshots. This means that, during a replica or backup, Veeam uses VMware to Hyper-V to create a snapshot of the server. Veeam replicates the server at this point in time to the cloud replica server to create a restore point. This process can be scheduled automatically creating restore points daily at a specific time or run every couple of hours. This image based replication means that you will only be able to failover to those specific points in time when the restore point was created. Let’s say you replicate daily at 8:00 p.m. Tuesday around lunch time, your exchange server then becomes invalid or a user accidentally deleted all files on a file server. At this point, your latest point in time to failover to is Monday at 8:00 p.m. So, any data that was created after 8:00 p.m. Monday would not be available on the replica server. This is important to consider as you may have particular RPO (Recovery Point Objective) goals or requirements. It is possible to run replication several times throughout the day and hold weeks’ worth of retention, but you need to consider the space that would be used to hold the snapshots.
When Veeam replicates a server to the iland cloud, the replica server is built and remains powered off. This is helpful because during a failover, there are no tasks or changes needed to present the server to our environment. Failovers essentially only need to revert to a snapshot or restore point and then power on. Therefore, the actual time for a server to failover is mostly dependent on how fast the operating system is able to power on, and if there are any boot delays set for this server. This helps provide very low RTO (Recovery Time Objective) possibilities.
Veeam DRaaS Failover Access Considerations
Failing over your servers and having the replicas power on is just the first step when recovering from a failover. You must also ensure that you, your end users and customers all have the ability to access the servers, applications or websites as they normally would in your production environment. The Veeam NEA is a basic router/firewall that can be configured through your failover plan to allow public access to particular servers. You could allow RDP to a terminal server, HTTP and HTTPS to a web server, etc. However, the NEA is not able to set up IPsec or SSL VPN access to the replica servers. In many cases, more network control is needed and, in these cases, we can utilize a third-party firewall. This can be done with a customer provided virtual firewall or an iland provided Cisco ASAv. With a third-party virtual firewall, the networking can be configured similarly to how it is utilized in production. You would be allocated a public IP block to create your own NAT/firewall rules, IPsec or SSL VPN access and more.
At this point in time, you will not have management access to your replica servers at a hypervisor level– meaning you will not have the ability to access the replicas through a console or be able to power the server on and off. iland developers and Veeam are working on this integration into vCloud Director in the near future, but for now you will need to contact iland Support for any changes to replica servers. This means it is important to test your failover plans or capabilities to ensure access is functioning as expected through the Veeam NEA or a third-party firewall.
Stay tuned for further detail on the above considerations and more in upcoming blog posts. In the next post, we will walk through how to connect to a VCC Service Provider.