Optimization and Performance Questions

[PeakSoftware]

Hi,

I am in the process of setting up Veeam for backing up 2 virtual hosts to both local and off-site storage. I have decided to run Veeam B&R in a VM on one of the virtual hosts. The hosts use iSCSI storage and I have given the VM running Veeam access to a volume on the iSCSI by initiating it as a logical drive on the host and then connecting the VM to the logical drive.

So my first question is since the VHDs and backup all exist on the same iSCSI device attached directly to the servers, is there anything I should do to optimize the backup process? Multipathing on different iSCSI connections maybe? The hosts have 2 connections to the iSCSI device for redundancy.

My second question is about offsite backups. I have a NAS device over a VPN, so my off-site backups are going over the internet to the NAS. I assume that for the repository configuration I should choose Windows share, but since I am doing forever incremental, I assume that the full backup gets sent back over the network to be merged with the latest incremental. Would setting up a proxy that is local to the NAS optimize this process? Can I install the proxy on any version of Windows?

Any other input or flaws you see in my config would be welcomed.

Thanks,
George

[rbrambley]

George,

Never a good idea to use the production storage as the backup repository. If you lose your iSCSI SAN you lost your backups too. You'll also probably find that Veeam restores, especially vPower jobs like Instant Recovery and Surebackup, will generate additional I/O that could impact you production VMs (depends on # of spindles, arrays, etc on your SAN)

Go to the Veeam Backup and Replication Resources page to get the Eval Guide for Hyper-V

Just on the surface and without fully knowing your infrastructure, I would investigate repurposing an old physical server as a Veeam server. Find one with 6 or 8 local hard drives and use that storage as the backup target (repository). This will give you local performance without impact to your prod VMs and peace of mind if something very bad happens. Getting a copy of the backups to the remote site could be done a couple of ways with or without Veeam. A Veeam job would work best usng our distributed architecture, for example, but hopefully the Eval Guide will help you understand your options better.

[Helqasem]

On your second question related to offsite back-up.. you do need to deploy a proxy in the remote site to act as a proxying server. The idea being that when you are going across a WAN you need compute capability at each end of the link to deal with connection stability, compression, deduplication, etc.

You need to keep your current local proxy set to run the back-up job at the source. The back-up job proxy should always be as close to the source as possible. The remote proxy is not configured in the back-up job, but in the repository settings for the share. In the "share" page of the repository configuration, there is an option to "Write data to this share: Through the following proxying server". You can select the remote proxy in there.. this kind of set-up should optimize performance.

[PeakSoftware]

@rbrambley - I totally understand the silliness behind my decision to store backups on the production storage. The off-site backups are really my backups if something goes wrong, but the on-site backups are in the case something gets screwed up on the machines that was related to human error, I can quickly roll back without having to wait for a transfer.

So I still need a way to optimize the job without adding too much additional hardware. I will take a look at the resource guide and see if that helps.

Thanks!