Sicherung von Raspberry (SSD 60GB) mit openHabian auf Raspberry mit OMV als NAS

[Locke]

Hi,
ich würde gern mein vorgehen Sicherung des Raspi's ändern/verbessern, nachdem bei meinen letzten crash meine Sicherung für die Katz war, da ich es nicht nach dem wechsel von SD-Karte auf SSD nicht angepasst hatte.
Dank @Udo habe ich es wieder zum laufen bekommen.

Bisher hatte ich immer ein kpl. Image von meinem Raspi mit SSD gemacht per dd (um Grafana+Influx mit gesichert zu haben), nun kam hier auf es auch über rsync zu machen um auch Speicher zu sparen, da es (so wie ich es verstanden habe) nur 1x eine Datei in voller Größe gesichert wird und danach nur noch veränderte Dateien ausgetauscht werden.

Open Media Vault bietet rsync und rsnapshot an, nur habe ich noch nie damit gearbeitet, im Netz stehen soviele Möglichkeiten das mir der Kopf raucht.
Könnt ihr mir helfen beim einrichten, wie zb. muss rsync auf dem openHab Raspi installiert werden, was muss ich mounten (/dev/sda ?) damit es läuft, muss openHab oder weitere Dienste gestoppt werden ?

Dann ist da noch Pull und Push, wie muss ein Script für rsnapshot aussehen ?
Auf OMV habe ich einen Ordner "Backup-rsync" freigegeben.

Vielleicht nutz ja jemand von euch auch OMV.

Ich hoffe ihr könnt mir dabei helfen es einzurichten und zu verstehen.

Danke

[udo1toni]

Ja, rnsapshot ist eine wirklich leistungsfähige und sehr datensparsame Art der Sicherung.

rnsapshot nutzt dabei rsync als Dienst.

Je nachdem wie man das möchte, reicht es schon, auf dem openHAB System einen Backup User anzulegen (mit Public/Private Key), der Leseberechtigung für alle zu sichernden Dateien hat. Der Zugriff kann dann über ssh erfolgen.

Auf dem Server, der rsnapshot ausführt, wird dann in der rsnapshot.conf eine Zeile (oder auch mehrere) mit den Zugangsdaten und dem/den zusichernden Verzeichnis(sen) eingetragen. Weiterhin wird in derselben Datei festgelegt, wie viele Versionen der verschiedenen Stufen aufgehoben werden sollen. Zusätzlich musst Du natürlich noch den Private Key hinterlegen und in der

Wenn die Konfiguration hinterlegt ist, kannst Du einen Testlauf machen, indem Du z.B. einfach rsnapshot hourly aufrufst, woraufhin rsnapshot ein Backup aller konfigurierten Verzeichnisse erzeugen sollte.
Zum Abschluss musst Du dann noch cron Jobs einrichten, die (passend zum jeweiligen Namen...) regelmäßig rnsapshot mit der passenden Frequenz und dem jeweils dazu passenden Parameter aufrufen (z.B. 5 * * * * und der Parameter hourly - und dran denken, das crontab als kleinste Einheit Minuten hat, nicht Sekunden wie Quratz Cron in openHAB)

Statt ssh kann man auch rsync auf dem openHAB Server installieren, rsync hat einen extra Modus um über IP zuzugreifen.

[Locke]

Ja, rnsapshot ist eine wirklich leistungsfähige und sehr datensparsame Art der Sicherung.

Hi Udo,
mein Problem ist das ich nicht weiß wie ich es in OMV einstelle, bzw. was ich mounten muß.
Muß ich ein extra Backup-Programm laufen lassen oder erledigt das alles rsync/rsnapshot selbst ?

so sieht es unter OMV aus, kannst Du mir da auch weiterhelfen ?

rsnapshot.png

rsync.png

Danke

[udo1toni]

Gute Frage

Mit OMV kenne ich mich nicht aus, aber ein paar Postings zu rsnapshot und OMV legen für mich nahe, dass es folgendermaßen läuft:

1. Du richtest einen ssh Zugang auf dem Quellsystem (openHAB Rechner) ein. Der ssh Zugang beinhaltet ein Login mittels Public/Private Key Verfahren.
2. Du richtest im OMV eine rsync Aufgabe ein, die per Pull über ssh regelmäßig (z.B. immer 5 Minuten nach der vollen Stunde) ein Backup zieht. Dieses Backup speicherst Du lokal in einem OMV verzeichnis.
3. Du richtest rsnapshot ein, das lokale Verzeichnis von OMV zu snapshotten. Dieser Job sollte naturgemäß erst laufen, wenn der rsync Job durch ist.

Initial kann rsync eine Weile beschäftigt sein, danach sollte es aber, von absoluten Ausnahmen mal abgesehen, innerhalb weniger als einer Minute alles übertragen haben - die Änderungen innerhalb einer Stunde sind ja überschaubar und rsync überträgt nur Änderungen und nutzt dabei auch noch starke Kompression.
Es bietet sich also an, zunächst den rsync Job einzurichten und zu prüfen, dass die Daten lokal ankommen. Sobald rsync das erste Mal erfolgreich gearbeitet hat, kannst Du dann den rsnapshot Job einrichten.

Was mir nicht zu 100 % klar ist, ist, ob rsyncd lokal auf dem openHAB system eingerichtet werden muss, und leider ist das bei mir auch schon wieder sechs Jahre her...

[Locke]

Gute Frage

ich habe jetzt die Verbindung hinbekommen (frage mich bitte nicht wie), wenn ich aber als Quellserver /mnt/nas/ nehme holt sich OMV ein altes Backup von einer Sicherung die ich mit dd und cronjob gemacht hatte aus dem Verzeichnis (hier raspi_164) welches auf dem OMV liegt.

Muss ich eine neue Sicherung per dd machen und mit dieser Sicherung den rsync laufen lassen ?

Oder sollte rsync eine eigene kpl. Sicherung starten und damit weiter arbeiten ?

Wenn ja was muss ich dann als Quellserver angeben und auf dem openHAB System mounten ?

sorry, ich habe noch nicht verstanden ob rsync die Sicherung selbst erstellt oder ob ich sie erst erstellen lassen muss.

ich habe mal die alten Sicherungsdateien aus dem Ordner "raspi_164" auf dem OMV gelöscht (probiere es mit einem Testsystem) und dann rsync manuell gestartet.

Als Ausgabe von OMV kommt:

Code: Alles auswählen

Please wait, syncing <openhabian@192.168.123.164:/mnt/nas/> to </srv/dev-disk-by-uuid-95583d56-cb1a-4d70-a385-1aa7327fedef/test/> ...

receiving incremental file list

sent 20 bytes  received 51 bytes  142.00 bytes/sec
total size is 0  speedup is 0.00
The synchronisation has completed successfully.

END OF LINE

[udo1toni]

Du willst gar keine Sicherung per dd erstellen, dafür müsstest Du den entsprechenden Datenträger vorher aushängen oder zumindest ReadOnly remounten. Du willst Dateien bzw. Verzeichnisse sichern, keine Images.
rsync kopiert Daten von a nach b (wobei a und b zwei frei wählbare Verzeichnisse sind, a und b müssen sich unterscheiden (klar...), es ist aber egal, wo sich die beiden Verzeichnisse befinden, ob lokal und lokal, remote und lokal, lokal und remote oder auch remote und remote.

Da das Backup vom Remote System (openHAB) auf das lokale System (OMV) erfolgen soll, muss der Quellserver für den rsync Job das Remote System sein, gewöhnlich erfolgt der Zugriff dann über ssh (so ist das auch abgebildet...)
Wie oben erwähnt musst Du das Ganze in zwei Schritten erledigen, weil Du rsnapshot unter OMV nicht passend konfigurieren kannst (das ist aber eine reine OMV Einschränkung)
Schritt 1: vom Remote System die Daten nach OMV kopieren (über ssh und rsync, die rsync Konfiguration kümmert sich darum)
Schritt 2: vom lokalen Verzeichnis eins ins lokale Verzeichnis zwei per rsnapshot. Damit wird also die Historie erstellt, mit der Du zu verschiedenen alten Dateiständen zurückkehren kannst.

[Locke]

Du willst Dateien bzw. Verzeichnisse sichern, keine Images.

Hi Udo,
kannst Du mir sagen welche Verzeichnisse die wichtigen sind um das System nach einem Ausfall wieder zum laufen zubekommen incl. Grafana/Influxdb ?

Ich denke das ich dann für jedes Verzeichnis/Datei welches kopiert werden soll ein Auftrag anlegen muss, oder kann man es in einem Auftrag eingeben ?

Ich finde im Netz immer nur Anleitungen wie man OMV auf einem Raspi installiert (haufenweise), aber keine richtigen Beispiele wie es zb. eingerichtet wird um das zu tun was ich möchte. Klar kann es das nicht genau für meine Bedürfnisse geben, aber ich finde da garnichts in der Richtung das es jemand so gemacht hat und Beispiele zeigt.
Da ich in der Beziehung nicht viel Ahnung habe ist es dann schwer es zum laufen zubekommen.

Danke

[udo1toni]

Für openHAB sind die relevanten Verzeichnisse
$OPENHAB_CONF (enthält textuelle Konfiguration. Wenn Du hier nicht explizit Änderungen vornimmst, kannst Du das Verzeichnis auslassen)
und $OPENHAB_USERDATA. Hier landet alles, was über die UI konfiguriert wurde, außerdem noch Persistence und Backups, deshalb Obacht, evtl. das Verzeichnis $OPENHAB_USERDATA/backups/ ausklammern.

Eine vollständige Liste aller relevanten Verzeichnisse für openHAB liefert der Befehl openhab-cli info, aber tatsächlich reichen die beiden genannten Verzeichnisse, um ein frisch installiertes openHAB komplett zu konfigurieren. Beim Restore muss man nicht mal alle Dateien zurück spielen, oftmals reichen die Zweige $OPENHAB_USERDATA/jsondb, $OPENHAB_USERDATA/etc und $OPENHAB_USERDATA/persistence

Grafana: Es sollte ein Verzeichnis /etc/grafana/ geben, dort sollte eine Datei grafana.ini zu finden sein. Zum einen muss das gesamte Verzeichnis /etc/grafana/ gesichert werden, zum anderen musst Du in der Datei grafana.ini nachschauen, wie Grafana seine Daten sichert. Leider ist Grafana extrem flexibel und es gibt verschiedene Optionen, die Einstellungen zu sichern. Eine einfache Möglichkeit ist sqlite, dann wären die Daten vermutlich in /var/lib/grafana zu finden.

InfluxDB hat seine ganz eigene Strategie, Daten aufzubewahren. Grundsätzlich sollte es ein Verzeichnis /var/lib/influxdb geben, in dem es ein Verzeichnis engine und darin wiederum ein Verzeichnis data geben sollte, welches dann weitere Verzeichnisse enthält. Ob es hinreichend ist, dieses Verzeichnis zu sichern, kann ich Dir aber nicht sagen, ich bin noch nie in die Verlegenheit gekommen, Daten wiederherstellen zu müssen...

Ganz grundsätzlich böte es sich an, wenn Du alles neu machst, die Partitionierung der SSD etwas besser zu organisieren, als openHABian das tut (denn die Partitionierung ist auf eine SD-Karte optimiert und für SSDs eher ungeeignet). Leider mache ich damit schon wieder das nächste Fass auf, mit dem Du Dich ins Koma saufen kannst...

[Locke]

Hi Udo,
erstmal Danke dafür das Du und andere hier soviel Unterstüzung geben bei Problemen oder bei Fragen (die für viele hier einfache Fragen sind).
Ich denke ohne eure Unterstützung würden viele hier verzweifeln.

Ich werde es mal testen mit rsync und den besagten Verzeichnissen/Dateien. Das Testen wird helfen es evtl. besser zu verstehen.

In der Tat habe ich gelesen das einige die Partion auf der SSD verkleinern (auf 32GB) mit "gparted" und einem Raspi auf dem Raspian OS mit Desktop läuft, dann die SSD anhängen und die Partition verkleinern.

Hast Du vielleicht einen Link wo man lesen kann wie man die Partitionierung der SSD besser zu organisieren kann/sollte ?

Danke

[udo1toni]

Letztlich ist das ein Stück weit Geschmacksache Es ist ja nicht so, dass es mit einer großen Partition nicht ginge. Aber gerade wenn man tatsächlich Backups per Image macht, ist z.B. eine einzelne 120 GByte Partition eher unhandlich (und selbst 32 GByte sind in meinen Augen too much).
Außerdem enthält eine große Partition jede Menge "Müll", der eigentlich überhaupt nicht gesichert werden sollte.
Eine typische Aufteilung wäre z.B., etwa 4 GByte für / zu verwenden, /home auf eine eigene Partition zu packen, genau wie /var und /tmp. Diese extra Partitionen werden anschließend auf diesen Punkten eingehängt. Als Größe kann man abhängig von der echten Größe auch eher niedrige Werte nehmen, meinetwegen jeweils 4 GByte. Wenn man sehr viele Daten hat (massig Items, die persistiert werden, mit rrd4j, MariaDB und InfluxDB) vielleicht auch 16 GByte für /var, aber meist überschätzt man den Platzbedarf auch.
Wenn Du ein bestehendes System hast, kannst Du Dir mittels

Code: Alles auswählen

sudo du -hs /*

einen Überblick verschaffen, welches Verzeichnis tatsächlich wie viel Speicherplatz belegt.

Nun kann man das System (also /), die Userdaten (also /home) und variable Daten (also /var) getrennt sichern, und temporäre Daten (/tmp) werden überhaupt nicht gesichert.
Das Mehr-Partitionen-Modell ist aber nicht nur für die Image Sicherung praktisch, sondern z.B. auch, wenn eines der Dateisysteme wegen eines Fehlers Probleme macht, weil der Rest des Systems weiterhin funktioniert; man hat also bessere Chancen, das System zu reparieren (immer vorausgesetzt, man kennt sich aus...)

Noch besser wird es, wenn man lvm nutzt (Logical Volume Manager), denn damit kann man Partitionen "einfrieren" (Snapshot erstellen) und sogar klonen. Auch vergrößern und sogar verkleinern der Partitionen ist damit leicht möglich.
Snapshots sind in dem Zusammenhang nicht dazu gedacht, dauerhaft erhalten zu bleiben, man kann damit aber dafür sorgen, dass die Partition einen konsistenten, unveränderlichen Zustand hat, um z.B. in Ruhe im laufenden Betrieb ein Backup zu erstellen, ohne dass Schreibzugriffe hier zu Fehlern führen könnten.