Worth trying Veeam Agent to reduce incremental size?

[BertM]

Hello all,

I'm currently on a mission to reduce our backup storage, thanks to running low in our object store.

One of our VBR jobs backs up a couple MSSQL servers in an Availability Group. It's already not using per-VM backup chains in the hope it will save a little extra space by deduping within the backup files (although I hear this is going away). A full backup is 14.7TB (so ~7.35TB/server) and incremental is 1-2.8TB (not sure if it's both servers or the active AG node creating the large space). What's extra special is the SQL log backups (.vlb files), which are only 5GB/day max.

I've read through a ton of posts here about CBT and how it can create inflated numbers. I already checked AV, defrag, and OS dedup. No local SQL backups. So I'm left to think that SQL server is doing something crazy that changes a ton of blocks, but doesn't cause much to actually go to the SQL log files. The SQL server supports a single app, and I already talked to the vendor about it. They don't know what's up either. If anyone has a clue what to look for that could cause this on the SQL side, I'd appreciate it, but that's not why I'm posting.

Considering the large difference between the SQL log backup files and the VM incremental backup, would it make sense to try a Veeam Agent instead? My hope is the Agent's method of CBT using the NTFS MFT will cause smaller backups than VMware's CBT. Thoughts?

[david.domask]

Hi Bert,

In theory it could work, but keep in mind whatever is producing a ton of changed data may also be reflected in the Agent CBT mechanism as well.

Any chance you have deduplication enabled on the VMs? If you're not seeing huge growth on the database files themselves or an unusual number of transactions, my guess would be deduplication or something similar on the VMs that is shuffling the data around without producing new changes.

[BertM]

I double checked, and we don't have dedup on the VM. I also disabled AV just in case, but the backup size didn't change.

I watched resource monitor for a bit yesterday. The server is usually quite busy with reads, but writes aren't at the level needed to generate 1TB+ of incremental change. It averaged around 1 to 2 MBps writes, which is only 86 to 172GB per day.

I might try the agent, but I think I'll also reach out to the vendor again. Maybe if I explain how CBT works, they can advise about some process the DB uses to process data at some point in the day (like caching records and clearing them over and over)

[BackupBytesTim]

I'll say in case you didn't think of it already, I've seen SQL databases installed and managed by a third-party application like you've described, is that the application itself may have configured some database backups or snapshots, which are often compressed in some manner themselves, which then creates inflated storage in the backups since Veeam is then backing up an already compressed file. (Being compressed, it can't be compressed again with any real efficiency in the backup.) Just in case the vendor doesn't explain much about what's going on, that could be something worth checking. Which you can probably find by looking for any single large files as the database backup is likely a single file each version.