Sanity Check for Architectural Changes

[Kimboaticus]

Hi Folks,

Just wanted to get a sanity check on some changes to my backup architecture. Here is how things are now:

3 Host VSphere 5.1 environement. 2 Hosts at the head office, one host at a remote site. Veeam B&R & Enterprise Manager are installed on a VM at the head office is backing up all the VM's there. The third host at the remote site is using VDP 5.1. VDP is currently set to backup 3 VM's at the remote site daily with 365 day retention. That site has a comparatively small amount of data with very small deltas. VDP appliance at remote site is located on a VMFS datastore on an iSCSI attached NAS located in another building at the remote site. There is a VPN linking head office with the remote site.

Proposed changes:

Eliminate VDP at the remote site. Install B&R on one existing VM at remote site (note this VM will have production data on it and so will need to be backed up. Cant afford the cost of another Server license to use solely for B&R at that site.) and have Enterprise collect backup info from both B&R servers. Create a VMDK on the iSCSI NAS at the remote site for the Veeam repository there and add it to the server that I will install B&R on at the remote site, setting it to be independent so snapshots wont be taken of it.

Based on this, I have a few questions:

1)Is this plan sound? Anything I should change?

2)I know setting up another server to just run B&R on would be idea but I simply cant. Any issues with backing up this VM as part of a job in B&R? Incidentally, it is also a domain controller\file server.

3)What is the best way to setup my backup jobs at the remote site to imitate the current behavior of daily incremental with 365 day retention? Is it basically daily incremental with 365 restore points kept? Is there a better way to do this and still have many recovery options?

4)Any comments on the amount of traffic generated by Enterprise manager collecting backup info across the WAN link? With there be much? Little?

Thanks all!

[veremin]

Generally, it's recommended to deploy additional instance of VB&R in remote location in case of replication jobs. The idea is to increase the speed of Failover, Failback operations in "disaster" situations.

Though, in case of backup jobs, you could still stick to 1 server deployment, as both local and remote jobs can be managed by local V&R server without any issues.

The backup server can be protected with configuration backup feature. Should any disaster situation happen (backup server goes down, for instance), all you would need to do is to install Veeam on any other virtual machine you have and import previously backed up configuration.

In order to mimic the existing jobs, you can clone them, using "Clone" feature, and change the "target" repository.

As to the NAS device, if it supports ISCSI protocol, there is no need to create vmdk on it, as the device can be directly connected to any Windows machine you want to.

Thanks.

[foggy]

In addition to what Vladimir has suggested and to answer the rest of the questions:

2)I know setting up another server to just run B&R on would be idea but I simply cant. Any issues with backing up this VM as part of a job in B&R? Incidentally, it is also a domain controller\file server.

No issues with backing up Veeam B&R itself besides the limitation of using CBT if hotadd transport mode is used.

3)What is the best way to setup my backup jobs at the remote site to imitate the current behavior of daily incremental with 365 day retention? Is it basically daily incremental with 365 restore points kept? Is there a better way to do this and still have many recovery options?

Yes, that's pretty basic, just set the daily job to keep 365 restore points. However, don't forget to schedule active fulls to avoid extremely long incremental chains.

4)Any comments on the amount of traffic generated by Enterprise manager collecting backup info across the WAN link? With there be much? Little?

The amount of traffic depends on whether you use guest OS file system indexing on your VMs for faster file-level restores and, if yes, the amount of files inside those VMs. While jobs session stats traffic is not essential, indexes could be pretty large.

[Kimboaticus]

Hi Folks,

Thanks for your comments. Based on what you have said, I have a couple more questions:

1)If I go with the suggestion of just keeping the existing B&R server and not setting one up at the other site, what kind of traffic would be going across the WAN at that point? Should it be more or less than what would involved if it was just updates being sent to the Enterprise server? Its not a huge pipe so I want to pick the option that would have the least impact.

2)I was wondering about the periodic active fulls if I keep the 365 day retention. I would prefer to do the fulls from time to time but my big concern is that doing so will eat up the storage I have available for backups. Perhaps I'm wrong in my understanding of VDP, but it is using less than %30 of the space allocated for the VDP appliance and it has been doing incrementals since June of last year. My concern is that if I now introduce fulls, say once a month, that it will eat up the allocated space. I guess I will just have to try it and see! Is doing a full once a month still going to leave an incremental chain that is too long?

Thanks again!

[foggy]

1. Control traffic from Veeam B&R management console to proxy and repository servers, as well as to vCenter server (if there's a separate instance of vCenter in remote site). All the backed up data would be transferred locally in remote site. However, restore from remote repository could involve more.

2. Please find recommendations on the full backup frequency in this thread: How often do I need a full backup?