helm-openldap
helm-openldap copied to clipboard
Feat : add backup&restore
Add backup&restore capabilities with a cronjob
I experiment a bit with having a backup. I use the the backup variant of osixia. The following changes in my values.yaml seem to work:
image:
# From repository https://github.com/osixia/docker-openldap
repository: osixia/openldap-backup
I manually created a persistant volume and created the following persistent volume claim:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: openldap-backups
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Ti
storageClassName: csi-fs-ret
volumeName: vol-apps-openldap
Then i mounted the extra volume to my pods:
## @param extraVolumes Optionally specify extra list of additional volumes for the OPENLDAP pod(s)
##
# extraVolumes: []
extraVolumes:
- name: openldap-backups
persistentVolumeClaim:
claimName: openldap-backups
## @param extraVolumeMounts Optionally specify extra list of additional volumeMounts for the OPENLDAP container(s)
##
# extraVolumeMounts: []
extraVolumeMounts:
- name: openldap-backups
mountPath: /data/backup
Finally I added some env variables:
env:
...
LDAP_BACKUP_CONFIG_CRON_EXP: "22 2 * * *"
LDAP_BACKUP_DATA_CRON_EXP: "42 * * * *"
LDAP_BACKUP_TTL: "30"
So far it seems to work. Of course all my replicas try to backup to this volume, but that's not realy a problem. The whole restore thing I haven't looked in to yet, but that should work as well. Isn't that a viable solution to this issue? Maybe you think about some other solution?
Hi @euh2 ,
Thank you for your insight !
If this solution works for you , go for it 😁
IMHO , I think that readWriteMany
disk is too restricted for a global approach see for more details
For separation of concern , i think it’s more reliable to have an external solution taking care of the backup and not the openldap
itself
It can be an openldap
client in a cronjob
With a dedicated volume or offload to a S3
endpoint
It can also be a third part solution like using Velero
it’s an open topic 😄