How to backup Kubernetes? Kubernetes Backup and Restore.

The world's first enterprise-grade Kubernetes backup and restore solution

Bacula Enterprise is the world’s first enterprise class backup and recovery solution to offer advanced, automated Kubernetes backup with clusters support. Its Kubernetes backup and restore module makes container orchestration more deployable than ever before. This backup module includes persistent volumes, and provides a large range of architecture possibilities.

This automated Kubernetes backup is Bacula’s second step in recent months towards full orchestration integration. It is available at most subscription levels of Bacula Enterprise at no additional cost for a limited period of time.

Early Adopter Program Download Whitepaper

Kubernetes Backup Use Cases

People using Kubernetes in production typically need a real strategy for restoring and upgrading clusters. In the case that a cluster goes into an unrecoverable state, backup of the config file and its persistent volumes is required to revert back to the previous stable state of the Kubernetes cluster.

Kubernetes cluster-level backups give DevOps teams the tools to back up and restore their entire Kubernetes clusters (automatically) and restore them with a single action to a known good state to minimize production interruption. Bacula Systems asserts that speed and efficiency of restores always needs to be considered, even in a highly automated and resilient containerized environment.

Overall, Bacula Enterprise’s unique solution for Kubernetes backup and recovery both safeguards critical data and enables developers to be more productive. It helps to streamline the workflow of a DevOps environment through to deployment of mission-critical systems. However, there are four main reasons why an IT department will likely be able to benefit from having Bacula Enterprise’s backup and recovery mechanism in place for its deployed Kubernetes cluster.

These are:

As part of a solution to help recover from disasters in the event of catastrophic cluster failure
To help replicate an environment
To help migrate Kubernetes Clusters
To have an independent recovery tool that provides additional security and separation of duties from the cluster automation tools and code repository

Kubernetes Backup Challenges

Since the data itself in cloud-native applications can be classified as ephemeral, and works using a set of containers, management is needed. The most popular management system today is Kubernetes (K8s). The core of this management system is called etcd, and it stores all of the Kubernetes current state info as well as container cluster configuration information, meaning that any change within the system that is Kubernetes is reflected in that etcd part.

The first challenge of Kubernetes backup – since the nodes themselves are disposable and typically last only around a day, it would be easy to restore them in case a disaster wipes them out. The problem is that the restored nodes would have no previous data whatsoever and would have to get that data from etcd – which would have to be backed up frequently and efficiently for the whole system to operate properly after something happens, since etcd itself can be compared with the whole development system’s neural system, containing the knowledge of the infrastructure in general and the placement of persistent volumes that have data that may need to be stored somewhere.

The second challenge of Kubernetes backup is connected with the migration from one cloud service to another which requires the backup system to be granular, since it is likely some things in a users previous cloud-native structure would have to change if your new cloud service has a different structure. You may not need to restore the entirety of etcd, or to restore the entire Kubernetes environment in that case – that’s where the need to be granular comes in. Another need for a granular job may arise if a part of your system is corrupted in the process of migration or for any other reason – it’s highly likely that you would only need to restore that one specific part of the system instead of rewriting everything to restore one small part.

The current day’s app development cycle brings the third challenge of Kubernetes backup to mind – it is typical for applications to be tested in a sandbox environment that is isolated from the rest of the system (namely, production environment, that’s already interacting with customers). In this specific case those environments (dev and test environments) would have to get “hydrated” with application data to provide meaningful test results. These scenarios allow specific containers or volumes to back up a current production environment and restore it over at the test environment – meaning that you’ll need to tag a part of your infrastructure to backup at one place and restore it in the other location or environment.

Bacula Enterprise’s Kubernetes Backup Features

Kubernetes cluster resources configuration backup
Ability to restore single Kubernetes configuration resource
Able to backup and recovery persistent data
Ability to restore Kubernetes resource configuration to local directory
Kubernetes backup and restore for persistent volumes
Ability to restore Kubernetes persistent volumes data to local directory

Bacula Enterprise’s Kubernetes module can backup a number of Kubernetes Resources, including:

Deployments
Pods
Services
Persistent Volume Claims

Kubernetes Backup and Restore Module Benefits

Free of charge with Bronze Level Subscriptions and above
Kubernetes clusters backup and restore
Fast restore of a cluster's persistent data
Enabling fast and efficient redeployment of a cluster's resources

Saving amended configurations for complete security, and restoring to exact same state
Saving configurations for use with other operations

Safe & Efficient Deployment of Kubernetes Clusters

Effective DevOps environments must be scalable and automated wherever possible. Bacula Enterprise is designed to be stable, reliable and highly scalable and its container backup modules are aimed at easing the workloads of IT and DevOps departments using Docker, Kuberbetes, SUSE, Caas or Openshift. It makes Kuberbetes safer and more convenient to deploy than ever before.

Whether your deployed container environment is used for lift-and-shift of monolithic applications, or refactoring legacy applications, or building new distributed applications - developers and systems administrators can use Bacula's advanced Kubernetes backup technology with an especially high level of flexibility – via either Bacula’s GUI or command line interface. Remember, this high level of flexibility and customization possibilities are fundamental to Bacula’s approach: to empower the user by introducing a wide range of options to her/him you achieve their aims.

Why Backup Kubernetes Environments?

As Kubernetes is increasingly deployed in mission-critical operational environments, organizations are increasingly becoming concerned with Kubernetes backup and recovery, security and other data management issues. Initially, the majority of containerized applications were stateless, which allowed them to be more easily deployed on a public cloud. However, as stateful applications that require access to a database have become containerized using Kubernetes, the need to seriously consider Kubernetes backup and recovery has increased dramatically.

Whether Kubernetes is being used in a deployed environment to give a new lease of life to monolithic applications, or refactor legacy applications, or implement new dynamic distributed applications, the need to protect its stateful data remains. An organization’s need to maintain SLAs, and ensure container-based services are always available in a correct state, will always be top of mind. Therefore, a minimum viable Kubernetes distribution requires effective backup and recovery of Kubernetes cluster components and persistent data for productive operation.

For organizations running Kubernetes in production environments, Bacula Enterprise is the first enterprise backup and recovery platform that provides an enterprise-grade solution with deployed Kubernetes clusters to backup and recover data consistently across all its platforms.

Bacula brings agility benefits to Kubernetes environments because of its unusually high degree of modularity and flexibility. For example, Bacula can also make it possible to migrate persistent volumes between Kubernetes clusters – e.g., at the restore time, you can specify another Kubernetes system to write to. This agility in turn offers organizations the opportunity not only to save time, but also to significantly reduce complexity, costs and vendor lock-in.

Many organizations have deployed Kubernetes on least two of three major public clouds, and a good proportion of those running containers on Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure. Bacula’s native integration with these cloud platforms help to speed and ease operations in these environments. Bacula also helps companies to avoid being locked into a single vendor, because apart from its own open source-based code, it also facilitates Kubernetes to be more easily moved from one cloud to another. Bacula also facilities hybrid cloud via its ease of integration of private and public cloud services to support parallel, integrated or complementary tasks.

Bacula’s unique solution for Kubernetes backup includes not just backups of persistent volumes, but also of config. files.

Kubernetes Restore Process

The Kubernetes backup module provides a choice of two targets for restore operations:

Restore to Kubernetes cluster
Restore to a local directory

To ensure best practice backup and recovery for Kubernetes container environments, data should be backed up automatically and system administrators should test backups regularly to make certain that they will do what is needed when recovery is necessary.

Resource Listing Feature for Kubernetes Backup

The Bacula Enterprise Kubernetes backup module supports the listing feature of Bacula Enterprise 8.x or newer. This mode displays some useful information about available Kubernetes resources such as: