In my role here at Veeam, I talk to a lot of people across different industries throughout the world. Virtualization is a great community in a sense where we can do that, and we can quickly gravitate to discussing similar topics. Luckily, Veeam helps solve problems for people when it comes to backing up VMs!
Often, questions like “what backup storage do you recommend?” or “what is the best backup storage?” come up. These are difficult questions to answer as there are many factors and unique priorities that help steer a storage decision. I frequently will counter those questions with queries of my own, something to the effect of: “What is most important: space savings, performance or cost?” That is a tough question to answer for your VM backup storage investment. Chances are all are effectively equally important. Other questions around protocol and brand preferences or specific product knowledge also come up but that first question carries the most weight.
When we launched v7 of Veeam Backup & Replication; one of the key initiatives that Anton Gostev (VP of Product Management) and I discussed was the need to change the way people think about how backup storage is provisioned. This falls nicely in line with the new Backup Copy Job and Built-In WAN Acceleration features that are now available with version 7 and the larger message around giving people what they need. Fast backups, fast restores and peace of mind with backups being efficiently written off-site.
We can benefit greatly if we change the way we deploy VM backup storage.
To the heart of the matter, what is the ultimate storage solution for backups? Gostev’s Ultimate VM Backup Architecture is a very flexible way to meet these goals. The best part is that your priorities, budgets, recovery expectations and more can be met with this approach. I think a diagram is appropriate, so let’s take a look at the figure below:
A lot of things are going on here, but basically with this approach (and there are many) Veeam backups can be written to backup storage near the primary storage resource. This can exist in many forms, it could be a separate primary-class storage system, a separate drive array on the primary SAN or even a high-speed storage system running SSDs. This can accommodate most restore situations very well because it has a few key characteristics:
1. High performance storage: By providing faster storage for your first “line” of backups; this will speed up the backups and more importantly the recovery. Everything in this new way of doing backups starts with higher performing storage; besides, this will help also meet the expectations your stakeholders have for the quickest recovery options.
2. Low retention: Because you’ve provisioned a high performance storage resource in step 1; this means we can’t keep the bulk of our backups here. Especially any retention points (like full weekly, monthly or annual backups such as GFS retention).
3. Is a source for the backup copy job: The VMs can be written to a different storage resource (the one on the right) for off-site protection as well as additional retention (such as GFS retention); and that different storage resource can be a slower performing storage device.
Why should you copy backups in the first place? The reason is a best practice of backups known as the “3-2-1 rule”. This states that you should have 3 different copies of your data, on two different media, one of which is off-site. Check out Maria’s recent blogpost on this topic. Personally, I love the 3-2-1 rule AND it fits well into the notion of the ultimate VM backup architecture. It can accommodate almost any failure scenario and it does not lock us into any specific technology.
Now there are literally hundreds or maybe even thousands of ways to slice this up and implement it. Further, if we start talking about a one-to-many or many-to-one approach; then we really have a lot of scenarios to discuss! Let’s take a look at what all of these features do to help improve the backup process. When it comes to relatively low retention, there is less traversal across restore points to improve the performance of the incremental backup. The higher performing storage also can aid the performance of the incremental backup as well. But the big time saver comes with the backup copy job. This will write the VM’s restore points off-site after the VM backup is completed. All three steps critically help address the desire for faster backups, faster restores and getting backups off-site.
That’s one way to address this need, but of course; everyone’s needs are different. I’ve spoken to some people who now prefer to provision a LUN on the primary SAN for that first step of the backup process. I’ve always been a fan of separation; but I heard their design out and it made sense. One way to design around these guidelines is to provision a LUN for that first backup repository and let the backup copy job then write VM restore points to multiple storage resources: one on-site and one off-site. That’s important as the first storage system may have little retention, and not be able to protect against a site failure. That’s a great design!
If one of the repositories are to keep multiple restore points, such as the GFS retention that is included with v7, the only practical way to implement this is with deduplication. Simply put, if we keep multiple full backups for weekly, monthly, quarterly and annual checkpoints; there will be a large number of VBKs on disk.
Deduplicated storage systems are another topic that are somewhat of a complicated discussion point. Deduplication appliances such as ExaGrid, Data Domain, HP StoreOnce and others are valid options. But software deduplication with Windows Server 2012 is also a solution; and everyone’s needs are different. One thing I’ve noticed over the years here at Veeam is that there are many ways to tackle deduplication, and different appliances address deduplication differently. One example is the ExaGrid EX Series of deduplication appliances, which maintains a landing zone of the latest data profile in a fully hydrated state; this allows restore operations to proceed at network speeds rather than re-hydrating blocks across a large data profile. This is important for VMs as there is a good chance of a large amount of random reads-especially on tasks such as Instant VM Recovery. To learn more, be sure to download the ESG lab report, Virtual Machine Backup Without Compromise, where the details of this deduplication approach are measured with Veeam backups.
Provisioning storage for backups is much like examining fuel efficiency for a vehicle: it’s the classic situation where your mileage may vary. It all comes back to the questions on what is most important: speed, space savings and cost. Other questions come up as everyone’s needs are not equal.
What tips and tricks have you done to approach provisioning backup storage with Veeam and in particular now with the Built-In Copy Job feature? Share your comments below.
