Good news! Veeam is building on our integration with storage systems to take backups of your VMs with zero impact. We call it Backup from Storage Snapshots, and it’s one of 2 disruptive innovations that Veeam is delivering in Veeam Backup & Replication v7. (The other disruptive innovation is Built-in WAN Acceleration, which you can read about in my previous post.)
As I’ve been explaining this new capability to my colleagues at Veeam, I’ve described it as a way to put RPOs (recovery point objectives) in places never before thought possible. Because in addition to daily backups, you will now be able to do backups during production hours without impacting your production environment.
Backups from storage snapshots aren’t entirely new – there’s at least one tool out there that can do this today. So what’s new about what Veeam is doing? A lot:
- How we make a VM backup from a storage snapshot
- What you can do with that backup
- What you have to do to make it all work
Backup from Storage Snapshots is actually a bit of a misnomer – in v7, you can create backups and replicas from storage snapshots. The new functionality is specifically for VMware (we already make use of storage-assisted backups and replicas for Hyper-V). And initially it will work with HP StoreVirtual VSA, HP StoreVirtual (LeftHand/P4000) and HP StoreServ (3PAR) storage lines.
Before you ask – yes, we are working on adding support for other storage systems. Our Alliances team is already talking with several storage vendors. Be sure to let your storage vendor know that integration with Veeam Backup & Replication is important to you.
Before we get into how we do it, let’s talk about why we’re doing it. It’s pretty simple: RPOs. It’s just one little TLA (three-letter acronym), but it’s hugely important to your business. It represents the amount of data your business stands to lose if something goes awry and you have to start over from a backup.
So what do storage snapshots have to do with RPOs? Storage snapshots can significantly improve your RPOs. Many organizations I talk to take backups once a day (a 24-hour RPO); some backup critical systems every couple of hours (a 2-hour RPO). But you can easily take storage snapshots every 30 minutes – that’s nearly a 50x improvement over daily backups. This is possible because storage snapshots have zero impact on your virtual machines. This wasn’t always the case, but leading storage vendors like HP have worked out the kinks in storage snapshots, and organizations today routinely use storage snapshots to protect against data loss (but only for certain scenarios – more on that later).
The unique appeal of storage snapshots is why Veeam introduced Veeam Explorer for SAN Snapshots in Veeam Backup & Replication 6.5. Explorer for SAN Snapshots makes it easy to recover individual VMs, guest files, Exchange items and SharePoint items from a storage snapshot. Explorer does all the hard work for you, including cloning the snapshot, promoting it to an active LUN, presenting it to a vSphere host, etc. Explorer even cleans up after itself when the recovery is done. You can read all about it here. Even better, you can download it here and use it for free – that’s because Explorer for SAN Snapshots is, and will continue to be, offered at no cost in Veeam Backup Free Edition.
Recovering from a snapshot was a great first step. But what if you could create real backups from storage snapshots? Because storage snapshots (at least the good ones) have zero impact on running systems, you could take a backup any time you want, even of I/O-intensive workloads. More frequent backups mean better RPOs and less data loss to the business. And less data loss means less impact to users, customers, and the bottom line if, for example, you lose your SAN.
Real backups from storage snapshots
While storage snapshots are ideal for some recovery scenarios, you still need a “real” backup. There are 4 major reasons for this:
- You need to have a copy of your data that does not reside on your production storage in case something goes wrong there (which is not as unlikely as you might think/hope – I’ve talked with many organizations that lost SANs). You could copy storage snapshots to other storage, but that’s expensive (requires duplicate storage and mirroring options) and doesn’t satisfy the 3-2-1 rule of backup (3 copies, 2 different media, at least 1 copy offsite).
- Storage snapshots are not application-consistent (they are only crash-consistent). Some vendors provide application consistency through integration with VMware, but this has all the same limitations as VMware Tools VSS integration.
- Storage snapshots don’t perform application-aware processing, such as transaction log truncation.
- The number of storage snapshots is limited and may not meet your data retention requirements.
In addition, storage snapshots take up a lot of space on expensive production storage (expensive compared to backup storage). This is where Veeam Backup & Replication v7 comes in. By combining the power of Veeam backup with strengths of storage snapshots, you can get real backups from storage snapshots:
- Production data and backups reside on different media.
- Backups are application-consistent (through Veeam-provided VSS integration).
- It’s a regular Veeam backup, so we perform application-aware processing.
- You can keep as many backups as you want on low cost (per TB) storage.
And because the storage snapshot is removed immediately after the backup is complete, it doesn’t consume space on your production storage. That means big savings on storage.
In Veeam Backup & Replication v7, you have the option to create a backup from a storage snapshot. In true Veeam fashion (think “Powerful, Easy-to-Use and Affordable”), creating a backup from a storage snapshot is incredibly straightforward – just check a box in the Backup job (labels are not final):
When this box is checked, we take a VM snapshot just like we do today, but then we take a storage snapshot. The storage snapshot includes the VM snapshot, so we can release the VM snapshot on the production datastore immediately after, and create the backup from the VM snapshot inside the storage snapshot. We create the backup in exactly the same way as we do today: We perform advanced application-aware processing (including log truncation). We use VMware Changed Block Tracking (CBT) to speed incremental backups. And you can perform Instant VM Recovery, SureBackup recovery verification, Universal Application-Item Recovery, etc. from backups created from storage snapshots. The only difference is where the VM snapshot is read (from the production datastore or from a storage snapshot) and how long it’s open.
In the case of a backup from a storage snapshot, the VM snapshot is open for only a few seconds. The VM runs on the VM snapshot for a brief moment only, so the snapshot commit is nearly instant.
This technology – and other Veeam innovations that will be the subject of my next post – make Veeam backups from storage snapshots up to 20x faster than the competition, taking RPOs to levels never before possible.
The functionality is also a lot easier to deploy – you don’t need a team of consultants, and you can have everything up and running in your lab in less than an hour. In fact, if you’re considering Veeam Backup & Replication, I encourage you to try it for yourself – it’s that easy to use, and I’m that confident you’ll be successful with it.
Let me show you by way of an example what the differences are between a backup sourced from a VM snapshot on a production datastore and a backup sourced from a VM snapshot inside a storage snapshot…
Below is an example of a Backup job in the current Veeam Backup & Replication 6.5. On the left you see all the machines that are backed up by this job. I highlighted the SQL Server VM so that I can track its progress. Let me go through the steps with you:
Preparing guest for hot backup: This is an important application-aware processing item.
Creating snapshot: This is where the Veeam Backup Server requests a VM snapshot from the hypervisor or vCenter. Once the VM snapshot is created, the guest snapshot framework is released.
Saving VM files & Hard Disks: At this point the Veeam Source Proxy retrieves all the VM snapshot data from disk, dedupes and compresses it, and sends it to the Veeam Target Proxy to write to backup storage.
Removing VM snapshot: Here we are committing all the changes made to the VM while we were doing the backup.
If you add up the durations in the timings table, you’ll see that this full backup took about 1½ hours (running in a lab environment), and at the time I took the screenshot we were already working for 27 minutes to get the delta file committed. By adding a storage snapshot right after “Creating snapshot” above, we can move “Removing VM snapshot” up to before we start reading all the VM files and hard disks. This completely removes the need to commit a large delta, since the time to take a VM snapshot and then take a storage snapshot is negligible.
We are on track for general availability (GA) of v7 in Q3 of this year, including Backup from Storage Snapshots. Are you looking forward to this new capability from Veeam? Share your comments below.