- Removing a corrupted Canon print driver - Fri, Apr 8 2016
- VMware vSphere licensing update 2016 – No love for the little guy - Fri, Mar 25 2016
- Veeam releases free Endpoint Backup 1.5 - Fri, Mar 18 2016
With the latest release, Veeam Backup & Replication v8, a number of new features and improvements have been added, including end-to-end encryption of your backup data, a path to cloud-based service providers to host your offsite backups and disaster recovery plans, and new explorers that will allow down to brick-level restores of Exchange, SQL, SharePoint, and even Active Directory.
Veeam Backup & Replication v8
This last feature even allows you to restore user accounts with the passwords intact. But, to get to the point where you can use all these new features, we all have to start somewhere, so the point of this article is to assist you in designing your deployment.
One of the best parts of Veeam’s flagship product is that you can very easily be up and running in about 15 minutes—deploying all of the components you need to a single physical server, using SQL Express and a whole lot of disk space. That is great for very small installations and for testing; however, in a production environment—even in the SMB space where you may only have three hosts—you may find that your needs exceed the performance such a solution is capable of. On the other end of the spectrum, using the exact same installers in a distributed deployment model, you can support even the largest virtualized infrastructures. In short, as long as you are virtualized, an option is available for using the product to make this facet of your job easier.
Let’s start by looking at the basic components that make up a Veeam Backup & Replication deployment and how you may choose to deploy those. In a follow-up article, we’ll take that and start setting up your backup, replication, and other types of jobs, taking advantage of v8’s new features.
Required components
Backup server
The Veeam Backup & Replication server is the core puppet master of the whole system. This role manages the configuration of the server, manages all of your jobs and roles, handles the logging and tracking of jobs, and provides your central visibility into each of your backup servers. As part of that tracking and logging, the backup server is responsible for handling communication to the SQL database where all this tracking is stored.
An important thing to note about Veeam’s licensing model is that you license by protected sockets, not by installations or supported applications like you do with other backup software packages. For example, if you have three dual CPU ESXi hosts, you would need six licenses. This is important because it means that the cost is the same whether you protect such servers with a single Veeam backup server or twenty. You can install as you need to; use cases exist for both, as well as everything in between.
Backup proxies
In talking to Veeam types, you’ll hear these described quite a bit as the data movers because that is just what they are. Due to the various services that Veeam provides in processing data being backed up (change block tracking, encryption, logging, etc.), the actual act of moving bits out of production and into backup can be somewhat CPU heavy. As of v7.5, we’ve been able to do parallel processing of disks; however, this is limited to the number of CPU cores doing the backup. To address this limitation, the backup proxy feature was born. With multiple proxies in your environment, you can scale out the backup processing of your jobs, which enables more jobs to run synchronously.
Determining how many backup proxies you need is simply a matter of knowing what you have to back up and the window within which you have to back it up. Veeam actually recommends that you set all your jobs to start at the same time, and then let the backup server handle the task of getting things started when resources are available. If you are a small shop, you might want to start with just a single backup proxy and see if your jobs are getting done in the time you have available; if not, then add one or more additional proxies. Another best practice is to make your backup proxies physical boxes to limit the potential impact on production systems.
Backup Repositories
Repositories are where you are going to be storing your actual backup data. From what I’ve seen, a repository is normally a Windows server with large chunks of disk behind it, either locally installed or through a mapped volume of shared storage. Personally, I am very fond of using Windows Server 2012 R2 with deduplication enabled on the volume. In this case, if you are going to be using anything bigger than 4 TB, be sure to format the volume with the /L flag prior to use; failing to do so may lead to large-scale corruption of your backup data over time. Using any form of a managed Windows Server allows for the use of what Veeam calls vPower NFS—the ability to mount VMs directly from the repository to your virtualization infrastructure for both testing and recovery purposes.
Repositories
Other options exist for repositories. Linux servers and just raw CIFS shares are supported as well, although each option has drawbacks in terms of manageability, including lack of support for vPower NFS. New in v8 is support for deduplicating storage devices, such as EMC DataDomain and Exagrid products. Again, these devices do not support vPower; however, for long-term backup storage, these are supposed to be more robust than what the Windows dedupe feature provides.
Optional components
If you have the above, you have all you need to get backups going and working. The following components will enable you to scale out your backup infrastructure.
WAN accelerator(s)
We’ll be getting into the different types of backup jobs that Veeam offers in the next post, but we all know we are supposed to have copies of our data outside of the production environment. Who here still has a shoebox full of tapes in their closet at home, or a safety deposit box across town? Veeam’s version enables us to provide for this need by moving bits efficiently across the wire to remote repositories, either in the form of just pure copies of your local incremental backups or replicas of what they call WAN accelerators. This component is used in pairs: one at the data source site and one at the remote repository location.
WAN accelerators
WAN accelerators work by providing a multi-gigabyte hard drive cache, which the proxy fills with job data. The accelerator then handles making sure the link between site A and site B is fully saturated with traffic.
For this reason, I recommend you use the throttling capability within Veeam, or network-level packet shaping if you don’t have a hard-and-fast period in which only backup data is necessary. I have 50 Mbps of WAN capability, and I have seen it completely maxed out with backup data transfer without some mechanism slowing it down.
Cloud Connect service providers
As mentioned above, new in v8 is support for what’s called Cloud Connect service providers—companies that will sell you not only disk space to store your offsite backups but also compute resources so that you can then spin them up at their location when needed. You will need to negotiate terms with the provider, but, once purchased, adding this to your backup infrastructure is much like adding any other repository and then choosing it as a location for backup copy jobs.
Enterprise Manager
A couple of scenarios exist where installing Enterprise Manager makes sense. The first is if you are deploying multiple Veeam Backup & Replication servers; in this case, Enterprise Manager will allow you to have a single place for job management and restore across all of your deployed servers. Second, a new v8 feature enables you to give your users or groups of users the ability to restore their own data as needed by allowing them access to certain virtual machine backups. Finally, Enterprise Manager, in conjunction with Microsoft Search Server, allows you to do keyword searches within groups of backups to look for files.
Backup Enterprise Manager
Deployment scenarios
Now that we have all of our components, how would you like to deploy them? This boils down to your need. Let’s look at the options.
Single server deployment
Single server
This is a great starting point to support not only smaller shops but also larger installations. You can start here and scale out as needed. In this scenario, all of the components (server, proxy, repository, accelerators, etc.) are installed on a single, typically physical, server with lots of storage and memory. A good example is the Dell PowerEdge 720xd, allowing for two six-core sockets, 128 GB of RAM, and 32 TB of internal SATA disk space. With this, you can handle everything you need for local backups. You can augment this with a Cloud Connect provider to handle your offsite requirements as well.
Semi-distributed deployment
Semi-distributed
What I call semi-distributed is great for the SMB shop that needs to back up and replicate to multiple locations but can contain all its backup data within a nice 20- to 30-terabyte repository. In this scenario, the actual Veeam server is a virtual server, allowing for it to be backed up and shipped offsite like everything else, but all of the components in each site live on the same beefy physical server or two. With this configuration, you can have two different sets of your data but with a single, replicated server that can see all and pulls the strings.
Fully distributed
Finally, for the large enterprise that needs lots of backups in a small window—either because it is an always-on company or because you are doing near-continuous backup/replication—you can fully distribute the components. So, you may have two or more backup and replication servers, feeding multiple proxies that feed multiple repositories at multiple sites. All of this is controlled and managed by the Enterprise Manager to allow for eased management.
All of the above are perfectly acceptable and, more important, supportable methods of deployment. Unless you are a major enterprise, you are most likely going to want to start at the single server level and then scale out from there after looking at the effects on your infrastructure. I personally use a semi-distributed model to allow for more backup proxy and repository needs, but that’s what fits my needs.
The good news is that, for anyone, Veeam provides a 30-day evaluation license; for an admin with just about any form of credentials (VCP, MCSE, vExpert, Cisco Champion, etc.), the company offers 180-day, two-socket NFR licenses that are infinitely renewable so you can try it out for yourself. Further, I highly recommend that you check Backup University for lots of videos and reading resources to guide you.
In my next post I will explain in detail the different kinds of backup jobs of Veeam Backup & Replication 8.
