Veeamzips and another backup solution

[portmaster1000]

We want to use the free version of Veeam to Veeamzip some of VMs to a portable hard drive for another form of offsite storage. The last time we tried this we put the other backup solution schedule on hold and did the Veeamzips over a weekend. When we reenabled the backup schedule, all the VMs we had Veeamzipped had to do a full backup instead of being able to do an incremental.

Is there a way to Veeamzip a VM that being backed up incrementally daily without triggering a full in our other backup solution?

thanx
PM1K

[ronnmartin61]

Definitely sounds like a bug since we didn't detect and disable the "other backup solution"...just kidding

It appears VeeamZip performs some sort of CBT manipulation so guessing you'll see the same behavior with the current v11

[PetrM]

Hi Mark,

It's difficult to say without clear understanding of the reason of the issue with 3rd-party solutions. Probably, it's not connected to VeeamZip. For example, Veeam can perform incremental runs even without VMware CBT, more info is on this page:

If Veeam Backup & Replication cannot leverage VMware vSphere CBT, it fails over to Veeam’s proprietary filtering mechanism. Instead of tracking changed blocks of data, Veeam Backup & Replication filters out unchanged data blocks.

Thanks!

[Andreas Neufert]

Hi Mark,

Veeam-ZIP does full backups and do not leverage CBT. Did you shutdown your VMs for Veeam ZIP? The reason why I am asking is, if you shutdown the VMs and do things like Storage vMotion, it will reset CBT by design of VMware.

Even if Veeam-ZIP was using CBT, CBT is designed in a way that multiple backup vendors can use it in parallel.

I suggest to do some testing with a test VM. Backup with your application, then do a Veeam-ZIP and start a backup again with your application. If your run again into this, then please open a support ticket and upload logs. The team can then help you to identify what happened.

Veeam has enhanced consistency checks for CBT within our backup processing. If we detect a situation that would make CBT unreliable (even for your other applications), then we reset CBT automatically. This is one of the things that could happened here but without logs it is wild guessing.

[portmaster1000]

We tried a test on a small VM per a ticket we have open with VMware. We looked in the datastore for the ctk file and took note of the timestamp which was from the previous night's incremental backup. We kicked off a Veeamzip and immediately saw the ctk file timestamp update. Once the Veeamzip was finished, we tried another incremental backup and it failed with the message:

Backup failed: Failed to get changed blocks for disk. Remove any snapshots that may exist for the guest: Error getting changed disk areas: FileFault.
This issue may be resolved by removing all snapshots and performing a Full backup of this VM.

This is the same message as before and a full backup does work.

thanx
PM1K

[Gostev]

Creating a backup of a vSphere VM requires the creation of VM snapshot, during which ESXi host will in turn update CTK file. So everything looks normal and expected here. No idea what is the issue with your other backup solution, as the same certainly does not cause any problems to Veeam's own backup jobs.

[Andreas Neufert]

CTK file is always updated by the VM when changes are written or you create new snapshots.
It works high level like this. You start with change counter 1. Any data area that changes get a change ID number 2.
When you create a new VM snapshot (even a manual snapshot) the change ID counter go up by one. As Backup vendor
you keep track of this change counter. For example if you create a snapshot and backup the VM at counter 44 and other backup solutions create new snapshots and you as well create manual snapshots. At the next Veeam Backup run the counter is at 50. Then Veeam knows that any data area marked with changes higher than 44 (between 44 and 50) needs to be backed up.

That way all backup solutions work independantly of each other. Maybe you have a backup solution that do not follow the standards here. As Anton shared we have to create a snapshot (temporarly) to be able to leverage the VMware APIs. This is given by VMware processes.

Dumb question. What happens if you backup with the other software, then create a snapshot and then backup again? Would it run into same error?

[portmaster1000]

We've backed up incrementally while having manual snapshots without any issues. I'll open another ticket with our other vendor and include the information I've learned here and from VMware.

thanx

[soncscy]

I would strongly recommend against long-running snapshots though. It's one of those things where "you can", but really, it causes a lot of problems for the Vmware platform and specifically the backup api; everything that makes VMware backups works is basically built around no snapshots by Vmware (check the Vmware docs for the vADP library -- it constantly tells you to ensure no snapshots).

I can guess why you're doing this, but multiple snapshots and multiple backup solutions using vADP is just a recipe for trouble -- surely whatever purpose the long-lasting snaps serve can be replaced by backups, no?