Moin Moin Freunde...
ausgangssituation wie folgt:
Mein FHEM lief 2 Jahre ohne Probleme. Er macht jeden Abend automatisch auf meine NAS ein Backup. Heute merkte ich dann dass mein ALEXA mein Licht nicht maehr schalten möchte.
Ein Blick auf das Web-Frontent verriet mir dann, nichts... Webseite nicht mehr verfügbar. Mein FTUI ist auch tot.
1. Anpingen geht
2. SSH geht
Ich habe seit Wochen und Monaten nichts gemacht. EHRENWORT!
Habe dann nachgesehen, letztes BACKUP vom 23.03.2020 (ja, habe seit dem ALEXA nicht zum Licht an und ausmachen genutzt,...)
root@raspberrypi:~# sudo /etc/init.d/fhem start
E: Problem parsing dependency 20
E: Error occurred while processing bind)-(ost (NewVersion2)
E: Problem with MergeList /var/lib/dpkg/status
E: The package lists or status file could not be parsed or opened.
root@raspberrypi:~# sudo systemctl status fhem
● fhem.service - LSB: FHEM server
Loaded: loaded (/etc/init.d/fhem; generated; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2020-03-27 17:27:38 CET; 9min ago
Docs: man:systemd-sysv-generator(8)
Process: 338 ExecStart=/etc/init.d/fhem start (code=exited, status=100)
Mar 27 17:27:34 raspberrypi systemd[1]: Starting LSB: FHEM server...
Mar 27 17:27:38 raspberrypi fhem[338]: E: Problem parsing dependency 20
Mar 27 17:27:38 raspberrypi fhem[338]: E: Error occurred while processing bind)-(ost (NewVersion2)
Mar 27 17:27:38 raspberrypi fhem[338]: E: Problem with MergeList /var/lib/dpkg/status
Mar 27 17:27:38 raspberrypi fhem[338]: E: The package lists or status file could not be parsed or opened.
Mar 27 17:27:38 raspberrypi systemd[1]: fhem.service: Control process exited, code=exited status=100
Mar 27 17:27:38 raspberrypi systemd[1]: Failed to start LSB: FHEM server.
Mar 27 17:27:38 raspberrypi systemd[1]: fhem.service: Unit entered failed state.
Mar 27 17:27:38 raspberrypi systemd[1]: fhem.service: Failed with result 'exit-code'.
root@raspberrypi:~# ^C
root@raspberrypi:~#
Jemand eine Idee für das weitere Vorgehen?
Gruß Torben
Was sagt denn das FHEM-Log?
Gesendet von iPhone mit Tapatalk
Hallo Torben,
was sagt?
df -H
SD Card voll oder defekt?
Läuft eine Datenbank?
Was sagt
tail /opt/fhem/log/fhem-2020-03.log
So ganz allgemein:
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
Gruß Otto
Vorab, es tut mir leid, dass ich nicht selber gerade tief in die Fehlersuche einsteigen kann, muss mich hier parallel um zwei Kinder kümmern, die in der KiTa freien Zeit voll unf ganz meine ganze Aufmeksamkeit haben wollen... :-)
df -H:
root@raspberrypi:~# df -H
Filesystem Size Used Avail Use% Mounted on
/dev/root 16G 2.1G 13G 15% /
devtmpfs 482M 0 482M 0% /dev
tmpfs 487M 0 487M 0% /dev/shm
tmpfs 487M 19M 468M 4% /run
tmpfs 5.3M 4.1k 5.3M 1% /run/lock
tmpfs 487M 0 487M 0% /sys/fs/cgroup
/dev/mmcblk0p1 43M 22M 22M 51% /boot
tmpfs 98M 0 98M 0% /run/user/0
tail /opt/fhem/log/fhem-2020-03.log:
root@raspberrypi:~# tail /opt/fhem/log/fhem-2020-03.log
2020.03.24 09:29:03 3: sduino IT: Toto off->off
2020.03.24 09:29:59 3: nanoCUL IT_set: Toto off
2020.03.24 09:29:59 3: nanoCUL IT_set: Toto off
2020.03.24 09:30:00 3: sduino IT: Toto off->off
2020.03.24 09:30:05 2: sduino: CUL_TCM97001_08: Unknown device CUL_TCM97001_53 model:W044 msg:s35514F545100, please define it
2020.03.24 09:30:05 1: sduino: SD_WS_Parse UNDEFINED sensor SD_WS_51_TH detected, code SD_WS_51_TH_1
2020.03.24 09:30:24 3: LaCrosse: Unknown device 0A, please define it
2020.03.24 09:30:59 3: nanoCUL IT_set: Toto off
2020.03.24 09:30:59 3: nanoCUL IT_set: Toto off
2020.03.24 09:31:01 3: CUL_HM set HM_4D0C5A getConfig
Also, fhem ist offenbar seit dem 24.3. nicht mehr gestartet.
Die Meldung beim Start kommt mir komisch vor, diese Art Meldungen passen eher zu Installationen nicht zum Start von Diensten.
Was gibt Dir dies zurück?
cat /etc/init.d/fhem
Wie sehen die am Start beteiligten Dateien aus?
ls -lha /opt/fhem/fhem.*
Gruß Otto
Was ich komisch finde, dass es sich ohne Stromausfall usw verabschiedet. Ich hatte mich schon gewundert, dass Abends ALEXA mein Licht nicht mehr ausschaltete, dachte aber dass das sonst etwas wieder ist...
cat /etc/init.d/fhem:
root@raspberrypi:~# cat /etc/init.d/fhem
#!/bin/sh
# description: Start or stop the fhem server
# Added by Alex Peuchert
### BEGIN INIT INFO
# Provides: fhem.pl
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: FHEM server
### END INIT INFO
set -e
cd /opt/fhem
port=7072
if test "$2" != "noaptmark"; then
apt-mark hold fhem > /dev/null
fi
case "$1" in
'start')
echo "Starting fhem..."
# if you need to start hmland for use with
# Homematic, please start the hmland daemon
# like this (please use correct path and port,
# depending on your installation!)
#
# /opt/hmcfgusb/hmland -d -p 1234 -r 0
#
perl fhem.pl fhem.cfg
# if you want to use configDB for configuration,
# use this command to start fhem:
#
# perl fhem.pl configDB
#
# and remove/comment the above line including fhem.cfg
RETVAL=$?
;;
'stop')
echo "Stopping fhem..."
# if you want to stop hmland during fhem stop:
# pkill hmland
pkill -U fhem perl
RETVAL=$?
;;
'status')
cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
if [ "$cnt" -eq "0" ] ; then
echo "fhem is not running"
else
echo "fhem is running"
fi
;;
*)
echo "Usage: $0 { start | stop | status }"
RETVAL=1
;;
esac
exit $RETVAL
root@raspberrypi:~#
und
ls -lha /opt/fhem/fhem.*:
root@raspberrypi:~# ls -lha /opt/fhem/fhem.*
-rw-r--r-- 1 fhem dialout 49K Feb 25 2019 /opt/fhem/fhem.cfg
-rw-r--r-- 1 fhem dialout 25K Jul 18 2019 /opt/fhem/fhem.cfg.demo
-rw-rw-rw- 1 fhem root 189M Mar 24 09:28 /opt/fhem/fhem.db
-rw-rw-rw- 1 fhem dialout 32K Mar 24 09:30 /opt/fhem/fhem.db-shm
-rw-rw-rw- 1 fhem dialout 4.0M Mar 24 09:30 /opt/fhem/fhem.db-wal
-rwxr-xr-x 1 fhem dialout 157K Jan 1 20:35 /opt/fhem/fhem.pl
root@raspberrypi:~#
Zitat von: Torben80 am 27 März 2020, 17:54:44
E: Problem parsing dependency 20
E: Error occurred while processing bind)-(ost (NewVersion2)
E: Problem with MergeList /var/lib/dpkg/status
E: The package lists or status file could not be parsed or opened.
Das hier riecht nach Problemen in der apt-Library.
Läuft bei Dir ein automatisches Update vom System? Wenn, hat es sich da wohl etwas zerhäckselt.
Du kannst mal hier https://www.linuxquestions.org/questions/debian-26/apt-get-problem-problem-parsing-dependency-depends-906264/ (https://www.linuxquestions.org/questions/debian-26/apt-get-problem-problem-parsing-dependency-depends-906264/) reinlesen. Könnte helfen.
Ansonsten ist es aber wohl einfacher, das System kurz neu aufzusetzen und das Backup zurückzuspielen.
Zitat von: alanblack am 27 März 2020, 21:01:01
Läuft bei Dir ein automatisches Update vom System?
Wie finde ich das denn nun wieder heraus. Wie gesagt, ich hatte alles vor 2 Jahren fast aufgesetzt, seither lief alles einwanfrei. Habe lediglich alle paar Monate mal bei FHEM UPDATE gemacht...
System neu aufsetzen und Backup einspielen, bedeutet für mich dann aber auch, dass ich den Fehler wieder mit einspiele?
ohohoh, Ich habe so keine Zeit dafür gerade... Das kann doch nicht wahr sein.
mfg T
Von Hand als root apt-get update mal ausführen. Wenn das geht ein apt-get upgrade
@CoolTux
root@raspberrypi:~# apt-get update
Get:1 http://archive.raspberrypi.org/debian stretch InRelease [25.4 kB]
Get:2 http://mirrordirector.raspbian.org/raspbian stretch InRelease [15.0 kB]
Get:3 http://archive.raspberrypi.org/debian stretch/main armhf Packages [220 kB]
Get:4 http://mirrordirector.raspbian.org/raspbian stretch/main armhf Packages [11.7 MB]
Get:5 https://deb.nodesource.com/node_4.x stretch InRelease [4,647 B]
Get:6 http://archive.raspberrypi.org/debian stretch/ui armhf Packages [45.0 kB]
Get:7 https://deb.nodesource.com/node_4.x stretch/main armhf Packages [1,010 B]
Get:8 http://mirrordirector.raspbian.org/raspbian stretch/contrib armhf Packages [56.9 kB]
Get:9 http://mirrordirector.raspbian.org/raspbian stretch/non-free armhf Packages [95.5 kB]
Fetched 12.1 MB in 1min 9s (174 kB/s)
Reading package lists... Error!
E: Problem parsing dependency 20
E: Error occurred while processing bind)-(ost (NewVersion2)
E: Problem with MergeList /var/lib/dpkg/status
E: The package lists or status file could not be parsed or opened.
root@raspberrypi:~#
Da hat es wohl das packages System zerlegt. Schau mal im Netz welche Möglichkeiten es da zur Reperatur gibt. Einfach den letzten Fehlersatz mal in Google eingeben.
Ja, das mache ich,...
oder ist es hier gleich ratsam Raspbian Buster Lite gleich neu zu installieren?
Zitat von: Torben80 am 27 März 2020, 22:07:09
Ja, das mache ich,...
oder ist es hier gleich ratsam Raspbian Buster Lite gleich neu zu installieren?
Das wäre natürlich das beste!!!
Zitat von: Torben80 am 27 März 2020, 21:04:26
System neu aufsetzen und Backup einspielen, bedeutet für mich dann aber auch, dass ich den Fehler wieder mit einspiele?
Eher nicht, denn der Fehler liegt offensichtlich im System und nicht in FHEM. Also:
- Image von raspian
- Perl und was Dein FHEM sonst noch braucht
- FHEM-Ordner aus dem Backup holen
- starten... sollte laufen
Zitat
ohohoh, Ich habe so keine Zeit dafür gerade... Das kann doch nicht wahr sein.
Zitat von: Torben80 am 27 März 2020, 22:07:09
Ja, das mache ich,...
oder ist es hier gleich ratsam Raspbian Buster Lite gleich neu zu installieren?
Das letzte Mal, als ich das obige durchgeführt habe, hat es ca. 2 Stunden gedauert. Frei nach dem Motto:
"Du hast nur ein Backup, wenn Du das Restore auch schon zum Laufen gebracht hast."
Mit einem funktionierenden Backup habe ich mir abgewöhnt, lange nach Fehlern zu suchen; zumindest wenn die Fehler so eindeutig wie bei Dir aus einem kaputten Betriebssystem kommen.
EDIT: wenn Du selbst keinen Cron-Job für Updates angelegt hast, dürfte kein automatisches Update die Ursache sein. Dann solltest Du über
Zitat von: Otto123 am 27 März 2020, 18:05:52
SD Card voll oder defekt?
nachdenken. Zusätzlicher Tipp: voll ist Deine nicht . ;)
Ich vermute SD Card defekt ::) also auf alle Fälle eine neue nehmen.
Und 2 Jahre nichts gemacht bedeutet sicher auch restore nie probiert. Na da bin ich mal gespannt und drücke die Daumen!
Trotzdem ist mir noch nicht klar, wieso beim start vom fhem service nichts ins Log geschriebn wird und statt dessen ein Systemupdate anläuft?
Und offenbar wird der Service mit fhem.cfg gestartet aber die fhem.db (configdb) verwendet?! Oder was ist fhem.db Für logging wäre doch 189 M ziemlich wenig?
-rw-r--r-- 1 fhem dialout 49K Feb 25 2019 /opt/fhem/fhem.cfg
-rw-r--r-- 1 fhem dialout 25K Jul 18 2019 /opt/fhem/fhem.cfg.demo
-rw-rw-rw- 1 fhem root 189M Mar 24 09:28 /opt/fhem/fhem.db
Hier mal schnell einige Antworten.
@Otto, danka für das Daumen drücken.
Habe das neue System aufgesetzt, und danach direkt das Backup eingespielt.
Musste jetzt lediglich die Module vom LED_Stripe sowie Alexa nachziehen... Außerdem muss ich die Scripts für mein externes Backup neu einrichten.
Alles weitere (HM-Mod-RPI, LaCrosse, NanoCUL, uvm) lief auf Anhieb wieder.
Ich glaube das war es dann wohl... Schieben wir es mal auf eine defekte SD-Karte?
Ich wünsche erst einmal ein schönes Wochenende :-)
#StayHealth
Torben
So, moin noch einmal...
Das Einzige was jetzt echt länger gedauert hat, war das Backup. Das Mounten über das Script hat nicht mehr hingehauen.
vorheriger Mount-Befehl:
mount //192.168.xxx.xxx/fhembackup /mnt/syno cifs username=pi,password=GEHEIM,iocharset=utf8,sec=ntlm 0 0
musste durch:
mount //192.168.xxx.xxx/fhembackup /mnt/syno cifs username=pi,password=GEHEIM,iocharset=utf8,vers=1.0,sec=ntlm 0 0
ersetzt werden.
Danach hat der Zugriff / Mount wieder funktioniert.
@Torben80
Alles jetzt zufällig nachgelesen, da ich gerade selbst eine Frage stellte.
Zitat von: Torben80 am 28 März 2020, 22:03:11
Habe das neue System aufgesetzt
Besser ist das.
Das Protokoll in Deinem ersten Beitrag sagte recht eindeutig, dass ein Systemupdate (des Servers selbst) schief ging. (Das kann man oft nachträglich reparieren, aber nicht immer.)
Falls Dein FHEM-Server ein Raspberry ist, ist es eine schlaue Idee, immer mal wieder (so jeden Monat oder jeden zweiten Monat) eine bitgenaue Kopie der SD-Card zu sichern: FHEM runter, SD-Card in PC, unter Linux mit dd das ISO wegschreiben. (Unter Windows geht das auch, aber da suche ich Dir das Tool jetzt nicht.)
Bleib fein gesund.
Unter Windows nennt sich das Tool Win32DiskImager.
Damit sichere ich in regelmäßigen Abständen die produktive SD-Karte und habe auf meinem NAS diverse Zwischenstände davon gesichert.
Das ist nur die halbe Wahrheit.
Denn wenn wenn man Pech hat, dann ist die neue SD-Karte gleicher Größe um die entscheidenen Byte zu klein. Und dann funktioniert Win32DiskImager nicht mehr.
Karten gleichen Typs eines Herstellers können auch unterschiedliche tatsächlich nutzbare Kapazitäten haben.
Mein Image verkleinere ich daher immer noch über ein Script. (Stichwort pishrink.sh)
Und wenn man ganz viel Pech hat, dann ist die Kopie von einer bereits defekten (oder auf dem Weg dahin) SD Karte angefertigt worden und somit auch gleich Müll...
...also zumindest die Daten "darin"..
Mir reicht es locker fhem-backup zu machen, nicht viel Platz (verglichen mit Komplett-Image), daher kann ich leicht mehrere aufheben (falls obiges Problem auch da zuschlagen sollte)...
PI neu aufsetzen mit neuem Buster-lite (oder was immer aktuell ist) dauert kürzer (weil kleineres Image ;) ) als das Einspielen einer 16GB (oder noch mehr) Komplettsicherung...
Dann ein paar Einstellungen und fhem installieren (the easy way geht ratz fatz)...
Gut jetzt wäre in etwa das Sicherungsimage eingespielt ;)
Dann noch (aus den hoffentlich guten Notizen) fehlende Pakete und Einstellungen...
...Backup einspielen -> done...
UND: ich kann so gleich auf ein (sauber installiertes / gegenüber "hochgezogen") neues OS (falls es was gibt inzwischen) :)
Hat die letzten Male prima geklappt... :)
(Einmal wegen SD-Defekt und dann eben von Wheezy über Jessie und Stretch nun zu Buster)
Gruß, Joachim
P.S.: man kann auch mit Clonezilla "clonen", dann wird nur "verbraucht" (beim Aufheben) was auch tatsächlich genutzt wird (also nicht die vollen 16GB oder mehr)...
...gut beim Zurückspielen muss man bissi was "üben", dafür ist es aber auch egal wie groß die neue SD ist, Hauptsache groß genug für den genutzten Platz...
Zitat von: MadMax-FHEM am 30 März 2020, 08:59:34
Mir reicht es locker
(Drei Kilometer weitere Anleitung gelöscht.)
Du hast echt zu viel Zeit.
Es muss einfach sein, sonst macht das doch niemand.
Eine bitgenaue Kopie ist völlig einfach, da muss ich auch einem Windows-Vorredner widersprechen: SD-Card in den PC-Reader, dann "dd if=/dev/dasistdasDevice of=2020-03-30-fhem-sicherung.iso . Das ist dann eine Datei auf dem PC. Und wenn die neue SD-Card wegen eines Bytes rumzicken sollte (unwahrscheinlich), dann kauft man die nächstgrößere SD-Card.
Zitat von: MadMax-FHEM am 30 März 2020, 08:59:34
Gut jetzt wäre in etwa das Sicherungsimage eingespielt ;)
<lacht laut> Ich sag es doch. ;)
Zitat von: Torben80 am 29 März 2020, 23:25:04
mount //192.168.xxx.xxx/fhembackup /mnt/syno cifs username=pi,password=GEHEIM,iocharset=utf8,vers=1.0,sec=ntlm 0 0
Wenn das wirklich so ist, das deine NAS nicht besser als SMB 1.0 kann, dann würde ich nicht mit samba bzw cifs arbeiten. Ich verlinke dazu mal noch diesen Beitrag (https://forum.fhem.de/index.php/topic,107312.msg1013478.html#msg1013478).
Die syno kann doch bestimmt was unix "eigenes" wie nfs!?
Gruß Otto
Einfach ja...
...aber wenn das "ursprungs-Image" bereits "Ausfallerscheinungen" hat(te) wovon das Sicherungsimage stammt...
...dann hat man schnell und einfach (einen Haufen) "Müll" ;)
Gruß, Joachim
P.S.: einfach ist halt nicht immer einfach ;)
@Otto
Die NAS kann SMB1, 2 und 3.
Werde heute Abend mal weiter schauen ob es auch mit ,,Ver 3.0" klappt oder was ich als Mount-Befehl eintragen muss.
Dem Rest erst einmal danke an dieser Stelle wieder für die Ideen und Beiträge.
Mit freundlichen Grüßen
Torben
Gesendet von iPhone mit Tapatalk
Zitat von: Nobbynews am 30 März 2020, 08:51:20
Das ist nur die halbe Wahrheit.
Denn wenn wenn man Pech hat, dann ist die neue SD-Karte gleicher Größe um die entscheidenen Byte zu klein. Und dann funktioniert Win32DiskImager nicht mehr.
Karten gleichen Typs eines Herstellers können auch unterschiedliche tatsächlich nutzbare Kapazitäten haben.
Mein Image verkleinere ich daher immer noch über ein Script. (Stichwort pishrink.sh)
Gibt es hier auch Alternativen für Windows-Nutzer, wie mich?
Deine genannte Problematik leuchtet ein.
Zitat von: Torben80 am 30 März 2020, 09:44:58
@Otto
Die NAS kann SMB1, 2 und 3.
Du hast doch gesagt, dass der Krempel wieder läuft?
Dann gilt die Regel "never touch a running system".
Zitat von: Dracolein am 30 März 2020, 09:55:53
Gibt es hier auch Alternativen für Windows-Nutzer, wie mich?
Du willst die Antwort nicht hören: Du musst auf Linux umsteigen.
Hattest Du ja eh schon ins Auge gefasst - jetzt ist der perfekte Zeitpunkt.
Zitat von: Torben80 am 30 März 2020, 09:44:58
@Otto
Die NAS kann SMB1, 2 und 3.
Werde heute Abend mal weiter schauen ob es auch mit ,,Ver 3.0" klappt oder was ich als Mount-Befehl eintragen muss.
Ich bin da immer sehr minimalistisch und bin der Meinung die sollten das selbst aushandeln. Ich bin nicht sicher ob dein ntlm dabei gestört hat.
Ich mache das über fstab, falls da es nachlesen willst (https://heinz-otto.blogspot.com/search?q=cifs). :)
Gruß Otto
@Curt
Oh man,... hab eben die Version von ,,vers=1.0" auf 3.0 versucht. Nun Mountet er gar nicht mehr.
Ich idiot. Auch nach dem löschen derceinträge in ,,fstab".
Naja,... dann hab ich nachher und heute Abend etwas zu tun, LOL.
Schönen Nachmittag erst einmal.
@otto
Ich werde deine Idee mal versuchen umzusetzen. Muss meine Script dann aber anpassen und mal schauen wo der Unterschied beim mounten zwischen unseren beiden ist.
Mit freundlichen Grüßen
T
Gesendet von iPhone mit Tapatalk
Aus meiner Sicht nur Vorteile:
mount über fstab:
- credentials nicht im script sondern in der fstab oder im credential file - damit besser abgesichert
- mount erfordert keine erhöhten Rechte ( sudo ) wie beim ad hoc mounten wie in deinem Fall.
- mount Befehl einfacher/kürzer : mount /pfad
Gruß Otto
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:
#!/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
#!/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:
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
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
@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
Zitat von: MadMax-FHEM am 30 März 2020, 16:46:15
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.
Zitat von: MadMax-FHEM am 30 März 2020, 16:46:15
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
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"
Zitat von: CoolTux am 30 März 2020, 17:22:48
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
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
@Torben80
Wegen dem verlinkten Beitrag
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 ...
@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.
@flummy1978
Zitat von: flummy1978 am 30 März 2020, 17:28:58
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".
Zitat von: flummy1978 am 30 März 2020, 17:28:58
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.