Backup

info

Looking for the GitGuardian legacy architecture Backup page? Please visit the Backup (legacy) page.

For information on the new architecture, as well as determining whether you are using the new or the legacy GitGuardian architecture, explore the New GitGuardian Architecture page.

Strategy

info

For detailed information on backup and restore, including the Velero Version Compatibility, please refer to the Replicated website.

caution

GitGuardian encrypts all sensitive information in the database using a data encryption key (aka Django Secret Key). In case of disaster recovery, this key will be needed to restore your data.

Regardless of the installation method (whether KOTS or Helm), ensure the encryption key is securely stored and you have access to it.

Backup

To fully backup the GitGuardian application, you need:

• To back up the PostgreSQL
• To back up the Redis
• To back up the KOTS config (for KOTS-based installation)
• To back up the Helm config (for Helm-based installation)

Backing up embedded PostgreSQL and Redis instances is feasible, yet not advised for running GitGuardian in a production environment. We strongly recommend utilizing externally managed databases and data stores, complemented by a robust strategy for snapshots and backups.

For KOTS-based installation, backup up the KOTS config files using:

kubectl kots download --namespace <namespace> gitguardian --dest .

cp -r gitguardian <backup_location>

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

danger

Do not edit these files manually.

Restore

To restore a GitGuardian instance, start by restoring the database and datastore.

For a KOTS-based installation, begin by installing a new KOTS instance and configuring it with the essential settings: use an embedded database and a basic hostname, among others. These initial configurations will be updated in the subsequent step.

To proceed with the restoration of manifests:

kubectl kots upload --namespace <namespace> <source_folder>

Next, access the KOTS Admin Console to deploy the version you've uploaded. During this process, it might be necessary to adjust the database host settings.

KOTS Snapshots

KOTS offers a mechanism to simplify the backups of your GitGuardian application.

info

This procedure has been only tested on embedded clusters.

Management

Backups can be managed through the KOTS Admin Console. Backups can be launched manually or scheduled to run daily, weekly, etc.

Backups are only used for the embedded PostgreSQL and the embedded Redis. External databases are not backed up or managed.

Backups can be restored through the KOTS Admin Console for rollback purposes, or via CLI in case of a disaster recovery. See below for more information.

Types: full vs partial

There are 2 types of snapshots: full and partial.

• Partial snapshots only save the GitGuardian application data. It includes the embedded databases if you use them, your config set in the config page, and a copy of the Kubernetes' manifests for the GitGuardian application. They cannot be used on another instance.
• Full snapshots include everything in the partial snapshots, but also the license, and the KOTS data (databases, manifests, support bundles...). They can be used in another instance (for example for disaster recovery).

We recommend doing full snapshots since they allow for both full and partial restores.

Storage

By default, snapshots are only stored on the cluster, and they need to be exported. You can also choose to upload these to an AWS S3 bucket or another S3-compatible storage. More information on how to configure it is available here.

Schedule

There is no default automatic backup schedule. We recommend configuring a schedule.

Usage

These backups will mainly be used in two cases:

• A cluster crash/wipe: The persistent volumes containing the data do not exist anymore, only backups have a recent copy of the data.
• Rolling back the application if all else failed.

Postgres backups

PostgreSQL writes changes almost immediately to disk. In case of a crash, it should restart with all the data. Backups will be used in the cases mentioned above. Postgres is backed up using the pg_dumpall command. The SQL file is then compressed and sent to the location of your choice. During restoration, using the "Restore" button on the KOTS Admin Console, an empty database is created, and the SQL dump file is applied to it.

Redis backups

We are using the RDB persistence for Redis. Snapshots are done every 30s if there is at least 1 change over this period. In the event of a Redis crash, this snapshot will be used at Redis restart. During backups, the latest snapshot is exported to the location of your choice. During restoration, the backed-up snapshot is copied, and Redis is restarted.

KOTS Restore

Via KOTS Admin Console

The KOTS Admin Console allows you to perform a partial restore. It will only restore the GitGuardian application, not the KOTS/kURL dependencies. This is useful when the application is in a bad state after an update.

To do this, go to the "Snapshots" tab. Then you can use either the full snapshots or the partial snapshots. Go to the "Full Snapshots" or "Partial Snapshots" tab, depending on how you configured your backups. Choose the backup you want to restore. You can use the timestamp (underline in red in the screenshots below) to choose the correct one. Then click on the blue $ rotating arrows. A dialog will open up with instructions. With a full snapshot, you have 2 options, but only the partial restore can be done from the web interface, for the full restore, you will need to use the given command line.

Via CLI

With the CLI, you can perform a full instance restore. This is useful to transfer GitGuardian to another instance, or for a disaster recovery.

The easiest way to get instructions for a restore is to go to the snapshot tab, select the correct snapshot, and get the instructions by clicking on the two blue rotating arrows. Then, go to your instance, and run the command.

Example: Recreate a fully embedded instance

Here, we will describe a situation where we do a backup of GitGuardian on instance A to restore it on instance B.

First, in instance A, you need to create a directory owned by user 1001 and group 1001:

mkdir ${HOME}/kots-backups
chown -R 1001:1001 ${HOME}/kots-backups

Then configure Velero to use this directory for snapshots with KOTS CLI:

kubectl kots -n default velero configure-hostpath --with-minio=false --hostpath ${HOME}/kots-backups

And create a snapshot. Copy the backup name once it's finished:

kubectl kots backup

You will now need to copy the whole backup folder (${HOME}/kots-backups here) to instance B. To do it, we advise you to create an archive (zip, tar...), and copy it:

# Instance A
cd ${HOME}
zip -r kots-backups.zip kots-backups

# Your laptop/workstation
scp instance_a:kots-backups.zip .
scp kots-backups.zip instance_b:.

# Instance B
cd ${HOME}
unzip kots-backups.zip
chown -R 1001:1001 ${HOME}/kots-backups

If it's not already done, install the embedded Kubernetes cluster on instance B:

curl -sSL https://kurl.sh/gitguardian | sudo bash

Now you can configure Velero on this new Kubernetes cluster:

kubectl kots -n default velero configure-hostpath --with-minio=false --hostpath ${HOME}/kots-backups

And finally, restore the backup created on instance A:

kubectl kots restore --from-backup=<backup-name>

You can now change your DNS/reverse proxy/load balancer, to redirect traffic to the new instance.

Was this page helpful?