Haltbarkeit des Raspberry Pi erhöhen

[MichaelO]

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

[Tom111]

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

[Thorsten Pferdekaemper]

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).

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. 

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

[Tom111]

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:

nicht wirklich stiefmütterlich

was ist daran falsch zu verstehen ?

[Thorsten Pferdekaemper]

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.

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 

[Hollo]

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.

[MichaelO]

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

[Dr. Boris Neubert]

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

[MichaelO]

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  ) 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/

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?

[PeMue]

Sorry für die blöde Nachfrage, aber was ist ein LVM?

Hallo,

genau das hätte ich auf gefragt und Wikipedia hat mir da auch nicht viel weitergeholfen.

Gruß PeMue

[Dr. Boris Neubert]

Hallo,

LVM= Logical Volume Management, siehe bitte hier http://www.selflinux.org/selflinux/html/lvm.html und hier 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:

Code Auswählen Erweitern

#!/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

[sceadm]

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/.

[Sunny]

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

[Tedious]

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.

[Bartimaus]

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.