Replication Source Bug?

[Zew]

can someone explain this to me?

I create a replication job, point to primary production VM, in job select source from backup repo. Run Job, Success, See VM in VM cluster, and see a Replica under the Veeam Home Replicas.

Now I run the VM manually, play around, it now has some changed data from the initial job. Shutdown the VM, run the Replication Job, end with Warning no new replication points. True and fair enough, but Why doesn't it revert to the last snapshot to actually bring the VM back to where it was? I could understand that cause I did something on the backend without it's knowledge, but wouldn't reverting to last snapshot be a failsafe either way?

Next, and this is what really irks me. If I delete all snapshots, and run the job it has to do calculation to determine the changed blocks, I get that, no big deal (though it is slow) so instead, I delete the VM entirely, If I rerun the job it still presumes there's a VM and job ends with a warning "no new restore points" Again, ok I did something on the backend, but one would kind of expect there to be some checks at this point from Veeam to the cluster to see if the VM is even still there instead of assuming. But fair enough, ok and the real irk beings. I now go to the known repcas in veeam Home Replicas, click the VM in question and select "Remove from Configuration", at this point I assume it removes what it thinks it knows about the replica VM and you can just start the replication job over again, but what you find is the replication job says 0 VM's... WHY?! Why do I have to re-add the source VM to the replication job... why is removing the known REPLICA from the Veeam replicas area remove the SOURCE VM from the replication job? This is really annoying.

[soncscy]

>Now I run the VM manually, play around, it now has some changed data from the initial job. Shutdown the VM, run the Replication Job, end with Warning no new replication points. True and fair enough, but Why doesn't it revert to the last snapshot to actually bring the VM back to where it was?

Heya Aemilianus,

The part above confuses me as I'm not clear which VM you actually powered on -- the production or the replica. Can you clarify this for us?

Regardless, I think that in general reverting snapshots without user authorization is generally a bad idea. The snapshot hunter __consolidates__ snapshots, which isn't so bad but it also has its own issues which are tangential, but I'm of the mindset that the software shouldn't touch what I manually do outside of it. But maybe I understand wrong on what you're meaning here, and you can clarify for us.

As for the last part, I can harbor a guess because I've played a lot with veeam's .net code with powershell, but maybe it's because remove from configuration breaks the replica association and you end up removing the pairing. My understanding is that replica jobs basically are an association between two objects, a source VM item and a replica item, and when you remove replica from configuration, you likely did so with some intention; imagine the alternative where you really did mean to completely remove a replica and not use it again, the job maintains the relationship, and then you wake up to tons of messages about the bandwidth being saturated because you're unexpectedly replicating the replica you meant to remove.

This second part is just my understanding, so I think it bears confirmation, but if I understand what a "replica" object is in veeam correctly, then I think the above is the right behavior.

[PetrM]

Hello,

but wouldn't reverting to last snapshot be a failsafe either way?

In this case actual data will be lost, therefore we cannot trigger revert without user's consent. Anyway, we don't recommend to power on replicas manually as this may impact replication job or even cause loss of important data. If you'd like to test replicas, you can perform Failover and Undo Failover, all changes made to the replica will be discarded. One more option is to take advantage of SureReplica job to validate the replicated workloads.

would kind of expect there to be some checks at this point from Veeam to the cluster to see if the VM is even still there

If I'm not mistaken but "no new restore points" message simply occurs earlier than VM availability check is performed.

why do I have to re-add the source VM to the replication job...

Let me clarify this point with my colleagues but it seems that Harvey's version about strict relationship between the source and replicated VM does really make sense.

Thanks!

[Zew]

Hey Harvey, The Replica is mucked with, and I know those things I do this on my own accord cause it works better for my needs. I can see what you're gettin at, but in my case, I just want Veeam to forget that there's a replcia VM, cause one no longer exists, then the next time the job runs create a new replica, it's like when you create the job for the first time, it's not like the replica VM exists in the replicas area, cause it doesn't exist. This is the state I'm trying to bring the job back to without having to re-add the source VM.

Hey Petry, Thanks for that, honestly I know about those other ways (RE:Failover, Failback), they were simply questions on design. For my perspective, Veeam would always restore the VM to the state as expected within the job, if it was mucked outside Veeam knowing, it would self heal. I understand where you are coming from in terms of loss of data, however loss of data is what you see in many applications that utilize something like a database, and your manually configuration or setting get over-written by the app. If you do unsupported things you should get slapped, but it's nice to know Veeam is designed not to do that, so fair enough in that regard (I simply revert to the last known snapshot to go back to a clean slate anyway). Not a deal breaker just odd in terms of results. But for my needs the manual way beats the failover/failback jobs in so many ways. I won't bother to get into as it's out of scope of this thread.

Let me explain the second issue a bit more clear, If I muck with the replica (in this case just power it on and do some stuff, then power it off), if I run the replication job it'll say no new restore points available (as it should since the source of the job is a backup set within a backup repo, and no new restore points exist since the main backup job has not run since the replication job has run), so far so good, even if I delete the actual VM itself, Veeam still thinks there is a VM and says no new restore points to restore to, but there's not even a destination VM anymore, thus the reason to remove it from the replicas area "Remove from Configuration", at this point I'd hope to just rerun the replication job, however I first have to re-add the source VM else the replication job states 0 instances of any objects and completes instantly saying success when in fact it did nothing at all.

[PetrM]

Hi Aemilianus,

Thanks for clarifications. Just out of curiosity: why does manual way beat failover jobs for your needs?

Also, I can confirm that the original VM is excluded from job automatically after you make "Remove from replicas". In addition to Harvey's argument, this approach allows us to get rid of potential job failures: it won't be possible to create a new replica while the original one still exists on the target host. By the way, this behavior is documented on our help center as well. However, if you want to delete replica but continue to process the source VM, then you may use the "Delete from disk" option.

Thanks!

[Zew]

Yeah I always used Delete from disk, when I wanted to actually have Veeam delete it for me and I'd watch vSphere to see the actions take place, and yes using that option it would not remove it from the job. I just tested and verified even if you manually delete the VM and use "delete from disk" it, it simply removes the replica from Veeams configuration and does nothing in vSphere, which feels unintuitive.... almost as if it just "remove from configuration".

I'll just do that from now on, but I hope you can kind of see how from my perspective the terms used in the context menu didn't fully line up with what I thought they each did.