Instant Recovery for Kubernetes is a new feature in Kasten K10 and VBR V12 that allows users to leverage some powerful features of VBR and vSphere to get Kubernetes workloads running very quickly.
Instant Recovery has been a killer feature for VBR and is relied on by many Veeam users to bring their protected workloads back online without delay. With the addition of this feature to Kasten K10, the same benefits can be applied to Kubernetes workloads. If speed of recovery has been a blocker to deploying workloads on Kubernetes, you’ll love this feature!
How does it work?
First, let’s go over some background on vSphere. vSphere splits storage into multiple datastores where VMs and disk images are stored. A single vCenter may have multiple datastores – vSAN, a shared disk array or an NFS filer. vSphere also has Storage vMotion, a feature that allows storage to be moved between datastores without restarting virtual machines.
Veeam used these capabilities along with significant engineering in VBR to produce Instant Recovery for VMs. Typically, a restore involves copying all of the data from the backup system, such as VBR into a vSphere datastore. However, before the VM is usable, all of the data must be copied, which can take a significant amount of time.
When you perform an Instant Recovery, VBR creates a virtual NFS datastore that is attached to vCenter and your ESXi hosts. The virtual NFS datastore melds read-only data stored in VBR with auxiliary redo logs to provide read/write storage while leaving the original backup image unchanged. Virtual disks and VMs are created by VBR in that datastore and their storage uses the backed-up data stored in VBR. The VM can be started immediately, without waiting for the data to copy -- this is the "Instant" part of Instant Recovery. At that point, your restored VM is fully functional and can be started. The VM can be migrated using Storage vMotion to the datastore where it will work long-term -- without any interruption in service.
Extending these capabilities to Kasten K10 and Kubernetes required additional engineering. Kubernetes on vSphere uses the Cloud Native Storage/First Class Disk (CNS/FCD) infrastructure to manage disks independently of virtual machines. Veeam VBR was the first backup product to provide Instant Recovery for FCDs. Kasten K10 uses the underlying technology in VBR to provide this feature for Kubernetes.
On vSphere, each Kubernetes Persistent Volume (PV) maps to an FCD.
When a Kasten K10 Instant Recovery is triggered, rather than creating volumes and populating them with data from VBR, Kasten K10 asks VBR to do an Instant Recovery of the FCDs that are needed, then creates PVs that use those FCDs. VBR handles the virtual disks and Kasten K10 integrates them into the Kubernetes application that’s being restored.
Once the Instant Recovery has completed, the application will run using the VBR storage. At that point, the storage can be migrated into its permanent home with no service interruption. The application will not see any differences in how it is using the storage, and all of the pods using the disks will continue operating without any restarts. Alternatively, the restored application can be removed and the VBR instructed to "stop publishing" the Instant Recovery session.
When should you use this feature?
First and foremost, you should use this feature when you need to restore a Kubernetes application and time is of the essence. The application will start quickly and can be migrated afterwards with no impact on the application, no interruption in service, and no container restarts.
Another time to use Instant Recovery is if you need to run tests against a copy of an application. You can bring up the copy using Instant Recovery runs tests against the copy, do reporting or other inspection, then delete the copy without ever migrating it.
Can I always use Instant Recovery?
There are two reasons you might not want to use Instant Recovery:
- First, after the Instant Recovery has completed, you will need to either migrate the workload or stop publishing the session from VBR. This is a little extra work you need to do as the administrator, and if you don't need something running quickly or if the amount of data is so small that Instant Recovery doesn't make any difference, using a regular restore may be the right way to go.
- Another reason not to use Instant Recovery is the overall efficiency of restoring the data. If you have a very large dataset and time-to-usage is not critical, a regular restore will make better use of CPU and network resources. What’s more the total time for the restore, from starting the restore to having a restored application in its final destination, may be less.
Instant Recovery for Kubernetes speeds recovery
Kasten K10 ‘s Instant Recovery with VBR feature gets Kubernetes applications back up and running faster. If you have been wondering how you can get VBR Instant Recovery speeds for your Kubernetes workloads, this is the answer. If you've been delaying the move to Kubernetes because of concerns about recovery time, Kasten K10 Instant Recovery removes that blocker.
New to Kasten K10? Try it for free today!
Dave Smith-Uchida is a technical leader at Kasten by Veeam. Dave has been a leader in data protection for Kubernetes for the last several years. In addition to his work at Kasten, he is a founding member of the Kubernetes Data Protection Working Group and was formerly the architect for the Velero Open Source Kubernetes backup project. Dave remains involved in a number of open source projects including Kubernetes, Velero, Kanister and Astrolabe. He has over thirty years’ experience ranging from embedded systems to supercomputing and cloud systems, with an emphasis on storage and networking technologies.
