Backup CLI reference

Exact dispatch and argument order for the four backup CLIs. All four wrap Duplicity; full-vs-incremental is never a CLI verb (it is decided in _set_mode), and there is no --verbose/--debug flag (verbosity is the _AWS_VLV variable, default warning).

multiback — root engine

Form: multiback <ACTION> <SERVICE> <USER> [RESTORE_TARGET] [RESTORE_PATH] [RESTORE_TIME]. <USER> is the path-set selector (global, data, custom, or a tenant). Fewer than three positionals prints usage and exits.

Action Effect Duplicity underneath
test Verify credentials + reach the bucket cleanup --dry-run --timeout 8
backup Run a backup pass now full/incremental (mode auto-selected)
cleanup Apply KEEP_WITHIN age retention remove-older-than --force
list List current files in the set list-current-files
purge Wipe the entire bucket (destructive) remove-all-but-n-full 0 --force
status Report collection status collection-status
repair Repair an incomplete backup set cleanup --force + collection-status
restore Restore (extra positionals below) restore with optional --time / --path-to-restore

There is no install/setup/update action on multiback — those belong to dcysetup (see multiback operations). purge deletes everything in the bucket; it is not an age-based trim.

multiback test b2 data
multiback backup b2 data
multiback list b2 data
multiback status b2 data
multiback cleanup b2 data
multiback repair b2 data

multiback restore

Restore is positional — there is no --time flag at the CLI. The last three arguments are optional, in this fixed order:

multiback restore <SERVICE> <USER> [RESTORE_TARGET] [RESTORE_PATH] [RESTORE_TIME]

multiback restore b2 data /var/backups/restored                  # whole set, latest
multiback restore b2 data /var/backups/restored data/disk/o1     # one subtree, latest
multiback restore b2 data /var/backups/restored data/disk/o1 7D  # one subtree, 7 days ago
  • RESTORE_TARGET — local directory to restore into (default /var/backups/restored/). Created if missing.
  • RESTORE_PATH — absolute path with no leading slash of the single file or directory to extract (omit to restore everything).
  • RESTORE_TIME — a Duplicity interval/date, e.g. 1D, 2W, 1M.

Restored content lands under RESTORE_TARGET (a basename-joined subdir); it does not overwrite the original on disk — rsync/mv it back yourself.

mybackup — tenant front

Tenant-facing, scoped to the lshell account. The only action a tenant may invoke is restore; scheduled backups, cleanup and listing are driven by the root-side run, not the tenant. Form (the account is implicit — no <USER>):

mybackup restore <SERVICE> [RESTORE_PATH] [RESTORE_TIME]

mybackup restore aws static/projects 1D
mybackup restore b2 static/another-project 2W

RESTORE_PATH is an absolute path without a leading slash and may not contain whitespace or shell metacharacters (the queue path validates this); RESTORE_TIME matches the days/weeks/months/years form. Tenant restores are queued via static/control/.run/command.txt and executed by the root-side consumer, which re-validates the arguments and drops to the tenant user (su -s /bin/bash - <user> -c 'exec mybackup ...') before running Duplicity. Restored files land in /data/disk/<user>/static/restores.

Unlike multiback (which scales --concurrency by CPU count, 1/2/4), the tenant restore runs Duplicity with a fixed --concurrency 4 and adds --no-restore-owner, so restored files are owned by the invoking tenant, not the original UIDs.

Tenant credential files: /data/disk/<user>/static/control/remote_backups/credentials/<service>.txt.

duobackboa — second AWS-S3 destination

A near-twin of backboa: a root-side, AWS-S3-only Duplicity tool with its own bucket and its own config file. It is a single, independent S3 destination — not a dual-provider fan-out, and there are no DUO_PROVIDER_* variables. Its actions take no <SERVICE> <USER> positionals:

duobackboa install            # dependency setup
duobackboa backup             # run a backup
duobackboa cleanup            # apply _AWS_TTL retention
duobackboa list               # list backups
duobackboa status             # collection status
duobackboa test               # verify connectivity
duobackboa restore file [time] destination
duobackboa retrieve file [time] destination hostname

It reads _AWS_* from /root/.duobackboa.cnf (not /root/.barracuda.cnf), targets bucket daily-remote-<host>, and uses --s3-use-ia. Because it has a separate config file and bucket, it lets you run a second AWS account/region/ bucket alongside backboa without disturbing it. The restore path must not start with a slash; the optional time is the second positional, not a flag.

backboa — legacy AWS-S3

See Legacy backboa for the full reference. Verb shape matches duobackboa:

backboa install
backboa test
backboa backup
backboa cleanup               # apply _AWS_TTL retention
backboa list
backboa status
backboa restore file [time] destination
backboa retrieve file [time] destination hostname

install only installs/upgrades dependencies (Duplicity, Python, par2, pipx awscli/boto3) — it does not validate config. Config (_AWS_*) is sourced on every invocation; connectivity validation is the separate test verb.

Log paths

Logs are per bucket, not a single fixed file. There is no multiback.log or backboa.log:

CLI Log path
multiback /var/log/boa/back-to-<user>-<host>-<service>.log (+ .archive.log)
duobackboa /var/log/boa/daily-remote-<host>.log
backboa /var/log/boa/daily-boa-<host>.log (+ .archive.log)
mybackup per-run logfile under the tenant tree; waiting queue at /var/log/mybackup_waiting_queue.log

multiback also copies each finished run to /root/.remote_backups/logs/OK-<bucket>.log or ERR-<bucket>.log depending on whether the Duplicity output contained Backup Statistics.

Debugging

Raise verbosity by setting _AWS_VLV (one of error/warning/notice/ info/debug; default warning) in the relevant config, re-run the action, and tail the per-bucket log. Use info/debug when test passes but a real backup fails.

Related