using planned failover is a nice thing - I was using it many times for maintenance windows in the past, but it took a while to have those two replication passes gone by until the vm got started (which took some minutes in my case and so it wasn't a "clean" transition).
Now CDP failover itself has some offset in terms of replication due to the fact that you're not replication every millisecond, so you might loose a bit of data one you failover. That's why I was curious to see how the planned failover works and I did a small test. I saw the following (shortened):
- vm was shut down
- creating long-term restore point (+34 sec)
- starting replication (+20 sec)
- failing over (+20 sec)
WOOOOOW!!
So doing a planned failover here is done in a bit more than one minute (and this is for sure not the fastest hardware in the world) - that is fantastic! Very well done veeam, thanks very much, what a great product!
In my experience, the failback takes exponentially longer than failover, due to calculating fingerprints/digests. Most likely just a configuration error on my side though.
if your hardware is able to calculate the digests fast AND you're not having too much data, it should still be quite "fast". of course, not seconds, but maybe some minutes...
ralfl wrote: ↑Apr 29, 2024 5:58 am
Be aware of this, if you loose your Veeam Server Running CDP you have no possiblity to failover. Place the Server on DR Site.
The problem (for me) with placing the Veeam server on the DR side is licensing. We're using Veeam Rental licensing which means that, for the purposes of replication, as long as the VM is getting backed up by that VBR, it doesn't consume an additional license when it gets replicated. However, if we place a VBR server in DR and use that to perform the replication, it's not backing up the VMs (that's the VBR on the Prod side), so it will charge us for additional replication licensing. We're still at the early stages of using Veeam for replication (we were using VMware Availability, until Broadcom got involved), but we think the solution will be to have a second "cold" VBR in DR with the Config Backup getting sent there.
Sorry David, I don't get that. If you're having a VBR-server, no matter where it "sits", it consumes the same amount of licenses. If your production goes down, you will bite yourself to not have the vbr on the DR site. For instance, CDP-vms can't be started without VBR-servers actions.
So you'd have to move your VBR-server to the DR and everything else could stay as it was: Proxies, Storages, etc. VBR would still connect to the same vcenter/hosts and would do its job as before. You "just" have to be careful with e.g. FLR, where (if I recall correctly) it would mount your backup to the machine with the explorer open and if you have a bad link between the two sites, that could be painful. But I assume there is a good link as you'd have to do replication and such stuff...
mcz, that's not the case with rental licenses. If I have a VBR licensed for 1100 instances, I am licensed for 100 VMs. If I use that VBR to back up 100 VMs (which will consume all of the instances), I can use that VBR to also replicate those 100 VMs without using additional instances. However, if I use a different VBR to replicate those VMs, I will end up consuming 1100 instances on BOTH servers.
Moving the entire VBR to the DR side is an interesting thought. Right now, it's the Mount server for all of the Linux repos so I'd need to repoint those. Other than that, though, it's like you say - everything would stay the same (I think).
Right now, there is only one VBR, which lives on the Prod side. But even if I had the second VBR and managed it with the same EM, I don't think that would change things.
RubinCompServ wrote: ↑May 13, 2024 3:17 pm
However, if I use a different VBR to replicate those VMs, I will end up consuming 1100 instances on BOTH servers.
Moving the entire VBR to the DR side is an interesting thought. Right now, it's the Mount server for all of the Linux repos so I'd need to repoint those. Other than that, though, it's like you say - everything would stay the same (I think).
That's the idea here. Move the VBR itself to the DR site, don't duplicate it just to handle replication.
The other way would be to have regular configuration backups sent to the DR location so you can restore from that config, but running the VBR in the DR would be easier.
RubinCompServ wrote: ↑May 13, 2024 3:59 pm
Right now, there is only one VBR, which lives on the Prod side. But even if I had the second VBR and managed it with the same EM, I don't think that would change things.
When you connect both backup server to the same Enterprise Manager, the same VM (backup job on 1st VBR, replica job on 2nd VBR) should only consume the rental license once. If not, then it should be investigated by our support team.
RubinCompServ wrote: ↑May 13, 2024 3:17 pm
Moving the entire VBR to the DR side is an interesting thought. Right now, it's the Mount server for all of the Linux repos so I'd need to repoint those. Other than that, though, it's like you say - everything would stay the same (I think).
If you move your VBR to the DR site and if that causes some significant performance penalties due to the network between those two sites, you could still deploy a new (linux) proxy on the production site so that this one acts as the mount-server for your linux repos. That should cover most of the usecases...
Mildur wrote: ↑May 14, 2024 7:27 am
When you connect both backup server to the same Enterprise Manager, the same VM (backup job on 1st VBR, replica job on 2nd VBR) should only consume the rental license once. If not, then it should be investigated by our support team.
Best,
Fabian
Great solution here if there is a concern about re-working the Veeam deployment to handle a DR based VBR. Spin up EM, have it handle the licensing and connect your on-premises and DR site VBRs. Have the on-premises VBR handle backup/backup copy jobs and have the DR VBR handle replication. Easy and quick.
