er databases. This is the default backup strategy.database - the database is copied to a backup database in the same database server. This requires the ZENML_STORE_BACKUP_DATABASE environment variable to be set to the name of the backup database. This backup strategy is only supported for MySQL compatible databases and the user specified in the database URL must have permissions to manage (create, drop, and modify) the backup database in addition to the main database.

dump-file - the database schema and data are dumped to a filesystem location inside the ZenML server container. This location can be customized by means of the ZENML_STORE_BACKUP_DIRECTORY environment variable. When this strategy is configured, users should mount a host directory in the container and point the ZENML_STORE_BACKUP_DIRECTORY variable to where it's mounted inside the container. If a host directory is not mounted, the dump file will be stored in the container's filesystem and will be lost when the container is removed.

The following additional rules are applied concerning the creation and lifetime of the backup:

a backup is not attempted if the database doesn't need to undergo a migration (e.g. when the ZenML server is upgraded to a new version that doesn't require a database schema change or if the ZenML version doesn't change at all).

a backup file or database is created before every database migration attempt (i.e. when the container starts). If a backup already exists (i.e. persisted in a mounted host directory or backup database), it is overwritten.

the persistent backup file or database is cleaned up after the migration is completed successfully or if the database doesn't need to undergo a migration. This includes backups created by previous failed migration attempts.

the persistent backup file or database is NOT cleaned up after a failed migration. This allows the user to manually inspect and/or apply the backup if the automatic recovery fails.