Backup the replicated VMs

[DaveBristolIT]

So using CBT in this scenario would result in bad backups.

Hmmm... 5 years later and I read this - I've got many places that are backing up replicas, to move the whole backup process offsite. Please tell me that Veeam actually knows that it can't use CBT and just disables it? I'm fine with that, I'm just not fine with the wording: "Bad Backups"

*Edit: Just re-read the whole thread, looks like in 6.1 you guys automatically disable CBT which is fine I just never like the word "Bad Backups"

[severson_bnc]

Okay, I've got backup proxies up the wazoo and everything has been running since the weekend.

Here's a new screenshot of the replica backup job: http://i.imgur.com/tRbzniz.png. This is an forever incremental job and the screenshot here would be the third run since this weekend in this configuration.

CBT was disabled on another replica, the message reporting that the CBT data was invalid, but this shows this replica VMDK getting siphoned off with CBT enabled.

Anything else you guys recommend I look at, or is this enough confirmation that this might be working now in VS5.5+Veaam8?

[severson_bnc]

Okay, so something very interesting.

Despite the [CBT] tag showing in the replica job, I inspected the VM configuration file and found CTK was set to false for each of the VMs.

Further research on the VMware side found this particular KB article: http://kb.vmware.com/selfservice/micros ... Id=1020128
In it, it stipulates that CBT works when enabled with 0 snapshots, but the implication is that subsequent snapshots would leave CBT enabled.

I imagine then, this just means that for Veeam to use CBT on replica's, it's a matter of changing how the replica is first created so that CBT is enabled while there are no snaps. Thoughts?

[tsightler]

It's 100% obvious that CBT is not working in your screenshots. If CBT was working then the amount read would not be almost exactly equal to the amount processed as that's the entire point of CBT, to only require reading the changed blocks. Those screenshots are definitely of a system running "snap and scan" backups, which is what Veeam used prior to CBT, effectively Veeam takes a snapshot and scans the entire disk transfering only non-duplicate blocks. That's definitely what is happening in your screenshot.

And this is exactly as it should be if you are backing up replicas. This is simply due to the way CBT works on VMware. The process responsible for updating the CTK files (the file that actually contains the data used by CBT) is the VMX process for the running VM. If you think about this you can already see the problem, a replica is not powered on so there is no VMX process, thus nothing is actually tracking CBT data and updating the CTK data. As far as I know there is no method to make this work even with vSphere 5.5 due to this architectural limitation.

[Vitaliy S.]

CBT was disabled on another replica, the message reporting that the CBT data was invalid, but this shows this replica VMDK getting siphoned off with CBT enabled.

Yes, this message should be observed on the incremental run of the backup jobs targeted to replicas.

[thavener]

Really wish this was a built in option.

Maybe setup a second schedule in the replication job to run a backup and prevent the replication from running during that time.

[tsightler]

We do have replicate from backup. If you want your backups offsite where your replicas are you can always run the backup directly to offsite repository and then update the replica from the backup data. The end result is the same, i.e. backups and replicas offsite from a single source pass, the only difference is the backups happen first, then the replicas are updated, instead of the other way around. Yes it might not be exactly what you want, but it's something we have available now.

[jaredondo]

is it posible (supported) to make a backup from replica virtual machines???

[foggy]

Backing up a replica is supported, however has some limitations, which are covered in the topic above. Thanks.

[jeancharles]

Hello,

I would like to go on with this discussion and ask a question about a best practice over WAN link.

Can I made replicas onsite, backups onsite note from replicas but from VMs, and make replicas offiste over WAN link with WAN Accelerator and then backup the VM replicas offsite?

I read some limitations are ongoing, but in vSphere 5.5 and VEEAM 8p2 what can we see like problems other than those?

- CBT not working for offsite backups from replicas?
- Problems with scheduling when a backup occurs over a replication job result in CBT failure

My main goal is evidently to send the least possible data over the WAN link and have a replica and backups offsite for the same "price"

Thank you for your answers that will make a nice sum up for people arriving on this topic.

[foggy]

My main goal is evidently to send the least possible data over the WAN link and have a replica and backups offsite for the same "price"

Remember, with Veeam B&R v8 you can do replicas from backup to achieve that goal.

[jeancharles]

You are so right I totally forgot that...

So I can send Backups over the WAN then create replicas from them, and safely ignore most of the points I listed as eventual problems.

That is a great way to achieve 3-2-1, I will have a copy and a replica local, a copy offsite then a replica offsite too

[jadams159]

I know we can create replicas from backup files, but does anyone know of a way to create a backup from a replicated VM?

[foggy]

Justin, nothing special, you can back replicas up, just keep in mind the limitations discussed in the thread above.

[Saad]

Hello
I'm thinking of switching Veeam backup jobs to run on the replicated vms instead of production vms , but i got a couple of questions before i do that

1. do i need to buy extra licenses for the other hosts that are holding the replicated vms ?
2. any down side of doing that for replication jobs ? i heard that there was an CBT issue " i haven't looked at it yet"

[veremin]

1. If you want to backup both production and replication VMs, then, you would need a license covering number of sockets both hosts have in total.
2. Absence of CBT would be biggest drawback, right.

[Vitaliy S.]

If the reason for switching to this strategy is having snapshot on production VMs only once, then you can keep using backup jobs and then configuring replication jobs to replicate data from these backups.

[jbarrow.viracoribt]

So we replicate from site A to site B.
We want to get a backup of the VM's at site A as well but we don't want to transfer it over the wire.
So, we were thinking of setting up an backup job that would backup the replicated VM's created at site B to save on the WAN bandwidth.

My question is, what would happen if the backup job kicked off, and it attempted to backup a replica image that was currently being replicated into by the replication job? Would it wait, give an error, go haywire, etc?

[foggy]

Consider using replication from backup files instead, since backup of replica VMs has some limitations (review this thread for details).

[jbarrow.viracoribt]

I get this error "Changed block tracking cannot be enabled: one or more snapshots present." When I attempt to back up replicated VM's. Is there any way to disable this feature since a replica VM will always have a snapshot present?

[veremin]

Are trying to backup replicated VMs? If so, absence of CBT is expected, and you can totally disable this feature in the job settings. Thanks.

[jbarrow.viracoribt]

FYI, you CANNOT backup a replica VM while a replica job is running. There is currently no detection built into Veeam B&R for this and it will in turn corrupt your replica images and cause all sorts of job errors. You must manually make sure these jobs don't overlap (with scheduling) otherwise you could have a headache to comb through and replicas to recreate.

Case: 01130050

[veremin]

You're right. If backup and replication jobs are executed from different backup consoles, you'd better make sure they do not overlap. Otherwise, different issues are expected.

If both are created on the same console, you should not come across the said problem.

Thanks.

[jbarrow.viracoribt]

Nope, the problem exists on even if on the same console. The jobs do not wait for each other. Check my ticket details for confirmation of this.

[foggy]

I believe hotadd is the culprit here, at least in your particular case. When the replication job started to remove disks from the target proxy, it was confused by the disks created by backup job's snapshot. So the recommendation to avoid jobs overlapping does indeed make sense in such scenarios.

[jbarrow.viracoribt]

So are you saying that if we used Network mode instead of hottadd we should not run into this issue?

[Vitaliy S.]

There could be other consequences as per our support team investigation. Switching to network mode might be a fix for your current ticket, but still general recommendation should be to avoid any overlaps.

[5mall5nail5]

Hi all -

I have a particular instance where I am unable to use Veeam to replicate from my source to my final destination. The company I am working for has been acquired and we're moving our virtual infrastructure to the parent company. However, due to politics right now, I cannot get access to the remote ESXi host. Instead, the IT team wants to use Veeam replication to replicate to a host that they will send me on-prem. Then, they'll establish a VPN between that ESXi host and one at their facility and Veeam the server from this intermediate host to their host. So, in short, rather than Veeam directly to the destination, there is a middle ground ESXi host that the VM will be replicate to (but will not run from). The parent IT team will then configure Veeam replication on that VM, while it's still being replicated at the source side, and cut over to the final destination.

Is this a support migration path for Veeam replication? My concern is that the source side replication may not be lock-step with the remote replication and the VM may not replicate safely/entirely.

Thanks all.

Bill

[veremin]

You can backup and replicate already replicated VMs. This approach has some limitations, however (check this thread for additional information).

Since you're in need to migrate production VMs, wouldn't it be easier to backup them to removable drive, send device to a given location, and restore VMs afterwards? This way you would avoid unnecessary intermediate steps (shipping new ESXi host, setting it up, replicating VMs to it, etc.)

Thanks.

[5mall5nail5]

That would be more convenient except I am not provided room for down time as these are highly utilized production machines and there's about 7TB to deal with. So moving it to external storage, shipping it 500 miles, and moving it from external storage may all be too time consuming.

I understand that I can backup already replicated VMs, but can I replicate a replicated VM? I am concerned that the source Veeam process is pushing the VM to the intermediate host (already deployed) while the intermediate host is pushing the VM to the destination there's potential there for locked file issues/out-of-sync states, etc. since Veeam is not a constant replication.