Backups, Replications, and the vSphere Snapshot Limit

[jwhite.vcf]

In planning replication and backup frequency, I'm trying to figure out whether I need to concern myself with the vSphere 30 snapshot limit and it's interaction with the CBT database. That is, if I have an ever-24-hours replication job, but more than 30 backups that occur between the replications, will the CBT information get pushed out of the VADP interface?

Or do I need to take into account the number of backup jobs that will generate CBT entries and schedule more replications if before 30 other entries occur?

Or perhaps, I see there's a virtuallyGhetto article about raising the snapshot limit (though I'm not clear whether that will raise the CBT database history).

[dellock6]

Even if the article shows that trick, I'm almost sure it's something totally unsupported by VMware, so a configuration not to be done in a production environment.
I'm not following you on the CBT interaction: apart the need to activate CBT before the first snapshot in order to work (but there is also a workaround to reset it) there is no correlation between CBT and the snapshots' depth. Snapshots created for a backups are temporary and are removed after the job completes, so those snapshots do not count in regards to the limit of 31 snapshots.

Luca.

[jwhite.vcf]

Even if the article shows that trick, I'm almost sure it's something totally unsupported by VMware, so a configuration not to be done in a production environment.
I'm not following you on the CBT interaction: apart the need to activate CBT before the first snapshot in order to work (but there is also a workaround to reset it) there is no correlation between CBT and the snapshots' depth. Snapshots created for a backups are temporary and are removed after the job completes, so those snapshots do not count in regards to the limit of 31 snapshots.

Luca.

My understanding was that CBT entries existed to mark the dirty blocks between snapshots.

From the Virtual Disk API Programming Guide:

On hosts running ESX/ESXi 4.0 and later, virtual machines can keep track of disk sectors that have changed. This is called changed block tracking. Its method in the VMware vSphere API is QueryChangedDiskAreas, which takes the following parameters:
[...]
changeId –An identifier for the state of a virtual disk at a specific point in time. A new ChangeId results every time someone creates a snapshot.You should retain this value with the version of change data that you extract (using QueryChangedDiskAreas) from the snapshot’s virtual disk.

So if the the system only tracks 30 snaps, will the changeID still be valid if more than 30 snaps have occurred between replication jobs? Or is this not an issue? Perhaps I'm misunderstanding the 30 snap limit. I know it refers to 30 open/existing/nested snaps but I assumed that it referred to CBT changeID history too, that as soon as the 31st snap was created, the CBT history from the changeID of the 1st snap was lost. But ... maybe I was overthinking that?

[veremin]

It seems that you’re overthinking it, indeed.

I’m also along the same line with those who find no correlation between number of snapshots occurred and CBT utilization.

To put in a different way:

Assuming this was the issue, numerous customers would be affected; especially, those are running several jobs on regular basis (for instance, hourly replication in conjunction with daily and monthly backup job). By the time the monthly backup job takes place, the 30 snapshot limit would have been already exceeded several times, and the backup job wouldn’t be able to leverage CBT.

Thanks.

[jwhite.vcf]

Assuming this was the issue, numerous customers would be affected; especially, those are running several jobs on regular basis (for instance, hourly replication in conjunction with daily and monthly backup job). By the time the monthly backup job takes place, the 30 snapshot limit would have been already exceeded several times, and the backup job wouldn’t be able to leverage CBT.

Is there no limit to the CBT history, then?

[veremin]

This question has been previously discussed in VMware Forum and the conclusion was that it’s quite unlikely that you’ll be able to reach the maximum changeID value. So, you shouldn’t be worried about it. Thanks.