So Veeam B&R v7 has been announced. For me, the 7 pre-announced features (support for vCloud Director, vSphere Web Client, the Veeam Explorer for Sharepoint, Virtual Lab for Hyper-V and replicas, archive to tape and finally self-service 1-click restore) are good enhancements to the product, but not earth shattering. There are, however, two features that you could call just that. In this three-part blog post, I’ll dive into each of them while also shedding some light on the licensing and offering my own insights and conclusion. Let me start with the beginning of this saga, the status quo:

Using Veeam for on- and off-site backup storage

I use Veeam a lot to provide both on- and off-site backups for many of my customers. The v6.5 Cloud Edition release was a great first step towards long-term archival of backups and replication of backup files on the primary backup repository to a secondary off-site repository (be it a 2nd Windows server or Amazon Glacier-alike services), but was rather limited in its features and options. The best part of these v6.5 ‘Cloud Backup’ and v7 ‘Archive to tape’ features is that you can have a 2nd copy of your backup file without touching (snapshotting!) the source (production) Virtual Machine twice. For some shops, the ‘archive to tape’ feature in v7 will be what the v6.5 Cloud Backup feature was to others. To me, the features are very alike (apart from the physical medium: tape or ‘cloud’) but are still too limiting for many shops. I do really hope that the ‘archive to tape’ feature in v7 doesn’t require touching the source VM; I hope its source is the backup file (created by the regular backup job) instead of the production VM.

Anyway, when I learned that Veeam was finally removing the last (virtual) hurdles to true off-site storage, they got my attention. Basically, they’re introducing a ‘backup copy job’. It’ll efficiently copy existing backups off-site using a forever-incremental backup method. The great this is: this job type can look inside the backup files and enables you to copy specific VMs. This enables you to use a hierarchy of backup jobs based on application type (for instance: selection of VM Folders inside the vCenter Inventory) and use a different selection inside the copy job (for instance: importance of the application). Even better: this type of job doesn’t require you to touch the source virtual machine twice. The less snapshots, the merrier. There are other good things to be discovered about this backup copy job: you can maintain long-term retention (with support for the Grandfather-Father-Son system!) whilst freeing up storage capacity, thus optimizing the primary repository for fast backups and restores. I do hope, however, that this GFS system will make its way into the archive to tape option.

The second fantastic feature is that this type of job has WAN acceleration. Getting backups off-site was always very hard to do efficiently. Specifically in smaller shops, the amount of bandwidth available for off-site replication was very limited and a WAN accelerator added complexity and cost. With v7, Veeam has announced their very own WAN acceleration. Please note that this is not some OEM-deal, it’s purpose-built by Veeam and optimized for Veeam image-based backup. Best of all: it’s built into the product and is agent-free.

From what I can gather, the WAN accelerator is an additional role (like the proxy, repository) available from the console. It’ll read from the primary backup repository and store the backup on the off-site backup repository. If you have different VM in different source backup repositories, the WAN Accelerator will actually do global dedupe across these VM’s during transport, essentially giving you a deduped copy of those VMs on the target repository, so the copy job type is actually much more than a dumb ‘copy the repository from point A to point B’.

As a side note: there’s not going to be any technical changes to the ‘Cloud Backup’ feature (in the v6.5 Cloud Edition). It won’t do block level incremental copy (so you still can’t use this feature with Reverse Incremental backup files). This tool will not be included in version 7. From Veeam’s perspective, I get that the copy job type plus WAN acceleration is way more important; having the backup stored remotely is only really useful if you can restore to a compute layer (i.e. vSphere infrastructure on the secondary site). In a sense, the new copy job is functionally comparable to the Cloud Backup tool with a “File System Storage Account” (i.e. a Windows file server); if you were using Cloud Backup for this type of “cloud” storage, you can migrate to the backup copy job painlessly. I do hope Veeam will integrate the other types of cloud storage (like Glacier) into the backup copy job type. That way, ‘Cloud Edition’ can be replaced with a native Veeam job type (which will benefit from stuff like WAN acceleration). It’s a step back in terms of flexibility, since v7 will not be able to do a (rudimentary) ‘copy job’-type replication to a storage cloud while version 6.5 can. From an RTO-perspective, copying backup files to a general purpose cloud storage provider (with the Cloud Backup tool) doesn’t make sense: you’d have to copy back all the files and arrange for a new infrastructure (compute infrastructure) to be able to continue your business after a disaster. That would take days and days… With v7, customers have more choice to leverage the service-based cloud provider trend: being able to replicate to a Backup or DR as a Service provider (who are running Veeam v7, obviously).

Using Veeam in a SAN environment

In a next post, I will dive deeper into the 9th awesome new feature of Veeam Backup & Replication v7: SAN snapshots. Check it out: The awesome 9th feature of Veeam B&R v7: ‘SAN Snapshots’.