Reducing backup footprint for repository for VAW

[Mgamerz]

I've recently changed my client backups over to VAW from another product, and I'm noticing a huge increase in backup sizes over time. My old product would store the *data* portion of systems in about 3TB of space after the whole pool was deduplicated. Veeam I know does per-system backups that are deduplicated per-chain. I have about 55 systems and i'm using almost 15TB of disk space now (on refs) (with over 42TB actually stored!) and i'm not even at the same retention yet. I'm not sure how to reduce the amount of disk space used in an effective manner.

Does a backup copy job of a workstation backup policy deduplicate all of the backups to the target like normal backup copy jobs do for a multi-VM job since it puts it into a single file? I don't want to enable deduplication on the storage as I've seen how fun that is with 2019 Refs right now.

I have adjusted my settings to now be at High Compression and Storage Target as LAN rather than Compression Optimal and Storage as Local Target. I have also turned off backup when connection to target is established (not sure if this does what I want, as I want it to backup every 8 hours, or whenever target becomes available after this, but i've seen it seems to backup more often than indicated).

Any other advice?

[jmmarton]

The deduplication in Veeam does not work against the data itself. Compression is used for reduction of regular data, while deduplication is used to eliminate redundant OS blocks. If compression doesn't reduce the backup size of the data enough, the only option is to use deduplication capabilities within the target repository system itself (outside of Veeam).

Joe

[Mgamerz]

I guess I am confused. I was under the assumption that Veeam deduplicates it's own backup files (not the filesystem) across the backup chain - e.g. do not store blocks that have already been backed up. This would effectively mean, if for example I had 2 copies of the same files (this is a gross oversimplification), only one would be stored. Compression would then compress that data. If I then added a third copy of this file, it would not store that file either. However this is done per chain and not across all bacups, so Computer 1 would not deduplicate against computer 2 and others, only computer 1.

However, since 55 systems have 55 Windows 10 OS, there is a lot of duplicate data here. I'm wondering, if I was to do a copy job for the workstation backup protection group, does this send all the data over to 1 file, in which case it would be "1 backup chain"... not sure the correct terminology. It's in the same sense that I have per-vm chains in the main VM-style backup, but when I do a copy job over to another repo the data isn't 1:1 in size because it's essentially merging them all into one file for the job. At least, that's what I've seen - copy jobs are typically smaller because it seems to not send duplicate data over multiple chains.

[Egor Yakovlev]

Hi Mgamerz,
You will not win much space with Backup Copy of agent backups.

Just as a thought on potential improvement for overall backup strategy:
- you have 55 machines to manage, when new laptop comes in, are you doing manual Win10 installation or have automated deployment system\PXE boot\corporate ISO? If it is manual, one good way to improve overall IT experience is to automate this part.
- when new software needs to be installed on said machines, is it automated or manual? Once again, good point to automate and save IT human hours.
- now, if fresh OS and software deployment is done in an automated fashion, what is the point of backing up client OS systems? If client machine dies, you have 3 options: going to reuse older hardware from the IT pool, use existing identical model of hardware, or buy a new machine. Cases 1 and 3 will lead to "dances with drivers" if you restore C: from backup, plus software licensing might go nuts, plus certificates might lose its trust chain, TPM will change so on. Plus Recovery Media is human driven, and you will spend yet even more time managing manual volume recovery process. Ain't it much easier to re-deploy OS afresh from corporate image and let corporate software be pushed automatically? Looks so to me.
- Main idea here, is that in many cases, there is no need to backup OS disk at all, but rather focus on personal user data(which can also reside on a network location, but that's another story).

Tuning backup application settings is a great choice, but DATA is what we are protecting and it is a source of entire "backup storage challenge". Once again, it's just an opinion, but in my IT organization, I would start looking at "what" is being protected first, how entire process "backup -> restore" can be optimized, and only then look at how backup application settings\features can improve that even further.

Hope that helps!