Skip to content

Powered by Grav

Backups internals & operations

Backups internals & operations

Off-site backup on a BOA host: a Duplicity-driven subsystem with three orchestrators — multiback, mybackup, and the legacy backboa — each with its own config and gate.

Off-site backup on a BOA host is a Duplicity-driven subsystem with three distinct orchestrators, each with its own config tree, bucket-name scheme, and licence gate. This section documents the live interface — the scripts under /opt/local/bin, the config trees they read, and the cron paths that fire them — not a generic "how to back up" walkthrough.

The three orchestrators:

  • multiback — the current root-side engine. Eleven backend keys across nine providers, per-path-set config under /root/.remote_backups/, encryption passphrase from .secret.txt, licence-gated (_tRee set to pro or dev) via _verify_boa_keys. Installed and wired by dcysetup.
  • mybackup — the tenant-facing front of multiback. Restore-only from the lshell side; scheduled backups for tenants are driven by the same root cron path, not by the tenant.
  • backboa / duobackboa — the older single-bucket AWS-S3 tools, configured inline through _AWS_* variables. They ship and run on every host (no licence gate) and remain on the static cron.d crontab. Treat them as the legacy path; new hosts use the multiback/dcysetup suite.

mysql_backup.sh (the nightly per-DB mydumper/mysqldump local dump under /data/disk/arch/sql/) is the local-restore layer that the off-site tools archive on top of — covered in Database and cross-linked where the include/exclude sets reference it.

The pages below cover the subsystem architecture, multiback install and operations, the retention rules, bucket naming across providers, the full CLI reference, and the legacy backboa path.

See the Reference appendix for the consolidated variable and command tables, and Discontinued features for tools dropped from the suite.

© 2026 BOA Documentation. All rights reserved.