Backup & Restore

caution

GitGuardian encrypts all sensitive information in the database using a data encryption key (also known as the Django Secret Key). In the event of a disaster, this key will be essential to restore your data.

Regardless of the installation method (KOTS or Helm), ensure the encryption key is securely stored and accessible.

Use the following command to display the key:

kubectl get secrets gim-secrets --namespace=<namespace> -o jsonpath='{.data.DJANGO_SECRET_KEY}' | base64 -d

Backup

To fully back up the GitGuardian application, you need to:

Back up the PostgreSQL database (⚠️ and the data encryption key).
Back up the KOTS config (for KOTS-based installations existing cluster).
Back up the Helm values file (for Helm-based installations existing cluster).

We strongly recommend using externally managed databases and data stores, along with a robust strategy for snapshots and backups. An embedded cluster installation with an embedded PostgreSQL database is not recommended for production deployments and is intended for PoC/testing purposes only. For more information, see the Choose your installation method page.

Helm-based Installation

Ensure you back up the values file you created during the installation.

KOTS-based Installation

To backup the KOTS config files, use:

kubectl kots get config \
    --namespace gitguardian \
    --decrypt \
    --appslug gitguardian > config.yaml

caution

The backup configuration contains secrets. Ensure it is stored securely and access is strictly controlled.

If needed, specify the Kubernetes namespace with --namespace (the default namespace is used if not specified).

KOTS offers a mechanism to simplify backups of your GitGuardian application. For detailed information on backup and restore, including Velero Version Compatibility, please refer to the Replicated website.

Restore

Restoring the GitGuardian instance depends on the situation. Do you just want to go back in time to a previous database backup? Are you looking to roll back to a previous version of the application? Did you lose your database and/or Kubernetes cluster and need to restore the application and database from scratch?

Database restore only

To restore the PostgreSQL database, follow these steps:

Stop the application.
Flush the Redis cache.
Restore the PostgreSQL database.
Restart the application.

Application version rollback

danger

Do not roll back or downgrade without consulting our support team first. Certain scenarios may require restoring the database from a pre-upgrade backup due to the complexity of reversing some database migrations.

Disaster Recovery

In the event that you need to reinstall the application from scratch for disaster recovery, follow the appropriate installation procedure based on your setup:

Helm-Based Installation

Use your previously backed-up values file.
Ensure you specify the encryption key by either:
- Using the inline parameter miscEncryption.djangoSecretKey, or
- Referencing an existing secret with miscEncryption.existingSecret.

KOTS-Based Installation

Follow the installation procedure for your KOTS setup.
Configure the installation with the essential settings.
Once the installation is complete, restore the KOTS configuration files using the following command:
```
kubectl kots install gitguardian \
    --namespace gitguardian \
    --use-minimal-rbac \
    --shared-password <set_new_password> \
    --license-file license.yaml \
    --config-values config.yaml
```
- Replace <set_new_password> with your desired password (used to access KOTS Admin Console).
- Adjust the namespace if necessary.
- Ensure you use the config.yaml file from your backup.
- This command must be executed on a non-existent or empty namespace (i.e., no prior KOTS installation).
In the KOTS Admin Console, verify that the configuration is correct and deploy the application.

Backup & Restore