Hallo,
Ein Skript welches ich am Rpi mit
sudo /usr/local/bin/Backup.sh
starte funktioniert.
Nun möchte ich zwei Befehle über FHEM absetzen.
Wenn ich folgendes über ein notify mache klappt es nicht.
RPI.Backup:on set RPI.Backup:off; {system ("sudo /usr/local/bin/Backup.sh")}
Fehlt bestimmt wieder ne Klammer , oder ; ???
Bitte um Hilfe.
Kaspi :)
Versuche mal folgendes
RPI.Backup:on {
fhem("set RPI.Backup:off");;
system ("sudo /usr/local/bin/Backup.sh")}
Tje ... war zu einfach ;)
Danke
system ("sudo /usr/local/bin/Backup.sh")
Während das Script ausgeführt wird blockiert fhem allerdings.
Da ich nicht weiß was das Script tut bzw. wie lange es läuft mag es mehr oder weniger "schlimm" sein...
Besser z.B. nutzen:
system ("sudo /usr/local/bin/Backup.sh &")
oder:
fhem("\"sudo /usr/local/bin/Backup.sh\"")
Bzw.: https://heinz-otto.blogspot.com/2018/02/in-fhem-externe-programme-aufrufen.html
Der user fhem muss dazu aber auch "sudo" OHNE Passwort dürfen...
...also sudoers (bzw. extra Datei unter /etc/sudoers.d/) anpassen und ACHTUNG: besser NICHT dem User fhem generell sudo für ALLES ohne Passwort erlauben!
Gruß, Joachim
Das Script bildet ein komplettes image der SD Karte (bzw. USB Speichers).
Vorher wird FHEM gestoppt.
ca, 90 Minuten warten.......
Danach wird FHEM gestartet.
Ich denke eine andere Lösung gibt es nicht.
Kaspi ;-)
Raspibackup mittels cron...
Backup mittels dd (als einziges Backup) kann schon mal ein nicht (mehr) lauffähiges Backup-Image erzeugen...
Mir reicht automatisiertes fhem Backup auf ein NAS...
EDIT: gefühlt führt das Vorgehen zum "Abschießen" von fhem. Scriptaufruf blockiert fhem. fhem kann nicht "regulär" beendet werden -> wird gewaltsam beendet... (Oder Script bleibt hängen beim Versuch fhem zu stoppen...)
EDIT: ich hoffe das ist nicht deine einzige Backup-Strategie. Was machst du, wenn du auf eine andere OS-Version (oder gar andere Plattform) umziehen willst/musst?
Gruß, Joachim
dies habe ich von irgendeinem Spezi von euch:
#!/bin/bash
# VARIABLEN - HIER EDITIEREN
BACKUP_PFAD="/backup"
BACKUP_ANZAHL="2"
BACKUP_NAME="192.168.178.26-RPI"
# MOUNTEN
sudo mount -t cifs -o user=xxxx,pass=xxxxxxxxxx,vers=1.0 //192.168.178.11/Public/RASPBERRY-PI/RPI-BACKUP/192.168.178.26 //backup
sudo systemctl stop fhem
dd if=/dev/sda of=${BACKUP_PFAD}/${BACKUP_NAME}-$(date +%Y%m%d-%H%M%S).img bs=1MB
sudo systemctl start fhem
# Alte Sicherungen die nach X neuen Sicherungen entfernen
pushd ${BACKUP_PFAD}; ls -tr ${BACKUP_PFAD}/${BACKUP_NAME}* | head -n -${BACKUP_ANZAHL} | xargs rm; popd
# UNMOUNTEN
sudo umount ${BACKUP_PFAD}
hat bis jetzt immer geklappt.
Und natürlich mache ich auch regelmässig ein FHEM Backup auf einem NAS
Kaspi ;-)
Wie testest du geklappt?
Wichtiger als Backup ist der Restore-Test...
Gruß, Joachim
Hmmmm.....
ich habe zwar das Image mal zurückgespielt (ohne Fehler) aber wirklich getestet habe ich es nicht.
Ich ging davon aus, dass es OK ist.
Was kann schief gehen???
Was hat dd für Probleme??
Kaspi ;-)
Wenn z.B. Dateien geöffnet sind oder grad geschrieben wird etc. kann es zu "Inkonsistenzen" kommen...
Zurückspielen geht immer, sofern die "neue"/"andere" SD genug Platz hat.
Sagt aber noch nichts drüber aus, ob das auch Erfolg hatte...
...wenn das Backup-Image "korrupt" ist (siehe oben), dann kann es sogar sein, dass gar nicht mehr gebootet wird (hatte ich schon)...
Daher nutze ich automatisiert fhem Backup inkl. speichern von x Backups aufs NAS...
Und manuell, also runterfahren und SD raus und dann dd bzw. eher tar (wegen Platzverbrauch und auch der Möglichkeit auf unterschiedliche Medien[größen] zurückspielen zu können), wenn ich größere Änderungen vor hab (z.B. irgendwas installiere [OS-Ebene] etc.)...
Aktuell schaue ich mir raspibackup an und "schäle" den "tar-Teil" heraus für evtl. automatisierte Komplett-Backups...
EDIT: wobei mit runterfahren, SD/SSD ab/raus, manuelles dd o.ä. Backup dauert auch nicht länger (also bzgl. fhem Stopp) als automatisiert. Klar: man muss es auch machen gegenüber es wird autom. gemacht. Aber dafür kann ich (relativ) sicher sein, dass es auch i.O. ist... Weil was nützt ein automatisiertes Backup was sich nicht restoren lässt (oder nach dem Restore nicht läuft)...
Wobei ein Neuaufsetzen mit fhem Backup auch (weit) unter einer Stunde dauert, beginnend mit "nackter" SD (bzw. SSD)...
EDIT: und fast die meiste Zeit dauert das Aufspielen des OS-Images ;) Und ein Umzug auf neues OS oder neue Plattform geht genauso... :)
Geht halt nur (so schnell), wenn man geübt ist/hat...
...und alle Schritte gut dokumentiert oder gescriptet hat... :)
Gruß, Joachim
Der Spezi von dem du das Skript hast, hat wohl wenig praktische Erfahrung mit Unix Systemen :)
dd ist nicht für eingehängte Dateisysteme geeignet, da wie schon erwähnt das System in einem inkonsistenten Zustand gebackupt wird -> dd läuft beispielsweise los und wenn es bei der Hälfte angekommen ist, wird in der ersten - schon gelesenen - Hälfte der Partition etwas verändert. dd bekommt das nicht mehr mit. Genauso können noch Änderungen in der noch nicht gelesenen Hälfte passieren. Die bekommt dd zwar noch, aber in Kombination mit der anderen Hälfte pass womöglich etwas im System dann nicht mehr zusammen.
Das mindeste im laufenden System ist die Partition auf read-only zu bringen. Besser unmounten oder im Falle einer SD halt die SD offline lesen.
Vor allem am automatisierten Löschen von alten Sicherungen würde ich mich in dem Zusammenhang stören, da zumindest derzeit davon auszugehen ist, dass keines der Backups überhaupt verwendungsfähig ist.
Ich würde in dem Fall zweigleisig fahren:
- die SD Karte offline mit dd sichern, um das Betriebssystem zu erhalten.
- FHEM selbst aus dem laufenden Dateisystem heraus - FHEM selbst aber gestoppt - mit Dateisicherungstools wie tar usw. sichern und wegkopieren.
Damit kannst du in jedem Fall einen Restore durchführen. Wenn du allerdings Änderungen am Betriebssystem durchführst, muss auch der erste Schritt ab und zu wiederholt werden.
Das Problem mit dem Rücksichern eines dd Images bei defekter SD Karte: am besten mehrere baugleiche vorhalten, sonst kann das ziemlich schiefgehen und muss man u.U. das dd Image auf eine größere Rücksichern. SD Karten mit bspw. 32GB von 3 verschiedenen Herstellern oder aus 3 verschiedenen Serien haben 3mal verschiedene Anzahl an Sektoren. Leider.
Hmmm.
also alles stoppen, runterfahren und die SD extern kopieren ist das beste?
Eine Möglichkeit dies im Rpi mittels Script zu managen besteht nicht?
Wenn doch, wie müsste das Script aussehen?
Fragen über Fragen ::)
Kaspi :)
Zitat von: Kaspi am 20 August 2021, 10:30:45
also alles stoppen, runterfahren und die SD extern kopieren ist das beste?
Ja.
Weil (also System sauber runtergefahren vorausgesetzt) da eben nichts mehr läuft und das Dateisystem sauber ist...
Zitat von: Kaspi am 20 August 2021, 10:30:45
Eine Möglichkeit dies im Rpi mittels Script zu managen besteht nicht?
Wenn doch, wie müsste das Script aussehen?
Doch.
Hast du ja vor bzw. hast du ja ein Script.
Es gibt (wie erwähnt) auch Raspibackup, welches zumindest nicht dd nutzt, sondern tar oder rsync, da gibt es zumindest Fehlermeldungen, wenn Dateien eben nicht "konsistent" gesichert wurden (dann kann man ja entscheiden, ob es relevent ist / eine nicht aktuell erfasste Logdatei ist u.U. ja "verschmerzbar" eine wichtige Systemdatei u.U. nicht usw.)...
Aber auch bei dem Script werden (daher) möglichst alle Dienste (nicht nur fhem) beendet, daher: wo ist dann der Unterschied ("Nutzungs-technisch") zu einem Runterfahren und manuell sichern? Zeitlich spart man ("Nutzungs-technisch") nichts, weil ja die gewünschten Dienste eh nicht laufen (weder so noch so)...
Mit den genannten Risiken...
Einziger wichtiger Vorteil von autom. Scripts: man kann es nicht "vergessen"...
Daher fahre ich ja 2-Stufig: fhem Backup automatisiert inkl. Sicherung auf NAS (und Backup vom NAS) und eben ab und an manuell eine Komplettsicherung (aber eher selten, weil eben mein Restore-Mechanismus von "0 auf 100" eingespielt ist und nicht lange dauert [kaum länger als ein Komplettimage zurück zu sichern] mit dem Vorteil, dass ein Systemwechsel [OS/HW/Plattform] für mich keinen "Schrecken" hat, weil das keinen/kaum einen Unterschied zu einem "normalen" Restore ist / und einen Systemwechsel mache ich ja OS-bedingt eh immer mal wieder)...
Einen Fullbackup-Restore habe ich eher für Testsysteme um schnell zu einem bestimmten "Vor-Exerimetier-Stand" zu kommen und weil nat. meine Testsysteme so gut wie nicht dokumentiert sind -> Spielwiese :)
Dokumentiert wird hier dann "nur" der letzte gute gehende Versuch, bevor Dinge dann auf das Hauptsystem "wandern" um dann dort sauber dokumentiert (oder falls möglich) gescriptet werden...
Es gibt auch Installations-(Unterstützungs-)Scripte, mal im Netz suchen.
Ich glaube sogar Otto123 hat in seinem (Otto's Blog) was im "Angebot" ;)
Fragen wurden ja alle (mehr oder weniger) beantwortet.
Die Entscheidung (Risikobewertung vs. Aufwand vs. "ich vergesse das evtl. mal") liegt halt nun mal beim "Betreiber", also dir ;)
Gruß, Joachim