10 — Operation, maintenance, recovery
Backups that actually restore, kernel updates, card swaps, and the rebuild after an SD-card failure.
What lives where
| Data | Path | Backup |
|---|---|---|
Classes, photos, learned state (.fbz per card + companion JSON), zones, recipes, empty-belt references (leerbild/<camera>.png + _rausch.png), inspection archive, alarm history |
~/vorsa-m3/vorsa_daten/ |
always |
| Arm points and programs | ~/vorsa-m3/vorsa_daten/arm_punkte.json, arm_programme.json |
always |
| M3 detector | ~/vorsa-m3/vorsa_m3.fbz |
yes |
| Code | ~/vorsa-m3/vorsa, tools, root scripts |
git |
| Both Python environments | ~/akida-env, ~/m3-train-env |
rebuildable in 30 min (chapter 06) |
Backups — two kinds, both needed
- File backup of
vorsa_daten/andvorsa_m3.fbzafter every learning session. From Windows:backup_vom_pi.ps1(SSH key required). The learned state has a version number (LERNSTAND); an older saved state is relearned automatically at start, so a backup never silently degrades recognition. - SD-card image of the running system (Raspberry Pi Imager → "Read", or Win32DiskImager). Lesson from 2026-09-06: a file tar does not bring back a broken firmware layer; an image restores in ten minutes.
Rule: after every boot-, cmdline-, firmware- or kernel-level change, reboot immediately and run the camera proof (chapter 04) and the four-layer card check (chapter 05). Not weeks later, when nobody remembers what changed.
Kernel update
sudo apt full-upgrade → DKMS rebuilds akida-pcie → reboot → chapter 05 verify → akida.devices() in the runtime env → systemctl status vorsa. If the driver fails to build, re-run setup_akida_treiber.sh (idempotent).
Card fault-finding
Symptoms and recovery are in chapter 05. To decide card vs. slot: swap two cards, note the addresses, watch which one hangs next. Keep the slot/address table current after every swap — the reset button relies on it.
Rebuild after an SD-card failure
The full procedure is WIEDERAUFBAU_PI.md in the repo. In short: flash a new card, run the camera proof (this is the diagnosis: green = the old card was the culprit), chapters 04–07, then mount the old card's Linux partition on the running Pi via a USB reader and copy vorsa_daten/ and vorsa_m3.fbz back:
lsblk # find the old card, e.g. sda2
sudo mkdir -p /mnt/alt && sudo mount /dev/sda2 /mnt/alt
cp -r /mnt/alt/home/<user>/vorsa-m3/vorsa_daten ~/vorsa-m3/
cp /mnt/alt/home/<user>/vorsa-m3/vorsa_m3.fbz ~/vorsa-m3/ 2>/dev/null
sudo umount /mnt/alt
Expected: after systemctl restart vorsa the learned objects, zones and arm points are back without relearning.
CMA (contiguous memory)
A cma=256M kernel parameter was part of an earlier memory plan. Change it only with a fresh image in hand, then reboot and test the camera immediately. The 16 MB host-DDR window per card is sufficient for the silhouette models.
Daily operation checklist
Empty-belt reference still valid (light unchanged)? Cards all "active" in Status → Hardware? Build string in the footer as expected? Alarm book acknowledged? Backup after learning?
Checkpoint: you have an SD image less than a week old and a vorsa_daten/ backup from the last learning session.