Fault tolerent Veeam BR & SQL Server

[Hirosh]

Hi guys,


im considering using Fault tolerence for my Veeam Backup & replication server(VM) and its External SQL Server(VM) in Vmware to another Site. if for a reason we face a disaster (would the live shadow instance of the VM operates as our new Veeam VBR without any issue? i would appreciate ,if anyone who had implemented this could share their insights as well.


regards,
Hirosh.

[HannesK]

Hello,
technically it works, I just rarely ever see anyone doing it.

For SQL, there are AlwaysON availability groups. For the backup server itself, one could do it. But 8 vCPUs still seem to be the maximum on VMware side. I don't know how many machines you have, but that can be a limit.

In general, I would try to keep the configuration database local to avoid dependency & latency challenges.

Best regards,
Hannes

[Sturniolo]

As HannesK mentioned, It can technically work... but you run into vCPUs depending on your licensing model for vSphere:

vSphere Standard and Enterprise. Allows up to 2 vCPUs
vSphere Enterprise Plus. Allows up to 8 vCPUs

not to mention potential performance related issues.

There are several alternatives to having VBR in a more HA state. Like running VBR from the DR location, or Configuring the configuration backups to a repo that would allow it to be imported into another VBR installation...

Maybe take a look at our Best Practices guide, Its a great "from the field" resource, that really lays out things when it comes to designing and building out VBR.

https://bp.veeam.com/vbr

Hope this helps!

[Hirosh]

Hi Guys,

Thanks for your feedbacks, we can definately go for AlwaysON availability groups but since we configured teh SQL server as standalone, moving to AAG requires us to purchase licenses, which can costy. thats why we are considering FT at Vmware Level.We are using vsphere Enterprise plus.

regards,
Hirosh.

[Sturniolo]

Hi Hirosh,

If you can give me a little more background on the number of VMs you are trying to protect, backup infrastructure, etc.. might be able to give you a better idea of how to proceed.

[Hirosh]

H Sturniolo,

we are backing up around 600 Vms, in one of our location, we have multiple locations.
we have 2 datacenters per location, 1 Apollo Server + 1 Storeonce in each DC. The Apollo servers are configured as SOBR.
we are using MSL tape libraries for tape backup at each location. we are using Enterprise backup Manager to Manage all locations.

[Sturniolo]

So are you looking to FT VBR in a way that has one VBR server at one location.. then a failover at another location?

[Hirosh]

that is true, also i would like to utilize the FT capability for my external SQL as well.

[Sturniolo]

Keep in mind when it comes to FT...

vSphere FT will not protect against any in-guest issues (OS crash, SQL Server database/service corruption, etc.), FT can speed up a recovery from a hardware failure of an ESXi host compared to native vSphere HA.

[Zew]

I thought the best way to have/use multiple VBR servers in different sites, was to use Veeam Orchestrator?
I don't use it, and my FT is based on previous mentioned comments, just run a secondary Veeam server at secondary site, and import your backup copy sets into it in the event of a recovery operation requirement.

[Sturniolo]

Veeam Recovery Orchestrator is to automate the testing and recovery of workloads. But yes, @Zew You can run a 2nd VBR server at a DR site and import your backup configuration database in the event of a disaster.

[Zew]

Really? i thought Orchestrator allowed failover plans between two different Veeam servers (again across sites).
As for Testing of backup set I thought that was done using Veeam Sure Backup and then use Veeam One to get accurate reports on the results of these tests as well as to organize all the other logs (Back up jobs run, number of successes, number of failures, size of repos, etc)

[Sturniolo]

Hey @Zew

Orchestrator leverages the recovery capabilities of Veeam Backup & Replication to build disaster recovery workflows, automate recovery processes and eliminate error-prone manual steps. Orchestrator also provides reporting capabilities that let enterprises document their disaster recovery plans to meet compliance requirements. With Orchestrator, you can do the following:

Orchestrate recovery — create workflows to orchestrate recovery operations for both virtual and physical machines to VMware vSphere and Microsoft Azure cloud environments.
Automate checks and tests — schedule checks and tests to automate the verification of recovery plans, with features such as isolated test labs and comprehensive readiness checks.
Meet compliance requirements — view RPO and RTO achievements on the dashboard and generate automatically updated reports for recovery plan checks, tests and executions, ensuring that requirements for compliance and audit are met.

NOTE: Veeam Recovery Orchestrator is built on top of Veeam Backup & Replication and Veeam ONE, and requires both of these solutions in the environment.

[Zew]

Thanks for the more clear explanation of the products and their integrations/use cases.

[Hirosh]

Keep in mind when it comes to FT...

vSphere FT will not protect against any in-guest issues (OS crash, SQL Server database/service corruption, etc.), FT can speed up a recovery from a hardware failure of an ESXi host compared to native vSphere HA.

if the OS crashes and the VM becomes unresponsive the FT switches to shadow copy.for other in-guest issues we simply need to shutdown The VM, then the shadow instance takes over. as far as i know the FT is HA solution not only at the Host level but also att VM Level, meaning failures at VM level trigger FT. so what would be your recommendation , beside simply have anothe VBR on another location & importing configuration database?

[Sturniolo]

So here is a link to VMW documentation that talks about FT. In short it will immediately failover a VM if the host the primary VM becomes available. This doesn’t cover applications or OS crashes.

https://docs.vmware.com/en/VMware-vSphe ... 2ED21.html


Switching gears back to VBR… my recommendation would be to place your VBR server at your DR location. And then place your proxies/repos accordingly throughout your environment. In the event your VBR server goes down you can always import your configuration to a new VBR server and your up and running. With your VBR server living in your DR location, this helps with eliminating a step when it comes to a disaster, because VBR wasn’t affected.(lives in DR) A great resource is our Best Practice Guide.

https://bp.veeam.com/vbr

You can also reach out to your local Veeam sales team for any assistance with your particular environment. Sometimes it hard to scope something out from the internet.