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 deploys 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. The audit log database can run on MySQL, PostgreSQL or Oracle DB outside the container rather than on its default SQLite database.

It is an ordinary database, so back it 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 with the Zato_Audit_Log_DB_* variables 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 ODB lives inside the container, which creates it again at each start from the project's enmasse YAML, so it needs no backup of its own.
• The SQLite default of the audit log also lives inside the container. If it holds data that must be retained, run the audit log outside the container, where the section above applies.
• The pub/sub SQL store is a local SQLite file inside the container. Topics and undelivered messages in that file are not retained when the container is replaced.
• Anything you mounted yourself stays on the host and you decide whether to keep it - to send logs out of the container, 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