[FR] Mirroring backups between SOBR extents with automatic backup mapping

[d3nz]

Hello.
At one of our vSphere+vCD+VBR+VBEM installations we have 2 physical servers with connected by SAS to each of them his datastore with the same configuration.
We are searching for DR solution for this installation on repository layer like a mirroring backups from one extent (server 1) to another extent (server 2).
We need to realize this solution by Veeam software (ms replication or another third party solutions isn't allowed).
There is an idea to create File Copy Job from extent 1 to extent 2, but it's necessary to manually change hostnames of servers at DNS when extent 1 go down.
Now SOBR can balance by capacity his extents, and it should be much better if certain extents of SOBR can operate in mirroring mode and automatically mounting backup chains to jobs.

[HannesK]

Hello,

it should be much better if certain extents of SOBR can operate in mirroring mode

we have the backup copy job for that (in your case, both servers need to be a different repository instead of forming one SOBR). Well, or copy mode with capacity tier. I know, it's not perfect HA, but at least the data is mirrored.

Where is the backup server and enterprise manager installed? On the physical servers, or in VMs?

File copy jobs will probably not do what you need.

Best regards,
Hannes

[Gostev]

I'd say Backup Copy job in the Immediate Copy mode is quite perfect async mirroring. The next level of mirroring would be a storage-based metro-cluster, this would be as good as the mirroring gets

[d3nz]

The main requirement is continuing creating new backups and access to existing backups from Self-Service Backup Portal (VBEM) for our customers with vCD organizations when one of repository go down.
Backup Copy Job and Capacity Tier don't allow to continue backup chains, also Backup Copy Job backups are not accessible from SSBP/VBEM.

[d3nz]

Also don't forget my question about mapping backup chains to backup jobs. It's important.

[Gostev]

From these requirements it is starting to sound like you just need to deploy a redundant backup storage, as opposed to suggesting we should change our focus from building a backup product to a storage availability management product for standalone servers naturally, it would be a mistake to have our developers start addressing use cases around storage availability like transparent failovers between repositories, because already there is a whole bunch of existing solutions for highly available storage. For example:

1. Proven stuff like Windows Server failover clustering allows for creating continuously available general purpose file shares that leverage SMB3 transparent failover. One of the Veeam Vanguards (who is also a Microsoft MVP) played a lot with this a few years ago, and it's actually quite impressive.

2. Bleeding edge stuff like Storage Spaces Direct. This runs on general purpose servers and has fancy features like enclosure and rack awareness for guaranteed redundancy. It is also specifically designed to take advantage of ReFS, which also happens to be the recommended file system for Veeam repositories.

3. Linux of course has a number of storage availability solutions which are conceptually similar, in case you prefer the DYI approach to "pay Microsoft for a Windows license" one.

4. A more forward-looking approach would be to use an on-prem object storage solution on top of your two servers. These provide highly available S3 buckets spanning multiple standalone servers natively, and object storage is the future (at least from our perspective: we're making lots of investments around object storage).

5. And of course, if you did not already have two servers to work with, of course I'd just recommend an Enterprise-grade array with redundant controllers and power supplies... these can take a lot of beating and failures before you can no longer access your backups.

[d3nz]

High availability at Repository layer doesn't resolve problem of re-mapping backup chains to backup jobs. It's functionality of backup software then it should be good to improve functionality of Veeam software in this context.
For example, at software of one of your competitors there is functionality to change primary and secondary (backup copy\auxiliary) roles between storage policies, so when datastore of primary storage policy go down - it's just necessary to set primary role to second storage policy and backup chains will continue and will be available for tenants like a nothing happends.

[Gostev]

Well, we most definitely support re-mapping backup chains to backup jobs too, and from the very early days. If you are mirroring your backups to some other location with storage based replication, you can always update your backup job settings to point to backups on another node (using the map backup functionality) - and the job will continue on.

It's only if you're using Backup Copy job, then it may get tricky because chains are not guaranteed to be the same between primary backup job, and a backup copy job. Remember, Backup Copy does not simply copy backup files like storage-based replication - it works with restore points on a block level, and it creates new/different backup files chain on the target. This is because Backup Copy was designed with a totally different use case in mind: offsite backups, which often have different RPO (due to the limited bandwidth), encryption settings (due to data leaving the premises), etc.

Having said that, I believe that the Backup Copy job in the Immediate Copy mode, and with all settings identical to the primary backup job may provide a compatible backup chain for mapping a primary backup job to. @Dima P. could you please discuss with dev and QC folks if there are any underwater stones I don't see, and whether we can support this now or down the road - and let me know?

[d3nz]

Well, we most definitely support re-mapping backup chains to backup jobs too, and from the very early days. If you are mirroring your backups to some other location with storage based replication, you can always update your backup job settings to point to backups on another node (using the map backup functionality) - and the job will continue on.

If we have hundreds or thousands of backup jobs manually re-mapping is difficult. But main stopping factor - our vCD customers should see backups of his VMs and restore from it at Self-Service Backup Portal (VBEM).