CTK files are made automatically by VMware for all VMs with change tracking enabled. This is a great technology that allows products supporting changed block tracking (like Veeam Backup and Replication 4.0) to do extremely fast incremental passes.
CTK file contains change tracking information of the corresponding VMDK file. The concept is pretty simple (this is my understanding): CTK file describes the state of each block for tracking purposes, and contain USN (sequence number) for each block in the corresponding VMDK. This way, any application can ask VMware API "tell me what block have changes since THIS moment", and the API will easily tell that by simply comparing the provided sequence number with the actual USN on each block. If provided USN is smaller than actual for particular block, the block was changed (and needs to be backed up, replicated or otherwise processed).
Basically there should be one CTK file per VMDK file, and CTK file cannot grow out of proportion with number of blocks in VMDK (as it stores only 1 record per VMDK block). CTK file is also thousands time smaller than actual VMDK, because it stores only a few bytes of information (USN) for each corresponding 256KB VMDK block (I am 90% sure it is 256KB, used to calculate once using CTK debug/stats data, just don't remember for sure).
These files are permanent, and should not be deleted after backup/replication.
