Wow, hard to believe VeeamOn 2023 is upon us (May 22-25). As we did for VeeamOn 2022, VAST is sponsoring and exhibiting at the show. A lot has happened since our debut to the Veeam crowd last year, and we’re really excited to tell you all about it! And if not in person, we’d be more than happy to set up some time to meet after the show.
So looking back at the past year in a Veeam/backup context… what’s new?
One year ago: I was super excited about the early results we were getting for data reduction since adding a new technique: Adaptive Chunking. At this time last year, I was working with it in a pre-release/beta version of VAST OS v4.3. The results were very encouraging and I was certain it would make a huge difference… and it did!
Now: In the year since, I saw v4.3 go GA (then v4.4 and v4.5 AND most recently v4.6 !!!). All of them include this space savings enhancement, and as the number of data protection customers increase, and existing customers upgraded, we have seen the technique prove itself to be nothing short of awesome! More info on our advanced data reduction techniques can be found here.
One year ago: Veeam immutability support via S3 Object Lock was coming soon. VAST’s S3 Object Lock first appeared in v4.3, but in Governance mode only.
Now: v4.5 was released in December 2022 and included the last of the development work to complete our implementation of S3 Object Lock, including Compliance Mode (required by Veeam). Since then, we successfully completed the tests and earned our Veeam Ready - Object Immutability qualification, to add to the Veeam Ready Object, and Veeam Ready Repository qualifications we already had.
Veeam v12 came out earlier this year, followed by a new automated test suite for v12 Veeam Ready. I am happy to announce that we’ve successfully passed those tests as well.
One year ago: VAST Indestructible Snapshots were released. A very powerful additional line of defense in the fight against ransomware. Unfortunately, the workflow for protecting S3 buckets left a lot to be desired; it was not nearly as accessible and easy as recovering snapshotted data via NFS.
Now: v4.6 has gone GA and includes a feature called “Global Snapshot Clones”. Without getting into too much detail on this feature, the improvements are awesome for snapshotted S3 buckets (singular, or a group of them), whether local only, or replicated to another VAST cluster. With this feature, I can take any snapshot, instantly clone it elsewhere without having to incur any kind of upfront IO, and then use it in a read/write fashion in another path. Add an S3 Bucket view to this clone, and now Veeam can add this new bucket as a repository and scan it for pre-existing backups.
This is a total game changer! If you’ve ever ventured into the depths of an S3 bucket full of Veeam backup objects, you’ll be able to relate with what I’m getting at. It’s a maze consisting of 100’s of millions or billions of objects. Suppose you’ve got many terabytes or petabytes of backed up VMs in the S3 bucket, and of the millions of objects that somehow piece together 1000’s of VMs, you’ve got no idea which objects you need for the VMs you want to recover. Instead of having to first copy EVERYTHING just to get a little bit, you can clone it, even to a remote site, and then only pull across the objects Veeam asks for on-demand while restoring. This is as huge as Instant Recovery itself. No need to recover ALL the VM data just to turn it on and start looking inside… now that same concept applies to a protected backup repo 🙂
One year ago: Veeam v12 was out in beta. Early tests of new features and enhancements had me totally stoked and waiting for the GA release. There were times where I wasn’t sure if it would make it to GA, but at least the betas kept coming, and each one carried various improvements.
Now: V12 has been out for months, and has also already seen its first cumulative update! Highlights & features I am most excited about based on testing I’ve done and the overall improvements they’ve brought to a VAST + Veeam solution:
Scalable Gateways! - Finally, lots of proxies & transports means lots of parallelism… which falls squarely into VAST’s sweet spot for high performance at scale. Since VAST clusters can scale performance and capacity independently, adding both Veeam proxies and VAST CNodes can help you achieve just about any backup & recovery SLA you’re after.
VMs can be backed up directly to S3! No more SOBR to achieve a balance between performance and capacity when 1 tier can do it all. SOBR still exists, and has its place.. But no longer needs to be used as a workaround to get more proxies in play via more extents, or require a near-temporary high-performance repo to land in before sending to S3. With high performing S3 object storage, such as VAST’s, this greatly simplifies things and without any trade-offs.
S3 Performance Improvements - Many streams through the right DNS round-robining techniques, such as implementing VAST DNS, allow for great parallelism across all the available CNodes in a VAST cluster.
S3 Direct - And even better… where possible, which does not just cut out that middleman and allow agents to backup directly to S3 without squeezing through a potentially constraining bottleneck of gateway servers.
File-per-VM now includes a dedicated metadata file per VM (as opposed to previously being per-job). Now jobs can be used to accommodate scheduling without requiring active fulls when a VM is moved from one job to the next (assuming the target repo stays the same).
One year Ago: This next one isn’t specific to Veeam, but has a big implication for performance in vSphere environments. When restoring to the same VAST cluster where the backup files reside, the dedupe between VMs in their native VMDK formats and Veeam’s object or file (.vbk) formats reduce with almost perfect overlap. This scenario makes for a great recovery target when your production array is in a bind (such as a ransomware attack). However, performance has been a bit limited by NFSv3, maxing out around 2 GBps for a single datastore on a single host. At VAST we have been able to overcome this through nconnect (supported in standard Linux distributions) and with the VAST multipath driver for Linux client workloads but it was not supported by ESXi.
Now: On April 18th, VMware released vSphere 8.0 Update 1, with support for nconnect for VMware NFS datastores! And a feature I wish was added many years ago: VMkernel NIC binding! I’ve been experimenting with both of these in the lab with great results at the connections=4 (max default) and connections=8 (configurable max). I’m now able to push a single vdisk over 4.5 GBps, and I’m just getting started in my testing.
What, more? The resulting backup and restore times have been great! In some tests I was running, restoring from S3 on VAST to various datastores in an SDRS cluster dropped to a mere 40% of the time it used to take through this single vsphere enhancement alone! These are the VMs used in the Veeam Ready restore tests, which must complete concurrently in 30 minutes or less. They are currently down to only 6 minutes from request to fully recovered.
There are far more VAST updates that have happened, and the feature payload delivered in all those versions I mentioned above are quite impressive… and we’re really just getting started!
If you’re attending VeeamOn, please stop by the VAST booth and we’d love to chat in person about data challenges you’re facing, and how we may be able to help. And if you’re not able to attend, reach out and we’d be happy to give you the demos and updates you’d get from us at the show.
Until next time, Rob
