Exchange Virtual Machines Files

CHI-LTD
CHI-LTD used Ask the Experts™
on
Hi

I have had awful trouble with acronis replications and backups recently.  I'd like to know if there are any files here that can be deleted or look very large, or could be causing the backup/rep failures?

If not, going back to veeam!

Thanks
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
bbaoIT Consultant

Commented:
are you able to list the files for review?
Andrew Hancock (VMware vExpert / EE Fellow)VMware and Virtualization Consultant
Fellow 2018
Expert of the Year 2017
Commented:
If your VM is not operating on a snapshot disk, it's safe to move the unused files.

Author

Commented:
files...
files..JPG

Author

Commented:
i have a feeling CBT isn't working again!!!
VMware and Virtualization Consultant
Fellow 2018
Expert of the Year 2017
Commented:
All those files, look correct.

nothing required for deleting.

Since the last snapshot issue, I would delete the current backup job, delete ctk files.

Create new job, and start it again.
If not, going back to veeam!
Just a quick update: Veeam released a new version of Veeam Backup & Replication with native tape support, built-in WAN acceleration, advanced support for vCD and so on - http://go.veeam.com/v7
Andrew Hancock (VMware vExpert / EE Fellow)VMware and Virtualization Consultant
Fellow 2018
Expert of the Year 2017
Commented:
@chi... some background info on CB...

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.

@MaximVeeam:- still does not cure any snapshot issue left over, but then again, all other products are the same!

Author

Commented:
i have deleted the job, deleted the old _vmreplica VM and started to run a new job which was going to run for over 12+ hrs...  Not normal..

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial