Collate manages SaaS backups automatically at the platform level. There is no backup job to configure or monitor in the Collate UI, and backups do not appear among ingestion pipelines or applications.
Backups run once a day during a scheduled maintenance window.
Backups are retained for approximately two weeks.
A backup includes metadata, configurations, users, teams, policies, lineage, data quality data, ingestion pipelines, and other information stored in the Collate database.
Restores recover the full database. Selective database restores for individual assets, glossary terms, tags, or configurations are not supported.
To request a restore, open a ticket with Collate Support and provide the preferred backup timestamp. A typical restore takes approximately two to three hours and includes approximately one hour of downtime. Support is available 24 hours a day, Monday through Friday. Restore requests submitted during the weekend are reviewed on Monday.
Restoring a backup replaces the environment’s current database state. Changes made after the selected backup timestamp are lost. The backup should be restored to the same Collate version, and the search index must be rebuilt after the database restore.
For recovery of individual objects, use version history, soft delete, CSV exports and imports, or the API where applicable.
Before upgrading your OpenMetadata version we strongly recommend backing up the metadata.The source of truth is stored in the underlying database (MySQL and Postgres supported). During each version upgrade there
is a database migration process that needs to run. It will make changes to the OpenMetadata Application schema in the database and update the shape of the data to the newest OpenMetadata release.It is important that we backup the data because if we face any unexpected issues during the upgrade process,
you will be able to get back to the previous version without any loss.
You can learn more about how the migration process works here.
Since version 1.4.0, OpenMetadata encourages using the builtin-tools for creating logical backups of the metadata:
For PROD deployment we recommend users to rely on cloud services for their databases, be it AWS RDS,
Azure SQL or GCP Cloud SQL.If you’re a user of these services, you can leverage their backup capabilities directly:
If you’re running the project using docker compose, the ingestion container already comes packaged with the
correct mysqldump and pg_dump versions ready to use.
Start a local instance of OpenMetadata using the docker-compose file provided in the repository. Then, we can use the following commands to backup the metadata:
BACKUP_FILE="backup_$(date +%Y%m%d%H%M).sql"export COMPOSE_FILE="docker/development/docker-compose.yml"# backupdocker compose exec ingestion mysqldump --no-tablespaces -u openmetadata_user -popenmetadata_password -h mysql -P 3306 openmetadata_db > $BACKUP_FILE# create the restore databasedocker compose exec mysql mysql -u root -ppassword -e "create database restore;"docker compose exec mysql mysql -u root -ppassword -e "grant all privileges on restore.* to 'openmetadata_user'@'%';"docker compose exec mysql mysql -u root -ppassword -e "GRANT SUPER, SYSTEM_VARIABLES_ADMIN, SESSION_VARIABLES_ADMIN ON *.* TO 'openmetadata_user'@'%';"docker compose exec mysql mysql -u root -ppassword -e "flush privileges;"# restore from the backupdocker compose exec -T ingestion mysql -u openmetadata_user -popenmetadata_password -h mysql -P 3306 restore < $BACKUP_FILE
