Binions backs itself up automatically every day — but before any upgrade, take a fresh backup first. An upgrade changes packages and may advance your database and state, so a snapshot taken minutes beforehand is your safety net if you ever need to roll back. The good news: a backup is one command, and the platform already runs the same job nightly, so you are never starting from scratch.
Good to know. Restoring from a backup is a manual procedure on Binions today — there is no one-command restore tool yet. Taking a backup is fully automated; putting one back is a deliberate, step-by-step task documented under Backup & restore.
A single backup script collects everything needed to reconstruct your platform’s state and uploads it, as a dated folder, into the MinIO object-storage bucket binions-backups/<date>/. Each run captures three things:
binions database using the appropriate tool for your configured backend (for example, pg_dump for PostgreSQL), gzipped. This holds your durable application data (licences, accounts, schedules, persisted records)..rdb snapshot file per instance.config and secrets directories under /opt/binions, so your tuning and credentials are preserved alongside the data.The platform is single-host by design, so one backup folder is a complete picture of that host — there is no cluster state to chase down elsewhere.
Every run is self-checking, so a backup that lands in the bucket is one you can trust:
SHA256SUMS manifest hashing every payload (the database dump, each Redis snapshot, the config archive).SUCCESS file (timestamped) is written for the day’s folder. It is your at-a-glance signal that the backup completed end to end.Verify before prune. Old snapshots are only removed after the checksum re-verify succeeds. A corrupted upload can never cause your previous good backups to be deleted.
The nightly job runs in the early hours, so by upgrade time it may be many hours stale. Run the backup yourself, on demand, immediately before you upgrade. Run it as root:
sudo binions-backupIt logs each step as it works — the database dump, each Redis snapshot, the config archive, the upload, and the verify pass — and finishes with a done line. When it returns successfully, confirm today’s snapshot is present and complete: look for a folder named for today’s date under the binions-backups bucket, containing a SUCCESS marker and a matching SHA256SUMS manifest. With that confirmed, you are clear to proceed with the upgrade.
Tip. Pair this with the upgrade flow: take the backup, run the apt upgrade, then work through the post-upgrade checklist. If anything looks wrong afterwards, you can pin back to the previous version — see Rollback & downgrade.
Recovering from a backup reverses the steps above: restore the database dump using the appropriate tool for your configured backend, load each daemon’s Redis snapshot, and unpack the config/secrets archive. There is no automated restore command at this stage — restoring is a careful, manual operation you perform deliberately, not a button you press. The full procedure, with the exact order of operations and the checks to run afterwards, lives on the Administration page below. Read it before you need it, so a recovery is never your first time through the steps.