Lead Image © Alexander Bedrin, 123rf.com

Dos and don'ts of backing up Kubernetes storage

Securing the Load

Article from ADMIN 79/2024

By Andreas Stolzenberger

Containers offer great flexibility, but the data they contain often needs to be backed up. Stateful applications that store their information in a container's persistent volume can be backed up in a variety of ways, but not all of them are easy.

In practice, switching to a consistent scale-out architecture with stateless containers means that users have to rewrite their existing applications – not necessarily the application logic, but the data storage and structural components. Existing database technologies such as SQL can only handle stateless scale-out operations with major limitations. Object databases would be far better suited but entail a fairly extensive redesign of existing applications. I already described this problem in detail in a previous article [1].

In this article, I look at some methods for backing up your Kubernetes applications, preferably SQL databases. The main aim is to ensure that these data backups can be restored quickly in the event of a failure. The overview is deliberately restricted to the architectures; you will always need to adapt the code to suit your environment and your applications.

Backup and Restore Problems

An early idea of scale-out applications in containers was to change the way in which applications store their data. Applications are distributed across several nodes and do not have to write persistent data to any drives. The databases are distributed redundantly across groups of containers and only stored in temporary directories there. If a container fails, it loses the entire database, but redundant distribution prevents data loss.

A newly started container synchronizes with existing containers and adopts the redundant data of the failed container. The files need to be backed up as objects that the application regularly stores in Amazon Simple Storage Service (S3) buckets or comparable object storage in the active cluster. All high-level storage functions, such as a rollback history of object changes and backups, are handled by the object storage system, which explains why early versions of container clusters did not even

...

Use Express-Checkout link below to read the full article (PDF).