DEV Community

Cover image for Set up ZimaBlade backups in 20 minutes, and practise first on any box
Christian Anderson
Christian Anderson

Posted on

Set up ZimaBlade backups in 20 minutes, and practise first on any box

#linux #tutorial #ai #discuss

My ZimaBlade recipes are the stuff I learned running a ZimaBlade like a server instead of an appliance. The one most people need is backups, because the obvious way is broken in a way you don't notice.

On ZimaOS your SSH user isn't root and can't sudo. Parts of /DATA/AppData are root-only, mode 0700: your reverse proxy's certificates, tunnel tokens, auth databases. A plain tar can't read them. It complains, exits 2, and still writes the archive. You get a backup of a believable size with exactly the files you can't recreate missing from it.

The new setup guide lets you watch that happen, and the fix, on any Linux machine with Docker before you touch your real data. That practice run is tested on a fresh Ubuntu machine every week.

The practice run on a fresh GitHub runner: plain tar fails on the root-only tls folder, the dry run lists it, the backup includes it, and verify proves it

Practise on a throwaway folder

The guide builds a fake AppData in /tmp with one ordinary app and one root-only tls folder, then points the scripts at it:

export SRC_DIR=/tmp/zima-practice/AppData DEST_DIR=/tmp/zima-practice/Backups CONFIG_DIRS=/tmp/zima-practice/apps
tar -czf /tmp/plain.tar.gz -C /tmp/zima-practice AppData   # Permission denied, exit 2, archive written anyway
bash scripts/backup-appdata.sh --dry-run                     # lists the folder a plain tar would miss
bash scripts/backup-appdata.sh                               # root via a privileged container: it gets in
bash scripts/verify-backup.sh                                # proves it
Enter fullscreen mode Exit fullscreen mode

The line that matters is OK — all 1 root-only director(ies) are in the archive. An ordinary tar couldn't have read that folder, so seeing it in the archive is the proof the backup worked as root.

Then on the Zima

Copy the two scripts over, dry run, back up, verify. The backup runs docker run --privileged -v /:/host, which is root on the machine, so read the scripts first. Recipe 00 explains that one-liner bit by bit.

ZimaOS doesn't run cron, so the schedule lives on another always-on box that SSHes in with remote-trigger.sh. Nothing gets installed on the Zima.

Three new recipes this week

  • 03 Apps CasaOS can't eat. My Homepage dashboard vanished from CasaOS twice. The second time the compose file I'd restored from was gone too. It runs as a plain docker run now.
  • 04 Uptime Kuma on the Zima. Upgrading to the newer full image didn't remove the actively exploited Chromium bugs inside it. The -slim image did, and it's 540 MB instead of 1.71 GB.
  • 05 Disk pressure and a coldstore. I nearly moved data to the Zima to free space elsewhere. The space was Docker images, which can't live on NFS anyway.

What CI can't prove

Anything on a real Zima. The weekly run proves the scripts' root trick and the verify checks on Ubuntu with Docker. ZimaOS differences (BusyBox find, read-only root, no cron) are written up from my own box, not tested in CI.

Full guide: github.com/casareanderson/zimablade-recipes/blob/main/docs/SETUP.md

When did you last actually restore something from your homelab backups?

🤖 Drafted with AI assistance from my own homelab notes, logs and repos, then reviewed and edited before publishing.

Top comments (0)