Automating Backups to Multiple Repos (SMB & B2) & Policy Questions - New User

Support
2

First things first: I’m still working out, around the numerous rough edges of this software before I begin full shake down & burn in tests but these questions are pretty basic though quite important when trying to get oriented. I’ve already set similar confs up so:

  1. SOP would be to keep all repos connected unless there’s a specific need to disconnect (eg: failed drive on target). You can specify which repo to run a snapshot against via kopia snapshot --path="$path" --config-file="$HOME/.config/kopia/repository-N.config"
  2. Use systemd-timers for server/desktop. Cron is going to eventually be phased out as SystemD is more mainstream than ever on mainline distros. It looks to instead be regulated more & more to embedded Linux. For SystemD you might want to give timertab a punt.
    • There’s a Kopia policy you can set to regulate snapshot frequency. Eg: --snapshot-interval="10m"
      • --ignore-identical-snapshots="true" (should) ensure you’re not making needless writes of metadata for identical snapshots.
    • You’ll have to write your own pre & post actions shell scripts.
      • Kopia Actions support bash arguments so you can save considerable effort when having to use the same script for multiple repos. I won’t write an action-related sh without them.
        • Keep it all in git before publishing for deployment. You’ll thank yourself later.
          • Highly recommended: set up powerline-go; it really helps navigating git repos & makes statuses/dirs much more readable
            • Set up zoxide; cd $path is a waste of time, keystrokes.
        • #!/usr/bin/env bash for portability; #!/bin/bash for heightened security
        • exit 0 for success; exit 1 for fail/error. That’s needed to ensure must succeed.
        • Set up ShellCheck
  3. Kopia UI is merely Kopia CLI with a Electron wrapper. Note it does not seem to refresh when making changes via the CLI unless you relaunch Kopia UI.
    • Once global policies are applied they are to apply to any child repos (via 'inherit`). That can be toggled per-repo if needed (supposedly).
      • Be sure to give a quick read of my thread of a related issue.
      • You may want to check what sort of files you are going to back up. There’s no sense compressing what’s already compressed. See below.
    • If you want full access to Kopia’s advertised capabilities you’ll need the CLI. The GUI does not have feature parity.
  4. If you have the option for a ZFS file system do it. Otherwise trial BTRFS starting with blake2b until you find an acceptable perf v hash rate.

Never update Kopia in situ, in production. I’ve read there’s been at least one repo breaking change (IIRC) but cannot recall the source ATM. Regardless be sure every endpoint has its ‘auto-update’ file removed (rm $HOME/.config/kopia/*.update-info.json). I block it from communicating to any Google (which hosts most golang packages which Kopia itself is programmed in) & GitHub ASN in the firewall to help as extra insurance.

Keep a separate browser up for the docs & keep a log while confirming your changes while testing, bench marking, confirming, reproducing, deploying. Be sure to document/cite your sources.

Be prepared for unexpected behavior/nasty surprises. You’re dealing with software from macbook toting, ‘cloud native,’ ‘developers’ that have never considered any other end-user’s perspective.