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; on backboa, duobackboa, and multiback the legs that delete remote data run at a notice floor so deletions are always logged).

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)	backend-level deletion of every Duplicity-named file, repeated until a re-list is clean, then `collection-status`
`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            # delete extraneous/orphaned files (cleanup --force)
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.

Note the cleanup verb on backboa/duobackboa is not the _AWS_TTL age trim (unlike multiback cleanup): it runs Duplicity cleanup --force, which removes extraneous and orphaned files. _AWS_TTL retention runs only inside backup, on the weekly full-backup day — see Legacy backboa.

backboa — legacy AWS-S3

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

backboa install
backboa test
backboa backup
backboa cleanup               # delete extraneous/orphaned files (cleanup --force)
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.

When Duplicity is broken but its version matches: the dependency installer refuses to reinstall on a version match, so a Duplicity whose pipx environment a Devuan dist-upgrade has wrecked — while duplicity --version still answers correctly — stays broken through every install run. The recovery lever is touch /root/.force.duplicity.reinstall.cnf, which makes the next run rebuild it with pipx install --force regardless of the version match. Remove the marker afterwards — nothing removes it for you.

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. On backboa/duobackboa and multiback the remove-older-than and cleanup --force legs ignore values below notice — deletions of remote data are always logged. The purge wipe does not go through the Duplicity CLI at all; its per-file deletion report is written to the per-bucket log unconditionally.

multiback operations — install + config tree.
Regions & buckets — bucket names + target URLs.
Legacy backboa — the _AWS_* legacy interface.
Reference appendix — consolidated command table.