Adjusting my Veeam Backup strategy, could use some input

[james411]

Hi,

I'm reworking my Veeam backup strategy and was hoping for some comments if I'm on the right path. I've scoured the forums and read the help docs trying to identify best practices.

My environment consists of 2 ESXi hosts and 1 physical server running Windows 2012 (not R2) that will be used for the Veeam repository. It's a 1U server running a 4-disk raid 10 (~11TB usable storage).

The plan is to have my primary backups cover 30 days and then use a standard GFS retention to archive data weekly, monthly, and yearly to keep 7 years of data.

Since I only have one storage device, it will have to hold the primary backups and archives (I know not necessarily ideal, but that's what I'll have to do for now).

I plan to use 2012 dedupe and will use the following settings:

1. Format the drive using /L and 64K ntfs cluster size
2. Enable background optimization
3. Enable throughput optimization schedule (scheduled to run during hours backup will not be happening)
4. Change Garbage Collection to everyday (also at a time when not doing backups)
5. Set Minimum Age of Files to be deduped to 8 (based on my restore points, I believe this will allow me to keep the most recent week of backups from being deduplicated to help avoid synthetic activities on deduplicated data and random IO to deduplicated data in the case of an instant VM recovery for example.)
6. 1 Repository for backups
7. 1 repository for archives - limit concurrent tasks to 1 so multiple backup copy jobs aren't trying to write copies at the same time

4 backup jobs will be chained to run one after the other with the first starting at 12am. Each job will have 30 restore points with Active Fulls on Sun. Inline dedupe enabled, compression level set to dedupe friendly and storage optimization set to LAN target. Targeted to the Backup repository.

I will have a backup copy job for each backup job. Interval will be everyday at 4am. 7 restore points. Jobs targeted to the Archive repository. For 2 of the copy jobs GFS will be enabled to keep 4 weekly (default of Sun @ 22:00), 12 monthly, and 7 yearly. The other 2 copy jobs I don't need to keep as long, they will be set to 4 weekly and 12 monthly.

Based on a few full backup test runs, my VBKs range in size from 100-500GB. Running DDPEval showed a 65% space savings on the volume containing them.

Does this sound pretty solid the way I will configure the jobs and storage? Any input or something that I really shouldn't be doing? Thank you!

[foggy]

Looks solid to me. Let it run for a bit to see whether everything is sized properly and there are no issues with jobs overlapping, for example. Am I right in thinking that Veeam B&R is going to be installed on the physical server? Is your current plan to utilize hotadd as the transport mode for backups?

[james411]

Looks solid to me. Let it run for a bit to see whether everything is sized properly and there are no issues with jobs overlapping, for example. Am I right in thinking that Veeam B&R is going to be installed on the physical server? Is your current plan to utilize hotadd as the transport mode for backups?

Thanks for the reply! My 2 ESXi hosts have local storage. So, I currently have the VBR server installed on a VM on one host and will install another proxy on a VM on the other host to utilize hot add for both hosts. Veeam components are installed on the physical server. Sound OK?

Am I right in limiting the archive repository to 1 concurrent task, since I will have 4 backup copy jobs and they run continuously, I don't want them doing copies all at one time. So limiting the repository will make them wait until the other copy job finishes right?

Thanks!

[foggy]

Thanks for the reply! My 2 ESXi hosts have local storage. So, I currently have the VBR server installed on a VM on one host and will install another proxy on a VM on the other host to utilize hot add for both hosts. Veeam components are installed on the physical server. Sound OK?

Yes.

Am I right in limiting the archive repository to 1 concurrent task, since I will have 4 backup copy jobs and they run continuously, I don't want them doing copies all at one time. So limiting the repository will make them wait until the other copy job finishes right?

You can start from 1 task and then check whether your target storage is capable of a higher load.