You are reading the documentation for an outdated Corteza release. 2024.9 is the latest stable Corteza release.

Backups

We recommend backing up your database and uploaded files regularly. It is also highly recommended to do a backup before you upgrade to a more recent Corteza version.

You can define a cron job that backups your data to some external storage.

DevNote add some example setups, as we have now with a CRON job?

MySQL database

Backup

We recommend you use the mysqldump tool. It’s builtin into the db container (percona:8.0 image).

Do not try to copy raw database files to perform a backup. It might lead to corrupted data.

If you want to use a different tool to create your backup, you will need to connect to the container or publish MySQL ports.

If you’re using a different database engine, refer to their documentation on how to perform backups.

By default, mysqldump locks the tables when you run the export. Table locks might cause issues when running in production, so do keep this in mind.

Database dump command:
# This will dump the entire database and place it in the dump.sql file.
docker-compose exec -T \
    --env MYSQL_PWD=your-password db \
    mysqldump your-db-name --add-drop-database -u your-username > dump.sql

If you’ve changed the database service name (db) inside your docker-compose.yaml, make sure to change it in the above command.

Restore

We recommend that Corteza server is shut-down until the restore procedure finishes.

Database restore command:
# This will restore the database based on the dump.sql file
docker-compose exec -T \
    --env MYSQL_PWD=your-password db \
    mysql your-db-name -u your-username < dump.sql

If you’ve changed the database service name (db) inside your docker-compose.yaml, make sure to change it in the above command.

PostgreSQL database

Backup

We recommend you use the pg_dumpall or pg_dump tool. pg_dumpall is a utility for writing out ("dumping") all PostgreSQL databases of a cluster into one script file. The script file contains SQL commands that can be used as input to psql to restore the databases. It does this by calling pg_dump for each database in a cluster.

Do not try to copy raw database files to perform a backup. It might lead to corrupted data.

If you want to use a different tool to create your backup, you will need to connect to the container or publish PostgreSQL ports.

If you’re using a different database engine, refer to their documentation on how to perform backups.

By default, pg_dump locks the tables when you run the export. Table locks might cause issues when running in production, so do keep this in mind.

Database dump command:
# This will dump all databases and place them in the dump.sql file.
docker-compose exec db \
    pg_dumpall -c -U your-username > dump.sql

# This will dump the entire database and place it in the dump.sql file.
docker-compose exec db \
    pg_dump -d your-db-name -c -U your-username > dump.sql

# To reduce the size of the sql,
# This will dump all databases and place them in the dump.gz file.
docker-compose exec db \
    pg_dumpall -c -U your-username | \
    gzip > /var/data/postgres/backups/dump.gz

If you’ve changed the database service name (db) inside your docker-compose.yaml, make sure to change it in the above command.

Restore

We recommend that Corteza server is shut-down until the restore procedure finishes.

Database restore command:
# This will restore the database based on the dump.sql file
cat dump.sql | \
    docker-compose exec db psql -U your-username

# This will restore a specific database based on the dump.sql file
cat dump.sql | \
    docker-compose exec db psql -U your-username -d your-db-name

# To restore a compressed sql,
# This will restore the database based on the dump.gz file
gzip < dump.gz | \
    docker-compose exec db psql -U your-username

If you’ve changed the database service name (db) inside your docker-compose.yaml, make sure to change it in the above command.

Files

Backup

Without object storage service like Min.io, uploaded files are stored directly on the filesystem. Corteza server stores data to the /data directory (if not configured differently with *_STORAGE_PATH environmental variables).

You can use any standard file management tools to make a backup copy of the files.

Compressing files with the tar command:
# This will compress all your uploaded files into the backup.tar.bz2 archive
tar -cjf backup.tar.bz2 data/server/

Restore

Uncompromising files from the archive with the tar command:
# This will restore your backup.tar.bz2 archive
tar -xjf backup.tar.bz2