Raspberry - Backup- und Migrationsstrategie

Mr X. schrieb:

Zwangsläufig wird damit das Thema Backup interessant, wobei das bei mir weniger Daten, als vielmehr den Konfigurationsaufwand betrifft. Möglichst viel via Docker o.ä. erschlagen?

Meine Empfehlung (für die ich bestimmt gleich von besonders klugen Menschen gebasht werde) ist, Docker Swarm zu nutzen und alle Konfigurationsdateien in Unterverzeichnisse eines Verzeichnisses zu legen. Dadurch entkoppelst Du die Systemkonfiguration von den Konfigurationen der Applikationen und kannst die Konfigurations- und Bewegungsdaten Deiner Applikationen einfach vom Cluster ins Backup pullen. Dazu würde ich etckeeper mit einem Remote-Repository für /etc nutzen, um auch hier sowohl automatische, als auch versionierte Backups Deiner Systemkonfiguration zu erhalten.

Damit hälst Dir nicht nur einen Upgrade-, sondern auch einen Skalierungspfad offen: wenn die Rechenleistung eines RasPi nicht mehr ausreicht, kannst Du relativ einfach das Verzeichnis mit den Applikationskonfigurationen in ein repliziertes GlusterFS umziehen und dann einen oder mehrere weitere RasPis (oder andere Maschinen) in Deinen Cluster konfigurieren. Danach nur noch die Services neu verteilen (lassen), fertig ist die Skalierung.

Bei solch einem Setup empfehle ich Traefik als Reverse Proxy. Der überwacht den Swarm, die Services geben mit Labels bekannt, wo und wie sie erreichbar sein sollen, und um den Rest kümmert sich Traefik. Für Dich im Heimnetz ist vermutlich irrelevant, daß Traefik sich auch um TLS-Zertifikate von einem ACME-Provider wie Letsenctypt kümmern kann. Für das meiste andere eignet sich zumindest in einem Heimnetzwerk womöglich das Swarm Mesh, aber das würde ich in nichtvertrauenswürdigen Netzwerken nicht benutzen.

Ich persönlich nutze solche Setups (allerdings auf x86) gerne kombiniert mit Ansible und Git-Repositories. Das ist anfangs ein bisschen mehr Arbeit, aber bei Bedarf kannst Du in Minuten einen Ersatz hochziehen.

Mr X. schrieb:

vermutlich die einfachste Lösung, mir regelmäßig Images der SD-Karte zu ziehen.

Hab ich zu Beginn auch so gemacht. Hat halt den Nachteil dass, Tricksereien außen vor gelassen, die Images sehr groß werden.

Ich ziehe mir mittlerweile von allen Geräten Images der Systempartition auf Dateiebene mittels rsnapshot. Das benutzt intern rsync. Dass die Wiederherstellung im Fehlerfall klappt habe ich zuerst mehrmals ausprobiert. Hat auch den Charme dass du die Backups direkt durchsuchen kannst, ohne erst ein Image auf nem loopback zu mounten.

Mr X. schrieb:

Was kann ich beim Einrichten bestenfalls von Anfang an richtig machen, um später z.B. einzelne Funktionen unkompliziert auf andere Systeme (zweites Raspberry, ...) umziehen zu können?

Den Raspberry rauswerfen, einen kleinen Intel NUC für 120€ anschaffen, Proxmox installieren und jedem Dienst seine eigene VM oder Container zuweisen und dich freuen dass die Weboberflächen von ioBroker, Nextcloud und Co. sogar richtig flott sein können wenn sie auf richtiger Hardware laufen dürfen ;-)

Le X. schrieb:

Ich ziehe mir mittlerweile von allen Geräten Images der Systempartition auf Dateiebene mittels rsnapshot. Das benutzt intern rsync.

UND es benutzt dessen Feature, unveränderte Dateien nur als Hardlinks zu speichern, was die Inhalte wirksam dedupliziert.

Dass die Wiederherstellung im Fehlerfall klappt habe ich zuerst mehrmals ausprobiert.

Die Wiederherstellung von Backups regelmäßig zu überprüfen, halte ich für absolut essentiell für einen ruhigen Schlaf.

Den Raspberry rauswerfen, einen kleinen Intel NUC für 120€ anschaffen, Proxmox installieren und jedem Dienst seine eigene VM oder Container zuweisen und dich freuen dass die Weboberflächen von ioBroker, Nextcloud und Co. sogar richtig flott sein können wenn sie auf richtiger Hardware laufen dürfen ;-)

Wenn alles in VMs gepackt wird, bedeutet das leider, daß die Backups entweder pro VM eingerichtet werden müssen oder ziemlich groß werden. An dieser Stelle hat Docker, wie der Typ das vorschlägt, eindeutige Vorzüge.

Zudem haben wir in der Company leider die Erfahrung machen müssen, daß die Proxmox-Backups leider bisweilen dazu führen, daß die VM einfriert und nur mittels eines harten Reset wiederbelebt werden können.

Sheeva P. schrieb:

Backups leider bisweilen dazu führen, daß die VM einfriert und nur mittels eines harten Reset wiederbelebt werden können.

Das kann daran liegen, dass die Zeitstempel der Backups nicht zur Istzeit passen. Die internen virtuellen Netzwerke können sich dadurch blockieren und alles lahmlegen.

Ich schreibe Backups auf einen USB-Stick und auf ein NAS mittels https://github.com/framps/raspiBackup

Das Image kann man direkt wieder auf eine SD-Karte schreiben und es geht weiter.

Also ich betreibe meinen Pi 2B seit Jahren mit einer SSD. Diese SD-Karten sind nix für Dauerbetrieb. Ich boote nur davon. Und das Betriebssystem wird per LVM gemanaged. Perfomanceänderungen konnte ich dadurch nicht feststellen. Einfach im laufenden Betrieb per cron einen Snapshot machen und den dann gemütlich mit fsarchiver wegsichern. Restore auch (erfolgreich) damit. Diese ganzen Backupscripte mit Dienste in dieser und jener Reihenfolge stoppen und starten kann früher oder später nur in die Hose gehen. Damit hatte ich mich anfangs auch beschäftigt.

Inzwischen bin ich mit Docker und ein paar Grundregeln, wie o.g. separat abgelegter YAML- und Config-Files sehr zufrieden. Der Umzug eines kompletten RasPi 4 (von 2GB Auf die 8GB RAM Variante) mit 6 laufenden Containern zur Hausautomation hatte ich innerhalb von 1h wieder produktiv. Wobei ich /nicht/ mit SD-Karten hantiere, sondern die Daten immer auf SSD‘s liegen habe. Die Daten hatte ich mit rsync geschoben, hab‘ mir dazu ein paar Skripte gebaut. Weil die Konfiguration nicht am Benutzer klebte, war der Umzug unkompliziert. Die Sicherung von ganzen Images hat mir zu lange gedauert und zu viel Platz verschlungen.