Backups

In the event of a production outage, a proper snapshot of the last working condition will help rapidly restore service.

Most platform virtualization software and cloud vendors have snapshot backup features. For instance, Digital Ocean has Live Snapshot and Droplet Snapshot; VMWare has Snapshot Manager, etc.

Snaphots should be taken for all Gluu environments (e.g. Prod, Dev, QA, etc.) and tested periodically to confirm consistency and integrity.

#Tarball Method

All Gluu Server files live in a single folder: /opt. The entire Gluu Server CE chroot folder can be archived using the tar command:

1. Stop the server: service gluu-server stop or /sbin/gluu-serverd stop

2. Use tar to take a backup: tar cvf gluu40-backup.tar /opt/gluu-server/

3. Start the server again: service gluu-server start or /sbin/gluu-serverd start

#LDIF Data Backup

From time to time (daily or weekly), the LDAP database should be exported in a standard LDIF format. Having the data in plain text offers some options for recovery that are not possible with a binary backup.

Instructions are provided below for exporting OpenDJ data. The below instructions address situations where unused and expired cache and session related entries are piling and causing issues with functionality. Read more about this issue.

#OpenDJ

Errors that this may help fix include but are not restricted to:

• Out of Memory

If your Gluu Server is backed by OpenDJ, follow these steps to backup your data:

1. First check your cache entries by running the following command:

   /opt/opendj/bin/ldapsearch -h localhost -p 1636 -Z -X -D "cn=directory manager" -w <password> -b 'o=gluu' 'oxAuthGrantId=*' dn | grep 'dn:' | wc -l

   Copy

2. Dump the data as LDIF

   • Log in to root:

   sudo su -

   Copy
   • Log in to Gluu-Server:

   service gluu-server login

   Copy

   or

   /sbin/gluu-serverd login

   Copy

   • Stop the identity, oxauth and opendj services

   • If you are moving to a new LDAP, copy over your schema files from the following directory. Otherwise simply copy it for backup:

   /opt/opendj/config/schema/

   Copy
   • Now export the LDIF and save it somewhere safe. You will not be importing this if you choose to apply any filters as below:

   /opt/opendj/bin/export-ldif -n userRoot --offline -l exactdatabackup_date.ldif

   Copy
   • Now exclude oxAuthGrantId so the command becomes:

   /opt/opendj/bin/export-ldif -n userRoot --offline -l yourdata_withoutoxAuthGrantId.ldif --includeFilter '(!(oxAuthGrantId=*))'

   Copy
   • You may also wish to exclude oxMetric so the command becomes:

   /opt/opendj/bin/export-ldif -n userRoot --offline -l yourdata_withoutGrantIdMetic.ldif --includeFilter '(&(!(oxAuthGrantId=*))(!            (objectClass=oxMetric)))'

   Copy

3. Now, only if needed, rebuild indexes:

   • Check status of indexes:

   /opt/opendj/bin/backendstat show-index-status --backendID userRoot --baseDN o=gluu

   Copy

   Take note of all indexes that need to be rebuilt. If no indexing is needed, move on to step 4.

   • Start the opendj service

   • Build backend index for all indexes that need it accoring to previous status command, change passoword -w and index name accordingly. This command has to be run for every index separately:

   /opt/opendj/bin/dsconfig create-backend-index --port 4444 --hostname localhost --bindDN "cn=directory manager" -w password --backend-name userRoot --index-name iname --set index-type:equality --set index-entry-limit:4000 --trustAll --no-prompt

   Copy

   • Stop the opendj service

   • Rebuild the indexes as needed, here are examples :

   /opt/opendj/bin/rebuild-index --baseDN o=gluu --index iname
   /opt/opendj/bin/rebuild-index --baseDN o=gluu --index uid
   /opt/opendj/bin/rebuild-index --baseDN o=gluu --index mail

   Copy
   • Check status again :

   /opt/opendj/bin/backendstat show-index-status --backendID userRoot --baseDN o=gluu

   Copy
   • Verify indexes:

   /opt/opendj/bin/verify-index --baseDN o=gluu --countErrors

   Copy

4. Next import your previously exported LDIF. Here, we are importing without oxAuthGrantId .

If you moved to a new LDAP, copy back your schema files to this directory:

/opt/opendj/config/schema/

1. Start the identity, oxauth and opendj services

2. Finally, verify the cache entries have been removed:

   /opt/opendj/bin/ldapsearch -h localhost -p 1636 -Z -X -D "cn=directory manager" -w <password> -b 'o=gluu' -T 'oxAuthGrantId=*' dn | grep 'dn:' | wc –l

You should be done and everything should be working perfectly. You may notice your Gluu Server responding slower than before. That is expected -- your LDAP is adjusting to the new data, and indexing might be in process. Give it some time and it should be back to normal.

#Overview

This guide introduces how to backup and restore gluu deployment on Kubernetes.

#Persistence Backup and Restore

pg_dump dbname > dumpfile

psql dbname < dumpfile

#Configmaps and Secrets - Backup and Restore

#Backup of Configmaps and Secrets

1. Configmaps backup:

kubectl get configmap gluu -n <namespace> -o yaml > configmap-backup.yaml

1. Secrets backup:

kubectl get secret gluu -n <namespace> -o yaml > secret-backup.yaml

1. Get the user supplied values:

   Save the values.yaml that was used in the initial gluu installation using helm.

   In the event that the user supplied or override values yaml was lost, you can obtain it by executing the following command:

   helm get values <release name> -n <namespace>

   Copy

2. Keep note of installed chart version:

helm list -n <namespace>

Keep note of the chart version. For example: backup-chart-version

#Restore of Configmaps and Secrets

1. Create namespace

kubectl create namespace <namespace>

1. Configmap restore:

kubectl create -f configmap-backup.yaml

1. Secret restore:

kubectl create -f secret-backup.yaml

1. Insall gluu using the override or user supplied values with the same chart version:

helm install <release-name> gluu/gluu -f values.yaml --version=<backup-chart-version> -n <namespace>