Dos and don'ts of backing up Kubernetes storage
Securing the Load
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
...Buy this article as PDF
(incl. VAT)