Sudden increase in VM backup time and vrb file size

[jbodnar]

Our Veeam 4.1.2 resource backup job containing a Windows Server 2008 SP2 vm used for file shares suddenly went from less than one hour to over 15 hours.

I verified that this vm was causing this problem by looking at the session statistics.

It appeared to me that the equivalent of a full backup was being performed every night.

The only changes I am aware of on this vm is that Microsoft Updates were installed on it.

I disabled Diskeeper Server 2010 (not sure which build), and the following days the backup times and sizes went back to normal.

I realize we have not purchased Diskeeper's new vm-aware version.

I'm wondering if anyone else has experienced this problem.

Thanks.

[Mindflux]

If you are defragging daily or on some 'autopilot' type of defrag you are going to get a lot of CBT activity. Even though there's not a lot of NEW data, it's old data being written to different blocks from the defrag.

For example: I defragged my SQL server the night before last and this morning's *INCREMENTAL* was 25GB when it's usually much smaller.

Granted, it's not a 15 hour backup (it's more like an hour?) but seeing how defrag 'solved' your backup woes your best bet is to not run defrags frequently or only run them right before you run a full backup only.

[Bunce]

People still use defrag?

[Mindflux]

NTFS fragments, so... Yes.

[Felix]

While not directly related, I tend to create one partition per app/purpose. Eg. one for db log, one for db, one for swap, one for app. This way you have way less issues with fragmentation.

[Gostev]

Yep, most Linux distros even recommend doing this by default in setup, and this makes much sense - no reason not to use the same approach for Windows systems. Especially with thin disks. when you are no longer loosing disk space that is not occupied on those multiple partitions...