Backup Exec FP3 - CSV's running out of space due to checkpoints

[DaveC613]

We installed BE2015 FP3 to support our exchange email backups. Veritas in there wisdom turned on a "faster processing" feature for VM's backups by default.

We were not made aware of the implications of FP3 and when our existing VM backups ran checkpoints started to fill up space in our 3 carefully tuned Hyper-V 2012R2 clusters (managed by SCVMMR2).

The Clusters are now running out of space - due to the checkpoints not being merged at the end of backups.

We have about 90 VMS with checkpoints and are having to manually merge these as per the fix provided by Veritas here https://www.veritas.com/support/en_US/article.000100786

We are hoping that by turning off the faster processing "feature" in backup exec setting our existing backup jobs will revert to merging snapshots when they complete.

Can someone confirm if we will have to also delete all of our VM backup jobs and recreate them to avoid any checkpoints being created when our backups next run?

What a blooming nightmare.

Thanks

[pkh]

Unfortunately you have to follow the procedure in the document you referenced

[DaveC613]

Thank you pkh

So..

I've turned off the "faster vm processing option" in backup exec settings

Restarted backup exec service

Merged checkpoints/removed snapshots via powershell

Does this mean the next time the scheduled backup runs I will no longer have to deal with checkpoint disks or do I also have to delete and recreate all my backup jobs?

note the scheduled backups were all created and working fine before the install of feature pack 3

thanks

[Rick_C]

I was bitten by the same FP3 "feature" in regards to the checkpoints.  I turned off the "fast processing" and that solved my checkpoint issue.  (Had to manually deal with merging the checkpoints using the powershell script that is readily available from other posts)

The implications of FP3 was NOT made clear when it was announced.  Very disappointing...

[pkh]

I don't think you need to recreate your jobs.

[DaveC613]

Thanks phk,

I will post an update if this causes further issues.

I dread to think how many others are going to be effected by this issue and wonder if the feature wasn't pushed through by Veritas marketing instead of technicians.  

I hope someone from Veritas reads this and confirms in detail the effects (or not) this could have on production systems ie space, disk performance, inability to shrink, grow disks, interaction with hyper-v replica snapshots etc.

I won't be happy until I've removed all the checkpoints from my CSV's

[DaveC613 · Accepted solution]

Currently running power shell to remove checkpoints - even our exchange VMs have been cursed they are taking about an hour each to revert. The largest differencing disk I have found so far is on our production SQL server at 60 GB! We have had reports of poor SQL performance over the last few weeks I wonder if this has anything to do with it?  

So far all disks have merged without issue thanks goodness though several refreshes are required to update VMM. I've shutdown some of the critical VMs before merging as I don't have time to create new backups or copy the VHDs

UPDATE: All Disks merged without a problem it took a while but the issue is resolved.