ioBroker-Backup - Erfahrungen und Empfehlungen

[jahnbes]

ioBroker-Backup - Erfahrungen und Empfehlungen

Aus unbekanntem Grund kam es während oder nach einem Update von node.js zu einem totalen Crash des Betriebssystems (Raspberry Pi OS) auf einen Raspberry Pi 4. Der Rechner steckte in Folge nach dem Booten in einer endlosen, sekündlichen Wiederholung einer nicht lesbaren Fehlerausschrift, ohne dass ein Zugriff auf den Rechner oder eine Unterbrechung der Ausgabe dieser Liste möglich gewesen wäre.

Nichtsdestotrotz lief der ioBroker in rudimentärem Umfang weiter. Nach und nach verabschiedeten sich allerdings immer mehr Adapter, der Funktionsumfang der Hausautomatisation wurde schrittweise geringer. Glücklicherweise zog sich das über einige Wochen hin.
Eine Neuinstallation mit Übernahme der Backup-Daten wurde notwendig.

Ausgangssituation:

1. hardware: Raspberry Pi 4, HS: 8 GByte, SSD: 128 GB
2. booten: von SSD
3. software: Raspberry Pi OS (12, bookworm), ioBroker (26 Adapter), Grafana, InfluxDB
4. Laufzeit: seit ca. 3 Jahren
5. Backup: Adapter backitup
   https://github.com/simatec/ioBroker.backitup/blob/master/docs/de/backitup.md
6. backitup: Backup-Files auf der SSD und mittels FTP auf einem Synology-NAS
7. kein zweiter Raspberry Pi zum Testen

Erfahrungen hard- und software:

1. Der Zugriff auf das System zur partiellen Fehlerbehebung unter möglichst geringer Zerstörung der ioBroker-Installation scheiterte.
2. Es blieb nur die komplette Neuinstallation des Betriebssystems Raspberry Pi OS mit dem totalen Verlust des bisherigen Plattenstandes.
3. Diese Neuinstallation erfolgte sicherheitshalber auf einem inzwischen beschafften nahezu gleich ausgestatten zweitem Raspberry Pi 4 (HS: 8 GByte, SSD: 256 GB).
4. Der „kranke“ Raspberry Pi lief unterdessen weiter.
5. Die Neuinstallation des Betriebssystems Raspberry Pi OS erfolgte mit Hilfe des Raspberry Pi Imager (Windows-PC). Die SSD des Raspberry Pi muss dabei vom Raspberry Pi getrennt und an den Windows-PC angeschlossen werden. Dazu ist lediglich der Doppel-USB-Stecker zwischen dem Raspberry Pi und der SSD zu entfernen und die USB-Buchse des SSD mit dem PC zu verbinden (siehe Bild). Eine zusätzliche Stromversorgung des Raspberry Pi ist dabei nicht notwendig.
   
6. Installiert wurden:
   a. Raspberry Pi OS (12, bookworm)
   b. ioBroker
   c. Grafana
   d. InfluxDB

Einspielen des iobroker-Backups:

1. Ein Zugriff auf die von backitup auf der (alten) SSD erstellten Backup-Files war nicht mehr möglich.
2. Das Einspielen der auf der NAS geretteten Files (javascripts, zigbee, iobroker) mittels des backitup-Adapters gelang problemlos, die Daten waren danach im ioBroker sichtbar.
3. Aus unbekanntem Grund verweigerte backitup die Übernahme der Backup-Files von Grafana und InfluxDB von der NAS. backitup blieb ohne Fehlermitteilung stehen.
4. Als Workaround gelang es, die Backup-Files von Grafana und InfluxDB per FTP (FileZilla) von der NAS in die Directory (/opt/iobroker/backups) der SSD des Raspberry Pi zu kopieren, in der die anderen Backup-Files (javascripts, zigbee, iobroker) schon vorhanden waren.
5. Von dort aus konnten sie mittels backitup in den ioBroker eingespielt werden.
6. Danach waren in Grafana alle Diagramme verfügbar.
7. In InfluxDB wurden alten Daten nicht übernommen, obwohl das Backupfile der Datenbank die zu erwartende Größe hatte, die Daten im Backupfile offensichtlich noch vorhanden waren! Diese Daten waren verloren.

Erfahrungen mit dem backitup-Adapter:

1. Der Aufbau des Systems auf einem zweiten Raspberry Pi erleichterte die Arbeit wesentlich durch die dann gegebene Möglichkeit der wiederholten, auch testweisen kompletten Neuinstallation ohne Verlust während des Testbetriebes.
2. Nur die auf der NAS gespeicherten Backupdaten standen zur Verfügung, alles auf der SSD des alten Raspberry Pi war verloren.
3. Eine Übernahme der Backupdaten von Grafana und InfluxDB direkt von der NAS mittels des backitup-Adapters gelang nicht. Die Übernahme dieser beiden Backups erforderte mehrere Schritte und erfolgte mittels FTP.
4. Es gelang nicht, die in InfluxDB gespeicherten Messdaten zu übernehmen.

Backup der SSD
Die schrittweise komplette Neuinstallation des Betriebssystems, der Software und der Backupdaten erforderte einiges an Zeit und innerlicher Ruhe. Um diesen Aufwand in Zukunft gering zu halten, wurde nachfolgend ein komplettes, regelmäßiges und automatisiertes Backup der gesamten SSD des Raspberry Pi installiert.

1. Als Speichermedium für ein komplettes Backup der SSD wurde über den freien USB-3.0-Ausgang des Raspberry Pi eine externe 1 TB - SSD ständig angeschlossen.
2. Dieser Anschluss sollte über einen aktiven Hub erfolgen, da der Raspberry Pi nicht dauerhaft und sicher über den USB-Ausgang den Strom liefert, den die externe SSD benötigt.
3. Genutzt wird für das automatisierte Backup die Software raspiBackup.
4. Die originale, umfangreiche Webseite zu raspiBackup ist:
   a. https://www.linux-tips-and-tricks.de/de/raspibackup
5. Eine empfehlenswerte weitere Webseite zu raspiBackup, die sich auf das Wesentliche konzentriert, ist:
   a. https://forum-raspberrypi.de/article/7-raspibackup-installation-grundeinstellungen-erstes-backup-und-restore/
6. Es wird im Rhythmus „3-4-12-3“ gerettet, d.h., aufgehoben werden
   a. 3 Tages-Backup
   b. 4 Wochen-Backups
   c. 12 Monats-Backups
   d. 3 Jahres-Backups
7. Die Variante „0-4-12-3“, d.h. kein tägliches Backup, sondern die Backups beginnen im wöchentlichen Rhythmus, funktioniert offensichtlich nicht. Es muss immer mindestens ein tägliches Backup erfolgen.
8. Die Backups mittels raspiBackup erfolgen nachts um 3:00 Uhr.
9. Der in raspiBackup dafür einzustellende Backuptyp ist „rsync“.
10. rsync benötigt den geringsten Speicherplatz, da hier nur die tatsächlich geänderten Daten gesichert werden und jedes Folgebackup ein inkrementelles Backup unter der Verwendung von Hardlinks ist.
11. Es ist möglich, mit raspiBackup das Backup einer größeren SSD auf eine kleinere SSD zu kopieren, wenn es der Umfang der vorhandenen Daten erlaubt.
12. Die Nutzung der Synology-NAS zur Speicherung der Backupdaten gelang nicht, obwohl von raspiBackup angeboten.

Ergebnis des kompletten Backups der SSD mit raspiBackup:

1. Mit dem Befehl
   sudo du -sh /backup/raspberrypI-4/*
   ist es möglich, die Liste der Backups und des von ihnen real belegten Speicherplatzes anzuzeigen. "/backup/raspberrypI-4/" ist dabei die Directory der Backups und muss gegebenenfalls angepasst werden.
2. Das erste Backup (20240806) ist ein Snapshot, der jederzeit händisch angelegt werden kann, dauerhaft besteht und nicht der inkrementellen Beschränkung der Anzahl der Backups unterliegt. Er verschwindet erst durch manuelles Löschen.
3. Das zweite Backup (20240816) ist eines der vier wöchentlichen inkrementellen Backups.
4. Die folgenden drei Backups (20240818 … 20) sind drei tägliche inkrementelle Backups.
5. Ein monatliches oder gar jährliches inkrementelles Backup ist noch nicht erfolgt.
6. Deutlich zu erkennen ist die Ersparnis an Speicherplatz bei der Speicherung von eigentlich nahezu gleichgroßen Backups durch die Verwendung von rsync und Hardlinks.
7. Die mit raspiBackup erstellten Backups wurden testhalber mehrmals ohne Probleme wieder eingespielt (restore).

Backup der SSD mit anderen Programmen

1. Win32DiskImager
   a. Der Win32DiskImager läuft auf einem Windows-PC.
   b. Eine Nutzung des Win32DiskImager empfiehlt sich nur für ein allererstes, einmaliges und schnell zur Verfügung stehendes Backup der SSD des Raspberry.
   c. Das Restore eines solchen Backups wurde erfolgreich getestet.
   d. Ein Nachteil dieser Variante ist die Nutzung eines fremden Betriebssystems und fremder hardware.
   e. Zum Vorgehen bei der Kopplung beider Rechner siehe Abschnitt „Erfahrungen hard- und software (Punkt 5)“ weiter oben.
   f. Win32DiskImager rettet die gesamte SSD als Imagefile, egal wieviel Plattenplatz darauf wirklich belegt ist.
   g. Es ist nicht möglich, eine größere SSD auf eine kleinere zu kopieren, auch wenn es der Datenumfang erlauben würde.
   h. Ein automatisiertes Backup ist nicht möglich.
2. SD Card Copier
   a. Raspberry Pi OS in der grafischen Version bringt im Startmenü unter „Zubehör“ den SD Card Copier.
   b. Eine Nutzung des SD Card Copier empfiehlt sich für ein einmaliges und schnell zur Verfügung stehendes Backup der SSD des Raspberry.
   c. Das Restore eines solchen Backups wurde erfolgreich getestet.
   d. SD Card Copier kopiert nur die tatsächlich vorhandenen Daten, nicht die gesamte SSD.
   e. Es ist möglich, damit eine größere SSD auf eine kleinere zu kopieren, wenn es der Umfang der vorhandenen Daten erlaubt.
   f. Ein automatisiertes Backup ist nicht möglich.
   g. SD Card Copier ist in der Kommandozeilen-Variante von Raspberry Pi OS nicht enthalten.

Fazit und Empfehlungen:
Um nach einem Crash des Raspberry Pi mit ioBroker und Totalverlust des Speichermediums (SD-Karte oder SSD) mit vertretbarem Aufwand das System wieder herstellen zu können, wird empfohlen:

1. Der backitup-Adapter des ioBrokers ist zu nutzen, er ist sicher und einfach bedienbar.
2. Alle Backupdaten müssen unbedingt auch außerhalb des Speichermediums des Raspberry Pi gespeichert werden, z.B. auf einer NAS. Das ist innerhalb des backitup-Adapters einstellbar.
3. Es ist ein komplettes, regelmäßiges und automatisiertes Backup der gesamten SSD des Raspberry Pi durchzuführen. Dafür wird die Software raspiBackup empfohlen.
4. Die Sicherung der mit raspiBackup erstellten Daten erfolgt auf einer externen SSD.
5. Die Nutzung von zwei Raspberry Pi ist erstrebenswert, wobei einer dem Testen (ohne Reue) und der anderen der Produktion (stabiler Lauf der Hausautomatisation) dient.

Ergänzung zu den Empfehlungen:
Simatec und homoran haben mich dankenswerteweise (s.u.) auf eine wichtige Empfehlung aufmerksam gemacht, die ich zwar in der Doku gelesen und auch befolgt hatte, aber aus den Augen verlor:
Das Restore eines Backupfiles sollte mit backitup immer lokal erfolgen, d.h. das betreffende Backupfile steht bereits auf dem Speichermedium des RaspberryPi und wird von dort mittels backitup restored.
Wenn das Backupfile von außerhalb des RaspberryPi kommt, sollte es zuerst auf das Speichermedium des RaspberryPi kopiert werden, was z.B. komfortabel mit der backitup-GUI passieren kann (auch s.u.).

[simatec]

Zum Thema Influx restore hättest du die Doku von Backitup lesen sollen.
Es darf keine DB vorhanden sein. Wenn du aber den Influx Adapter bereits gestartet hattest, legt der Adapter die Datenbank bereits an.
Somit kann kein Restore erfolgen... Also erst die DB wieder löschen und zuvor den Influx Adapter stoppen. Dann den restore ausführen.

Zum Thema kopieren per FTP usw. Warum so kompliziert? Backitup bietet die Möglichkeit über die Gui ganz einfach Backup Dateien auf dem Host System hochzuladen... Und das ganz bequem von deinem PC aus.

Also alles im allem, kann ich einige Punkte und Empfehlungen nicht so recht nachvollziehen.

[jahnbes]

@simatec sagte in ioBroker-Backup - Erfahrungen und Empfehlungen:

Zum Thema Influx restore hättest du die Doku von Backitup lesen sollen.
Es darf keine DB vorhanden sein. Wenn du aber den Influx Adapter bereits gestartet hattest, legt der Adapter die Datenbank bereits an.
Somit kann kein Restore erfolgen... Also erst die DB wieder löschen und zuvor den Influx Adapter stoppen. Dann den restore ausführen.

Zum Thema kopieren per FTP usw. Warum so kompliziert? Backitup bietet die Möglichkeit über die Gui ganz einfach Backup Dateien auf dem Host System hochzuladen... Und das ganz bequem von deinem PC aus.

Also alles im allem, kann ich einige Punkte und Empfehlungen nicht so recht nachvollziehen.

Hallo simatec,

danke für die Hinweise.
zu Punkt 1:
Die Doku habe ich schon gelesen, leider habe ich diese Hinweise auf den Hilfeseiten nicht gefunden, ansonsten wäre ich ihnen selbstverständlich gefolgt. Beim nächsten mal werde ich es sicher tun.
zu Punkt 2:
Genau das hat ja nicht funktioniert, deshalb der Weg über FTP.

Aber vielleicht bin ja ich es, der sich irrt.

[Homoran]

@jahnbes sagte in ioBroker-Backup - Erfahrungen und Empfehlungen:

Genau das hat ja nicht funktioniert

was daran hat nicht funktioniert?
mit welcher Fehlermeldung?

[jahnbes]

@homoran
Ich habe keine screenshots davon mehr da, liegt auch eine Weile zurück.
Wenn ich mich recht erinnere, geschah einfach nix, ein Fenster öffnete sich, es sah aus, als ob das Restore losgeht und dann endloses nichts, weißes Fenster, keine Ausschrift, auch keine Fehlerausschrift. Nach einer halben Stunde Abbruch und Nachschauen, es erfolgte kein Umspeichern von der NAS und kein Restore. In den in backitup angegebenen Directorys auf dem Raspberry standen die backupfiles von influxDB und Grafana nicht drinn.
Möglicherweise eine von mir nicht verstandene Rechte-Frage.
Der Weg über FTP und FileZilla klappte sofort, siehe oben.

[Homoran]

@jahnbes sagte in ioBroker-Backup - Erfahrungen und Empfehlungen:

ein Fenster öffnete sich, es sah aus, als ob das Restore losgeht

dazu musstest du doch erst einmal das Backup per GUI upload auf den Server bringen.
Und dazu schreibst du es hätte nicht geklappt.

@jahnbes sagte in ioBroker-Backup - Erfahrungen und Empfehlungen:

kein Umspeichern von der NAS und kein Restore.

Wenn du das wolltest, müsstest du in dem neuen Backitup die gleichen Speichereinstellungen konfigurieren wie im alten System

Aber das ist ja was anderes als @Simatec schrieb

[jahnbes]

@simatec
Da hast Du recht, mein "Restore" ist etwas irrtümlich. Ich meinte damit, den gesamten Vorgang, einschließlich dem Upload.
Und der hatte nicht geklappt, das Restore im eigentlichen Sinne hatte noch gar nicht begonnen.

[jahnbes]

@simatec sagte in ioBroker-Backup - Erfahrungen und Empfehlungen:

Zum Thema Influx restore hättest du die Doku von Backitup lesen sollen.
Es darf keine DB vorhanden sein. Wenn du aber den Influx Adapter bereits gestartet hattest, legt der Adapter die Datenbank bereits an.
Somit kann kein Restore erfolgen... Also erst die DB wieder löschen und zuvor den Influx Adapter stoppen. Dann den restore ausführen.

Zum Thema kopieren per FTP usw. Warum so kompliziert? Backitup bietet die Möglichkeit über die Gui ganz einfach Backup Dateien auf dem Host System hochzuladen... Und das ganz bequem von deinem PC aus.

Also alles im allem, kann ich einige Punkte und Empfehlungen nicht so recht nachvollziehen.

Hallo simatec,

welche von meinen Empfehlungen (s.u.) kannst Du nicht nachvollziehen? Ich würde sie gern korrigieren.
Fazit und Empfehlungen:
...
Der backitup-Adapter des ioBrokers ist zu nutzen, er ist sicher und einfach bedienbar.
Alle Backupdaten müssen unbedingt auch außerhalb des Speichermediums des Raspberry Pi gespeichert werden, z.B. auf einer NAS. Das ist innerhalb des backitup-Adapters einstellbar.
Es ist ein komplettes, regelmäßiges und automatisiertes Backup der gesamten SSD des Raspberry Pi durchzuführen. Dafür wird die Software raspiBackup empfohlen.
Die Sicherung der mit raspiBackup erstellten Daten erfolgt auf einer externen SSD.
Die Nutzung von zwei Raspberry Pi ist erstrebenswert, wobei einer dem Testen (ohne Reue) und der anderen der Produktion (stabiler Lauf der Hausautomatisation) dient.

[simatec]

@jahnbes sagte in ioBroker-Backup - Erfahrungen und Empfehlungen:

zu Punkt 2:
Genau das hat ja nicht funktioniert, deshalb der Weg über FTP.

[Homoran]

@simatec...und dann restore starten!

Nach seinem vorletzten Post und der Aussage

@jahnbes sagte in ioBroker-Backup - Erfahrungen und Empfehlungen:

, es erfolgte kein Umspeichern von der NAS

tippe ich aber auf was anderes

[simatec]

@homoran Jup wollte damit nur zeigen, dass man über die GUI komfortabel die Backups auf den Host packen kann.
Und grundsätzlich ist ja auch die Empfehlung immer den restore lokal auszuführen, was ebenfalls in der Doku steht.

Ein restore vom NAS, oder aus der Cloud ist möglich, birgt aber Gefahren durch fehlerhafte Datenübertragung... Darum am besten Lokal

[jahnbes]

@simatec
Das das Restore lokal sicherer ist, hatte ich gelesen und, da vollkommen einleuchtend, auch versucht, zu befolgen. Das hat dann ja auch geklappt. Nur die Files auf den Host zu bekommen, gelang erst über den Umweg. Warum, weiß ich nicht.
Beim nächsten großen Crash, der hoffentlich nie eintritt, werde ich es noch mal versuchen.
Danke noch einmal für Eure Hinweise, ich habe den Hinweis zum lokalen Restore in meine obigen Empfehlungen aufgenommen.