Nachdem ich endlich meinen Raspberry Pi 4 + SSD erhalten habe, habe ich eine vollständige Neuinstallation von Gladys durchgeführt und beginne nun, weitere Dienste auf meinem Raspberry zu installieren.
Ich weiß, dass die Gladys-Datenbank in Gladys Plus gesichert wird, aber ich frage mich, wie es mit den anderen Daten/Diensten aussieht.
Wie handhabt ihr die Backups?
gelegentliche Kopie der Festplatte?
manuelles Backup-Skript (rsync) auf eine andere Maschine (z. B. in die Cloud)
Verwendung eines Backup-Tools (syncthings, rpibackup, …)
Was wird aktuell genau nicht in Gladys Plus gespeichert?
Fehlen im Großen und Ganzen die Dateien von Zigbee2mqtt / MQTT?
Ich frage mich, ob man in diesen Diensten nicht in der Lage sein sollte, bei einer Wiederherstellung eines Datenbank-Backups wieder auf die Beine zu kommen (Container und Dateien neu erstellen).
Denn im Grunde gibt es in diesen Dateien nichts, was nicht in der Datenbank ist, oder?
Ansonsten verwende ich auf meinen Servern rclone: https://rclone.org/ für alle Datei-Backups in die Cloud. Du kannst das mit allem verbinden (Google Drive, Amazon S3, Backblaze, Dropbox, etc.).
Hallo, auf meiner Seite verwende ich ein recht einfaches Skript, das die komprimierten Dateien von Gladys per SCP auf einen Server überträgt. Zusätzlich habe ich einen Ping zum Healthchecks-Dienst integriert, der mir ermöglicht, über einen Gotify-Server bei einem Fehler benachrichtigt zu werden.
Okay! Also müsste es in der Zigbee2mqtt-Integration idealerweise so etwas wie eine „Startroutine“ geben, die überprüft, ob der Container richtig gestartet ist usw. und falls diese berühmte Datei configuration.yaml nicht vorhanden ist, sie aus der DB neu erstellt, oder?
Ich denke nicht unbedingt, dass das mit der Gladys Plus-To-Do-Liste zusammenhängt. Wenn wir das auf der Seite von Zigbee2mqtt entwickeln, kann jemand, der seine Backups selbst erstellt, eine Instanz aus seiner DB neu starten
Hallo,
Ich greife auf diese Nachricht von @Albenss zurück, weil ich auch eine Sicherung auf diese Weise einrichten möchte. Da ich GladysPlus nicht verwende, welche Ordner/Dateien muss ich sichern, um sie wiederherstellen zu können, falls mein Raspberry abstürzt und ich mit einem ganz neuen Gladys Raspbian-Image neu starten muss?
Aber Achtung bei einem „heißen“ Backup: Gladys schreibt in eine SQLite-Datenbank im WAL-Modus, und es gibt daher drei DB-Dateien. Wenn du ein Backup erstellst, das die drei Dateien nacheinander sichert, erhältst du eine beschädigte DB
Am besten ist es, die CLI von SQLite3 zu verwenden, um die DB in eine einzige Datei zu duplizieren, bevor du sie sicherst.
Danke für die Klarstellung.
Ich nehme an, ich kann auch einen « docker container stop gladys » ausführen, bevor ich den entsprechenden Ordner sichere und dann mit einem « docker container start gladys » wieder starte?
Die CLI von sqlite3 ist bereits im Gladys Docker-Image enthalten (für Gladys Plus-Backups). Sie kann bei Bedarf wiederverwendet werden.
Rclone hingegen sollte meiner Meinung nach klar vom Benutzer eingerichtet werden, wenn er es wünscht. Es ist ein sehr dev-orientiertes Tool, das konfiguriert werden muss. Wenn der Benutzer es installieren möchte, kann er das tun, aber ich denke nicht, dass es unsere Aufgabe ist, es einzubinden (weder im Raspberry Pi OS-Image noch im Docker-Image). Wir bleiben bei den Abhängigkeiten minimalistisch
Falls das Ideen gibt: Ich erstelle Snapshots des Dateisystems (btrfs), die ich verschlüsselt über Restic auf verschiedenen Medien (Cloud/NAS/externer Festplatte, je nach Daten) sichere.
Die Snapshots ermöglichen es mir, die Datenbanken ohne Dienstunterbrechung und mit geringem Datenverlustrisiko zu sichern. Achtung, es ist aber eine etwas fortgeschrittene Technik, die mit Volumes/Partitionen/Dateisystemen hantiert, das Risiko von Datenverlust ist durchaus real.
Übrigens, ich sehe, dass ihr Syncthing erwähnt. Das ist ein super Software, aber sie macht nur Datenreplikation, keine Backups! Es mag ähnlich klingen, aber es sind zwei völlig unterschiedliche Dinge. Wenn eine Datei auf einem Speichermedium beschädigt wird, kann sich diese Beschädigung stark auf die anderen synchronisierten Speicher ausbreiten. Gleiches gilt für das Löschen einer Datei.
Also nicht geeignet für Backups.