Backup

A Zato environment has two things to back up - the project in Git and any SQL databases that run outside the container. Each chapter below includes the restore procedure that its backup enables.

The project, in Git

Backup. Your project - the services, the enmasse YAML, the configuration files - is the whole of your environment's definition, so keeping it in Git backs up everything that the definition consists of. The enmasse export never includes passwords, so Git holds no secrets. The YAML references them as environment variables instead - see enmasse for how the references work.

Restore. Start a container with the project mounted and Zato_Project_Root pointing at it, following the deployment tutorial. On startup, the container picks up the services from the mount, imports the YAML and reads the secrets from the Zato_Enmasse_Env variables you pass it. A project in Git plus the Zato image is enough to recreate the environment on any machine.

Any SQL database outside the container

Backup. Two databases can live outside the container:

• The ODB, when it is MySQL or PostgreSQL rather than the SQLite default
• The audit log database, when it runs on MySQL or PostgreSQL rather than SQLite

Both are ordinary databases, so back them up the way you back up your other databases - you already have procedures, tooling and a retention policy for that, and Zato adds no further requirements.

Restore. Restore the database with your database's own tooling, then point the container at it - Zato_ODB_* for the ODB and Zato_Audit_Log_DB_* for the audit log, both sets described in the environment variables reference. A restored copy behaves the same as the original - the container connects to the database that its variables point at.

What needs no backup

The container filesystem needs no backup. A container is disposable - you rebuild it from the image plus what you mount into it, so there is nothing in it worth capturing. This has two consequences:

• The SQLite defaults of the ODB and the audit log live inside the container. If either database holds data that must be retained across container replacements, run it outside the container, where the section above applies.
• Anything you mounted yourself, such as the logs directory, stays on the host and you decide whether to keep it - to ship logs off the box, see logging.

After a restore

The checks are the same as after any start - the server answers its ping endpoint, the Dashboard loads, the services are deployed, and the log is free of errors. For the full list, see starting and stopping.

See also

Learn more