-
How-to guides
- π₯ Set up backups
- ποΈ Make per-application backups
- π Provide your passwords
- βοΈ Make backups redundant
- π Deal with very large backups
- π Inspect your backups
- π¨ Monitor your backups
- π€ Extract a backup
- ποΈ Backup your databases
- πΈ Snapshot your filesystems
- π§Ή Add preparation and cleanup steps
- πΎ Backup to a removable drive/server
- π§ Run arbitrary Borg commands
- π₯ Customize warnings/errors
- π¦ Upgrade borgmatic/Borg
- ποΈ Develop on borgmatic
-
Reference guides
- βοΈ Configuration
- π» Command-line
- π Source code
New in version 1.9.11 When running inside a container, borgmatic can read Docker secrets and Podman secrets. Creating those secrets and passing them into your borgmatic container is outside the scope of this documentation, but here's a simple example of that with Docker Compose:
services:
borgmatic:
# Use the actual image name of your borgmatic container here.
image: borgmatic:latest
secrets:
- borgmatic_passphrase
secrets:
borgmatic_passphrase:
file: /etc/borgmatic/passphrase.txt
This assumes there's a file on the host at /etc/borgmatic/passphrase.txt
containing your passphrase. Docker or
Podman mounts the contents of that file into a secret named
borgmatic_passphrase in the borgmatic container at /run/secrets/.
Once your container secret is in place, you can consume it within your borgmatic configuration file:
encryption_passphrase: "{credential container borgmatic_passphrase}"
This reads the secret securely from a file mounted at
/run/secrets/borgmatic_passphrase within the borgmatic container.
The {credential ...} syntax works for several different options in a borgmatic
configuration file besides just encryption_passphrase. For instance, the
username, password, and API token options within database and monitoring hooks
support {credential ...}:
postgresql_databases:
- name: invoices
username: postgres
password: "{credential container borgmatic_db1}"
You can also optionally override the /run/secrets directory that borgmatic reads secrets from
inside a container:
container:
secrets_directory: /path/to/secrets
But you should only need to do this for development or testing purposes.
Improve this documentation
Have an idea on how to make this documentation even better? Use our issue tracker to send your feedback!