Skip to main content

Backups

Strategy#

Backup#

To fully backup the GitGuardian application, you need three things:

  • To backup the postgres
  • To backup the redis
  • To backup the Kots config

Backuping the embedded postgres and redis is possible (see below), but it is not the recommended way to run GitGuardian in production. We recommend using externally managed databases and datastores, and use the associated strategy for snapshots and backups.

Then, you will need to backup the KOTS config files. You can use these commands:

kubectl kots download -n <YOUR_NAMESPACE> gitguardian-seal --dest .
cp -r gitguardian-seal <BACKUP_LOCATION>

Do not edit this files manually.

Restoration#

To restore a GitGuardian instance, first restore the database and datastore.

Then, install a new KOTS instance, and configure it the most basic setup: embedded database, basic hostname... All these parameters will be replaced in the next step.

Finally, you can restore the manifests:

kubectl kots upload -n <YOUR_NAMESPACE> <SOURCE_FOLDER>

Connect to the admin console and deploy the uploaded version. You may have to edit the database's hosts.

KOTS Backups (beta)#

Beta status#

Backups are still a beta. But data export is mostly stable and safe. Import and restore might still have some issues. So, in case of a disaster recovery, data will not be lost, but restoration can be a bit tedious.

These backups can be used if you are using the embedded database and datastore.

Management#

Backups can be managed through the admin console. Backups can be launched manually or be scheduled to run daily, weekly, etc.

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

They can also be restored through the admin console.

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

Postgres writes changes almost immediately to disk. In case of a crash, it should restart with all the data. Backups will be used in cases mentionned 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 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 restarted.