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, |
# 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 ( |
Restore
We recommend that Corteza server is shut-down until the restore procedure finishes. |
# 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 ( |
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, |
# 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 ( |
Restore
We recommend that Corteza server is shut-down until the restore procedure finishes. |
# 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 ( |
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.
tar
command:# This will compress all your uploaded files into the backup.tar.bz2 archive
tar -cjf backup.tar.bz2 data/server/