Backup regions, bucket names & target URLs

multiback/mybackup construct the bucket name and the Duplicity target URL deterministically per backend. You do not pick the bucket name; you create a matching bucket up front where the provider requires it.

Bucket name construction

_construct_bucket_name builds:

back-to-<user>-<hostname-with-dots-as-dashes>-<service-with-underscores-as-dashes>
  • <user> — the path-set selector: global, data or custom root-side, or the tenant's o### user.
  • <hostname> — _hName read from /etc/hostname (falling back to hostname -f), dots replaced with dashes. Verify with cat /etc/hostname, not uname -n — the two can differ and only /etc/hostname is used.
  • <service> — the backend key with underscores replaced by dashes (aws_one_zone becomes aws-one-zone).

Example: tenant o123 on fr8.eu.aegir.cc to Wasabi gives back-to-o123-fr8-eu-aegir-cc-wasabi. The underscore-to-dash swap applies only inside the bucket name; the credential file keeps the underscored key (do_spaces.txt).

The legacy tools use their own host-wide names: backboa uses daily-boa-<host-with-dashes>, duobackboa uses daily-remote-<host-with-dashes> (see Legacy backboa).

Per-backend target URLs

_set_backup_target builds the Duplicity URL, interpolating the credential values per backend (the passphrase is never here — it is the separate PASSPHRASE env var):

Backend key Target URL form
aws / aws_one_zone / aws_standard_ia boto3+s3://<bucket> plus --s3-endpoint-url https://s3.dualstack.<region>.amazonaws.com --s3-region-name <region> (the two IA variants add --s3-use-ia)
azure azure://<storage-account>@<bucket>
b2 b2://<account-id>:<application-key>@<bucket> (both URL-encoded)
cloudflare boto3+s3://<key>:<secret>@<account>.r2.cloudflarestorage.com/<bucket>
do_spaces s3://<key>:<secret>@<region>/<bucket>
gcs gs://<bucket>
ibm ibmcos://<api-key>:<service-instance>@<region>/<bucket>
linode s3://<access-key>:<secret-key>@<region>/<bucket>
wasabi s3://<access-key>:<secret-key>@<region>/<bucket>

The region comes from the backend's own region variable in the credential file (AWS_REGION, DO_SPACES_REGION, LINODE_REGION, WASABI_REGION, IBM_REGION) — Cloudflare R2 is region-less (geographic placement is automatic), and B2/Azure/GCS take the region from the account, not the URL.

Bucket auto-creation policy

Most providers auto-create the bucket on first write if credentials have permission. Several do not and must have the bucket created by hand first:

Provider Auto-create Action
Wasabi Yes none
Backblaze B2 Yes none
DigitalOcean Spaces Yes (write perms) none
Google Cloud Storage Yes (write perms) none
Microsoft Azure Blob Yes none
AWS S3 Unreliable create manually (region propagation delays)
Cloudflare R2 Not supported create manually before first backup
IBM Cloud Object Storage Not supported create manually before first backup
Linode Object Storage Not supported create manually before first backup

When creating by hand, use the exact constructed name (back-to-<user>-<hostname-with-dashes>-<service-with-dashes>) in the provider console, keep the bucket private (BOA uses per-account credentials, not bucket ACLs), and pick the region closest to the host.

Connectivity test

After credentials and (where required) the bucket are in place, verify with the test action — it runs duplicity cleanup --dry-run --timeout 8 and reports whether it can reach the bucket:

multiback test wasabi data

test failure messages distinguish a missing/wrong-named bucket from a backend-connection failure. mybackup has no test action (its only verb is restore); a tenant's connectivity is exercised through the root-side scheduled run.

Choosing a region

  • Match the host's geographic region for lower restore latency and egress.
  • Avoid cross-continent destinations unless data-residency requires it.
  • A single-region account per host is sufficient; provider-level cross-region replication is overkill for this use case.

Related