Backing Up Space Docker

Hi Pawel, in fact, there's nothing specific in the Space On-Premises installation in this regard, so feel free to stick to the approaches recommended by Docker:

1. Back up and restore volumes themselves: https://docs.docker.com/storage/volumes/#back-up-restore-or-migrate-data-volumes

2. Bind mounts to the host path and backup the host path itself: https://docs.docker.com/storage/bind-mounts/#use-a-bind-mount-with-compose

I recommend Back up and restore volumes themselves. 

another way 'Bind mounts to the host path and backup the host path itself' is cause painful lfs-object uploading speed.

True...I would not use bind mounts either...but still there are many containers and lots of volumes to restore and backup.  I was hoping there was something simpler like a 'spacedump' as in 'mysqldump' to simplify backup and restore.

Pawel,  we're working on simplifying the backup and restore process for the Space installation and will share the results once ready. Talking about the DB in particular, you're right, the safest option would be using native means of PostgreSQL for this. In our case, it's a pg_dump command that results in a snapshot of the DB described as an SQL file. It can later be used to restore the DB from scratch.

I prepared a simple script that makes the process a bit easier. It allows using backup and restore commands, and takes 3 arguments in both cases:

• `DB_CONTAINER_ID` is the ID of the postgres container. Can be acquired with the `docker ps` command.
• `DB_USERNAME` is the `services.postgres.environment.POSTGRES_USER` value from the docker-compose.yml. By default it's `space`.
• `DB_NAME` is the `services.postgres.environment.POSTGRES_DB` value from the docker-compose.yml. By default it's `spacedb`.

#!/bin/bash

DB_CONTAINER_ID="$2"
DB_USERNAME="$3"
DB_NAME="$4"

if [ $# -ne 4 ]; then
    # incorrect number of arguments
    echo "Not all arguments are specified. Usage: script.sh [backup|restore] [DB_CONTAINER_ID] [DB_USERNAME] [DB_NAME]"
    exit 1
fi

case "$1" in
    backup)
    echo "Running backup command..."
    docker exec -t $DB_CONTAINER_ID pg_dump -U $DB_USERNAME -d $DB_NAME > spacedb_dump.sql
    echo "Backup created"
    ;;
    
    restore)
    echo "Running restore command..."
    docker exec -i $DB_CONTAINER_ID psql -U $DB_USERNAME -d $DB_NAME < spacedb_dump.sql
    echo "Restore completed"
    ;;
    
    *)
    # invalid argument
    echo "Invalid command. Usage: script.sh [backup|restore]"
    exit 1
    ;;
esac

The overall backup & restore process is as follows:

1. execute `script.sh backup [DB_CONTAINER_ID] [DB_USERNAME] [DB_NAME]`;
2. stop the installation;
3. assuming, there are no volumes with DB data anymore, start a DB container via `docker compose up postgres`;
4. execute `script.sh restore [DB_CONTAINER_ID] [DB_USERNAME] [DB_NAME]`;
5. start the whole installation again with `docker compose up`.

Wow...thanks, Pavel, for sharing.  So this implies that everything is persisted in the Postgres database?  There is nothing else to backup, except for the conf directory in case it was generated locally when initially installing space?  Awesome...I am going to try and test this.  Thanks for sharing.

Pawel, sorry for not being clear: my previous alswer only covers the DB backup process. Space also utilizes Minio as object storage for git, packages and other binary entities. It should also be backed up after the DB backup is done.

Just as in the case of DB, I'd recommend using a native option provided by Minio: https://min.io/docs/minio/linux/reference/minio-mc/mc-mirror.html

The process is pretty similar, but I haven't had a chance to document it yet. In general, you need to install a Minio Client (mc) tool on the host machine, make an alias to your Minio instance with `mc alias ...` and then execute `mc mirror ...` for all buckets there.

The order of backups is important: 1. DB backup; 2. object storage backup.