0

On VMware 6.5, VMs are running on CTK Delta files, could this causes inconsistency on storage level snapshot?

Stuggi
  • 3,506
  • 4
  • 19
  • 36
Zeus_vm
  • 3
  • 1

2 Answers2

0

CTK files contain information regarding if a block in a VMDK (the file containing the actual virtual disk) has been changed or not. They are not the same thing as a snapshot delta file, which contains the actual the data of the blocks that's been changed since the time the snapshot was taken.

CTK files are what enable VMware's Changed Block Tracking, which backup software uses to keep track of which blocks have been changed since the last time a backup was taken, which makes incremental backups exponentially faster since they don't have to compare the VMDK block by block to the last backup, and instead can just instantly backup the blocks that are flagged as changed in the CTK file.

Generally, these files are not an issue since they can't grow very big in the first place (the maximum size is a small sequence number times the amount of blocks in the parent VMDK).

However, there is a potential for these files to become orphaned, which can cause problems with incremental backups. I've personally never seen this in a production environment, but you can fix it by following these steps: https://kb.vmware.com/s/article/2139574

Stuggi
  • 3,506
  • 4
  • 19
  • 36
0

I cannot comment yet, however I would like to add to Stuggi's answer.

You are asking about storage level snapshots. These are in general happening on the LUN level, and really don't care about the contents, that be VMFS, NTFS or a whole different filesystem... they happen on block level. So the storage level snapshots would not be inconsistent - depending on what you are really asking.

If you on the other hand asks about storage level snapshots in conjunction with a backup solution, its a whole different story.

There are really 2 scenarios:

1) You use the storage-level snapshots only as that... you can revert to a storage level snapshot, and be at point-in-time on block level (which you rarely would like to do for a VMFS LUN)... in that case you got no issues with inconsistency, however the usefullness of the snapshot is more or less limited to either a complete disaster recovery scenario, or to mounting the snapshot and recovering individual files.

2) You use the storage-level snapshot in conjunction with a backup product (e.g. Veeam).

In this case - for it to work properly in the first place - the storage must be supported, and the solution must be configured correctly.

If that is the case, then you got no issues either, because the proper implementation of the backup solution dictates, that the backup software requests Vmware to create a snapshot of all VM's on the LUN for which the storage level snapshot is to be taken, after which the backup solution requests the storage subsystem to create the storage level snapshot. It is when Vmware creates the snapshot, a new CBT ChangeId is written to the CTK files, and as such all the information needed to perform the incremental backup from the storage level snapshot, will be present.

This is just a quick rundown, but if you want a more precise answer, update you question with the following information:

  • Where exactly are you afraid you may get inconsistensies?
  • If the question relates to inconsistency with incremental/differential backups, add the backup solution and backup methodology you use.
  • Add the vendore/model of your storage subsystem, along with the LUN configuration you use (iSCSI/fibre channel LUNS or NFS)
Sharza
  • 51
  • 4