Binions backs itself up automatically, every night, with nothing for you to set up. A bundled backup job captures the three things that hold all of your state — your configured database, every daemon’s private Redis store, and your configuration and secrets — verifies each one against a checksum manifest, and keeps a week of daily snapshots in object storage. This page explains exactly what is captured, where it lands, how integrity is guaranteed, and how to restore by hand when you need to.
Good to know. The nightly backup runs out of the box. A fresh install already has the job scheduled, so you do not need to configure anything to be protected from day one — you only need to make sure the snapshots are going somewhere you trust, and that you have tested a restore.
A backup is the complete state of your Binions installation, split into three artifacts. Together they are everything needed to rebuild the platform on a clean host:
pg_dump for PostgreSQL, mysqldump for MySQL/MariaDB, mongodump for MongoDB). The resulting file is then gzip-compressed before upload.Nothing else is needed: the binaries themselves come from the package repository via apt, so a backup is only the state that is unique to your installation.
The backup runs once a day from a system cron entry, early in the morning, as root — root access is required so the job can read every daemon’s data directory and secret files regardless of which service user owns them.
# /etc/cron.d/binions-backup
13 3 * * * root /usr/local/sbin/binions-backupThat is 03:13 UTC every day. Each run logs to the system journal under the tag binions-backup, so you can read exactly what the most recent run did — and confirm it finished cleanly — like this:
# everything the last backup logged
journalctl -t binions-backup --since today
# follow tonight's run live
journalctl -t binions-backup -fRun one on demand. You do not have to wait for 03:13. You can trigger an immediate backup — for example, just before an upgrade — by invoking the script yourself:
sudo binions-backupSnapshots are written into the platform’s built-in object store (the bundled MinIO S3 service that already runs on your host), into a bucket named binions-backups. Each run gets its own dated folder, so the layout reads like a calendar:
binions-backups/
└── 2026-05-31/
├── database-binions.sql.gz # database dump, gzip-compressed
├── redis-logger.rdb # one snapshot per daemon
├── redis-database.rdb
├── redis-playbook.rdb
├── redis-mailbox.rdb
├── ... # one .rdb for every daemon
├── config-secrets.tar.gz # config + playbooks + secrets
├── SHA256SUMS # checksum manifest (see below)
└── SUCCESS # written last, only on a clean runThe Redis snapshot files are named after the daemon they belong to — redis-logger.rdb, redis-mailbox.rdb, and so on — which is exactly what you will match up against during a restore. The SUCCESS marker is written last, and only if every preceding step (including the integrity re-check) passed. That makes it your one-glance signal that a given day’s folder is whole and safe to restore from: no SUCCESS file, no trust.
Backups are only useful if they are intact, so the job does not just hope the upload worked — it proves it. As it produces each artifact, it records that artifact’s SHA-256 checksum into a SHA256SUMS manifest. Then, after everything has been uploaded to object storage, the script does something most backup tools skip: it reads every blob back out of the store and re-hashes it, comparing the result against the manifest.
This round-trip is a guard against silent corruption — a truncated upload, a flipped bit on disk, a half-written file. If any re-fetched artifact’s hash does not match the manifest, the run fails loudly, and — crucially — the SUCCESS marker is never written, so the broken day is never mistaken for a good one. You can repeat the same check yourself at any time:
# verify a snapshot you have fetched into the current directory
sha256sum -c SHA256SUMSWhy this matters. A backup that cannot be restored is worse than no backup, because it gives false confidence. The verify-after-upload step means that a folder carrying a
SUCCESSmarker has been read back and proven byte-for-byte correct — not merely written and forgotten.
The job keeps a rolling seven days of snapshots. After a successful run, dated folders older than the retention window are pruned from the bucket, so you always have roughly the last week of nightly backups and never an unbounded, ever-growing store.
| Frequency | Daily, at 03:13 UTC |
| Snapshots kept | 7 most recent days |
| Older snapshots | Pruned automatically after a clean run |
| Marker of a good run | SUCCESS file in the day’s folder |
Seven days covers the common case — spotting a problem within a few days and rolling back. If your policy needs longer retention, copy the dated folders you want to keep out to separate, off-host storage on your own schedule; the object store is the working set, not your long-term archive.
There is no one-command restore yet. Restore is a deliberate, manual procedure — the exact reverse of the backup job. There is no first-class
restoretool in the current release, so follow the steps below carefully and in order. Order matters: stop the affected daemons first, restore their data, then bring them back.
1. Pick a snapshot. List the dated folders in the bucket and choose the most recent one that carries a SUCCESS marker.
# list available snapshot days (mc = the bundled object-store client)
mc ls binions-backups/
# fetch one day's snapshot into a working directory
mkdir -p /var/tmp/binions-restore
mc cp --recursive binions-backups/2026-05-31/ /var/tmp/binions-restore/2. Verify it before you touch anything. Re-check the artifacts against the manifest. If this does not report OK for every file, stop — pick an earlier day rather than restoring from a damaged snapshot.
cd /var/tmp/binions-restore
sha256sum -c SHA256SUMS3. Stop the affected daemons. Restoring into a running daemon corrupts its state. Stop the daemons you are restoring — both the service and its paired Redis instance — before overwriting their data. To restore the whole platform, stop them all:
# stop a single daemon and its Redis (example: mailbox)
sudo systemctl stop binions-mailbox.service redis-binions-mailbox.service
# or stop the entire platform before a full restore
sudo systemctl stop binions.target4. Restore the database. The database artifact is a compressed dump produced by the tool that matches your configured backend. Decompress it and replay it using the appropriate restore utility for your database engine. The procedure below shows a PostgreSQL example; users on other backends should use their engine’s own restore utility (for example, mysql for MySQL/MariaDB, mongorestore for MongoDB, sqlcmd for MS SQL Server) following the same principle: decompress the archive and pipe or import it into the Binions database.
# PostgreSQL example — decompress and replay the SQL dump
gunzip -c /var/tmp/binions-restore/database-binions.sql.gz \
| sudo -u postgres psql binionsFor other backends, decompress the archive first, then use your engine’s standard import command against the same target database name (binions by default), before proceeding to the next step.
5. Restore each daemon’s Redis state. Each redis-<daemon>.rdb file goes back into that daemon’s own Redis data directory under its expected filename. Do not guess those paths — read them from that instance’s config file, which tells you the directory (dir) and the on-disk filename (dbfilename):
# find the real data dir + filename for one instance (example: logger)
grep -E '^(dir|dbfilename)' /etc/redis/binions-logger.conf
# copy the snapshot into place under the filename Redis expects, then start it
sudo cp /var/tmp/binions-restore/redis-logger.rdb /var/lib/redis-binions-logger/dump.rdb
sudo chown redis: /var/lib/redis-binions-logger/dump.rdb
sudo systemctl start redis-binions-logger.serviceRepeat for every daemon you are restoring, each time reading dir and dbfilename from the matching /etc/redis/binions-<daemon>.conf — the destination directory and filename can differ per instance, which is why you check rather than assume.
6. Restore configuration and secrets. Unpack the config-and-secrets archive over the platform’s directories, preserving ownership and permissions:
sudo tar -xzpf /var/tmp/binions-restore/config-secrets.tar.gz -C /7. Bring the daemons back and check readiness. Start the platform again and confirm each daemon reports itself ready. The console’s status command rolls every daemon’s readiness into one table:
sudo systemctl start binions.target
binions-cliconsole statusWhen every row shows an UP state, the restore is complete. A row that stays down points you straight at the daemon to investigate — see Daemon won’t start and Health checks & readiness.
A backup you have never restored is a guess, not a guarantee. The single most valuable habit in this whole page is to practise a restore before you need one — ideally onto a spare or throwaway host so you can rehearse the full procedure without risk to production.
sha256sum -c SHA256SUMS. It takes seconds and confirms the artifacts are intact and downloadable.SUCCESS marker. If recent days are missing their marker, the nightly job is failing — check the binions-backup journal and fix it before you actually need a restore.