Designing for performance

[ditguy2012]

Hello All,

Wanted to get some real-world performance advice. We're about the deploy Veeam at a single site to start. I've tried reading up on what things affect performance so I was hoping you could help me wade through the issues.

* Master server - any special requirements? Virtual OK or is physical better?
* Proxy server - any special requirements? Virtual OK or is physical better?
* I read that a proxy server on each host in your clusters improves performance somehow. Not sure how or why. We have 10 on site plus 4 standalone esxi essentials hosts. That would be a lot.
* We want to use deduplication. Does that database run on master server, proxy server, or our SQL server? Should we use SSD if possible?
* Is the more cores in the proxy the better? Should we get dual 10-core CPUs?
* Is RAM a bottleneck? how much should we get?
* destination for backup is protentially going to be a Dell PowerVault system. Should we get smaller 10K drives with higher quantity or larger 7.2K drives? RAID 6 is slower than 5 for writes but faster for reads. RAID 10 is best but double the destination. Use that with 7.2K drives instead of RAID5 with 10K drives?
* Our tape libraries are connected via Fiber Channel. Anything to consider there?

I read there are various modes for doing backups. We have NetApp SAN for our VMs on ESXi 5.1. Something about hot-adds not working sometimes was worth considering.

Reducing our backup window is the biggest requirement for us. Get all the backups done as fast as possible. We need to do daily's for 30 days with weekly fulls (synthetic is OK but the Fulls need to go to tape) and then quarterlies that we'd keep for at least seven years.

We are hoping to only buy one physical server instead of separating the roles out to different servers. Is this OK?

Thank you to all who spend the time helping. Unfortunately our Veeam engineer rep is unavailable until next week but our VP is gone then so we're scrambling to design the environment.

[Shestakov]

Hello Blake,

Master server - any special requirements? Virtual OK or is physical better?

Both virtual and physical are ok.

Proxy server - any special requirements? Virtual OK or is physical better?

A machine used as a backup proxy should have direct access to the storage on which VMs reside or the storage where VM data is written. This way, the backup proxy will retrieve data directly from the datastore, bypassing LAN.
The backup proxy can be a VM with HotAdd access to VM disks on the datastore. This type of proxy also enables LAN-free data transfer.
Please check transport modes.

We want to use deduplication. Does that database run on master server, proxy server, or our SQL server? Should we use SSD if possible?

It`s perfectly explained here. Please read.

Is the more cores in the proxy the better? Should we get dual 10-core CPUs?

Correct.

Is RAM a bottleneck? how much should we get?

Depends on the infrastructure, job type etc. However, RAM is usually not a bottleneck. Please read the corresponding FAQ section.

Reducing our backup window is the biggest requirement for us. Get all the backups done as fast as possible. We need to do daily's for 30 days with weekly fulls (synthetic is OK but the Fulls need to go to tape) and then quarterlies that we'd keep for at least seven years.

You can use forward incremental job to get the fastest backup during week-days and full backup during the weekend(if workload is less and backup window size is less critical at the weekend). For archival purposes GFS retention policy can be used.
Thanks.

[ditguy2012]

Thank you so much. I've got some reading to do and I'll reply back later. One thing I need to do is understand the pros and cons of using forward incremental vs others. For the fulls I was hoping a synthetic full would be acceptable (not sure if that's what Veeam calls them - we were comparing Veeam to Commvault thus the terminology) and then let Veeam reconstruct a true full when it goes to tape.

[ditguy2012]

It`s perfectly explained here. Please read.

One question about this. I read the post and I'm still a bit confused. I don't know what it means when it says it performs the deduplication against the source datastore. To help me understand compare it to commvault - it stores hashes of data backed up and pointers in a database on the proxy/media-agent server. it doesn't touch the destination or source datastore in addition to getting data to back up or sending data to disk.

does veeam take a hash of the data it wants to back up and run hash checks against all other data in the source everytime? seems very inefficient and a potential bottleneck. I guess I don't understand how this is done without a database without hammering the source and/or destination disk. The other benefit of commvault from what I can tell is that less data is transfered over the wire.

[Shestakov]

I've got some reading to do and I'll reply back later. One thing I need to do is understand the pros and cons of using forward incremental vs others. For the fulls I was hoping a synthetic full would be acceptable (not sure if that's what Veeam calls them - we were comparing Veeam to Commvault thus the terminology) and then let Veeam reconstruct a true full when it goes to tape.

If your backups need to be moved to tapes, forward incremental is what you need. We also offer Forward Incremental-Forever Backup by default. This topic has related discussion. Please get familiar.

I read the post and I'm still a bit confused. I don't know what it means when it says it performs the deduplication against the source datastore. ... does veeam take a hash of the data it wants to back up and run hash checks against all other data in the source everytime?

FAQ section also helps to understand deduplication processes.

Note, that there are different types of deduplication.
When you backup several VMs which contain similar data blocks or blocks of free space, Veeam Backup & Replication eliminates them, which decreases the size of the created backup file. It`s performed by backup proxy.
Also if you use WAN acceleration Global Data Deduplication before sending data over WAN(backup copy and replication jobs). Veeam Backup & Replication uses three sources for data deduplication in this case: VM disks, Previous restore points for the processed VM on the target repository and WAN Global cache.

Thanks.

[ditguy2012]

FAQ section also helps to understand deduplication processes.

Note, that there are different types of deduplication.
When you backup several VMs which contain similar data blocks or blocks of free space, Veeam Backup & Replication eliminates them, which decreases the size of the created backup file. It`s performed by backup proxy.
Also if you use WAN acceleration Global Data Deduplication before sending data over WAN(backup copy and replication jobs). Veeam Backup & Replication uses three sources for data deduplication in this case: VM disks, Previous restore points for the processed VM on the target repository and WAN Global cache.

Thanks.

I'm only talking about local backup for now. not wan replication. So it sounds like it will dedupe across the source VMs before sending the data. does it then keep it deduped at the destination (including if we go to tape)?

[Vitaliy S.]

Yes, the dedupe also happens within the backup files (per each file). If you send backup files to tape, then there is no issue with that.

[ditguy2012]

Been doing some reading. From what I've read the more memory you put in the proxy server the more it will use but it is windows caching that's using it not veeam. Is this true? If so does it help significantly to add more memory? Memory is pretty cheap these days when buying it with your server initially. First we thought 32GB would be enough. Then we decided on 64GB. But if there's some level of linear relationship then even doubling that might make sense. Buying new CPUs is not cheap so we're starting with 2x 10-core cpus.

The bigger concern we have found is the disk destination storage size. Even with forward incremental and synthetic fulls we're being told we'll need up to 3x our actual data size to have enough space for our retention needs. this is crazy compared to synthetic fulls with other vendors (BackupExec and Commvault). It appears that every full, even when synthetic uses up the actual full backup size each time. Now most of it comes from already backed up data but it actually creates duplicates of the same data. So if you back up 100GB today and add 1GB a day, next week the synthetic full will go faster from the source VM perspective but the space used at the target will be 212GB to keep the first full, changes and second full. This does seem to offer some 'protection' in case the original full got corrupted all subsequent fulls wouldn't be but it's skyrocketing our disk target costs. Am I missing something here? Our goals are to dramatically reduce our backup windows and the amount of disk we're buying to store it.

[Vitaliy S.]

1. Actually, proxy servers are heavy CPU users rather than memory. CPU resources are utilized during VM backup compression process.
2. With new backup mode forever incremental, synthetic fulls are note required, so you will not need that much space > http://helpcenter.veeam.com/backup/80/v ... up_vm.html

[ditguy2012]

1. Actually, proxy servers are heavy CPU users rather than memory. CPU resources are utilized during VM backup compression process.
2. With new backup mode forever incremental, synthetic fulls are note required, so you will not need that much space > http://helpcenter.veeam.com/backup/80/v ... up_vm.html

Thank you Vitaliy,

However I'm curious though you still need memory for the proxy server. How do you determine how much to need?

Also is memory more of a concern in the master server? We also plan on running the Veeam One server. But SQL is on another SQL server not any of these.

As for "forever incremental" is this anything special other than old school full backup plus incrementals but never doing another full? Or is there something different and beneficial about Veeam's version of doing incrementals forever. I don't see what's so great about never doing a full again.

Thanks for taking the time.

[Shestakov]

It`s required to have 4 GB RAM plus 500 MB RAM for each concurrent job.

As for "forever incremental" is this anything special other than old school full backup plus incrementals but never doing another full? Or is there something different and beneficial about Veeam's version of doing incrementals forever. I don't see what's so great about never doing a full again.

Yes, it`s different: During first run of a backup job, VBR creates a full backup file (VBK), during subsequent backup job sessions VBR copies only changed VM data blocks, saves them as an incremental backup file (VIB) in the chain and merges first incremental of the chain with the full backup file, so you always have length of chain = preset number of restore points in accordance with retention policy.
This topic can answer additional questions. Thanks.

[Vitaliy S.]

However I'm curious though you still need memory for the proxy server. How do you determine how much to need?

If you're talking about dedicated proxy server, then system requirements should be these - 2 GB RAM plus 200MB for each concurrent task (Using faster memory (DDR3) improves data processing performance).

If you're going to combine proxy and backup server, then follow Nikita's advice. As regards Veeam ONE installation on this server, then make sure you provision enough resources for this servers as well (please check our release notes for Veeam ONE)