"Remove replica from disk" needs a safety option

[robg]

I learned the hard way that if you do this, it forcibly powers a VM off and then deletes it. It should not power off the VM, but instead warn you that it is running and abort.

Before anyone replies about failover, I'm aware of it, but still prefer to do this manually. In this case however, I was relying on the column that said "replica location." As it turns out, that was faulty information and it powered off and removed a VM from a different host than where the replica actually resided. I still had other copies of this VM to fall back on, but was a little surprised at how unusually destructive Veeam is behaving with remove replica from disk.

This environment is version 9, I'm not sure if this still an issue in modern versions.

[Mildur]

Hi Rob

Thanks for the request.
First let me say, version 9 has already reached end of support state. Veeam 9.5 was supported until February 2021.
If we would introduce such feature, then it will come in a newer version. V13 or later.

Before anyone replies about failover, I'm aware of it, but still prefer to do this manually.

As you already may know, it is recommended to use the console to power on Veeam replicas. If you doing it the recommended way, the Replica cannot be "removed from disk" by the console until you do a Failback operation. The option to "remove from disk" is greyed out. Doing it manually comes with a few disadvantages like not being able to do a failback without a new replica job. Or in your case, VBR not knowing which VM running on it's replica state.
Can you elaborate, why you prefer to do it manually? Are there any missing features if using the console we are not aware off? What would we need to change, that you use the console to failover the VM?

Thanks
Fabian

[robg]

Yes, the reason I prefer to do it manually is that it's not possible to backup or replicate the VM when it's in a failed over state. Although the last time I tried this feature was in 2014, maybe it is possible now.

There are situations when I would not be sure that I want to commit to a permanent failover or failback yet, such as not being sure if the problematic host is fixable, and of course during that time the business must go on. So in that scenario I would just point the existing backup job to the replica, or start replication to a 3rd host.

[Mildur]

Hi Rob

Thank you.
Understood. That makes sense to have a backup of the active replica to comply with your RPO requirements.

I just run a test in my lab with the latest V11a build.
- Backup of an active Replica works (with a new Backup Chain, because it's a new VM)
- Replication of an active Replica works

There is one limitation with CBT. If you decide to backup the replicated VM before you have done the failover, CBT data on the replica VM will be overwritten each time the replication job is running. When now the backup job starts to backup the powered down replica vm, the job will run with a warning that CBT data is not valid. So you can't use CBT while the VM is replicated.
But you can use CBT for a temporary backup job while the VM is in a failed over state.

Thanks
Fabian