Veeam 100 Summit - Day 1

Reading Time: 6 minutes

In the beautiful city of Prague morning, I had a warm morning meeting with the Veeam team Madalina Cristil, Safiya Mohamed, Nikola Pejková, and Rick Vanover. It was really a warm welcome like we met millions of times before.

I received my SWAGs. Well, It is my first time as a Vanguard, In fact, I received double swags as a Vanguard and VUG Egypt Leader.

So, I am happy with my swags. But there are many more important things than swag. It is an exclusive first session.

Day 1 was exclusive to those who were interested in Kasten by Veeam workshop. Actually, this is one of my personal/work interest.

The workshop was run by Michael Cade

The most thing I liked is that it was started from scratch. I mean, it is about Kasten backup for Kubernetes. But it started with what is Kubernetes itself, with its history, and about DevOps cycle as well.

If you’re not familiar with Kasten, It is #1 Kubernetes data protection platform. It is used for backup and restore application, disaster recovery, and application mobility.

Read Kubernetes backup and recovery for dummies for free.

I lead DevOps team at my current employer, so I knew already about this topic, but the way Michael introduced it was wonderful. And I took lots of notes.

Then We started with Kasten, I expected a question and I found it in the session: Why do we need Kubernetes backup?

Let’s talk about that, I came from a virtualization background, like most of the attendees. Where we are aware of VM backup. Well, all K8 components are already inside a VM. I mean I can backup files and retrieve them with a few modifications and we are good to go. So the argument is why do we need K8 backup after all?

We are talking here about native backup. I will quote here from Kasten for the reasons:

It accommodates Kubernetes deployment patterns.
In containerized applications, there’s no mapping to any servers or virtual machines. Application components are distributed across all servers to improve fault tolerance and performance. As such, traditional backup solutions are unable to capture the state of a specific application without collecting data from others, and as such, misconfigurations can result. While traditional solutions are appliance-centric and designed for backing up VMs, a Kubernetes-native solution can adapt to the dynamic aspects of containerized applications, performing load-balancing to accommodate the changing needs and contents of the container, discovering changes in real-time and capturing all application context.
It aligns with “Shift-left” development.
Kubernetes is all about rapid development cycles. Its unique design necessitates application-centric backup solutions and alignment with DevOps’ “shift-left” philosophy. In the shift-left approach, developers are the ones who define the application and infrastructure components as code and dynamically provision those programmatic requests. Although shift-left is a cornerstone of an agile development environment, it can introduce the risk of data loss resulting from a misconfiguration. Backing up and protecting Kubernetes requires discovering new and changing applications automatically, without developers needing to make any changes to their applications or packaging. The solution should also be API-driven, to remove any barriers to adoption.
It simplifies operations.
The skills gap is real. Many developers are coming to Kubernetes having worked only in Linux or vSphere environments, so the backup tool must offer CLI access and an easy-to-use dashboard. This will help bridge the gap and hide underlying complexity to simplify backup workflows. In this way, operators don’t have to understand how to protect millions of components in a cluster or perform a miscellany of manual tasks to update applications with restored volumes.
It accommodates multicluster scalability.
Handling the millions of discrete components in a Kubernetes cluster requires a solution that can capture and understand the relationships between the applications, data, and Kubernetes state — at scale. It must be able to dynamically accommodate application and cluster changes and scale down to zero when not in use — all with minimal operator involvement. The requirement is compounded by the increasing use of Kubernetes multicluster configurations, which are often distributed across environments, team and application boundaries, regions, clouds, and on-premise data centers. A solution that accommodates multicluster scalability will eliminate significant operational burdens, saving teams time and money.
It closes protection gaps.
Kubernetes is architected for fault tolerance — but replication isn’t a backup. Replications can suffer from data corruption and deletions — even in the cloud. Think of on-premises storage snapshots — they’re often not resistant to hardware failure, and if you delete one, related snapshots may also be lost. What’s more, quiescing file systems for backups may require elevated security privileges. A native solution can prepare the data for backup without sacrificing security, and work transparently across a wide range of application stacks and deployment methods, without adding complexity to the operator’s workflow.
It bolsters security.
Traditional backup solutions cannot discover, let alone access or quiesce applications without weakening isolation policies within the cluster. By contrast, a Kubernetes-native solution can embed itself into the control plane and circumvent those limitations. Role-based access control (RBAC) is a critical requirement and should align with the roles defined within Kubernetes to support self-service capabilities and minimize the need for developers to learn additional role management systems.

A native backup system will understand Kubernetes certificate management and storage-integrated Key Management Systems (KMSs), and support Customer-Managed Encryption Keys (CMEKs) through the Kubernetes Secrets interface, to avoid transferring application data in plain text. It can perform independent backups to protect against malware and ransomware, and will likely have deep platform integrations to enable rapid, automated restores.
Integration with the cloud native ecosystem.
The development ecosystem has expanded to include multiple data services (e.g., MongoDB, MySQL, and Cassandra), and often these are used within the same application. A Kubernetes-native backup solution can capture a consistent copy of the entire application stack, both within and across services. It can also identify and gather data from replicas, reducing the impact on the application, and improving performance and efficiency. As more and more organizations run Kubernetes clusters across different environments, the ability to integrate backup with the cloud-native tools that developers and operators are accustomed to — such as Prometheus or Kubernetes APIs for logging and root-cause analysis — will be critical.

The workshop itself was a full demonstration of building the Pac-Man app.

As I mentioned, we started by creating K8 cluster till working with Kasten backup, and integrating it with Veeam B&R.

The day was very interesting to me, followed by a welcome reception sponsored by Object First. I heard about it but need to know more about it. This will be my plan for Day 2….See you then