# Backup

Back up everything a Zato environment needs to be recreated on any machine.

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 {#the-project-in-git}

**Backup.** Your project - the services, the [enmasse](https://zato.io/docs/admin/enmasse.html) 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](https://zato.io/docs/admin/enmasse.html#environment-variables) for how the references work.

**Restore.** Start a container with the project mounted and `Zato_Project_Root` pointing at it, following the [deployment tutorial](https://zato.io/tutorials/devops/deployment.html). 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 {#any-sql-database-outside-the-container}

**Backup.** Two databases can live outside the container:

- The [ODB](https://zato.io/docs/admin/odb.html), when it is MySQL or PostgreSQL rather than the SQLite default
- The [audit log database](https://zato.io/docs/admin/audit-log/index.html), 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](https://zato.io/tutorials/devops/env-variables.html). A restored copy behaves the same as the original - the container connects to the database that its variables point at.

> **Note:** The ODB can be rebuilt from the project at any time, so a missing ODB backup costs time rather than information. Audit events cannot be rebuilt from anything, so if you keep records for compliance, give the audit log backups the same retention guarantees as the records themselves.

## What needs no backup {#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](https://zato.io/docs/admin/odb.html) and the [audit log](https://zato.io/docs/admin/audit-log/index.html) 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](https://zato.io/docs/admin/logging.html).

## After a restore {#after-a-restore}

The checks are the same as after any start - the server answers its [ping endpoint](https://zato.io/docs/admin/ping.html), the Dashboard loads, the services are deployed, and the log is free of errors. For the full list, see [starting and stopping](https://zato.io/docs/admin/start-stop.html).

## See also {#see-also}

- [ODB configuration](https://zato.io/docs/admin/odb.html) - Running the operational database on MySQL or PostgreSQL
- [Audit log](https://zato.io/docs/admin/audit-log/index.html) - The database of API traffic records and its retention
- [Enmasse](https://zato.io/docs/admin/enmasse.html) - The YAML export that makes the project the environment's definition

## Learn more {#learn-more}

- [Production checklist](https://zato.io/docs/admin/production-checklist.html) - What to confirm before an environment takes real traffic
- [Audit log](https://zato.io/docs/admin/audit-log/) - Every request, response and error, and what you can do with them afterwards
- [Health checks](https://zato.io/docs/admin/health-checks.html) - Have Zato ping your outgoing connections instead of waiting for traffic to fail
- [Logging](https://zato.io/docs/admin/logging.html) - What is written where, and how to ship it to Splunk, Loki, Elastic or Datadog
- [GitOps with enmasse](https://zato.io/docs/admin/enmasse.html) - Keep the whole environment in git as YAML and import it anywhere