Because the whole of Binions runs on a single host, backing it up is refreshingly simple. There is no cluster to coordinate and no external cloud holding your data — everything lives on one machine. That means you can protect a Binions install in one of two ways: take a snapshot of the whole host, or copy a short, well-defined list of files and data stores. This page explains both, with real commands you can adapt.
Good to know. Binions does not ship a one-button backup command. The commands below are standard Linux and database tools (
tar,mc, and the appropriate database dump utility for your configured backend) shown as examples. Adapt the paths and storage targets to your own environment, and always test that a backup actually restores.
Because Binions is a single-host platform, one snapshot of the host captures the entire system at once — the daemons, all configuration, every secret, the databases, the object store, and Redis state, all in a consistent set. If you run Binions inside a virtual machine or container and you control the hypervisor, this is by far the easiest and most complete option.
Tip. For the most consistent snapshot, take it while the platform is quiet, or briefly stop the Binions services first. A snapshot taken mid-write can still be restored, but a quiet snapshot avoids any chance of an in-flight database transaction being captured half-finished.
If you cannot snapshot the whole host — or you prefer a smaller, portable backup — you only need to capture a handful of things. The table below lists every location that holds state worth keeping.
| Configuration | Each daemon's /opt/binions/<service>/config/ (its application.toml and any per-domain config) plus the platform-wide /etc/binions/master.toml. |
| Secrets | Each daemon's /opt/binions/<service>/secrets/ and the Traefik certificate and key under /opt/binions/traefik/secrets/. These contain credentials — store them securely. |
| Databases | The data store used by the database daemon. The correct backup tool depends on your configured backend — for example pg_dump for PostgreSQL, mysqldump for MySQL, mongodump for MongoDB, or a file copy for SQLite. MS SQL Server has its own native backup tooling. |
| Object storage | The MinIO object store data (any files your playbooks have uploaded or generated). |
| Redis state | Each daemon runs its own Redis instance, which keeps its AOF/RDB files under that daemon's own data directory. Back up those data directories to preserve runtime state. |
| Licence files | /etc/binions/<daemon>.license. Worth keeping, but not critical — licences can be re-issued from your account if lost. |
| Logs (optional) | /var/log/binions/<service>/. Useful for auditing or troubleshooting, but not required to restore the platform. |
The commands below are illustrative examples, not a supported tool. They show the standard utilities you would use for a file-level backup. Adjust user names, paths, and database names to match your install, and run them as a user with the right permissions (the secrets directories are deliberately locked down).
The backup command depends on which backend the database daemon is configured to use. The example below shows a PostgreSQL dump; use the equivalent tool for your backend (mysqldump, mongodump, a file copy for SQLite, or your MS SQL Server backup tool).
# Example: dump a PostgreSQL-backed Binions database to a timestamped file.
# Replace the database name and connection details with your own.
# For other backends, substitute the appropriate tool (mysqldump, mongodump, etc.).
pg_dump --format=custom --file="binions-db-$(date +%F).dump" binions# Example: archive all daemon config + secrets + the platform master config.
# This captures /opt/binions/*/config, /opt/binions/*/secrets and /etc/binions.
sudo tar --create --gzip \
--file="binions-config-secrets-$(date +%F).tar.gz" \
/etc/binions \
/opt/binions/*/config \
/opt/binions/*/secretsFor the MinIO object store, copy its data with your usual object-storage tooling (for example the MinIO client, mc mirror, against a target bucket or directory). For Redis, include each daemon's data directory in your file copy so its AOF/RDB files are captured.
Handle secret backups with care. The archive above contains live credentials — database passwords, API keys, and TLS private keys. Store it encrypted and somewhere with strict access control. A leaked secrets backup is as dangerous as a leaked production host.
The detailed, step-by-step restore procedure lives in Backup and restore. At a high level, restoring a file-level backup follows the reverse of the steps above:
config/ and secrets/ directories and /etc/binions/ back in place, with the correct ownership and permissions.Restoring a whole-host snapshot is simpler still: roll the host back to the snapshot and the platform returns exactly as it was, no per-component restore required.
Retention is your call. How many backups you keep and for how long depends on your own recovery needs and any compliance rules you must meet. Choose a retention policy that fits your business rather than a fixed default.