All Change – Storage vMotion, CBT and Veeam

Ran into a puzzling issue recently, that had me scratching my head for a wee while. One of our regular Veeam backup jobs took several hours longer to complete than the normal 10 mins or so. 1st stop a quick look at the job reports from the previous night :-

Job_1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In comparison to the backup job which appeared to overrun (the error was from missing VMs which I have removed)

Job_2

 

 

 

 

 

 

 

 

 

 

As you can see quite a difference, 2 hours of difference. At first it I thought that the server was extremely busy, maybe the customer was running a DB import or similar, that was causing an increase in the amount of data read. It was during a conversation with a work colleague that storage vmotion was mentioned. Then it dawned on me, I had been carrying out some storage house keeping, moving vmdks from RAID6 to RAID10 storage, the previous day.

Off to Veeam/Google to find any KB articles about CBT and I discovered http://www.veeam.com/kb1113 , and at the bottom of the article was the answer

 

VMware CBT will be automatically reset due to certain operations, such as Storage vMotion. Note that the presence of snapshots will prevent successful reset of CBT. For more information see

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2048201.

 

The previous days storage vmotion had reset CBT and Veeam was still writing an incremental file, but it had to do a hash on the old and new data coming in to see what has changed.

Many thanks to Ben Milligan (@benmilligan) from Veeam for clarifying.

So a word of caution, if your Veeam backups start taking longer than normal, ask your admins if they’ve been performing any storage vmotion actions recently….