flat.vmdk

There is no problem to fix. The flat.vmdk file is the actual virtual disk, the .vmdk is the virtual disk characteristics and the vmx file is the VM configuration file.

i see a file called ctk.vmdk file in it.

and I guess a ctk-flat.vmdk file as well

This is completetly normal.

The flat file contains the virtual machine disk data, the other vmdk file, contains the disk descriptor, e.g. the virtual disk gemoetry, and it's just a text file.

The ctk file is a change block tracking file.

see here

from Anton Gostev from Veeam on CBT:

In essence, CBT is all about CTK files, these are the files which contain change tracking information of the corresponding VMDK file.

The concept is pretty simple, and if you are familiar with AD DirSync control, or Exchange ICS (public folders change tracking) – it is essentially the same: global USN (Update Sequence Number) for each object. CTK file describes the state of each block for tracking purposes, and contain USN for each block in the corresponding VMDK. After any block is updated, it is assigned the new global USN (which is previous USN value that was used on previously processed block plus 1). This way, any application can ask VMware API “tell me if this block was changed 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, it means that the block was changed (and needs to be backed up, replicated or otherwise processed). So multiple processes cannot conflict with each other anyhow. Each process just memorizes the USN corresponding to the snapshot that the application created during processing, and next time it will use the memorized USN to query for changed blocks.

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 it once using CTK debug/stats data, just don’t remember for sure – unimportant info escapes my head automatically to prevent overload with useless facts ;) . For the same reasons, I/O overhead is barely noticeable with CBT: change few extra bytes to write for each 256000 bytes of data.

The CTK files are permanent, and should not be deleted after backup/replication.

Andrew,
Thank you for this good explation.
I have not got good knowledge in vm.
When we edit the vm we can remove the hdd by removing the vmdk, this case server.vmdk, then we add same file back if we want that disk, not flat.vmdk, am I correct?

When you add a virtual disk to a Virtual Machine, the Configuration and VMX files, searches for the server.vmdk file, which has the geometry information for the virtual disk.

When the VM starts, the server.vmdk chains and loads the server-flat.vmdk file.

both the  server.vmdk and  server-flat.vmdk files, make up a complete virtual disk.

Occasionally, the server.vmdk may disappear, and get corrupted, and you will not be able to start the VM, or add it to a virtual machine, requiring the descriptor file to be recreated.

Thank you for your reply,
Sorry for my lack of knowledge , let me clear , I have a VM which is running .I shut down it go into edit.
Select Hard disk , here I see server.vmdk (which is about 300k) not serve-flat.vmdk (which is about 600GB).
If I remove this from vm always make sure that I add server.hdd not server-flat.vmdk is that correct?

Thank you Andrew, Great explanation.

No problems!