Files
ubuntu-post-install/services
Claude c48ed039e0 Guide + automate Backblaze B2 offsite mirror setup in backup.sh
Answers a direct ask: offsite mirroring existed only as a REMOTE_TYPE/
REMOTE_ARGS placeholder in backup.conf with a comment pointing at
`kopia repository sync-to --help` — no interactive setup at all, B2 or
otherwise.

Checked before building anything: Kopia's dedicated `sync-to b2`
provider is marked [DEPRECATED] on kopia.io's own command reference.
B2 also offers an S3-compatible endpoint (s3.<region>.backblazeb2.com,
same application key works as the access/secret key pair), and Kopia's
`sync-to s3` provider isn't deprecated — so this targets that path
instead of building on a command on its way out.

What's now automated vs. guided, deliberately split:
- Bucket creation and the application key are walked through as console
  steps, not automated. Object Lock specifically is a one-time,
  bucket-creation-only decision with a real tradeoff (undeletable-by-
  design vs. genuinely can't delete early) that shouldn't be silently
  flipped either way by a script on someone's behalf.
- Once the operator has a bucket + endpoint + scoped application key
  (B2 requires a key scoped to one bucket, not the account master key —
  noted in the walkthrough), this becomes mechanical: run a
  `sync-to s3 --dry-run` against the just-created 'default' repo to
  verify the credentials actually work, and only then write
  REMOTE_TYPE=s3 / REMOTE_ARGS into backup.conf. A bad bucket name or
  key leaves REMOTE_TYPE at "none" with a clear error instead of saving
  a broken config that fails silently at 2am.
- Encryption isn't a separate step — Kopia already encrypts client-side
  with the repository password set earlier in this same flow; called
  that out explicitly since it was asked about as if it needed its own
  setup step.

Also fixed a regression the new prompt would otherwise have caused:
backup.sh has no update/fresh distinction and re-asks everything on
every run, so an already-configured offsite mirror is now read back
from the existing backup.conf and preserved by default — answering "no"
on a re-run no longer silently resets REMOTE_TYPE to "none".

Verified the control flow (not just bash -n) against a mock kopia
binary and stubbed prompts: good credentials wire up REMOTE_TYPE/
REMOTE_ARGS correctly, a rejected credential leaves REMOTE_TYPE at
"none" rather than saving something broken, an existing configured
value survives a "no" answer on re-run, and blank fields skip cleanly
without attempting a dry-run at all.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H4k6J1qXXyYxhGEgnJaMvn
2026-08-13 19:28:00 +00:00
..