Veeam Architecture thoughts

[ccitrano]

Hi all,

I'm reconfiguring my backup environment which is currently using Veeam 6.5. Things are running well and now that I know the product a little better I'm getting a second crack at the configuration. I wanted to run my thoughts by this forum and explain my thinking. I'm hoping that you guys can help steer me in the right direction based on my thoughts.

My current Veeam Backup installation is 100% virtual. I have 3 Veeam servers (One is the Backup Server+Proxy and the other two are running Proxies). My storage for the Veeam backup repositories is on a SAN device (iSCSI) that is not part of the VMware environment that I'm backing up. My concern with this deployment (which almost happened) was that I had an event on my VMware SAN which basically crippled my VMware virtual environment. Since my entire Veeam infrastructure (excluding the storage) was on my VMware stuff ... I could not easily run Veeam to initiate any kind of restore in the event I needed to. My only option would have been to spin up a new Veeam installation, mount the Veeam storage volumes and import the repositories. Not a major deal, but one more thing I would have had to deal with under pressure.

This event led me to think that it would be best for my entire Veeam environment to run on physical iron that is not in anyway tied to by VMware infrastructure. This would hopefully ensure that either my production or backup environment was functional. In contemplating that, I realized that I would lose the hotadd capabilities of the Virtual Veeam Proxies which seem to work best for me. That would leave me with either direct SAN access (which I read a few scary things about) and Network Mode for backups which seem to be the least preferred method.

I then started to think about a hybrid approach. This would involve making my primary Veeam BR server a physical one and hook it up to a single Veeam Backup Repository on my dedicated SAN device via iSCSI. This server would have a Proxy installed on it by default, but I could disable it if needed. I could then create three virtual Veeam Servers that would run the Proxy side of things. This would allow my backup jobs to continue to run in hotadd mode.

In the event of a failure to my VMware infrastructure which would take down my 3 virtual Veeam servers, I would still have the physical server with the Veeam Repository 100% intact that I could use to target other ESX hosts with. It would run via Network mode, but at least I wouldn't need to anything special to start a recovery.

I'm currently backing up 500 virtual machines and the total size of my Veeam repository is 8TB which included 14 copies for retention. I'm primarily using Reverse Incremental.

Let me know if I'm off base on any of this ... or if I should consider another alternative. I'm a fairly small shop, and having a redundant site to use for replication is in the plan ... but not yet available because of capital resources. I'm exploring TwinStrata and Veeam Cloud as possible options for offsite backup of the Veeam Repository. Right now, we are doing the poor mans version of manually copying things off to disk and driving them away to another location.

Thoughts?

Thanks.
Chuck.

[andersonts]

Hi Chuck I think your plan is a solid one and I have seen this at several customers. Many customers still maintain at least one Domain Controller physical as well. You mention Veeam Cloud so not sure if you are referring to a service already offered or to the new Cloud Edition. Cloud Edition gives you some pretty good options for pushing archive copies off site to numerous providers (even your own remote location) just keep in mind you need enough bandwidth to transfer the amount of data you intend to keep offsite (Cloud Edition does compress the data beyond what you see in the job currently).

[dellock6]

Hi Chuck, your design sounds good, I would like to give you anyway another idea, slightly different:
- Veeam Server in virtual, so you protect it via VMware features, only console and sql on board, proxy and repository role disabled. Configuration backup saved to the repository
- several virtual proxies to process data, based on your performance requirement. No real need to backup those VM, a single template to reinstall all of them is enough
- physical repository, made with windows server, with the iscsi san in direct attach to it.

If you loose the virtual part of the design, you quickly install Veeam on the physical repository and import the configuration backup, 10 minutes maximum and you are ready to start recovery. All you need is already in that server.

I would also consider a replica of that backup data at least to a secondary destination, beeing it an additional NAS or a Cloud provider.

Luca.

(Wahhhh, my 1000th post in these forums!!)

[yizhar]

HI.

Your plan sound good.
However I also suggest that you consider the SAN mode of operation.
You can use the physical server as proxy with direct san mode which will reduce load from production vmware hosts, and I think that you will get better performance that way. You can combine this with additional proxy servers if you wish to run more jobs in parallel (either virtual or physical) but most of the backup processing can be offloaded to the physical backup server.

Here are few tips for direct san mode:

1. If your production san storage supports it - you should set read only access to the backup server on the vmfs volumes.
This will prevent most of the horror stories you might have read about, as I assume those were about someone trying to mount the vmfs volume on windows backup server.

2. Use MPIO and DSM if possible (especially for 1gbps iscsi) and/or a fast fiber connection from backup server to the production san, to improve read performance from source vmfs volumes.
Same goes to target backup san access (repository).

3. If you have about 500vm, I suggest that you run about 4 jobs in parallel on the same physical backup server, but start with 2 and then test and evaluate performance.

4. When you purchase the new backup server, I suggest that you load it with some local disk space (internal SAS or MDL SAS drives and internal raid controler with BBWC).
This will provide you with a fast disk space that you can use for whatever you wish, such as:
4a. An alternate or additional backup repository (in addition or replacing the san for some jobs).
4b. A sandbox - disk space that can be used for copying backup files, restoring data, or whatever you find the need for later.
4c. the NFS folder for storing changes if you use vPower to bring VMs online from backup.
4d. A place for storing all kind of files that you do not need to store on the SAN but still don't want to delete right now,
for example - backup files for VMs which are no longer in production.

BTW - How do you currently take offsite backups?
i.e. Which kind of disk devices do you use to copy those 8tb backup files?
How much time does it take to copy the backup files to removable disks?
What do you copy? (Only VBK)?

Bye
Yizhar