Skip to content

Gluu Server Backup#

The Gluu Server should be backed up frequently--we recommend at least one daily and one weekly backup of Gluu's data and/or VM.

There are multiple methods for backing up the Gluu Server. A few recommended strategies are provided below.

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

  2. Dump the data as LDIF

    • Log in to root:
    sudo su -
    • Log in to Gluu-Server: 
    service gluu-server login

    or

    /sbin/gluu-serverd login

    • 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/
    • 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
    • Now exclude oxAuthGrantId so the command becomes:
    /opt/opendj/bin/export-ldif -n userRoot --offline -l yourdata_withoutoxAuthGrantId.ldif --includeFilter '(!(oxAuthGrantId=*))'
    • 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)))'

  3. Now, only if needed, rebuild indexes:

    • Check status of indexes: 
    /opt/opendj/bin/backendstat show-index-status --backendID userRoot --baseDN o=gluu

    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

    • 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
    • Check status again :
    /opt/opendj/bin/backendstat show-index-status --backendID userRoot --baseDN o=gluu
    • Verify indexes: 
    /opt/opendj/bin/verify-index --baseDN o=gluu --countErrors

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

Note

You may import the exact export of your ldap exactdatabackup_date.ldif.Do not import your exact copy of your LDIF if you are following instructions to to clean your cache entries

/opt/opendj/bin/import-ldif -n userRoot --offline -l yourdata_withoutoxAuthGrantId.ldif

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 -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#

You can follow the Couchbase docs to backup and restore your persistence.

Note

Up to 6 backups will be stored at /opt/opendj/ldif on the running opendj pod. The backups will carry the name backup-0.ldif to backup-5.ldif and will be overwritten to save te data.

Automatic backup#

A typical installation of Gluu using pygluu or helm will automatically backup opendj at /opt/opendj/ldif.

Manual backup#

Opendj backup can also be configured manually:

  1. Edit your override.yaml file and set opendj.backup.enabled to true and opendj.backup.enabled.cronJobSchedule to the schedule of your choice.

  2. Run helm install or helm upgrade if Gluu is already installed

    helm upgrade <helm-release-name> gluu/gluu -f override.yaml -n <namespace>

  3. Save any custom files injected and used across Gluu services. These files might likely be saved in Jackrabbit.

Opendj restore#

  1. Access the opendj pod:

    kubectl exec -it gluu-opendj-0 -n <namespace> -- /bin/sh

  2. Let's assume the file you want to restore from is /opt/opendj/ldif/backup-1.ldif. Run this to perform the restore: 

    /opt/opendj/bin/import-ldif --hostname localhost --port 4444 --bindDN "cn=Directory manager" --backendID userRoot --trustAll --ldifFile /opt/opendj/ldif/backup-1.ldif --bindPassword "<Password>"

SQL databases backup and restore are a common feature whether in a User-managed or Cloud-Managed deployment.

One way to backup your postgresql database for example: 

pg_dump dbname > dumpfile

Restore the database using the generated 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

  2. Secrets backup: 

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

  3. 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>

  4. 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#

Note

You have to restore your Persistence before doing this step.

  1. Create namespace 

    kubectl create namespace <namespace>

  2. Configmap restore: 

    kubectl create -f configmap-backup.yaml

  3. Secret restore: 

    kubectl create -f secret-backup.yaml

  4. 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>