You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue/Feature Description:
KAHU project under the soda-cdm organisation deals with data protection aspects of container data management on Kubernetes .
Currently Kahu supports different volume backup and backup location with Provider framework. The framework provides a plugin approach to integrated Volume/BackupLocation driver in runtime itself.
Currently Volume/BackupLocation drivers are deployed either as “Deployment” or “Statefulset”. The solution works perfectly if the drive uses APIs to connect with respective servers. But it would not work
If backup/restore drivers are data movers (like Restic).
If volumes are topologically distributed
Currently Kubernetes does not support hot mount functionality, So if any Volume backup driver needs “Volume” mount for backup/restore. Current approach will be failure
Why this issue to fixed / feature is needed(give scenarios or use cases):
Data protection is a scheduled operation. So running a driver process and waiting for a backup/restore request to process is a waste of memory and CPU cycles.
An alternative approach is to make accept volume backup driver and backup location driver as Pod template and schedule a Kubernetes job to process backup/restore request
The issue is submitted to discuss an alternate approach (Job based data protection) to handle data protection.
How to reproduce, in case of a bug:
NA Other Notes / Environment Information: (Please give the env information, log link or any useful information for this issue)
AmitRoushan
changed the title
Kahu: Job based data protection framework
Kahu: Requirement analysis for Job based data protection framework
Jan 23, 2023
Issue/Feature Description:
KAHU project under the soda-cdm organisation deals with data protection aspects of container data management on Kubernetes .
Currently Kahu supports different volume backup and backup location with Provider framework. The framework provides a plugin approach to integrated Volume/BackupLocation driver in runtime itself.
Currently Volume/BackupLocation drivers are deployed either as “Deployment” or “Statefulset”. The solution works perfectly if the drive uses APIs to connect with respective servers. But it would not work
Why this issue to fixed / feature is needed(give scenarios or use cases):
Data protection is a scheduled operation. So running a driver process and waiting for a backup/restore request to process is a waste of memory and CPU cycles.
An alternative approach is to make accept volume backup driver and backup location driver as Pod template and schedule a Kubernetes job to process backup/restore request
The issue is submitted to discuss an alternate approach (Job based data protection) to handle data protection.
How to reproduce, in case of a bug:
NA
Other Notes / Environment Information: (Please give the env information, log link or any useful information for this issue)
Initial draft is compiled here
The text was updated successfully, but these errors were encountered: