We continue with our discussion on backup of Kubernetes resources
The chart described earlier provides the convenience of using helm with Kubernetes custom resources with either one resource encompassing all other required K8s resources at user namespace scope or use several discrete resources at the charts level while allowing transaction like behavior with create and delete at the overall chart level. The benefit is that resources are now grouped by user and automated for creation and deletion.
Backup and restore helps with data protection, disaster recovery and data migration across clusters. These are also routine activities performed on storage systems. In our discussion, the storage system comprises of hybrid components that may or may not have a backup and restore technique and if they do, their tools might vary.
The commands to do backup and restore have varied for storage systems. For example, filesystems are backed up with rsync or duplicity. Databases have their own backup and restore command. In some cases, the backup and restore may not be even needed for some data.
A virtualizer for translating a global backup and restore command will be helpful since it would know which data to backup and how. It provides a common entry point for triggering the individual backups. There are benefits to a common invocation point such as policy evaluation, monitoring and enforcement
A virtualizer also helps to work with the Kubernetes controller or external software.
The backup and restore works exclusively with persistence. It is also possible to sync between replicas
Most tools for backup now work with S3 storage. This allows web access from any source and to ant destination. Since object storage is considered limitless storage with durability and availability, this suits backup schedules very well. The backups to the web accessible can also be on a regular basis.
When the backups are on a regular basis, the web accessible storage can take incremental backups.
Tools that take backup from a cluster do not necessarily perform incremental backups. In such cases it is perfectly alright to take an incremental backup on local file system using rsync or duplicity and then uploading it to the final cloud storage destination.
The chart described earlier provides the convenience of using helm with Kubernetes custom resources with either one resource encompassing all other required K8s resources at user namespace scope or use several discrete resources at the charts level while allowing transaction like behavior with create and delete at the overall chart level. The benefit is that resources are now grouped by user and automated for creation and deletion.
Backup and restore helps with data protection, disaster recovery and data migration across clusters. These are also routine activities performed on storage systems. In our discussion, the storage system comprises of hybrid components that may or may not have a backup and restore technique and if they do, their tools might vary.
The commands to do backup and restore have varied for storage systems. For example, filesystems are backed up with rsync or duplicity. Databases have their own backup and restore command. In some cases, the backup and restore may not be even needed for some data.
A virtualizer for translating a global backup and restore command will be helpful since it would know which data to backup and how. It provides a common entry point for triggering the individual backups. There are benefits to a common invocation point such as policy evaluation, monitoring and enforcement
A virtualizer also helps to work with the Kubernetes controller or external software.
The backup and restore works exclusively with persistence. It is also possible to sync between replicas
Most tools for backup now work with S3 storage. This allows web access from any source and to ant destination. Since object storage is considered limitless storage with durability and availability, this suits backup schedules very well. The backups to the web accessible can also be on a regular basis.
When the backups are on a regular basis, the web accessible storage can take incremental backups.
Tools that take backup from a cluster do not necessarily perform incremental backups. In such cases it is perfectly alright to take an incremental backup on local file system using rsync or duplicity and then uploading it to the final cloud storage destination.
No comments:
Post a Comment