Hallo
Nach einigem Herumprobieren am PC habe ich nun meinen neuen Raspi als Produktivsystem installiert.
Bevor ich aber voll loslege beschäftigen mich am meisten die Themen
- Richtiges Installieren
- Richtiges Backup und vor allem richtiges Restore im Fall eines Problems.
Soweit ich es verstehe, kopiert Backup schlicht und einfach alle Dateien des Fhem Verzeichnisses. Heißt das, dass ich als Restore einfach auf die SD Karte wieder das Raspian Image drauf kopiere und dann noch das letzte Backup und alles läuft wieder? Oder passiert da bei den ganzen Repository Downloads gefolgt vom notwendigen Update so viel im Hintergrund, dass das zu einfach gedacht ist?
Wo steht, wie man Restore ganz richtig macht?
Ehrlich gesagt macht mir das Repository-Installationsverfahren auch in anderer Hinsicht Gedanken. Nennt mich jetzt bitte nicht gleich einen Ketzer aber was wäre wenn es in einigen Jahren den Fhem Server aus irgendeinem Grund nicht mehr geben würde. Das könnten finanzielle, technische, politische oder sonstige nicht vorhersehbare Gründe sein. Dann hätte ich gerne Offline eine lauffähige Installationsvariante mit allem was ich benötige inklusive aktuellem Fhem Stand und Frontend ohne der Notwendigkeit ein Update machen zu müssen. Also versteht mich nicht falsch, ich finde Fhem super, wünsche ihm ein langes "Leben" und danke allen Entwicklern. Aber wenn ich in Infrastruktur investiere und viel mehr Zeit zum Aufbau einsetze muss ich auch an die Zukunft mit allen Eventualitäten denken.
Also steinigt mich bitte nicht aufgrund meiner kritischen Frage.
Danke im voraus für konstruktive Antworten.
Ich denke zum Thema Backup / restore gibt es vermutlich genügend Informationen hier im Forum, deshalb lasse ich diese Frage mal zur Übung offen.
Zur Installation:
- Wenn Du mal im fhemwiki schaust wirst Du feststellen, dass FHEM auch auf anderen Plattformen (z.B.) Windows läuft.
- In der Installation für Windows ist erkennbar, dass FHEM eigentlich "nur" ein Perlskript und eine Verzeichnisstruktur ist, die sich manuell aus dem tar file installieren lässt. -> Voila, das geht so auch so ähnlich auf dem Raspberry (m.a.W. das debian package ist ein Komfortgewinn), damit ist dein Problem gelöst, denn es gibt eine offline Variante
- Warum sich diese Variante vom debian package, dass man auch offline speichern kann unterscheiden soll ist mir unklar
- Wie willst Du diese Frage denn für perl, Raspberries, Arduinos, AVR microcontroller, etc beantwortet bekommen
Ich verstehe Deine Bedenken also nicht und kann auch die Argumentation nicht nachvollziehen. Es gibt hier sehr viele die sehr viel Zeit in ihre Installation von FHEM hereingesteckt haben, die haben bestimmt alle diesen Punkt übersehen?
Achso und es gibt den fhem e.V.
OK, ich hatte schon befürchtet, dass die Frage trotz vorsichtiger Formulierungen kritisch ankommen könnte.
Ich habe halt für wirklich wichtige Dinge am liebsten eine Installations-CD in der Hand ohne Abhängikeiten vom Internet. Aber das ist hier wohl nicht so einfach möglich.
Nichts für ungut und bitte mich nicht gleich blacklisten wegen dieser Frage.
Installations-CD :o
Das /opt-Verzeichnis kannst du automatisiert regelmäßig sichern. Dazu gibt es im Wiki Anleitungen. Ich sichere dazu regelmäßig die SD-Karte und schreibe diese ggfls. als Image zurück.
kopiere dir /opt/fhem auf eine CD :P
Dann solltest du soweit alle Dateien haben, die du benötigst.
Oder du speicherst dir das .deb-Paket. Das kannst du ebenfalls bei Bedarf installieren (ist aber nicht immer auf dem neuesten Stand).
Grüße
Stephan
Die Frage ist ok und auch nicht doof :-)
Ich habe keine große Lust, meine Systeme im Falle eines Defekts der SD-Karte "from scratch" neu aufzusetzen. Gerade weil ich bei den verschiedenen FHEM Instanzen noch Sonderfälle habe, die aufgrund der Vielzahl von benötigten Perl Libraries nur unter erheblichen Zeitaufwand neu aufzusetzen sind (z.B. FHEM für Gäste-WC mit mpd/mpc als WiFi-Radio, GPIO-PIR-Bewegungsmelder, dazu die Überwachung der Techem Sachen). Oder die Integration der Jawbone Fitness Armbändern :), da kämen schon einige Viertelstunden zusammen.
Für meinen Fall habe ich mir angewöhnt, die SD-Karten zu sichern und zurückzuspielen. Danach ein update/upgrade und ggfls. die letzte Sicherung von /opt/fhem einspielen.
Und alle wichtigen Änderungen/Erweiterungen der Systeme zu dokumentieren. Hat mir zumindest bisher ungemein geholfen.
Und alle wichtigen Änderungen/Erweiterungen der Systeme zu dokumentieren.
Das dürfte das Wichtigste Backup sein!
Auch ein Dump der SD ist, gerade für Anfänger, eine super Möglichkeit des Backups! Bei einem HW Wechsel könnte es aber zu Problemen führen ....
Leider sollte aber ein Backup automatisch sein, da man es sonst vergisst. Automatisch die "/opt/fhem" wegzusichern ist eine optimale Möglichkeit.
@Brice:
Du brauchst kein FHEM Backup, sondern ein Systembackup .. bei der menge von zusätzliche "Produkten" ;o)
Nur bevor ich noch mehr über backup schreibe .... suche mal im Forum. Haben hierüber schon in mehr als einem Thread diskutiert!
Ergänzung:
FHEM bassiert auf perl. Das es kurzfristig perl mit seinen Paketen nicht mehr geben wird, glaube ich nicht. Es ist möglich, das z.B. das "dieses Internet" nicht mehr existiert, aber dann haben wir andere Probleme als die Funktionsfähigkeit von FHEM
Zitat von: Ajuba am 20 Dezember 2016, 12:16:21
OK, ich hatte schon befürchtet, dass die Frage trotz vorsichtiger Formulierungen kritisch ankommen könnte.
Ich habe halt für wirklich wichtige Dinge am liebsten eine Installations-CD in der Hand ohne Abhängikeiten vom Internet. Aber das ist hier wohl nicht so einfach möglich.
Nichts für ungut und bitte mich nicht gleich blacklisten wegen dieser Frage.
Nein, ich denke nicht an kritisch oder blacklisten aber ich finde die Assoziation einer "Installations-CD" mit einem im Netz geplegten Open-Source-produkt nicht klar. Trotzdem habe ich Dir beschieben, wie Du zu einer Offline-Installation kommen kannst und das war doch die ursprüngliche Intention
Backups halte ich für extrem viel wichtiger, sind aber auch nach meiner Sicht sehr gut dokumentiert für FHEM (und auch für das darunterliegende System). Die eingebaute Backupfunktion in FHEM halte ich für sehr simpel (und das meine ich im positiven Sinne) - Sie ist weitgehend vollständig, einfach zu automazisiern und mit wenigen Werkzeugen auch wiederherzustellen. Das ist aus meiner Sicht extreme Sicherheit - und die Dokumentation der Installationsänderungen, Erweiterung etc gehört am besten ins Backup
Danke mal für die vielen Antworten.
Ich werde jetzt mal mehrere Varianten durchspielen, damit ich sicher sein kann dass es funktioniert wenn ich es brauche.
Übrigens wirft die Forensuche für "backup restore" genau 127 Ergebnisse aus mit Problemen, die mich eher verunsichert hatten als beruhigt. Daher kam ja meine Frage, weil offensichtlich das Zurückspielen öfters Probleme machte.
Also ich verstehe das jetzt so.
Zum Sichern meines Fhem Projekts inklusive Web-Frontend nehme ich den "Backup" Befehl
Das Restore kann ich machen indem ich "/opt/fhem"vom Raspi lösche und das entpackte Backup wieder drauf kopiere.
Es wird nämlich so oft das Wort Restore verwendet, ohne es zu erklären. Ich komme halt aus der Windows Welt und bin mir noch nicht ganz sicher wie ich das bei einem headless Raspi anpacke. Aber wenn dieses einfache Zurückkopieren mit Restore gemeint ist werde ich es schon irgendwie schaffen.
Bezüglich Image sichern bin ich im Forum auf "Win32DiskImager" bzw. "dd" gestoßen.
"Win32DiskImager" scheint klar zu sein, da ich die Raspi Installation damit gemacht habe.
"dd" habe ich bis jetzt noch nicht wirklich durchschaut.
Da scheint es teilweise Probleme mit der SD Karten/Image -größe geben aber wenn das Zurückspielen problemlos funktioniert sollte ja alles sofort wieder voll einsatzfähig sein (System inklusive Fhem Projekt).
Also dann, sobald ich Zeit habe probier ich mal rum.
Das Sichern kannst du automatisieren. Um es dir zu erleichtern
define SYS_Backup dummy
attr SYS_Backup webCmd Ausführen
define SYS_BackupRun notify SYS_Backup:* backup
define BackupRun at *04:00:00 set SYS_Backup Ausführen
"Hübsch machen" kannst du selbst :P Backupverzeichnis in global setzen. Hilfreich ist auch immer ein
attr global backup_before_update 1
Für ein Restore ist kein Löschen von /opt/fhem notwendig, einfach das tar.gz drüberbügeln (oder korrigiert mich jemand?)
Dump der SD-Karte per dd kannst du automatisieren, wenn der Pi nicht gerade per WLan im Netz hängt. Kann je nach Größer der Karte länger dauern. Ich mache es nicht, sondern entnehme die Karte nach shutdown des RPi und dann per "Win32DiskImager" ein "read". Auf ein paar Minuten ohne FHEM kann ich verzichten.
Obwohl... wäre auch mal eine Übung.
Viel Spaß weiterhin.
Nur um mal das Programm (naja, wenn mans genau nimmt eher script) rsnapshot in den raum geworfen zu haben.
leistet bei mir seit Jahren treue Dienste und verbraucht in Summe weniger Speicher als Images...
Grüße
Stephan
alternativ dirvish oder andere auf rsync basierende Derivate .. hat noch den Vorteil, das man verschiedene "Versioenn" hat. Und die Platzersparnis kommt durch das Incrementelle Sichern, d.h. nur die Änderungen, trotzdem ist jedes wie ein "FULL" zu betrachten.
Ist aber ein FHEM und kein Systembackup!
(Ich sichere aber bei mir /etc/ fhem und Datenverzeichnisse auf extern angeschaltete/gemountete Festplatten als "die Backup Lösung". Bei mir ist aber auch ein Linux-System schneller aufgesetzt als ein Full-Restore eingespielt ...)
Also ich habe meine Synology in FHEM gemounted und schiebe dort auch ältere Logs per FHEM weg, Parallel dazu ein Verzeichnis, wo ich per RaspiBackup.sh (google) automatisch eine wöchentliche dd und tar Sicherung mache. Von dd behalte ich drei Versionen, von tar mehr.
Bei Problemen - schon häufiger passiert - kann ich das dd-Backup auf eine SD schmeissen und mit den Stand vom letzten Sonntag weiter machen. Wenn die Probleme es zulassen, kann man auch die logs übernehmen oder aus der tar-Sicherung nur die fhem.cfg ziehen. Hängt halt davon ab, was schiefgelaufen ist.
Letztens bin ich von raspi2 auf 3 umgezogen, und meine Linux-Basis war korrupt (beim Update honterher unbrauchbar). Da konnte ich alles neu installieren, aber fhem und logs hinterher übernehmen und auch crontab etc auf der Syno checken und die notwenidigen Zeilen auf dem Raspi nachziehen.
Kann ich nur empfehlen.
Lg, Ulf
*persönlicheMeinungEin*
Anfangs die komplette SD zyklisch sichern macht vermutlich Sinn.
Später kommen nur noch selten Linux(Perl)-Pakete dazu und FHEM wird vermutlich auch nicht so oft per update auf den neuesten Stand gebracht.
Mein Cubie bootet aus dem NAND und der Rest liegt auf einer SSD.
Wenn ich ein
apt-get update/upgrade am Cubie einwerfe landet alles auf der SSD (hoffe ich zumindest 8) ).
Bevor ich ein
updatein FHEM einwerfe schaue ich erstmal im Forum ob sich jemand über ein fehlerhaftes Update beschwert, wenn nicht
dann mache ich in FHEM ein save und sicher mir danach /media/hdd/fhem auf meine Netzwerkplatte und lass FHEM ein update durchführen.
Wobei ich FHEM-Updates erst auf einem meiner "Satelliten-RasPi" einspiele bevor mein Produktivsystem dran kommt.
Produktiv ist zu Zeit:
Zitatfhem.pl 12729 2016-12-09 12:48:50Z rudolfkoenig
also recht "frisch".
Im Heizraum ist ein
Zitat# $Id: fhem.pl 6080 2014-06-07 16:12:09Z rudolfkoenig $
installiert und läuft und läuft und ...
Ok, da hängen nur 5 I2C-LM75-Sensoren dran und er hat sonst nichts zu tun (war ein Spassprojekt
damals)
Also wozu immer alles updaten wenn der vorhanden Stand zufriedenstellend läuft?
*persönlicheMeinungAus*
Danke für die vielen Rückmeldungen
Ich habe mich nun nach Testläufen für folgendes Prozedere entschieden
- Immer Mitschreiben was ich installiere und ändere
- Fhem regelmäßig und vor allem vor einem Update mit "Backup" sichern (wahrscheinlich auch automatisiert)
- SD Karten-Image mit Win32DiskImager sichern. Damit sollte auch mein Wunsch erfüllt, dass ich ohne Abhängigkeit vom Internet wieder ein laufendes System bekomme
Das Zurückspielen des Fhem Backups mache ich mit puTTY
- Fhem stoppen mit "sudo /etc/init.d/fhem stop"
- Restore mit ,,sudo tar -xvzf /opt/fhem/backup/FHEM-201xxxxx_xxxxxx.tar.gz -C /opt/fhem/"
- Fhem starten mit "sudo /etc/init.d/fhem start"
Zum SD Karten-Image mit Win32DiskImager sichern habe ich noch eine Frage bzw. eine Idee zur Optimierung:Bei der Erstinstallation habe ich - wie im Wiki empfohlen - meine SD Karte mit "sudo raspi-config" auf die vollen 32 GB aufgeblasen.
Beim Sichern werde ich jetzt natürlich auch (nach 40 Minuten ::) ) mit einem 32 GB Image beglückt - welch Freude.Ich frage mich nun, ob es nicht sinnvoller wäre eine z.B. 4 GB Partition für Raspian+Fhem zu machen und die restlichen 28 GB als eine zweite Partition zu definieren wo dann Logfiles und Backups hinwandern. Die 4GB Partition ergibt ein leichtes Image und die Logfiles und Backups sollten sowieso regelmäßig aufs NAS wandern.
- Warum wird im WIKI und in Blogs die volle SD Karten Nutzung favorisiert und nicht die Aufteilung in "Betriebssystem" und "Nutzdaten"?
- Falls die Aufteilung machbar und sinnvoll ist, wie macht man das richtig?
- Wie gibt man dann dem Backup directory und FileLog den richtigen Pfad auf der anderen Partition mit? (Sorry bin noch sehr Linux unerfahren)
Zitat von: Ajuba am 21 Dezember 2016, 23:44:23
- Warum wird im WIKI und in Blogs die volle SD Karten Nutzung favorisiert und nicht die Aufteilung in "Betriebssystem" und "Nutzdaten"?
Deshalb:
Zitat von: Ajuba am 21 Dezember 2016, 23:44:23
- Wie macht man das richtig?
- (Sorry bin noch sehr Linux unerfahren)
Über den Sinn kann man streiten, ich persönlich spare mir die Arbeit. Aber ich habe ja auch ein anderes Backup und Restore-Konzept.
Ein paar Tipps:
https://wiki.ubuntuusers.de/Partitionierung/
Das ISO-Image kann man vermutlich ganz gut komprimieren, wenn noch viel Speicherplatz auf der SD-Karte frei ist -> tar.gz oder zip.
Grüße
Stephan
Hi,
zum SD Card Image.
Ich habe mir dazu mal Gedanken gemacht. -> http://heinz-otto.blogspot.de/2015/03/angepasstes-raspberrypi-image.html
Die aktuelle Raspbian Version erweitert allerdings das SD Card Image automatisch.
Dafür ist der Eintrag init=/usr/lib/raspi-config/init_resize.sh in der /boot/cmdline.txt verantwortlich. Wenn man den löscht wird das Volume nicht automatisch erweitert.
Gruß Otto
Hi, hab gerade deinen Blog-Eintrag gelesen.
Gute Arbeit! Gefällt mir.
Eine Anmerkung dazu:
ZitatEs geht damit los, dass es meines Wissen kein Tool gibt mit dem sich von einer SD Karte unter Windows ein Image der definierten Partitionen/Laufwerke machen lässt.
Unter Windows kann ich dir tatsächlich nicht helfen/Kenne ich mich nicht aus.
Unter Linux allerdings gar kein Problem.
Bordwerkzeug:
dd if=/dev/sda of=./FHEMbackup.isoQuelle:
https://wiki.ubuntuusers.de/dd/
Darin steht auch schön, wie man das Image komprimieren kann, um Speicherplatz zu sparen.
Sorry, auch kein Windows-Tool. Ich hab halt nur Linux;)
Grüße
Stephan
Hinweis zum Restore:
Du machst es als root, d.h. es könnte sein, das die Dateien dann nicht fhem, sondern root gehören ... dann darf fhem nicht schreiben (und das mag fhem nicht).
Also hinterher am besten alles korrigiren:
sudo chown -R fhem: /opt/fhem
Danke Wernieman für den wesentlichen Hinweis. Mein Fhem war schon in dumpfes Brüten verfallen und war ganz langsam
ZitatAlso hinterher am besten alles korrigiren:
Code: sudo chown -R fhem: /opt/fhem
Aber nun habe ich das Problem, dass ich mit Samba und Filezilla nicht mehr aufs Raspi-Fhem Verzeichnis zugreifen kann.Wenn ich Benutzer pi setzte geht der Zugriff, aber dann geht natürlich Fhem wieder nicht.Mein Versuch eine Gruppe aus Fhem und Pi zu bilden und der den Zugriff zu gewähren war erfolglos. Wahrscheinlich habe ich aufgrund meiner Linux Ahnungslosigkeit was falsch gemacht.Wie macht man das richtig?
Tipp: Benutze WinSCP, das hat einige Vorteile ggü. Samba und FTP.
Ob/Was falsch ist, kann man ohne weiterführende Informationen nicht beurteilen.
- als welcher User läuft smb?
- welche Dateirechte haben die Dateien unter /opt/fhem jetzt tatsächlich?
- welche Dateirechte hat das Verzeichnis /opt/fhem?
- Was bedeutet *nicht zugreifen*:
-- Kannst du Dateien anzeigen?
-- Kannst du durch Verzeichnisse navigieren?
-- Kannst du Dateien sehen?
-- Kannst du Dateien lesen/öffnen?
-- Kannst du Dateien schreiben? (vermutlich zumindest das nicht)
Grüße
Stephan
Vorallem .. mit welchem User gehst Du per smb (samba) in das Verzeichnis?
Würde Dir aber auch nicht winscp empfehlen, sondern das direkte Bearbeiten auf der Konfig mit FHEM. Warum solltest Du per winscp/samba o.Ä. denn ins FHEM-Verzeichnis zugreifen können?
Sorry für die unpräzisen Angaben. Mein dreijähriger hängt an mir und ganz genau kann ich es erst heute abend beantworten wenn er im Bett ist.
Vorerst gleich:
Es geht um die Schreibrechte.
Ich will auch nicht die Fhem Config bearbeiten sondern die HTML Seiten von Tablet UI. Am einfachsten wäre das wenn ich sie mit Samba direkt öffnen und Speichern kann. Zur Not geht auch Offline arbeiten und mittels FTP rüber schieben.
Wie gesagt, was ich aktuell an Usern und Rechten eingetragen habe kann ich erst am Abend in Ruhe auslesen. Soweit vorab
Wenn ich mit chown Fhem eintrage ist Fhem glücklich aber ich kann per FTP und Samba nicht schreiben. Das war auch logisch, da ich mich bei beiden als pi angemeldet hatte.
Wenn ich das Verbinden als Fhem probiere scheitere ich. Bei Samba hätte ich versucht auch für Fhem das Passwort zu setzen aber beim Anmelden als Fhem streikt dann mein Windows und behauptet ich hätte noch eine Verbindung (obwohl ich das Laufwerk definitiv getrennt hatte).
Und für FTP weiß ich nicht wie ich für den User Fhem ein Passwort setzen kann, der mir ein FTP Login erlaubt (Dass es mit pi nicht geht war mir auch klar).
Dann hab ich mir noch Befehl zusammen gesucht um ein Usergruppe (hab sie Fhem group genannt) zu bilden. Dort hab ich dann pi und Fhem hinzugefügt.
Aber eingeloggt als Pi hat FTP schreiben trotzdem nicht funktioniert.
Einigermaßen klar?
Genaue Details kann ich am Abend raus suchen.
Gesendet von meinem SM-G920F mit Tapatalk
Es gibt unter Unix 3 Rechte und 3 rechte-Gruppen
1. Persönliche Rechte
2. Gruppenrechte
3. Alle anderen
1. Leserechte
2. Schreibrechte
3. "Ausführungsrechte"
Bei 3. den Ausführungsrechten muß man bei Direktories aufpassen. Dort ist es nämlich ein "ins Direktory reintauchen-Recht".
Wenn Du jetzt z.B. per "ls -lhad" dir ein Verzeichnis anguckst, sieht Du z.B.
werner@rita:~$ ls -lhad test2
drwxrwxr-x 2 werner werner 4,0K Dez 27 18:00 test2
w
Der User und die Gruppe Werner darf dort lesen und schreiben.
drwxr-xr-x 10 fhem fhem 4,0K Mai 28 2016 /opt/fhem
Im Standard ist bei fhem der Ordner /opt/fhem für den User fhem und die Gruppe dialout gesetzt (Ich bin nicht Standard). Da ich davon ausgehe, das Du dieses nicht geändert hast, darf dann Deine neue Gruppe ... dort gar nichts.
Ansonsten .. siehe bitte im Netz für Unix-Berechtigungen nach
Edit:
Übrigens ist es unter Windows noch etwas komplizierter ... da kommen dann ACLs ins Spiel. Nur Versteckt Windows dieses unter einem "Grafische Konfigurationswerkzeug". So etwas geht zwar auch unter Unix ... Du willst es abr bestimmt nicht...
Edit2:
Bezüglich Windows:
Auch wenn DU ein Laufwerk trennst, speichert Windows dazu Daten im Hintergrund. Bei der Fehlersuche ist deshalb für die Verifizierung ein reboot des Clients (nicht RasPi!) "empfehlenswert"
Ich glaub, ich habs gelöst.
1.Samba
Du hattest recht - ein Neustart des Notebooks hat mir das Verbinden des SampaPi Laufwerks für Benutzer fhem ermöglicht und der hat ja die richtigen Rechte. Ich kann jetzt die Tablet UI htmls direkt im Atom Editor bearbeiten und wieder speichern. Wenn nichts dagegen spricht ist das für mich die optimale Variante und ich könnte eigentlich auf FTP verzichten
2. Nur der Vollständigkeit halber doch noch zu FTP
Die Rechte für /opt/fhem sehen folgendermaßen aus
drwxr-xr-x 11 fhem dialout 4.0K Dec 21 22:27 /opt/fhem
Also wie du gesagt hast sind "fhem" und die Gruppe "dialout" eingetragen und "dialout" enthält den user "pi"
dialout:x:20:piIch verstehe das nun so, dass "fhem" die vollen Rechte hätte (rwx) nicht aber "pi" in der Gruppe "dialout" (r-x) mit dem ich mich aber bei FTP einlogge.Wenn ich "pi" die Rechte gebe kann ich dann per FTP Dateien schreiben und Fhem beschwert sich berechtigtermaßen darüber, dass es nicht schreiben kann "WriteStatefile: Cannot open ./log/fhem.save: Permission denied"komischerweise ändert sich aber bei ls -lhad trotzdem nichts
pi@raspberrypi:~ $ sudo chown -R pi /opt/fhem
pi@raspberrypi:~ $ ls -lhad /opt/fhem
drwxr-xr-x 11 pi dialout 4.0K Dec 21 22:27 /opt/fhem
oder wie finde ich das Passwort von "fhem" heraus damit ich mich via FTP als "fhem" einlogge?Oder wie löst man das richtig?
Zitat von: Ajuba am 28 Dezember 2016, 00:05:46
drwxr-xr-x 11 fhem dialout 4.0K Dec 21 22:27 /opt/fhem
komischerweise ändert sich aber bei ls -lhad trotzdem nichts
drwxr-xr-x 11 pi dialout 4.0K Dec 21 22:27 /opt/fhem
Hi, natürlich ändert sich was. Wie du siehst, gehören die Dateien nicht mehr "fhem", sondern jetzt "pi".
fhem ist damit ausgesperrt (darf nicht mehr schreiben) und meckert natürlich.
Mach das also rückgängig
chown -R fhem:dialout /opt/fhem/Jetzt darf fhem wieder schreiben, und jetzt gibst du der Gruppe dialout schreibrechte:
chmod g+w /opt/fhem/dann versuchst dus nochmal, das ls sollte dann so aussehen:
drwxrwxr-x 11 fhem dialout 4.0K Dec 21 22:27 /opt/fhemGrüße
Stephan
Wobei ich Dir nicht empfehlen würde, mit FTP anzufangen! Stichwort: Security
Hallo,
Gibt es denn eine möglichkeit per raspberry consolen befehl z.b dd die komplette partition zu komprimieren dann sichern und diese direkt auf eine zb synology zu schieben. Dann hätte man doch alles was man braucht am besten als *.img
Diese Diskussion hatten wir schon mehr als ein mal im Forum:
Gängige (Lehrbuch) Meinung:
Ein Image eines Laufendes System per dd kann mit großer Wahrscheinlichkeit fehlschlagen, da geöffnete Dateien / geänderte Fileeinträge nicht mit gesichert werden können (liegen im Speicher)
Wenn DU dagegen mit einem 2. System startest (oder eben die SDCarte in einen anderen rechner "packst", ist es kein Problem
Zitat von: mpl8580 am 28 Dezember 2016, 12:11:29
Hallo,
Gibt es denn eine möglichkeit per raspberry consolen befehl z.b dd die komplette partition zu komprimieren dann sichern und diese direkt auf eine zb synology zu schieben. Dann hätte man doch alles was man braucht am besten als *.img
Hi,
wie Werner schon schreibt: das wäre ein "dummes" Backup. Das einzige Backup was man regelmäßig braucht ist die Kopie von /opt/fhem/ dazu gibt es ein backup Kommando und das tar File kann man dann wegsichern. Damit hat man schon mal drei Stufen gesichert: der Restore Pfad von FHEM, die tar Datei vom Backup lokal und die tar Datei remote.
Was man dazu braucht ist ein Betriebssystem Image, das macht man entweder "einmalig" offline oder man nimmt es neu vom download und man hebt sich das download produktive image (bestimmte Version) auf.
Dazu braucht man noch die fehlenden Pakete vom System, da ist es gut wenn man sich eine Liste (script) gemacht hat.
Alles in allem ist dieses Restore aus drei Komponenten schneller oder zumindest nicht langsamer als ein komplettes Image. Und flexibler ist es allemal.
Gruß Otto
Ups. Das ist peinlich, dass ich beim Analysieren der Rechte den Unterschied fhem->pi nicht gesehen hatte. Hab nur auf die rwx geschaut und vor lauter Bäumen den Wald nicht mehr gesehen. :-[
Weiters , FTP wegen der Sicherheit bleiben zu lassen ist auch kein Problem solange ich über Samba die FTUI HTML fertig entwickeln kann.
Kann/soll man FTP am Raspberry komplett abdrehen? Hab dazu im Internet noch nichts gefunden sondern immer nur über die Rechte Vergabe.
Samba hat dann aber wohl auch ein Gefahrenpotential. Oder sehe ich das falsch?
Und dann müsste man wohl SSH auch abdrehen, oder?
Aber solange ich mein Fhem entwickle brauche ich doch irgendwas!? Wenn ich ganz paranoid bin müsste ich am Raspi Fernseher und Tastatur anhängen und mir die geänderten htmls immer so vom Notebook holen.
Meine Frau würde sich freuen wenn für die nächsten Wochen der Fernseher abends immer blockiert wäre. ::)
Also ich plane nun das Projekt mittels Samba und ziemlich langem, sicheren Passwort fertig stellen.
Kann mir noch jemand sagen wie ich ftp komplett abdrehe?
Gesendet von meinem SM-G920F mit Tapatalk
Hi,
also bei mir ist per default nur ssh aktiv und das nicht mal mehr im neuesten Raspbian Image.
FTP müsstest Du also aktiviert haben.
Samba und ssh sind ne andere Nummer als ftp -> authorisierung ist anders!
Und solange Dein Pi nicht per Portfreigabe im Internet steht ist erstmal die direkte Gefahr nicht so groß.
Gruß Otto
also .. wenn ssh Unischer wäre, würden definitiv praktisch alle Unix Server und damit praktsiche alle Internetserver im Weltweitem Netz unsicher sein ... hoffen wir mal, das dieses nicht der Fall ist ;o)
Was natürlich nicht heißt, das man bei der Konfiguration nicht etwas aufpassen muß. z.B. kein root login etc.
samba dagegen ... es ist eher ein "Leistungsproblem". Ich würde an Deiner Stelle samba nach dem Entwickeln abschalten.
Wegen ftp ... weist Du, welchem FTP-Deamon Du installiert hast? Wenn nein .. gib uns doch mal ein:
ls -lha | grep -i ftp
Mein debian (ok, ist kein Raspi) ist von aussen nur per SSH (auf anderem Port und Authentifizierung per Zertifikat) erreichbar, darüber klappt dann auch SFTP. Wenn das öffentlich nicht erreichbar ist (und in der Familie keine kleinen Hacker unterwegs sind ;) ) würde ich Samba und FTP nicht so eng sehen.
Kurz zum Hintergrund:
- FTP überträgt Nutzer und Passwort unverschlüsselt
- SMB überträgt je nach Version Nutzer und Passwort unverschlüsselt oder verschlüsselt
- SSH verschlüsselt alles
Ich hab meine ganze dokumentierte Raspi Installationshistorie durchgesehen und wäre mir nicht bewusst, FTP installiert oder aktiviert zu haben.
Aber ich habe bei Filezilla gesehen, dass ich mich gar nicht über FTP (Port 21) sondern SFTP (Port 22) verbunden habe weil die Verbindung über Port 21 verweigert wurde.
Habe nun nachgelesen, dass SFTP für SSH FTP steht. (Wusste gar nicht, dass es das auch gibt)
Heißt das nun, dass es über SSH läuft und somit genau so sicher wie SSH ist?
Übrigens
ls -lha | grep -i ftp
ergibt rein gar nichts. Keine Ausgabe. Es kommt einfach wieder die Eingabeaufforderung.
Wenn Du kein FTP-Server laufen hast, dann ist diese Ausgabe so O.K.
sftp geht über ssh. ist analog wie scp .. bzw. für Windowsuser winscp.
Aber jetzt verlassen wir den "Thread Titel" Backup und Restore
1. Nachdem nun geklärt ist, dass es kein FTP sondern sicheres SFTP ist, habe ich entsprechend abc2006
chmod g+w /opt/fhem/
bzw. weil die Rechte nicht reichten
sudo chmod g+w /opt/fhem/
ausgeführt um Schreibrechte für dialout (pi) zu bekommen.
Das Ergebnis ist, dass der Raspi so langsam reagierte, dass ich wegen timeout mit Filezilla nicht verbinden konnte und auch mit putty komm ich nicht mehr ran. Der erste Einsatzfall für mein erstelltes Image - gut, dass ich es gemacht habe.
Was kann da falsch gelaufen sein?
2. Ich habe mich für die von Otto favorisierte Sicherungs-Variante mit SD-Karte raus / Image schreiben entschieden
Das dauert aber bei meiner 32GB SD-Karte ca. 45 Minuten und verbraucht nebenbei sinnlos viel Platz
Darum möchte ich nochmal fragen, warum ich das nicht in 2 Partitions (System / Daten) aufteilen soll:
Eine Partition mit ca. 4GB für Linux inkl. Fhem
Eine zweite Partition mit dem restlichen Platz (ca. 28 GB) wohin ich dann auch gleich die Fhem-Logfiles und Fhem-Backups speichere .
Idealerweise sollen die Fhem Logfiles und Backups automatisch regelmäßig aufs NAS kopiert werden.
Wenn es nur ein Fhem Problem gibt kopiere ich das Backup von der Daten-Partition zurück. Wenn es richtig gekracht hat, spiele ich in wenigen Minuten das Letzte Image zurück. Idealerweise überschreibe ich nur die System Partition (Keine Ahnung, ob das mit Win32Diskmanager geht). Falls nicht, überschreibe ich halt alles und muss mir nachher dir Daten Partition wieder erstellen - auch nicht schlimm.
So kenne ich es von der DOS/Windows Welt und bin bisher gut damit gefahren.
Ist das denkbar, unmöglich, zu kompliziert?
Das Expand bei der Erstinstallation verhindern funktioniert wie Otto weiter oben beschrieben hat.
Aber nun stehe ich an: welches Partition Tool, wie vergrößert man die System Partition, wie erstellt man die Daten Partition, wie definiert man in Fhem die Speicherorte auf der anderen Partition?
Was meint ihr dazu?
Moin,
ich mache das etwas anders. Ich habe einmal ein Image der SD-Karte mittels dd erzeugt und habe die auf einen NFS share geladen. Wenn ich ein Backup machen möchte, dann mounte ich die root-Partition aus dem Image über das loop-Device und fahre einen rsync zwischen dem aktuellen System und dem gemounteten Image. Anschließend unmounte ich das Image wieder und gut ist. Das dauert nur ein paar Minuten...
Sollte meine SD-Karte mal den Geist aufgeben, dann nehme ich mir das Image und schreibe es zurück auf eine entsprechend große SD-Karte...
Das ganze geht über ein kleines Skript, welches bei mir so aussieht...
root@pi2:~/Software/skripte# cat piBackup.sh
#!/bin/bash
. /etc/profile
DATE=$(date +%Y.%m.%d)
# pi2 imaga mounten
losetup -o 939524096 /dev/loop0 /var/lib/owncloud/pi2.img
# fsck auf imaga
fsck -fvy /dev/loop0
# mounten nach /mnt
mount -t ext4 /dev/loop0 /mnt
# rsync ausfuehren
rsync -av --progress --one-file-system --delete --exclude -/var/swap --exclude -/dev --exclude -/proc --exclude -/sys --exclude -/tmp / /mnt
# mysql-Dateabanken komplett dumpen
mysqldump --lock-tables -uroot -P --all-databases --add-drop-database --allow-keywords --complete-insert --quote-names > /mnt/root/backup/mysql_$DATE.sql
mysqldump --lock-tables -uroot -P --databases configDB fhemPowermeter fhemSensors fhemThermostate fhemWeather netatmo --add-drop-database --allow-keywords --complete-insert --quote-names > /mnt/root/backup/fhem_$DATE.sql
# image unmounten und deaktivieren
umount /mnt
losetup -d /dev/loop0
...nebenbei werden auch noch zur Sicherheit die Tabellen der MySQL-DB exportiert. Der einzige Knackpunkt ist es herauszufinden, wo im Image die root-Partition liegt, das hängt von der Größe ab und muss einmal ermittelt werden. Dazu gibt es aber im Web einige Tuts, die das sehr schön erklären.
Gruß,
Stephan
Hi,
Zitatdann nehme ich mir das Image und schreibe es zurück auf eine entsprechend große SD-Karte...
Dafür ist es eine gute Idee das Volume etwas kleiner als die SD zu machen. 32 GB SD sind nicht immer gleich 32 GB SD
Sonst muss man jedesmal die nächste Größe kaufen ;)
Gruß Otto
Ja, das gilt eigentlich ja immer, wenn man mit Partitionen arbeitet... ;) Dumm nur, wenn man dann irgendwann das Setup die Partition selbständig auf den restlichen Platz erweitert... Ich meine bei meinem Setup war das so, dass nach dem initialen Boot und der Installation, beim nächsten Boot die root Partition automatisch erweitert wurde - so ganz kann ich mich aber nicht mehr dran erinnern.
...und zum Glück ist meine ja nur 15G... ;)
Zitat von: budy am 29 Dezember 2016, 12:36:12
Dumm nur, wenn man dann irgendwann das Setup die Partition selbständig auf den restlichen Platz erweitert... Ich meine bei meinem Setup war das so, dass nach dem initialen Boot und der Installation, beim nächsten Boot die root Partition automatisch erweitert wurde - so ganz kann ich mich aber nicht mehr dran erinnern.
Ist so!
Habe ich überprüft ->
ZitatDie aktuelle Raspbian Version erweitert allerdings das SD Card Image automatisch.
Dafür ist der Eintrag init=/usr/lib/raspi-config/init_resize.sh in der /boot/cmdline.txt verantwortlich. Wenn man den löscht wird das Volume nicht automatisch erweitert.
Gruß Otto
Eine Frage: warum nutzt ihr SD-Karten > 8GB?
Ich nutze für meine Installationen Karten von 2GB bis 8GB. Die letzte 4 GB-Karte hatte ich vor ca. 6 Wochen für einen Pi 2B gekauft. Ok, ist zwar nur Class 4, aber funktioniert auch. Logfiles werden auf alte USB-Sticks geschrieben (1GB oder 2GB) und am Ende des Monats auf die NAS-Platte verschoben.
Images von z.B. 4GB-SD-Karten können doch bei Bedarf auf z.B. 32GB-SD-Karten geschrieben werden, danach per raspi-config ein "Expand Filesystem" und alles ist paletti.
Hatte ich vor ca. 2 Wochen so gemacht. Oder übersehe ich etwas?
Stefan
edit: 2GB und nicht 1GB
Fassen wir mal zusammen:Offensichtlich haben nicht alle SD Karten die gleiche Größe und sind manchmal zu klein für früher erstellte Images. Da bleibt dann nur umsteigen auf die nächste Größe, egal ob man es braucht oder nicht. 4->8->16->32->64 Aber irgendwann ist dann Schluss.Das von Otto beschriebene Verhindern des automatischen Vergrößerns funktioniert. Hab ich gestern so gemacht. ZitatDie aktuelle Raspbian Version erweitert allerdings das SD Card Image automatisch. Dafür ist der Eintrag init=/usr/lib/raspi-config/init_resize.sh in der /boot/cmdline.txt verantwortlich. Wenn man den löscht wird das Volume nicht automatisch erweitert.
Um diesem Problem zu entgehen hat Otto mE nach ein gutes Verfahren beschrieben http://heinz-otto.blogspot.co.at/2015/03/angepasstes-raspberrypi-image.html?m=1]http://heinz-otto.blogspot.co.at/2015/03/angepasstes-raspberrypi-image.html?m=1 (http://[/color)[/color]Das Verfahren ist super um ein Schnellstart Image inklusive Fhem zu haben. Wenn es aber um laufende Sicherungs Images geht darf man meiner Meinung nach die GRÖßE NIE ERWEITERN . Weil sonst habe ich beim nächsten Versuch diesen Status als Image zu sichern das selbe Problem wieder.Warum ich eine 32GB Karte benutze? Weil ich als Neueinsteiger bei http://www.meintechblog.de/2016/05/fhem-server-auf-dem-raspberry-pi-in-weniger-als-einer-stunde-einrichten/ (http://www.meintechblog.de/2016/05/fhem-server-auf-dem-raspberry-pi-in-weniger-als-einer-stunde-einrichten/) gelesen habe, dass das so am Besten ist um genug Platz für Logfiles zu haben. Natürlich könnte ich eine kleinere kaufen und Logfiles auf USB Stick speichern.ABER ich frage aber noch einmal :Kann man am restlichen SD Karten Platz nicht eine weitere Partitionen nutzen für die Daten? Ich habe mit meinen Linux Null-Kenntnissen mal folgendes zusammengebracht.Mit "parted" habe ich die Raspian Partion auf ca. 4GB vergrößert und auf den restlichen 28GB noch eine Partition erzeugt.Entsprechend dieser Anleitung http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_Install.html (http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_Install.html) konnte ich sie dann noch formatieren und als Home mounten.Meine SD-Karte sieht nun so aus
pi@raspberrypi:/$ fdisk -l
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 137215 129024 63M c W95 FAT32 (LBA)
/dev/mmcblk0p2 137216 8000000 7862785 3.8G 83 Linux
/dev/mmcblk0p3 8388608 62332927 53944320 25.7G 83 Linux
pi@raspberrypi:/$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 29.7G 0 disk
├─mmcblk0p1 179:1 0 63M 0 part /boot
├─mmcblk0p2 179:2 0 3.8G 0 part /
└─mmcblk0p3 179:3 0 25.7G 0 part /home
Also wenn man die Gefahr mit der Größe des Images sieht, muss man sie lediglich nicht komplett sondern per Hand bis fast komplett erweitern.
Ich persönlich finde die laufende Image Sicherung nicht sinnvoll. Sie bringt mir keinerlei Vorteile.
Ich habe
- ein Image von dem Raspbian Stand meiner ursprünglichen Installation.
- das aktuelle Image Raspbian aus dem Internet.
- ein Script mit meiner Raspbian Grundinstallation.
- ein Script zur Installation von FHEM.
- ein aktuelles Backup.
Ich weiß wie Restore geht.
Getrennte Partitionen machen alles komplizierter und bringen rein technisch keinen Vorteil.
Aber das ist meine Meinung 8)
Gruß Otto
Zitat von: Otto123 am 29 Dezember 2016, 23:57:55
Ich persönlich finde die laufende Image Sicherung nicht sinnvoll. Sie bringt mir keinerlei Vorteile.
Ich habe
- ein Image von dem Raspbian Stand meiner ursprünglichen Installation.
- das aktuelle Image Raspbian aus dem Internet.
- ein Script mit meiner Raspbian Grundinstallation.
- ein Script zur Installation von FHEM.
- ein aktuelles Backup.
Ich weiß wie Restore geht.
Getrennte Partitionen machen alles komplizierter und bringen rein technisch keinen Vorteil.
Aber das ist meine Meinung 8)
100% Zustimmung von meiner Seite aus.
Allerdings kann ich tatsächlich keine Argumente dagegen anführen.
Das einzige, was mir durch den Kopf geht, ist die "Abnutzung" der SD-Karte. Früher gabs mal Probleme mit Flash-Speicher, weil die einzelnen Zellen nur endlich oft beschrieben werden können(ist immer noch so). Wenn du eine 32-GB karte hast, und 32-mal 1GB schreibst, kann der Controller das so verteilen, dass hinterher jede Zelle ein mal beschrieben wurde. Wenn du jetzt eine 1-GB karte hast, und 32-mal 1 GB schreibst, kommst du auf 32-mal schreiben pro Zelle.
Muss allerdings zugeben, dass a) ich nicht sicher bin, ob das unterhalb oder oberhalb der Partitionslogik durchgeführt wird, und b) ich nicht weiss, ob diese Problematik mittlerweile keine mehr ist (weil zb die Anzahl der Schreibzyklen so hoch ist, dass man die nicht mehr erreicht).
Ich habe nen Server mit 1 TB Festplatte auf 1 Partition, davon sind 10 GB belegt, und ich würde im Leben nicht auf die Idee kommen, die 1TB-Partition zu sichern, um ein Backup zu haben. Nur, um mal andere Größenordnungen zum Vergleich zu bringen.
Grüße
Stephan
PS: wobei ich die Lösung mit "Image mounten und rsync" persönlich auch SEHR interessant finde. Ist halt nur nicht inkrementell.
Das stimmt bei SDCarten leider definitif nicht. Die kennen kein "Zeilen verschieben", d.h. es ist irrelevant, ob man immer die Komplette Karte schreibt, löscht oder nur Teilbereiche. Wenn eine Zelle (Speicherbereich) zu häufig beschrieben .... die logig zumBeschreiben sitzt laut definition im Speicherschreiber, nicht auf der Karte.
Das ist der Unterschied zu SSD (oder auch CompacFlash-Karten).
Zitat von: abc2006 am 30 Dezember 2016, 07:12:21PS: wobei ich die Lösung mit "Image mounten und rsync" persönlich auch SEHR interessant finde. Ist halt nur nicht inkrementell.
Wie? Das ist aber sowas von inkrementell... Ich wüsste nicht, wie es noch inkrementeller gehen könnte... ;)
Gruß,
Stephan
Ich glaube, er meinte "verschiedene Speicherstände" .. Du hast nur einen.
Zitat von: Wernieman am 01 Januar 2017, 17:25:32
Ich glaube, er meinte "verschiedene Speicherstände" .. Du hast nur einen.
Ja, richtig, das meinte ich. Wie heisst das denn korrekt?
Grüße
Stephan
Zitat von: abc2006 am 01 Januar 2017, 18:13:07
Ja, richtig, das meinte ich. Wie heisst das denn korrekt?
Grüße
Stephan
versioniert ?
Das kriegt mal sehr gut mit dbconfig hin, würde ich sagen. Ich musste nach Weihnachten erstmal die letzten 50 Stände entfernen... das waren mir zu viele. ;)
Außerdem... bei den vielen Änderungen, macht eine echte Versionierung meiner Meinung nach gar keinen Sinn, weil man sich eh' nicht mehr erinnern kann, was wann genau wie konfiguriert war. Wenn man also immer fröhlich drauflos konfiguriert, dann hat man sehr schnell den Überblick verloren. Ich finde ja, dass ein Backup vor einem Update zu machen eine gute Idee ist. Ansonsten würde ich mit dbconfig gehen...
Gruß,
Stephan
naja ... Versionierung ist nicht nur in FHEm sinvoll ... warum macht man den in Firmen ein Backup mit verschiedenen "Datenständen"?
Ich misch mich in die Expertenrunde mal wieder mit meinen banalen Anfängerfragen ein:
Ich hab jetzt ein wenig mit Diskdump geübt und dachte ich hätte es unter Kontrolle
Auf einen vorher leeren 8 GB USB Stick hatte ich zum testen bereits 3 unterschiedlich Große Images mit jeweils gut 1,5 GB geschrieben. Es waren also noch rund 3 GB frei
Beim nächsten Test kam folgende Fehlermeldung
root@raspberrypi:/# dd bs=1M count=1400 if=/dev/sde of=/media/usbstick/raspbian.img
dd: error writing '/media/usbstick/raspbian.img': No space left on device
353+0 records in
352+0 records out
369283072 bytes (369 MB) copied, 58.3729 s, 6.3 MB/s
Ich formatierte den Stick unter Windows neu - half nichts. Ich probierte es auch unter Linux mit parted (mklabel msdos, mkpart primary fat32 Start 1s End -1s + mkfs.fat32. Half auch nicht
lsblk gibt zwar die volle Größe an
root@raspberrypi:/# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sde 8:64 1 29.7G 0 disk
├─sde1 8:65 1 63M 0 part
└─sde2 8:66 1 1.2G 0 part
sdf 8:80 1 7.5G 0 disk
└─sdf1 8:81 1 7.5G 0 part
mmcblk0 179:0 0 15G 0 disk
├─mmcblk0p1 179:1 0 63M 0 part /boot
└─mmcblk0p2 179:2 0 1.2G 0 part /
aber angeblich wären nur 459MB frei. Ähnliche Werte kommen für verschiedene USB Sticks raus egal ob sie 4GB oder 64GB haben
root@raspberrypi:/# df -h /dev/sdf
Filesystem Size Used Avail Use% Mounted on
devtmpfs 459M 0 459M 0% /dev
außerdem wird seit Verwendung von parted beim mounten ein Eintrag in fstab verlangt
root@raspberrypi:/# mount -t vfat -o utf8,uid=pi,gid=pi,noatime /dev/sdf1
mount: can't find /dev/sdf1 in /etc/fstab
Den Stick konnte ich übrigens unter Windows perfekt bis zum Rand anfüllen.
Um auszuschließen, dass ich beim Linux was verbockt habe, habe ich sogar das original Image nochmal neu auf die SD geschrieben um ein jungfräuliches Linux zu haben. Hat nichts genützt.
Ich bin ratlos - Habt ihr irgendwelche Tips?
1. Deine Größenangaben beziehen sich nicht auf den Stick
devtmpfs 459M 0 459M 0% /dev
Was ist wohl devtmpfs?
2. Ein Mount braucht nicht nur eine Quelle, sondern auch ein Ziel (oder eben einen Eintrag in der fstab)
Also im Stiele von:
mount Quelle Ziel
Du gibst aber nur Quelle an!
Warum beim mount das Ziel gefehlt hat ist mir unerklärlich. Wie auch immer, hier noch mal alles mit einem neu gestarteten Raspi:
pi@raspberrypi:~ $ sudo mkdir /media/usbstick
mkdir: cannot create directory '/media/usbstick': File exists
pi@raspberrypi:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 7.5G 0 disk
└─sda1 8:1 1 7.5G 0 part
sde 8:64 1 29.7G 0 disk
├─sde1 8:65 1 63M 0 part
└─sde2 8:66 1 1.2G 0 part
mmcblk0 179:0 0 15G 0 disk
├─mmcblk0p1 179:1 0 63M 0 part /boot
└─mmcblk0p2 179:2 0 1.2G 0 part /
pi@raspberrypi:~ $ sudo mount -t vfat -o utf8,uid=pi,gid=pi,noatime /dev/sda1
pi@raspberrypi:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.2G 1.2G 0 100% /
devtmpfs 459M 0 459M 0% /dev
tmpfs 463M 0 463M 0% /dev/shm
tmpfs 463M 6.3M 457M 2% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 463M 0 463M 0% /sys/fs/cgroup
/dev/mmcblk0p1 63M 21M 43M 34% /boot
pi@raspberrypi:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sde 8:64 1 29.7G 0 disk
├─sde1 8:65 1 63M 0 part
└─sde2 8:66 1 1.2G 0 part
sdf 8:80 1 7.5G 0 disk
└─sdf1 8:81 1 7.5G 0 part
mmcblk0 179:0 0 15G 0 disk
├─mmcblk0p1 179:1 0 63M 0 part /boot
└─mmcblk0p2 179:2 0 1.2G 0 part /
sda ist der Memory Stick (gemounted)
mmcblk0 ist die SD Karte im Raspi
sde ist die SD Karte im Kartenleser auf die frisch das Raspian Image gespielt wurde (nicht gemounted)
Was devtmps ist weiß ich nicht.
Der Memorystick hat 4 Image Dateien drauf, die ich unter Windows drauf gespielt hatte.
Sie haben insgesamt 5,5GB und Windows sagt, dass noch 2 GB frei sind.
df ist wohl der Meinung, dass 1.2G verbraucht sind und 0% frei.
Übrigens hatte ich vor dem letzten lsblk den Stick abgezogen um im Windows nachzusehen wie viel drauf ist. Beim neuen Anstecken war er dann nicht mehr auf sda sondern auf sdf. Muss ich vor dem abziehen immer unmounten? Muss jeder (neue, andere) USB Stick neu gemounted werden?
fstab sieht so aus: /dev/sda1 hatte ich gestern händisch eingefügt, weil ich nach Verwendung von parted dazu augefordert wurde.
[/size]
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
/dev/sda1 / fat32 defaults
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
Im übrigen bekomme ich folgende Ergebnisse für df direkt auf sda angewendet bzw. allgemein
[/size]
pi@raspberrypi:~ $ df -h /dev/sda
Filesystem Size Used Avail Use% Mounted on
devtmpfs 459M 0 459M 0% /dev
pi@raspberrypi:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.2G 1.2G 0 100% /
devtmpfs 459M 0 459M 0% /dev
tmpfs 463M 0 463M 0% /dev/shm
tmpfs 463M 6.3M 457M 2% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 463M 0 463M 0% /sys/fs/cgroup
/dev/mmcblk0p1 63M 21M 43M 34% /boot
Einen 64 GB Stick (FAT32) kann ich übrigens gar nicht mounten
[/size]
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 57.6G 0 disk
└─sda1 8:1 1 57.6G 0 part
sde 8:64 1 29.7G 0 disk
├─sde1 8:65 1 63M 0 part
└─sde2 8:66 1 1.2G 0 part
mmcblk0 179:0 0 15G 0 disk
├─mmcblk0p1 179:1 0 63M 0 part /boot
└─mmcblk0p2 179:2 0 1.2G 0 part /
pi@raspberrypi:~ $ sudo mount -t vfat -o utf8,uid=pi,gid=pi,noatime /dev/sda1
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
Was kann ich jetzt noch untersuchen?[/size]
1. JA, immer eoi9nen Stick unmounten bevor Du Ihn abziehst!
Übrigens sollte man es eigentlich unter Windows auch (Auswerfen) ....
2. Wegen Mount:
Ich würde Dir Empfehlen, Dir mal folgendes Verzeichnis anzusehen:
/dev/disk/by-id/
Dann kannst Du auch anstatt /dev/sda die richtige /dev/disk/by-id/blablabla verwenden.
(Kleiner Hinweis: Bei einem Dist-Upgrade kann sich eventuell der Name ändern, ist dann aber fest)
3. Du must nicht einen mount in der fstab eintragen, wenn Du, wie schon von mir geschrieben, denn vollem mount-Befehl eingibst:
sudo mount -t vfat -o utf8,uid=pi,gid=pi,noatime /dev/sda1 /media/usbstick
4. Du hast gelesen, das Du das Verzeichnis /media/usbstick nicht anlegen mustest, da es schon angelefgt war?
5. Du hast übriegns Glüclk, das DU Dir Dein System nicht abgeschossen hast.
Was soll dieser Eintrag in der fstab wohl erreichen?
/dev/sda1 / fat32 defaults
Vorallem, wenn Du es mit dem Vorherigen vergleichst:
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
Stichwort: "/" ist root-Verzeichniss!
5. Wenn Du Dir Deine Ausgaben richtig durchsiehst, dann erscheint Dein Stick und hat auch 2GByte frei ... schau doch einfach mal ;o)
DANKE - Scheint wieder zu passen. :P
Habe den Eintrag aus fstab entfernt und neu gestartet.
Wahrscheinlich habe ich diesen Strudel angeworfen durch nicht oder falsches mounten/unmounten gefolgt von neu Formatieren und Eintrag in fstab - Kann es das sein, oder glaubst du, es war was anderes?
Ich werde in Zukunft immer brav unmounten.
[/size]Danke noch mal
Ich glaube, der Hauptfehler "saß vor dem Bildschirm" ;o)
(Bitte nicht falsch verstehen ;o) )
Das ist sowieso klar. Als Autodidakt kann ich nur mit Trial and Error durchstolpern.
Aber nur durch Fehler lernt man. :D
Gesendet von meinem SM-G920F mit Tapatalk
So, ich glaub nun habe ich meine Konfiguration gefunden
- Fhem Backup vor jeder Fhem Konfigurations-Änderung
- Image DiskDump vor jedem Update (SD raus und am Raspi mit anderer SD Karte+Kartenleser+USB-Stick)
Warum inkrementelle Images?
Weil ich im Fall eines Crashs nur das Image aufspielen möchte mit der funktionierend-installierten Software Version (Fhem, FTUI, Kalender etc.) die sicher läuft.
Ich habe so oft im Forum über Probleme nach einem Update gelesen. Wenn ich bei einer Null-Installation starte bekomme ich beim notwendigen Update natürlich die neueste Version und es könnte was nicht passen.
Wegen der SD-Lebenszeit wäre wahrscheinlich eine kleine SD-Karte plus USB-Stick für Logs und Backups am sinnvollsten.
Da ich nun mal schon mal meine 32GB SD-Karte habe und trotzdem an inkrementellen Images festhalten möchte habe ich mich mit Partitions durchgekämpft. Somit lasse ich die Root Partition auf 2GB Größe.
"Home" mit Unterverzeichnis "Fhem" und darin "backup" und "log" habe ich auf der großen neuen Partition angelegt und Fhem hat die Schreibrechte dort. Die Backups und Logs hole ich natürlich regelmäßig aufs NAS. Das werde ich auch noch mal automatisieren.
pi@raspberrypi:/home/fhem/backup$ sudo fdisk -lu
[font=courier]...
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 137215 129024 63M c W95 FAT32 (LBA)
/dev/mmcblk0p2 137216 4194304 4057089 2G 83 Linux
/dev/mmcblk0p3 4194305 62333951 58139647 27.7G 5 Extended
/dev/mmcblk0p5 4198400 62333951 58135552 27.7G 83 Linux
pi@raspberrypi:/home/fhem$ ls -ls
total 8
4 drwxr-xr-x 2 fhem dialout 4096 Jan 6 20:04 backup
4 drwxr-xr-x 2 fhem dialout 4096 Jan 6 00:49 log[/font]
In Fhem habe ich die Directories folgendermaßen angepasst
attr global backupdir /home/fhem/backup
attr global logdir /home/fhem/log
attr global logfile /home/fhem/log/fhem-%Y-%m.log
...und - Hurra - wenn ich das Image mit Win32diskimager wieder drauf spiele bleibt sogar die Erweiterungs-Partition mit Home erhalten.
Mit dem Platz auf root sollte ich hoffentlich das Auslangen finden oder wird das mit der Zeit recht groß und ich soll gleich auf 4GB gehen?
[font=courier]pi@raspberrypi:/home/fhem$ df -la
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 1963344 1179544 665992 64% /
devtmpfs 469532 0 469532 0% /dev
sysfs 0 0 0 - /sys
proc 0 0 0 - /proc
tmpfs 473864 0 473864 0% /dev/shm
devpts 0 0 0 - /dev/pts
tmpfs 473864 6588 467276 2% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 473864 0 473864 0% /sys/fs/cgroup
cgroup 0 0 0 - /sys/fs/cgroup/systemd
cgroup 0 0 0 - /sys/fs/cgroup/cpu,cpuacct
cgroup 0 0 0 - /sys/fs/cgroup/blkio
cgroup 0 0 0 - /sys/fs/cgroup/memory
cgroup 0 0 0 - /sys/fs/cgroup/devices
cgroup 0 0 0 - /sys/fs/cgroup/freezer
cgroup 0 0 0 - /sys/fs/cgroup/net_cls
systemd-1 0 0 0 - /proc/sys/fs/binfmt_misc
mqueue 0 0 0 - /dev/mqueue
debugfs 0 0 0 - /sys/kernel/debug
configfs 0 0 0 - /sys/kernel/config
/dev/mmcblk0p5 28480140 172068 26838300 1% /home
/dev/mmcblk0p1 64456 21320 43136 34% /boot[/font]
Es scheint alles zuverlässig zu laufen.
Meine offenen Fragen:
- Sehen die Experten irgendeine Gefahr in diesem Setup?
- Habe ich irgendetwas übersehen oder vergessen?
- Reichen 2GB für Root oder soll ich lieber gleich auf 4GB gehen?
Moin,
Wie hat sich Deine Vorgehensweise bewährt?
Ich stehe aktuell vor den gleichen Fragen und Problemen. Ziel ist es, im Fall der Fälle (sd-Karte geht hops) ein möglichst aktuelles image auf eine neue sd-karte zu bügeln, bzw. bügeln zu lassen. Dabei muss es im fall zwei, also dem bügeln lassen, dem laiendarsteller ohne druidenwissen möglich sein, das image auf eine neue sd-karte zu bringen.
Meine Infrastruktur beinhaltet einige windows-pcs sowie android-devices und einen synology-nas (tv, Webradio usw. lass ich mal aussen vor). Ein raspi 3 dient fhem als Grundlage und ist das neuste Geräte im Netz.
Da ich kein Freund automatischer Updates bin und zudem nicht allzuviel Zeit in Systempflege investieren kann und will, benötige ich ein eher konservatives backup-konzept.
Die Trennung von Betriebssystem und Anwendung über Partitionen macht aus meiner Erfahrung Sinn, ebenso das schreiben von log-files auf externe Medien.. wobei man ggf über eine Minimierung der log-einträge nachdenken müsste (dazu kenn ich aber das System noch zu wenig).
Meine idee:
- backup des Betriebssystems vor jedem Update als disk-image
- backup der Anwendungen vor Updates und Konfigurationsänderungen als zip-archiv (ggf. auch zyklisch Backups)
Beide Backups werden auf dem nas abgelegt und können von dort über einen windows-client zum erzeugen eines Abbildes der letzten Umgebung genutzt werden.
...so der plan....
Ich Frage mich nun, wie das alles möglichst simpel umzusetzen ist.
- Scripte zum Betriebssystem-backup manuell anstossen oder im update-script einbauen
- Scripte zum applikations-backup als cron-job und manuell anschubsbare Lösung, bzw. im update-script einbauen.
- Scripte für die windows-clients zum herstellen von systemkopien des raspi/fhem konglomerats auf eine neue sd-karte
Gruss vom fpg
Hi fpg,
- aufschreiben was installiert und konfiguriert wurde.
- regelmäßig FHEM Backup machen und extern sichern.
- setup Script mit eigenen Modulen und speziellen Installationen pflegen.
- bei Bedarf: Neues aktuelles Systemimage installieren, Setup script ausführen, FHEM restore machen.
Gruß Otto
Und vorallem, das Backup auch mal testen!
Moin,
um es mal anders zu formulieren: ich suche nach einer backup-Lösung deren Restore ein lauffähiges System generiert. Das muss auch dann funktionieren, wenn kein linux/fhem-druide in der Nähe ist. Das setzt voraus, das man bei einem Ausfall des Datenträgers eine technische Lösung parat hält, die dem System eine notwendige Autonomie verleiht, indem jeder, auch ohne tiefere systemkenntnisse in der Lage ist, das System wieder in Betrieb zu nehmen.
Die Anweisung würde sich dann nur auf den Kauf einer passenden sd-karte, deren Einsatz in den card-adapter und den Start einer "APP" beschränken. Komplette Systemdokumentation mit allen Releases ist zwar nett, aber wenn die zeit knapp ist eher hinderlich.
Die Installation eines aktuellen image bringt zudem neue Unsicherheiten. Was spricht dafür ein stabil laufendes System anzufassen, zumal der erwartete Ausfall nicht ursächlich auf einen Softwarefehler zurückzuführen wäre?
Ich könnte mir vorstellen, dass ich nicht allein mit derartigen Anforderungen bin. Zudem würde eine gute Lösung zur Professionalisierung des Projekts führen.
Gruss vom fpg
Hi fpg,
was Du willst bedeutet im Klartext:
- System so aufsetzen das SD Card nicht voll genutzt wird!
- System herunterfahren
- SD Karte raus offline Image machen
- SD Karte wieder rein
- System starten
Den Rest kannst Du so machen wie Du vorgeschlagen hast. Eventuell baust Du einen kleinen SD Karten Roboter, was allerdings der Slot dazu sagt ???
Um es vorneweg zu beantworten: Nein es gibt kein 100% funktionierendes "dummes" Online Image Backup, in keinem System.
Der erwartete Ausfall ist übrigens meistens der Admin (entschuldige Werner :D)
Gruß Otto
moin,
fast... bis auf den Roboter :-) und die 100%-Aussage. Gerade im Fall eines Datenträgerversagens gibt es seit ewigen Zeiten Lösungen. Aber die greifen bei den fussel-rechnern nicht... ausser man könnte eine art fail-over Spiegel einrichten. Soetwas triebe den Aufwand aber etwas weit (wobei ein zweiter raspi im Netz ja übernehmen könnte wenn es gelänge alle Periferie wie CUxe zu teilen... hmmm da ginge was mittels pub/sub a la mqtt).
zunäxxt aber simpleres ;) :
- gibt es ggf. eine brauchbare Lösung, ein online-image der SD-Karte auf dem raspi zu ziehen und an einen sicheren Ort zu schreiben ?
- kann man Betriebsystem incl. boot-Partition separat von den Anwendungen (FHEM) "partitionieren" ohne das man beim ersten update den Laden an die Wand fährt ?
- Wie gross muss eine SD-Karte mindestens sein, um eine fhem-Umgebung incl. OS fassen zu können ?
gruss vom fpg
Zitat von: fpg am 05 Januar 2018, 13:48:42
- Wie gross muss eine SD-Karte mindestens sein, um eine fhem-Umgebung incl. OS fassen zu können ?
4 GB der Rest hängt von Dir ab ;D
Nochmal: Online Image ist Quark - aber mir ist das Wurscht. Die Diskussion gibt es nicht jede Woche aber aller halben Jahre. ;D
Du kannst mit dd irgendwohin ins Netzwerk schreiben. Also Stichworte:
dd
fstab
mount
Gibt es glaube ich auch schon einiges an Beiträgen hier im Forum.
Gruß Otto
Zitatgerade im Fall eines Datenträgerversagens gibt es seit ewigen Zeiten Lösungen.
Aber eben nicht für absolute Daus .. und genau dafür willst DU eine Lösung.
Für Daus: Mache eine Offline-Kopie der SDCard und lege sie Dir ab. Bei jeder Änderung .....
(Wobei mir dazu auch noch einige Sachen einfallen. Eine Offline Kopie einer SDCard mit einer 2. Partition für FHEM. Beim Start von FHEM automatisch aus einem Backup fhem + config holen (z.B. Deiner Synology). Und alle 30 Minuten/Shutdown aktuellen Stand ins Backup ... + Versioniertem Backup (wird meistens vergessen))
@Otto123
Mit dem Hinweis auf "Admins" ärgerst Du mich nicht (mehr). Den häufigsten Ausfallvon Servern in meinem (Admin)-Leben hatte ich Durch Entwickler *griiins*
Moin,
Ich hatte mir diesen Thread ausgewählt, weil mir der Ansatz vom Themenstarter gefiel.
Otto 123, warum ist ein online-abzug Quark? Funktioniert doch auf anderen Plattformen sehr gut. Sinn macht sowas vor systemänderungen. Wenn da was schief geht, spart einem das image jede menge zeit und arbeit.... ggf. auch geld.
4gb ist recht happig für eine linux-Installation.... kann man die nicht schlanker machen ??
Meine Anforderung an das backup und Restore ist zweiteilig zu betrachten:
- das backup muss so gut sein, wie der letzte konfigurierte betriebszustand und soll so weit wie möglich automatisiert ablaufen. Scripte können da hilfreich sein. Was nicht automatisierbar ist, muss im Ernstfall (update, konfigurationsänderung) manuell durch kundige User erfolgen.
- Restore ist dabei der einfachere Prozess. Der ist, soweit ich es überblicken kann, auch durch nicht-it'ler durchführbar. Eine "APP" zu bedienen und eine sd-karte zu handhaben ist heute quasi Kulturgut.
Es wäre doch eine gute Idee, ein brauchbares Konzept für solche Fälle zu entwickeln. Nicht jeder macht seine smarthome-lösung zum lebensmittelpunkt :)
Gruss vom fpg
Zitat von: fpg am 05 Januar 2018, 16:27:45
Otto 123, warum ist ein online-abzug Quark? Funktioniert doch auf anderen Plattformen sehr gut. Sinn macht sowas vor systemänderungen. Wenn da was schief geht, spart einem das image jede menge zeit und arbeit.... ggf. auch geld.
4gb ist recht happig für eine linux-Installation.... kann man die nicht schlanker machen ??
Wenn alle Komponenten im System Online Image unterstützen geht das sicher. Aber ich meine schon raspbian ist dafür nicht gebaut. Aber Du kannst gerne sowas bauen, ich sage da nix dazu...
Gibt es noch kleinere Karten als 4GB ? ;)
Aber ja, raspbian lite hat glaube ich weniger (1,8 GB) und FHEM braucht quasi das was Du brauchst. Ich hatte 4 GB nur gesagt weil es aus meiner Sicht mit weniger keinen Sinn ergibt.
Viel Spaß beim Online Backup und vor allem dem Restore für DAUs ;D
Otto
Zitat von: fpg am 05 Januar 2018, 13:48:42
zunäxxt aber simpleres ;) :
- gibt es ggf. eine brauchbare Lösung, ein online-image der SD-Karte auf dem raspi zu ziehen und an einen sicheren Ort zu schreiben ?
- kann man Betriebsystem incl. boot-Partition separat von den Anwendungen (FHEM) "partitionieren" ohne das man beim ersten update den Laden an die Wand fährt ?
- Wie gross muss eine SD-Karte mindestens sein, um eine fhem-Umgebung incl. OS fassen zu können ?
Mit ein wenig Aufwand ist das schon machbar.
Online Backup der SD-Card?
--> https://www.linux-tips-and-tricks.de/de/raspberry/23-pi-erstellt-automatisch-backups-von-sich-selbst-pi-creates-automatic-backups-of-itself/
Habe ich selbst im Einsatz. Feine Sache.
Optional, damit du offene Filehandler verhinderst oder reduzierst, welche Probleme machen könnten.
--> Fhem und DB beim Backup stoppen.
Im Falle eines Fehlers --> Backup auf SD Schreiben (Windows Win32Imager) und fertig
moin,
ja super ! scheint genau das zu sein, was ich gesucht habe :) :)
was besonders gefällt, ist die option, nicht die volle sd-kartengrösse zu sichern. man erspart sich blöde klimmzüge.
danke für den link... ich hatte etwas ähnliches schon gefunden, aber das war lange nicht so gut beschrieben, wie es in diesem link gemacht ist !
gruss vom fpg
die Option nicht verwendeten Speicher nicht zu sichern ist etwas blöd beschrieben.
Angenommen du hast eine 8GB Karte und (Raspbian üblich) alles als Partition --> Image ist auch 8 GB
Wenn du aber die 8GB verkleinerst, und die Karten "hinten" noch 2 GB nicht zugeordneten Speicher hast --> Image nur 6 GB.
Ich würde die Partition immer etwas verkleinern. Das hat den Vorteil wenn deine Ersatzkarte ein paar MB weniger hat kannst das DD-Image dennoch zurückspielen. Das ist oft das Problem da bei gleicher Kartengröße trotzdem ein paar MB Unterschied sein können.