FHEM Forum

Moin,

ich betreibe seit einigen Wochen fhem auf meinem (ersten) Raspberry Pi (B+) und soweit funktioniert alles. Nun las ich, dass die microSD-Karten wohl nicht sonderlich lange halten, bei der ganzen Schreiberei aufrgrund diverser Logfiles etc.

Mich würde interessieren, wie ihr dies löst. Nachdem schon viel Zeit in die Konfiguration des Systems gegangen ist, würde mich meine Frau töten, wenn das System abraucht und ich alles wieder neu aufsetzen muss (und bis dahin weder Licht noch Rolladen das tun, was sie tun sollen).

Macht es Sinn, eine externe HDD am Pi zu betreiben und da alles drauf laufen zu lassen? Falls ja, habt ihr einen Link, wo anfängertauglich beschrieben wird, wie man ein bestehendes System verlustfrei auf Betrieb von HDD umstellt?

Oder würde es reichen, meine dauerhaft laufende Synology irgendwie ins Raspberry-System einzubinden (wie auch immer), um dann dort alles Schreibintensive abzulegen, und die SD nur noch für "normale" Systemaufgaben zu nutzen (was sie hoffentlich die nächsten Jahre überleben lässt).

Ich würde mich über jeden Tip freuen.
Gruß
Michael

Also,

1.) vieles ist sicherlich nur Panikmache , meinen ersten Raspberry hatte ich mit der selben Karte fast 2 Jahre betrieben und ich habe die Karte nicht wirklich stiefmütterlich behandelt (lesen und beschreiben). Dann kam der Raspberry 2 den ich mit MicroSD-Karte fahre und das auch schon seit gut 6 Monaten mit derselben Karte.

2.) Wenn mein System "abfackeln" sollte wird einfach die Sicherungskopie (die ich einmal pro Woche anfertige) aufgespielt und fertig!

Gruß
Tom

Zitat von: Tom111 am 18 Oktober 2015, 16:26:581.) vieles ist sicherlich nur Panikmache , meinen ersten Raspberry hatte ich mit der selben Karte fast 2 Jahre betrieben und ich habe die Karte nicht wirklich stiefmütterlich behandelt (lesen und beschreiben).

Du meinst wohl entweder "nicht wirklich gut" oder "wirklich stiefmütterlich", oder?
Meine Erfahrung ist die: Ich hatte zuerst eine SD-Karte, die bei einem Komplettpaket (Pi im Hitschienengehäuse) dabei war. Die ist mir nach ein paar Monaten abgeraucht. Das System lief allerdings noch, nur die Logs gingen nicht mehr und man konnte keine Änderungen mehr speichern. Ich nehme mal an, dass es ein Durchstarten allerdings nicht ausgehalten hätte.
Ich habe mir dann eine etwas teurere Karte zugelegt, die läuft jetzt ohne Probleme etwa ein Jahr. 

Zitat
2.) Wenn mein System "abfackeln" sollte wird einfach die Sicherungskopie (die ich einmal pro Woche anfertige) aufgespielt und fertig!

Man kann eine solche Kopie auch gleich auf eine Ersatz-Karte schreiben. (Natürlich nicht einmal pro Woche...) Man muss dann nur die Karte austauschen und durchstarten. Damit sollte auch jemand nicht ganz so technikaffines nach einer kurzen Einweisung das Teil wieder flott bekommen.
Gruß,
    Thorsten

Zitat von: Thorsten Pferdekaemper am 18 Oktober 2015, 16:40:49
Meine Erfahrung ist die: Ich hatte zuerst eine SD-Karte, die bei einem Komplettpaket (Pi im Hitschienengehäuse) dabei war

Ich rede hier natürlich nicht von irgendwelchen "dabeigepackten" Karten, die hab ich eh alle immer weggeschmissen!
Ich habe für meine erste 8GB Karte 30 Euro bezahlt (SanDisk Extreme Pro SDHC 8GB 95MB/s - 8GB ist die Grenze, mehr sollte niemand nehmen, aber darauf geh ich jetzt hier nicht ein)

Gruß
Tom

PS:

Zitatnicht wirklich stiefmütterlich

was ist daran falsch zu verstehen ?

Zitat von: Tom111 am 18 Oktober 2015, 16:49:23
Ich rede hier natürlich nicht von irgendwelchen "dabeigepackten" Karten, die hab ich eh alle immer weggeschmissen!

Dann sind wir je einer Meinung: Man sollte keinen Billigkram nehmen.

Zitat

Zitat
nicht wirklich stiefmütterlich

PS:was ist daran falsch zu verstehen ?

Etwas "stiefmütterlich zu behandeln" bedeutet meiner Meinung nach, dass man es schlecht behandelt. Etwas "nicht stiefmütterlich" zu behandeln bedeutet also, dass man es eher gut behandelt. Ich nehme aber an, dass Du eigentlich meinst, dass Du auf die Karte nicht besonders aufgepasst hat, und sie trotzdem keine Probleme bereitet  hat.
Natürlich kann es auch sein, dass Du betonen wolltest, dass Du die Karte gut behandelt hast. Dann ist es aber kein Wunder, dass sie lange durchhält.

Gruß,
    Thorsten 

Vor/nach wichtigen Änderungen Backup (auf eine 2. Karte) machen und fertig.

Alles andere ist meiner Meinung Panikmache.
Man kann immer Pech haben, es kann auch genauso gut jahrelang problemlos funktionieren.
Gute SD-Karten sind bestimmt nicht schlechter als billige USB-Sticks (zum Log) auslagern; und ständig auf die FestPlatte eines NAS schreiben verschiebt nur das Problem... wobei auch Festplatten das zig Jahre mitmachen.

Hm, mal sehen. Ich dachte nur, da das NAS eh läuft, könnte es die microSD auch gleich entlasten. Nach Murphy wird die Karte eh dann ausfallen, wenn man gerade im Urlaub ist und alle Rolladen oben und überall das Licht an 8)

Hallo,

ich habe meinen Raspberry Pi im Hutschienengehäuse und einen zweiten im Cold Standby.

Ich verwende eine 32 GB Marken-SD-Card. Je größer, desto besseres Wear Leveling.

Die Raspian-Basisinstallation habe ich mir auf eine identische Karte dupliziert (dd).

Der Teil mit der FHEM-Installation (/opt/fhem) liegt auf einem LVM. Davon ziehe ich nächtlich einen Snapshot, der dann in meine nächtliche Sicherung aller meiner Daten einbezogen und danach sofort weggeworfen wird (Backup-Lösung: BackupPC).

Wenn die Karte krepiert, nehme ich die zweite Karte und stelle /opt/fhem wieder her. Wenn der Raspberry krepiert (so wie letztes Jahr durch Blitzschlag), kommt der Ersatz zum Einsatz. Die Ausfallzeit letztes Jahr betrug daher nur 4 Stunden vom Blitzschlag bis zur vollen Wiederherstellung.

Mir genügt das. Wenn ich auch während längerer Abwesenheiten (Urlaub) gegen Defekte geschützt sein möchte, würde ich auf Hot Standby übergehen, wobei es erheblich schwieriger wäre, dafür zu sorgen, dass der Spare nicht demselben externen Schaden (Blitzschlag) unterliegt. Bevor ich dem Raspi existenziell wichtige Aufgabe übertrage, würde ich mir noch ganz andere Gedanken machen (z.B. ob ich noch alle Tassen im Schrank habe ;-).

Ansonsten geht es dem OP aber insbesondere darum, die Anfälligkeit gegen Defekte des Speichermediums zu senken. Speicherung auf NFS hat den Nachteil von Multiple Points of Failure. Ich hatte das eine Weile so laufen, aber die Abhängigkeit zur Wartung des NAS hat auf Dauer genervt. Eine rotierende Festplatte am Raspi ist wegen des Dauereinsatzes auch nur dann eine bessere Lösung, wenn es eine für Dauerbetrieb geeignete Platte ist. Mag sein, dass die dann viel länger als die SD-Card durchhält.

Fazit: nachdem ich mir mal vor einer Weile ähnliche Gedanken gemacht hatte, kam ich auf die für mich beste Lösung wie beschrieben. YMMV.

Viele Grüße
Boris

Zitat von: Dr. Boris Neubert am 18 Oktober 2015, 18:15:25
Der Teil mit der FHEM-Installation (/opt/fhem) liegt auf einem LVM. Davon ziehe ich nächtlich einen Snapshot, der dann in meine nächtliche Sicherung aller meiner Daten einbezogen und danach sofort weggeworfen wird (Backup-Lösung: BackupPC).

Sorry für die blöde Nachfrage, aber was ist ein LVM? Ich habe zur Sicherung im Netz ein Skript gefunden, welches täglich auf fhem läuft und alles auf mein NAS sichert (hoffe ich zumindest, es erscheinen zumindest täglich 20MB Zip-Dateien  :o ) Wie die Rücksicherung ginge, kann ich nicht sagen, soweit bin ich mit dem RasPi und Linux noch nicht.

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

Zitat von: Dr. Boris Neubert am 18 Oktober 2015, 18:15:25
Bevor ich dem Raspi existenziell wichtige Aufgabe übertrage, würde ich mir noch ganz andere Gedanken machen (z.B. ob ich noch alle Tassen im Schrank habe ;-).

Das stimmt wohl. Die Absicherung zielt auch eher darauf, dass ich im Falle eines Defekts der SD-Karte (was ja zumindest laut etlicher Berichte öfters vorkommt) nicht wieder stundenlang den RasPi und vor allem fhem neu einrichten muss.

Ich denke, ich werde meine 16GB Karte laufen lassen und lege mir eine zweite mit einer Kopie des laufenden Systems in den Schrank. Vielleicht noch eine Frage außerhalb des Threads...

Ich logge meinen Stromverbrauch per LogFile und stelle daraus den Plot dar. Nun las ich, dass man auch mySQL anbinden kann. Würde es Sinn machen, auf meiner Synology NAS die DB zu erstellen und den RasPi anstatt alle 60 Sek. ins LogFile in die DB schreiben zu lassen?

Zitat von: MichaelO am 18 Oktober 2015, 19:08:07
Sorry für die blöde Nachfrage, aber was ist ein LVM?

Hallo,

genau das hätte ich auf gefragt und Wikipedia (https://de.wikipedia.org/wiki/Logical_Volume_Manager) hat mir da auch nicht viel weitergeholfen.

Gruß PeMue

Hallo,

LVM= Logical Volume Management, siehe bitte hier http://www.selflinux.org/selflinux/html/lvm.html (http://www.selflinux.org/selflinux/html/lvm.html) und hier http://tldp.org/HOWTO/LVM-HOWTO/ (http://tldp.org/HOWTO/LVM-HOWTO/). Ich benutze das, um einen konsistenten Schnappschuss zu erhalten, da sonst ja während des Backuplaufs Dateien verändert werden können und dann die Sicherung nicht in sich schlüssig sein könnte, von Dateisperren einmal ganz abgesehen.

Ich verwende folgendes Skript, das vor/nach einem Backup/Restore ausgeführt wird:

#!/bin/sh
#
# neubert 2014-08-24
#

MNT=/opt/fhem-snapshot
SZ=252M
VOLUMEGROUP=vg0
LOGICALVOLUME=lv0
FSTYPE=ext4


#
#
#

VDEVICE=/dev/$VOLUMEGROUP/$LOGICALVOLUME
SNAME=${LOGICALVOLUME}_snapshot
SDEVICE=/dev/$VOLUMEGROUP/$SNAME

create_snapshot() {
        # erstellt einen Snapshot des LV, hängt den Snapshot ein und setzt die Berechtigungen
        if [ -b $SDEVICE ]; then
                destroy_snapshot
        fi
        lvcreate -L$SZ -s -n $SNAME $VDEVICE
        mount -v -t $FSTYPE $SDEVICE $MNT
}


destroy_snapshot() {
        #M=30
        #while fuser -am $MNT; do
        #       sleep 1;
        #       M=`expr $M - 1`
        #       echo -n "$M "
        #       if [ $M -eq 0 ]; then
        #               break
        #       fi
        #done
        sleep 30
        # setzt die Berechtigungen zurück und hängt den Snapshot des LV aus
        umount -v $MNT && lvremove -f $SDEVICE
}


mount_lv() {
        # hängt das LV selbst ein und setzt die Berechtigungen
        mount -v $VDEVICE $MNT
}


unmount_lv() {
        # setzt die Berechtigungen zurück und hängt das LV aus
        umount -v $MNT
}



case "$1" in
        dump_pre)
                create_snapshot
                ;;
        dump_post)
                destroy_snapshot
                ;;
        restore_pre)
                mount_lv
                ;;
        restore_post)
                unmount_lv
                ;;
        *)
                echo "Usage $0 {dump_pre|dump_post|restore_pre|restore_post}"
                exit 3
                ;;
esac

Loggen in eine DB auf einem anderen Rechner ist eine Alternative, schafft aber auch eine Abhängigkeit, die dazu führt, dass FHEM hängt, wenn die DB offline ist. Wie gesagt, ich bevorzuge eine autarke Lösung, sonst hätte ich das ganze wie früher weiter in einer virtuellen Maschine betrieben. Der Raspi rennt und rennt und rennt (up 138 days, 23:11).

Viele Grüße
Boris

Hallo in die Runde,

habe die Schreibzyklen auf die SD minimiert, indem ich ein Ram-Drive ,,ramfs" gemountet habe. Darin werden die LogFiles geschrieben.
Ein Script sorgt dafür, das nur jede Stunde die Logfiles vom Ram-Drive  auf die SD geschrieben werden.
Das Logfile auf der SD lasse ich mittels eines Dropbox-Python Skript synchronisieren.
Außerdem habe ich in das /etc/init.d/fhem Script das Kopieren der Logfiles vom Ram-Drive zur SD und beim "stop" das Kopieren der Logfiles von der SD in das Ram-Drive bei "Start" erweitert.
Gleiches mache ich mit dem Dropbox-Python Script für das Verzeichnis /opt/fhem/.

Moin,

ich nutze seit Nov.2014 Rpi's + BPi mit SD zum booten und HDD für root.
Im Vergleich zu SD starten die Pi's bei mir mit HDD schneller.
Bin gerade am Tablett, wenn Du einen Linke haben möchtest wie das mit HDD als root funktioniert, einfach fragen. Hier im Forum war etwas mit dd beschrieben, das hat bei mir nicht wirklich funktioniert.

@Boris,
Danke für Deinen Tipp mit LVM werde ich, wenn ich Zeit habe mal testen.

@sceadm,
Hättest Du Lust, Deine Version mal genauer zu erklären?

Viele Grüße
Sunny

Hi,

ich hab da eine "rustikale" Lösung, ob das Sinn macht? Keine Ahnung, aber ich fühl mich besser dabei ;)

- Nach jedem RPi bzw. Linux-Update fahre ich den RPI runter, packe die SD in einen Rechner und erstelle ein bitgenaues Abbild. Das ist selten, also überschaubarer Aufwand.
- Alle Logfiles, also FHEM und Linux, landen auf einem USB-Stick um die Schreibzyklen auf der SD-Karte zu minimieren. Bei Aufall muss ich nur den Stick ersetzen
- Vor jedem Update erstellt FHEM automatisch ein Backup
- Das Backup-Verzeichnis wird per Cronjob jede Nacht um 0 Uhr auf ein NAS gespiegelt.

Zerlegt es den Pi oder die Karte muss ich nur das bitgenaue Abbild am Laptop zurück schreiben, das letzte stabile FHEM-Backup drüberbügeln und mein System ist wiederhergestelt. Zeitaufwand ca. 5 Minuten...

Ok, einmal pro Woche leere ich das Backup-Verzeichnis und verschiebe den letzten Snapshot auf dem NAS in ein anderes Verzeichnis.

Bei mir sind auch die USB-Sticks abgeraucht auf die ich die Logs geschrieben habe.

Seit einem 3/4 Jahr habe ich auch die SD zum booten, und RootFS auf eine angeschlossene SSD ausgelagert. Die SSD-Controller verteilen die Daten angeblich besser auf die einzelnen Cluster.
System läuft seitdem sehr performant. Backups werden täglich via LAN auf einen USB-Stick an der Fritz, sowie wöchentlich aufs NAS erstellt.

SSD macht Sinn, ja - nur nicht beim RPi ;) Dat hammer nicht ;)

Deswegen Banana mit SATA  ::)

Jau - aber wie lautet der Threadtitel? Haltbarkeit des BananaPi? ::) Wird dem TE nicht wirklich weiter helfen... ;)

Zitat von: Tedious am 20 Oktober 2015, 10:40:56
...Alle Logfiles, also FHEM und Linux, landen auf einem USB-Stick um die Schreibzyklen auf der SD-Karte zu minimieren. Bei Aufall muss ich nur den Stick ersetzen...

Sorry, aber das ist doch auch Blödsinn.    :P
Das ist beides die selbe Technologie und Du hast damit statt 1 gleich 2 Devices die "theoretisch" kaputt geschrieben werden können.

Das Vollbackup der SD-Karte als Image und Notfallersatz ist da wesentlich besser.
Und/oder Daten/Logs auf einem anderen Medium sichern, sofern das eh läuft.  Fertig.

Stimmt. Aber bei einem Logfile isses mir ehrlich gesagt wurst ob der Stick kaputt geht, beim System (SD) nicht ;)

Die Logs kann man ja simpelst abschalten, wenn man Sie nicht auswerten möchte (global verbose auf 0 setzen). Sobald alles wie gewünscht läuft, braucht man die Logs in der Regel nicht mehr.

Logdaten nur bei Änderungen erfassen, Änderungswerte erst ab einer gewissen Abweichung erfassen - es braucht bei Temperaturänderungen selten die Erfassung von mehr als einer Stelle hinter dem Komma (event-on-change-reading
temperature:0.1) ... Daten die nicht benötigt werden nicht speichern (gibt ja oft redundante Daten, wie temperature / T ...).

Das reduziert die Schreibzyklen auf die Speicherkarten erheblich. Wenn die Karten zuvor schon Monate gehalten haben, dürften diese dann auch ein Jahrzehnt schaffen ...

Backups und zweite Hardware sind nicht verkehrt, wenn davon wichtige Bereiche im Haus abgedeckt werden (wie Heizsystem). Man sollte bedenken, dass auch ein Dritter/Laie im Notfall das Austauschen kann (passiert garantiert was, wenn man für eine Woche außer Haus ist ...).

Zitat von: TSB am 20 Oktober 2015, 13:02:45
Die Logs kann man ja simpelst abschalten, wenn man Sie nicht auswerten möchte (global verbose auf 0 setzen). Sobald alles wie gewünscht läuft, braucht man die Logs in der Regel nicht mehr.

Schaltet das denn nur die FHEM Logs aus, oder auch alle anderen (Temperatur, Energieverbrauch etc...)?

Ich habe von der SD Karte ein Image-Backup gemacht, dabei dann aber bemerkt, dass man es auch auf die exakt gleiche Karte zurückspielen muss: Eine 8GB Kingston Karte ist ein paar Byte größer, kopiert man das auf eine 8GB Sandisk, läuft nix mehr :-)

Meine Idee wäre auch gewesen, den "Logs" Ordner unter /opt/fhem einfach als Symlink auf einen einfachen USB-Stick zu legen, das sollte kaum Aufwand sein, schnell gehen - und USB Sticks habe zumindest ich genug herumliegen :)
Andere Sachen sollten dann beim laufenden Rechner nicht mehr all zu oft geschrieben werden?

Es werden ja noch mehr Logs geschrieben, nicht nur FHEM schreibt ;) Die Pfade lassen sich aber via Webmin recht bequem anpassen.

Zitat von: Tom111 am 18 Oktober 2015, 16:49:23
Ich rede hier natürlich nicht von irgendwelchen "dabeigepackten" Karten, die hab ich eh alle immer weggeschmissen!

Hehe, ich verwend die immer. Waren die einzigen, die bei mir bisher nie Probleme gemacht haben.
Im Gegensatz zu sündteuren SanDisk SD.

Der Raspi ist leider ziemlich wählerisch, was SD-Karten angeht. Ich hoffe, das wird noch irgendwann besser.

Ich seh das so - im Moment bastel und spiele ich noch damit, da kann ich mit kleineren Problemchen leben. Wenn denn nächstes Jahr der Hauskauf oder -bau ansteht und das ganze denn sinnig alles ("produktiv") steuern soll wird der RPI eh durch einen NUC oder vergleichbar abgelöst werden, incl. Umstellung auf SQL(lite) statt der txt-logs.

Jaja, "nur rumbasteln". Das sagen alle. Und dann hat man irgendwann so viel erreicht und ist so begeistert, dass aus der Bastelei plötzlich ein Fixum wird, auf das man nicht mehr verzichten kann.
Ich kenn das ;)

Zitat von: drhirn am 22 Oktober 2015, 15:27:57
Jaja, "nur rumbasteln". Das sagen alle. Und dann hat man irgendwann so viel erreicht und ist so begeistert, dass aus der Bastelei plötzlich ein Fixum wird, auf das man nicht mehr verzichten kann.
Ich kenn das ;)

:D :D :D

/dev/shm steht für "shared memory", das sind Speicherbereiche im Hauptspeicher. Unter /dev/shm sind diese Bereiche nach außen sichtbar.
In /dev/shm tauchen normal nur die shared memory Segmente auf, gemischt mit normalen Dateien ist es ein wenig unübersichtlich.
Aber trotzdem. Die FHEM Logfiles  schreibe ich nun nach /dev/shm.

/dev/shm wird aber beim nächsten Reboot gelöscht. Also muss man sicherstellen das beim Reboot alles kopiert wird.

Also habe ich erst mal die /etc/init.d/fhem angepasst.

case "$1" in
'start')
        echo "Starting fhem..."
        cp /opt/fhem/log/*.log /dev/shm/
        perl fhem.pl fhem.cfg
        RETVAL=$?
        ;;
'stop')
        echo "Stopping fhem..."
        cp /dev/shm/*.log /opt/fhem/log/
        perl fhem.pl $port "shutdown"
        RETVAL=$?
        ;;


Ausserdem ein cron angelegt:
# m h  dom mon dow   command
*/60 * * * * cp /dev/shm/*.log /var//log/fhem


also alle 60 Minuten alle Logfiles kopieren. Wenn der Rechner abstürzt, sind max 60 Minuten Log verloren.

Man muss ausserdem abwägen, welche Logfiles man wirklich benötigt und ,,event-on-change-reading" nutzen, um die Logfiles klein zu halten.

Damit verringert man die Schreibzyclen auf SSD/USB/CF... erheblich.

Um bei einem Systemausfall oder HW defekt nicht alles zu verlieren, sichere ich die Logs und den Ordner /opt/fhem zu dropbox https://www.dropbox.com/install?os=lnx

Wenn gewünscht, kann ich das auch im Detail beschreiben.

Zitat von: sceadm am 22 Oktober 2015, 21:47:08
Wenn gewünscht, kann ich das auch im Detail beschreiben.

Naja, ja, sehr gerne!

Ist sicher gestellt, dass bei einem manuellen Reboot/Shutdown FHEM ordentlich beendet wird?
Und für was genau verwendest du event-on-change?

Danke!

Hätte auch Interesse an deiner Lösung

Me2  ;)

Backup brsucht man doch nur die fhem.cfg. nach neuaufsetzen des raspi einfach reinkopieren und starten

Sent from my OPO

Zitat von: satprofi am 27 November 2015, 18:46:26
Backup brsucht man doch nur die fhem.cfg. nach neuaufsetzen des raspi einfach reinkopieren und starten

Sent from my OPO

Klar - und auf die kommenden Fehlermeldungen freuen.

Was ist mit den selbst erstellten Plot-Dateien und eingebundenen cfg`s?
Die soll/kann man vergessen oder wie steht es damit?

Deine Aussage ist allgemein so einfach nur Blödsinn - nur weil du keine selbst erstellten SVG-Files hast heisst das ja noch lange nicht das niemand sowas hat.

Edith: *Grumpf* Da antwortet jemand mit Müll auf einen 1 Monate alten Beitrag und ich geb noch meinen Senf dazu - schade um die Zeit.

Mein RasPi läuft jetzt 14 Monate im Dauerbetrieb mit ein und derselben SD-Karte, eine zweite SD Karte (erstellt mit Win32DiskImager) liegt im Safe ... Ansonsten betreibe ich auf einem NAS eine dokumentierte Versionshaltung meiner SD-Backups.

Zitat von: Puschel74 am 27 November 2015, 19:42:32
Klar - und auf die kommenden Fehlermeldungen freuen.

welche fehlermeldungen?
habe gerade erst eine dockstar gegen raspi ersetzt, fhem.cfg reinkopiert, und gestartet. alles läuft wie vorher auf der DS.
habe fhem nur in der sparversion laufen, keine gimmicks wie Plots etc. , vielleicht liegts daran ? ;-)

Zitat von: satprofi am 28 November 2015, 11:14:28habe fhem nur in der sparversion laufen, keine gimmicks wie Plots etc. , vielleicht liegts daran ? ;-)

Genau daran liegt es. Wahrscheinlich hat sonst jeder mindestens einen Plot oder eine 99_myUtils.pm, irgendeine Komponente, die nicht in der "offiziellen" FHEM Auslieferung ist (wie z.B. Tablet UI oder HM485 Unterstützung), gar ein komplett selbst gestricktes Modul oder einfach nur die fhem.cfg in mehrere Dateien aufgeteilt. Dann soll es auch noch diejenigen geben, die gar keine fhem.cfg haben, da sie die ConfigDB verwenden.
Vielleicht fällt sonst noch jemandem was ein...
Gruß,
   Thorsten

das solche files gesichert sind , sehe ich als selbstverständlich. auch diese braucht man dann nur rüberkopieren.
habe selber einige umgestrickte modulfiles, aber das brauch ich nicht zu erwähnen.

Zitat von: satprofi am 28 November 2015, 11:46:38
das solche files gesichert sind , sehe ich als selbstverständlich. auch diese braucht man dann nur rüberkopieren.
habe selber einige umgestrickte modulfiles, aber das brauch ich nicht zu erwähnen.

"Rüberkopieren" ? und was ist mit den Rechten oder Benutzer und Gruppe (um nur einiges zu nennen)  ?
Wenn das alles so einfach wäre würde niemand mehr eine Imagedatei erstellen.

Zitat von: satprofi am 28 November 2015, 11:46:38
das solche files gesichert sind , sehe ich als selbstverständlich. auch diese braucht man dann nur rüberkopieren.
habe selber einige umgestrickte modulfiles, aber das brauch ich nicht zu erwähnen.

Dann braucht man auch die fhem.cfg nicht erwähnen da diese Datei doch wohl die wichtigste im ganzen System ist (wenn noch nicht auf DB umgestellt wurde).
Aber gut, wer lesen (und das gelesen verstehen) kann ist klar im Vorteil.

Zitat von: Tom111 am 28 November 2015, 11:56:19
"Rüberkopieren" ? und was ist mit den Rechten oder Benutzer und Gruppe (um nur einiges zu nennen)  ?
Wenn das alles so einfach wäre würde niemand mehr eine Imagedatei erstellen.

komisch, bei mir gehts einfach, per ftp. Rechte /user anpassen, das wars.

aber jeder wie er will/mag.
kannst ja auch einmalig ein backup machen, und das auf dem neuen raspi dann einspielen, ist eigentlich selbiges.
oder wer ändert stündlich seine config? ich nur wenn neue devices eingebunden werden.

Zitat von: satprofi am 28 November 2015, 12:08:50aber jeder wie er will/mag.

Genau.
Man sollte nur manchmal bedenken, dass auch Leute mitlesen, denen nicht immer alle Zusammenhänge 100%ig klar sind. Der ein oder andere mag dann denken: Oh, cool. Einfach nur die fhem.cfg sichern, alles plattmachen, neu installieren, fhem.cfg zurückschreiben und schon läuft alles wieder...
Gruß,
   Thorsten

Nicht zu vergessen sind übrigens zusätzliche Pakete, die zur Funktion einiger Module erforderlich sind.   ;)

Was haltet ihr von folgender Idee:

-) SD-Card wird nur zum Booten verwendet.
-) zwei USB Sticks im RAID 1 Betrieb für root

Da es eher unwahrscheinlich ist, dass beide USB Sticks zur exakt gleichen Zeit ausfallen, könnte man einen defekten Stick sogar im laufenden Betrieb wechseln?

Zitat von: chunter1 am 09 Dezember 2015, 09:04:24
Was haltet ihr von folgender Idee:

Gar nichts  ;D

Das ist für den "Otto-Normal-User" viel zu viel Aufwand.
Ich halte eine qualitativ hochwertige SD-Karte in Kombination mit einer "in welcher Form auch immer"-Datensicherung noch immer für den einfachsten und sinnvollsten Weg.

Sehe ich auch so.

Ein RAID1 auf einem Raspi wäre mir zu viel Risiko. Geht der Raspi hin (kommt vor), dann kannst mit den USB-Sticks nichts mehr anfangen.

Ganz generell ersetzt ein RAID aber sowieso NIE ein Backup.

Ich sags mal so... am System per se schraubt man ja nicht ständig. Wenn die Linux-Dienste mal eingerichtet sind (Yowsup, Cups, etc...) kommt da ja nicht täglich was dazu was nicht per apt-get update && apt-get upgrade abzufackeln wäre. Mir persönlich reicht es nach großen Änderungen (z.B. neue Dienste, dist-upgrade) per dd ein neues Image zu ziehen und auf ein Nas zu kopieren. Damit ist das System per se schnell wiederhergestellt. Beim Update macht er bei mir eh ein Backup, die Backups werden per Cron nächtlich auf ein Nas gespiegelt und wöchentlich aufgeräumt. Logs laufen eh aufs Nas.

Im Worst-Case Szenario reicht es das Image zurückzuschreiben und das letzte Backup vom NAS zu kopieren. Verlust? Nur die Daten die wähend der Wiederherstellung einlaufen würden. Passt. Aufwand? Tendiert gegen Null, Backups laufen per Cron, nach einem größeren Systemupdate bin ich eh auf der Konsole und schiebe das neue Image/dd per Script an.

Dass zusätzlich zum RAID ein Backup gemacht werden sollte is ja wohl klar ;)

Anderer Ansatz wäre das komplette filesystem auf der SD-card als "read-only" zu mounten.
Die Log-Dateien werden dann einfach auf z.B. einen USB-Stick geschrieben der kaput werden darf.
Dadurch ist das absolut lästige Problem mit korrupter SD-Card beim spontanten power-off gelöst.

Für Systemupdates kann man das filesystem super-einfach temporär read-writeable "remounten".
Das geht on-the-fly, also ohne reboot.

Anleitung gibts z.B. hier:
https://hallard.me/raspberry-pi-read-only/

Läuft bei mir experimentell schon problemlos - (im dauer ein - aussteck versuch und vorerst ramdisk für log-dateien)  ;)