Conversation
alexarefev
added
improvement
alexarefev
requested review from
disa1217,
nikhil1697,
pranavcracker and
theboringstuff
| * make_descriptor | ||
| * pack | ||
|
|
||
| ### Periodic ETCD backups |
There was a problem hiding this comment.
So, to enable periodic backups, we need to run separate backup procedure. Problems here is that backup procedure goal originally (as I understand) is to actually backup data, not to install backup job which will perform backups in future. It seems strange to use backup to perform install. If we need clusters to be installed with disabled etcd fsync, and we recommend that backup job is enabled when fsync is disabled, it would be safer if we install backup job right in install procedure (where we disable fsync).
The provisioner/storageclass need not to be present immediately, it could be installed later, and once installed it can provision the volume for the job
| restore_plan: | ||
| etcd: | ||
| image: registry.k8s.io/etcd:3.6.6-0 | ||
| snapshot: /opt/local-path-provisioner/pvc-e3b0d6c5-495d-4887-90d9-000d6b3d4d00_kube-system_etcd-backup/etcd-snapshot-20260220_103000.db |
There was a problem hiding this comment.
What if some other provisioner is used, e.g. some network-attached like NFS. In this case there will be no directory on the host by default, since volume is not mounted. Do we expect users to mount the volume on their own and find the mount point?
Maybe we could use some additional "backup download" job, which we will run only during restore, which will mount backup volume and copy latest backup to some well-known node direcotry. Then kubemarine will take backup from this well-known location on this particular host
| if cluster.procedure_inventory.get('restore_plan', {}).get('etcd', {}).get('snapshot', {}): | ||
| cluster.log.debug('The particular snapshot will be used') | ||
| path_to_snap = cluster.procedure_inventory.get('restore_plan', {}).get('etcd', {}).get('snapshot', {}) | ||
| first_control_plane = cluster.nodes['control-plane'].get_first_member() |
There was a problem hiding this comment.
We probably should not assume that backup will be present on first master. E.g. local path provisioner could create volume on another node. Maybe using "download backup" job (and checking on which node it run) would be better
3 participants
Description
Solution
backupprocedure to createCronJobthat will manage periodic backupTest Cases
TestCase 1
Make sure the backup is working
Test Configuration:
Steps:
Results:
TestCase 2
Make sure the restoration is working
Test Configuration:
Steps:
Results:
Checklist