# 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.** The [audit log database](https://zato.io/docs/admin/audit-log/index.html) 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](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:** 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 [ODB](https://zato.io/docs/admin/odb.html) 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](https://zato.io/docs/admin/audit-log/index.html) 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](https://zato.io/docs/eda/) 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](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) - The SQLite database that the container recreates from the project at each start
- [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 best practices](https://zato.io/docs/admin/production-best-practices.html) - What to configure 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