FHEM ist plötzlich tot und startet nicht mehr.

[flummy1978]

Holla,

weil es jetzt doch von einigen erwähnt wurde und auch für einen Windows Nutzer (wie mich) der FHEM auf dem RasPI laufen hat, ist es eine lösbare Aufgabe geworden, die Datensicherung zu machen. Mein (übertriebenes) Backup sieht so aus (besser haben als brauchen )

Jeden Tag wird n Fhem Backup gezogen (extern)
Jeden Tag werden  die config Dateien von zigbee2mqtt gesichert (extern) - übertrieben ruht aber noch aus den Testzeiten und Basteltagen
Alle 3 Tage ein Fullbackup von der SD Karte gezogen (um genau zu sein Mittwoch und Samstag)
99 %der logs landen bereits auf der SQL Datenbank (extern)
Nur noch testlogs und cfg (noch nie dran getraut es auf dbconfig umzustellen)  schreiben effektiv (neben dem Betrieb) auf die sd Karte..... (das zum Schutz der Karte, dass diese eben nicht so schnell stirbt)


Tägliches Backup:

Code Auswählen Erweitern

#!/bin/bash
# VARIABLEN - HIER EDITIEREN
BACKUP_PFAD="//backup"
BACKUP_ANZAHL="5"
BACKUP_NAME="FhemPi"
# ENDE VARIABLEN

# Backup
sudo cp /opt/zigbee2mqtt/data/configuration.yaml //backup/FHEM_auto/zigbee/zigbee_config_$(date +%Y%m%d).yaml
sudo cp /opt/zigbee2mqtt/data/database.db //backup/FHEM_auto/zigbee/zigbee_database_$(date +%Y%m%d).db
sudo cp /opt/fhem/backup/FHEM-$(date +%Y%m%d)_013000.tar.gz //backup/FHEM_auto/backups/FHEM-$(date +%Y%m%d)_013000.tar.gz
sudo cp /opt/fhem/backup/FHEM-$(date +%Y%m%d)_013001.tar.gz //backup/FHEM_auto/backups/FHEM-$(date +%Y%m%d)_013000.tar.gz


Fullbackup

Code Auswählen Erweitern

#!/bin/bash
# VARIABLEN - HIER EDITIEREN
BACKUP_PFAD="//backup"
BACKUP_ANZAHL="5"
BACKUP_NAME="FhemPi"

# Backup mit Hilfe von dd erstellen und im angegebenen Pfad speichern
sudo dd if=/dev/mmcblk0 of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img bs=1MB

# Alte Sicherungen die nach X neuen Sicherungen entfernen (deaktiviert)
#pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd


Aufgerufen wird das Ganze über einen Cronjob:

Code Auswählen Erweitern


45 1 * * * sudo /usr/local/bin/Backup_daily.sh
30 2 * * 3,6 sudo /usr/local/bin/Backup.sh


Für mich persönlich einfach nur wichtig, vor allem für ungeübte Linux Nutzer wie mich:
Ihr kommt um das Lesen nicht herum. Eine Vorgekaute und vorgefertigte Lösung ist manchmal schön. Zu wissen WAS und vor allem warum ist meistens doch besser - Spätestens bei der Fehlersuche

Vielleicht hilft es ja jemandem, der diesen Beitrag mal findet

Viele Grüße & bleibt gesund
Andreas

[MadMax-FHEM]

Das Backup mittels dd des laufenden Systems würde ich aber nicht empfehlen...
...in den seltesten Fällen ist das brauchbar...

Und wie gut ein Backup(mechanismus) ist...
...merkt man erst beim (Test-)Restore...

Gruß, Joachim

[Torben80]

@otto

Es läuft ja gewissermaßen über FSTAB.

Ich mache es nach folgender Anleitung:

https://www.meintechblog.de/2015/05/fhem-howto-automatisches-backup-auf-externem-nas/

Kannst ja mal drüber schauen. Wenn du sagst ,, NEIN !!!!" dann ändere ich dahingehend gerne meine Backupstrategie

Mit freundlichen Grüßen
T


Gesendet von iPhone mit Tapatalk

[flummy1978]

Das Backup mittels dd des laufenden Systems würde ich aber nicht empfehlen...
...in den seltesten Fällen ist das brauchbar...

Mhmm wie gesagt, bin ich kein Linux Experte, daher würde mich interessieren, warum es so ist / sein soll.

Und wie gut ein Backup(mechanismus) ist...
...merkt man erst beim (Test-)Restore...

Genauso ist es und aus dem Grund habe ich bereits mehrmals (insg 3x) das Backup aus der laufenden FHEM Intallation auf eine neue / andere SD eingespielt und getestet. Ich muss dazu sagen, dass es (bis auf einmal) immer die gleiche Hardware war. Jedes Einspielen war ohne Probleme und vor allem war gesamte Restorezeit = Aufspielen des Images auf die SD Karte. Das wars.

Ich habe diese Backupstrategie bereits auf meinem FHEM Raspi und auf einem Raspi mit FipBox Funktion (VPN) und Unifi Controller in einem und auch auf meinem TestRaspi mit FHEM und ein wenig Blödsinn drauf getestet. Jeweil funktionierte es nach Tausch der SD Karte einwandfrei.

Viel Grüße
Andreas

[CoolTux]

Das schreiben von Daten erfolgt zu meist asyncron. Es können sich also noch Daten im Ram, oder im Speicher des Controlers befinden wärend Du eine 1 zu 1 Kopie der Festplatte machst. Und zwar wirklich 1 zu 1 (Bitweise)
Das kann zu inkonsistenz führen bis hin zu "keine Funktion mehr"

[flummy1978]

Das kann zu inkonsistenz führen bis hin zu "keine Funktion mehr"

OK, übersetzt heisst es dann, dass ich meine Anleitung lieber aus dem Beitrag entfernen sollte und es bei mir bisher nur Glücksache war, dass es funktioniert hat ? *grübel*
Mich wundert es einfach nur aus dem Grund, weil das immer und immer wieder empfohlen wird, wenn man Tante Gugl danach befragt.

Welche Variante wäre denn Eurer Meinung nach gut / sinnvoll ?

Grüße
Andreas

[CoolTux]

Ich kann es ohne weiteres offline empfehlen. Aber nie im laufenden Betrieb.

Für jemanden ohne weiterreichende Linuxkentniss würde ich genau die Methode empfehlen für ein Fullbackup.

Es gibt auch Möglichkeiten welche am Ende ein Desaster Recovery

[Wernieman]

@Torben80
Wegen dem verlinkten Beitrag

Code Auswählen Erweitern

fhem    ALL=(ALL) NOPASSWD: ALL

So etwas macht man nicht. Damit ist faktisch FHEM root und warum fhem das nicht sein sollte, dürfte bekannt sein.

Eine Anleitung, welche so etwas Vorschlägt, ist für mich schon ziemlich "heftig" (um nicht "Müll" zu sagen)

Noch eine Ergänzung zu CoolTux Beitrag bezüglich dd im Laufenden betrieb:
Anders als Windows schreibt Unix schon immer ins Ram und dann erst auf die Platte (wenn es zeit hat und/oder RAM braucht). Deshalb reagiert Unix (und Linux als Unix) so empfindlich auf "Strom weg" .... und nix anderes ist faktisch ein DD im laufenden Betrieb. 8Das eien SD dann auch noch relativ langsam ist, verschärft das Problem noch)

Ich hätte noch eine Anmerkung bezüglich Backup:
Ein solches muß automatisch geschehen. Ein manuelles wird vergessen/keine Lust/keine Zeit .... und dann ist im Notfall das letzte 1/2 Jahr alt. Wenn man dagegen /etc und sonstige Configfiles /z.B. /opt/fhem) hat, kann man mit wenig Wissen den Rechner wiederherstellen. Es fehlen "leider" dann bei fhem nur noch die ergänzten Libarys  ...

[Otto123]

@Torben Ja in dem Script wird die fstab angepasst - richtig.
Zu "fhem ist root" hat Werner schon was gesagt, dem kann ich mich nur anschließen. Vor allem wegen Backup von FHEM muss fhem nur "fhem" sein und nie und nimmer root

Der Artikel ist von 2015, das muss man bedenken. Da hat sich in den Systemen einiges geändert, vor allem vieles was 2015 schon bekanntermaßen "abgekündigt" war ist mittlerweile beerdigt. Das hab ich jetzt nur pauschal gesagt, ich habe nicht versucht das gesamte Script zu verstehen.

Wichtig an der Backupstrategie ist vor allem eins: Das restore muss für Dich funktionieren !!!

Versuch das mit dem mounten (auf besserem SMB Level) doch erstmal unabhängig und in Ruhe. Wenn das Backup erstmal läuft wie vorher ist erstmal alles gut.

[curt]

@flummy1978

OK, übersetzt heisst es dann, dass ich meine Anleitung lieber aus dem Beitrag entfernen sollte

Ich würde die Anleitung stehen lassen, aber einen roten Warnhinweis drüber nageln. So in der Art "Verfahren umstritten, siehe folgende Diskussion".

Welche Variante wäre denn Eurer Meinung nach gut / sinnvoll ?

An sowas scheitern selbst große Rechenzentren mit Spiegel-Rechenzentrum ab und an. Ich würde mal so sagen: Das Leben besteht aus Kompromissen. Immer und immer wieder.

Die reine Lehre wurde Dir ja vorgestellt: Nichts und niemand darf während der Sicherung auf das Medium zugreifen. Das Medium darf zudem nicht gemountet sein.

In der Welt der Kompromisse kommt das aber immer wieder vor. Ich habe hier zum Beispiel drei Systeme, die die ständig laufen und ständig laufen müssen, zudem komme ich an das Speichermedium gar nicht so einfach ran. Also mache ich es so ähnlich wie Du.

Die Falle ist aber tatsächlich, dass (wie erwähnt) das System glaubt, dass es auf Platte geschrieben hat, real hängen die Daten aber noch in irgend einem Puffer. Genau genommen ist es sogar noch schlimmer: Da so eine Vollsicherung ja seine Zeit braucht, sichert man praktisch den einen Teil um 2000 Uhr, der letzte Teil ist aber um 2100 Uhr dran - während der Zeit wird im zu sichernden System munter weiter rumgeschrieben. Du hast also gar keine Sicherung mit Stand "2000 Uhr", Du hast einen gewissen Mischmasch.

Viele Sicherungen sind recht gut zurückzuspielen (ich würde dann als erstes mal einem Plattencheck anwerfen!) - aber es gibt halt auch Sicherungen, da holt man sich die Pest (ach, schlechte Wortwahl in diesem Zeiten) also den wochenlangen Ärger direkt ins Haus.