Read the full series:
|
Ch.1 — Backup Server placement and configuration |
When it comes to deciding what are can be considered “BEST” practices, a lot can be up for interpretation. One thing that we do know for sure is that when Gostev presented VT-466 VMware Backup Best Practices: 2015 Edition there was something for everyone to learn. This was without a doubt one of the most popular sessions from VeeamON 2014 and 2015, and I can’t wait to see what the 2017 edition will look like!
That being said, we’ve decided to release a few key points here in a blog series from this session from last year, to share the knowledge and ramp up for VeeamON 2017. Additionally, be sure to watch the announcements coming for Veeam Availability Suite v9.5, as new features will roll out there to help deliver more Availability for your vSphere environments.
Best practices for Veeam Backup Server configuration
The Backup Server is the main role where Veeam Backup & Replication is installed, and there are a number of tips you can use to have a good experience with this critical component. Here are some best practices for the backup server in VMware environments:
- Disable the default roles of making the console a proxy and repository. For very small environments, these may make sense to keep around, but for any installation of size let the backup server do its job of managing the jobs and other components rather than doing the actual work of backing up.
- v9 removed the limit of 100 jobs in a backup server. This makes the point above a lot cleaner for installations with many jobs and the preference to have only one console.
- A few thousand VMs per server are reasonable. There are no hard or soft limits, but this becomes a good working number for how many VMs you can protect in one console. Other factors like number of sites, security zones and business requirements may introduce non-technical reasons to have more servers however.
- Allocate plenty of memory on the backup server. You can find these requirements in the Veeam Help Center, and the important thing to remember is to have a base of 4 GB RAM plus 500 MB RAM for each concurrent job. Additionally, don’t omit the memory requirements for other roles should they be on the backup server (Proxy, repository, WAN Accelerator, etc.).
Physical or virtual: Where to install your Veeam Backup Server?
There are a lot of discussions on whether to have the backup server physical or virtual, and here it’s also very difficult to make a specific recommendation. Here are some benefits of both having a virtual and physical Veeam backup server:
| Benefits of physical | Benefits of virtual |
| Best practice for any disaster recovery (DR) solution: Your DR system should not rely on the system – it is designed to protect and recover. | Enables 100% virtual data center (or gets you there closer). |
| Use configuration backup or remote SQL server to protect data. | More protection options ‒ back up or replicate the entire VM (the backup server VM) with Veeam. |
| Install Veeam Endpoint Backup FREE to protect the Veeam Backup server (if required to have a complete backup image of it). | Think through and test thoroughly your DR plan. |
I’ve generally encouraged people to make the Veeam backup infrastructure physical if there is only one vSphere Cluster. In addition to the reasons above, a benefit of the backup infrastructure (including the backup server, proxies, repositories, etc.) being physical is to avoid any “skew” of vSphere DRS during the backup window. It can take a good amount of CPU and RAM to perform the actual backup, so if you can do it without affecting everything else from a CPU and RAM perspective and avoid unnecessary vMotion events, that is a positive.
When multiple vSphere clusters are in place, a virtualized backup server becomes a great option as long as it is not managing the Availability of the cluster it is in. For example, this means that if a virtualized backup server is backing up Cluster A, it should reside in Cluster B. Likewise, a virtualized backup server in Cluster B can manage the backups of Cluster A.
Backup Server dependencies
Much like the deciding where to place the backup server in regards to having the highest levels of Availability, the same goes for any dependencies that may be in place. Here is a list of best practices to avoid issues due to dependencies:
- Think through the dependencies. Take a good look at your VMware environment as much as you can to ensure nothing could be required that you don’t have, in the event of a restore. Also, ask another opinion to try to identify an unforeseen dependency.
- Do a DR test. This goes without saying anyway, and we have big plans in this space with Veeam Availability Orchestrator, but using the backup server in a totally different site will make you find out what you need that you don’t have.
- Local accounts. These become a good idea when you are performing a restore of some type without Active Directory.
- SQL authentication. Much like the reasoning above, if the Active Directory domain isn’t available, you may have trouble accessing the SQL Server database that hosts the backup server’s database.
- Workgroup vs. Domain decisions. If you have a separate “management domain” of Active Directory that is completely isolated from a security and infrastructure perspective of what the backup server is protecting, then using a domain set of accounts (including for the previous two points) can be advisable. When there is only one Active Directory domain and Veeam is backing it up, it is more advisable to use local system workgroup credentials for the Veeam configuration of the backup server, as the domain becomes a dependency otherwise.
- Back to the physical vs. virtual server discussion. A dependency may be realized when considering the points above, which is why the broad consensus is to use a physical server.
Backup Server placement best practices
When there are backups and especially when there are replicas in use, a lot of factors go into deciding where to place the backup sever. It’s generally recommended to have the backup server on the same site as the VMs it is backing up, especially when the vCenter Server is in that site. vCenter communication over the WAN may be slow.
In regards to disaster recovery, having the backup server in the production site is OK. This is because the DR situation inherently means we are going to fail over to a replica. As such, the recovery time objectives (RTO) of the replicated VM(s) are very quick. Additionally, with an extra backup server at the DR site to manage the failover, you’ll be in good shape (discussed next).
If replication is used, it’s recommended to put a backup server in the DR site and have this server manage the replication jobs (but don’t forget the requirements and dependencies here either). This ensures that you can have one-click failover when the production site is down. Additionally, there is no recovery point objective (RPO) impact as replicas inherently have a less-frequent RPO than backups.
If you do virtualize your backup server on the production site, you have one additional point here in that you can replicate it to your DR site like any other VM. If you are concerned about the backup files themselves, the backup copy job is your friend and we’ll cover that in another post of this series.
Stay tuned for more posts in this series! Until then, here are some resources you can use to supplement this blog post:
