Haltbarkeit SD-Karte mit FHEM-Nutzung & Smart-Home?

[NewRasPi]

Ob es sinnvoll ist, Logfiles auf einen USB-Stick (beim Pi) zu schieben, bin ich mir nicht soooo sicher
- USB-Sticks sind von den Speicherzellen schlechter als (gute) SDCards
- Der USB-Bus vom Pi ... ist sehr speziell

Hallo Forum, hallo Wernieman
liegt der "Vorteil" an den Log-Dateien auf einem USB-Stick zu schreiben nicht mehr da, dass dann diese Schreibzugriffe eben nicht auf der SD-Karte durchgeführt werden? Die Hoffnung wäre eben das dieses weniger schreiben die Lebensdauer der SD-Karte sehr verlängert.
Wenn dann der USB-Stick kolabiert ist wenigstens das Raspian und FHEM System noch da.

@ rcmcronny
Meine Backups der SD-Karten sind immer genau so groß wie die gesammte Speichergröße der Karte. Könntest Du bitte mal einen Hinweis geben, wie man diese Image (mit Win32DiskImager) verkleinern kann. Vor allem wäre das auch von Vorteil wenn man eine laut Angaben gleich große SD-Karte (mit einem Byte weniger) doch fürs Rücksichern verwenden kann.
Vielen Dank für Tipps.
MfG NewRasPi

[Jens_B]

Hallo Forum, hallo Wernieman
liegt der "Vorteil" an den Log-Dateien auf einem USB-Stick zu schreiben nicht mehr da, dass dann diese Schreibzugriffe eben nicht auf der SD-Karte durchgeführt werden? Die Hoffnung wäre eben das dieses weniger schreiben die Lebensdauer der SD-Karte sehr verlängert.
Wenn dann der USB-Stick kolabiert ist wenigstens das Raspian und FHEM System noch da.

@ rcmcronny
Meine Backups der SD-Karten sind immer genau so groß wie die gesammte Speichergröße der Karte. Könntest Du bitte mal einen Hinweis geben, wie man diese Image (mit Win32DiskImager) verkleinern kann. Vor allem wäre das auch von Vorteil wenn man eine laut Angaben gleich große SD-Karte (mit einem Byte weniger) doch fürs Rücksichern verwenden kann.
Vielen Dank für Tipps.
MfG NewRasPi

Ich hänge mich mal dran an den Thread:
Ich selber habe 2  x 32GB SD Karten schon seit mehreren Jahren in meinem "FHEM" PI laufen (die nutze ich im Wechsel, einmal im Jahr tausche ich die Karte zurück, nachdem ich das Backup auf die Karte gespielt habe).
Habe so schon von einem PI2 -> PI3 -> PI3+ -> PI4 gewechselt . Immer ohne größere Probleme.
Ich mache wöchentlich eine Sicherung auf mein Netzlaufwerk per script -> https://www.linux-tips-and-tricks.de/de/raspberry/23-pi-erstellt-automatisch-backups-von-sich-selbst-pi-creates-automatic-backups-of-itself/
Die Sicherung erfolgt als komprimiertes tar Archiv. Die Sicherung ist nur so groß wie der benutzte Speicherplatz auf der SD Karte.
Das heißt man könnte theoretisch die Sicherung auf eine kleinere Karte zurückspielen.

Das hat bisher immer Problemlos geklappt. Das zurückspielen des Backups, mache ich an einem anderen laufendem PI (natürlich geht jeder anderer Linux Rechner auch) über folgenden Befehl:
sudo raspiBackup.sh -d /dev/sda /share/raspberry-backups/raspi-fhem-2/raspi-fhem-2-tar-backup-xxxxxxxx-yyyyyy/

(sda ist die SD Karte die später wieder in den PI kommt, ich nutze dazu einen SD->USB Adapter)

Das wars schon...

[Wernieman]

@NewRasPi

Unix mag es gar nicht, wenn eine Device im laufenden System nicht mehr schreibbar ist. Egal ob log oder root. Wenn der SUB-Stick defekt und damit reagiert Dein System nicht, machst Du (wie ich Dich einschätze) einen reboot und wunderst Dich, das "die Kiste" gar nicht mehr hochkommt.

Wie wahrscheinlich ist, das Du dann auf den Stick tippst?

[Dracolein]

Meine Backups der SD-Karten sind immer genau so groß wie die gesammte Speichergröße der Karte. Könntest Du bitte mal einen Hinweis geben, wie man diese Image (mit Win32DiskImager) verkleinern kann. Vor allem wäre das auch von Vorteil wenn man eine laut Angaben gleich große SD-Karte (mit einem Byte weniger) doch fürs Rücksichern verwenden kann.

Da hänge ich mich ebenfalls an diese Frage dran, denn ich bin Samstag GENAU daran gescheitert!
Ursprungs SD-Karte: Sandisk Ultra 32 GB
Ersatzkarte: Sandisk Ultra 32 GB

Bin dann schnell shoppen gewesen und habe eine Sandisk Extreme 32 GB und eine Sandisk Extreme 64 GB erworben, um am Wochenende wenigstens irgendwie weiterzumachen.
Glücklicherweise funktionierte bereits die 32 GB Variante. Dennoch schaute ich zunächst echt doof.

Und ja, ich mache meine Backups bisher auch alle von Hand auf einem anderen Rechner mittels Win32DiskImager und mülle mir mit den Backup-Files  mein NAS unnötig zu.

[Frank_Huber]

falls (gegen die Empfehlung) das Raspbian mit GUI installiert ist gibt es auch den "SD Card Copier",
dieses Programm erstellt eine 1:1 Kopie der SD Karte im laufenden Betrieb.
die Größe spielt dabei keine Rolle. (der verwendete Platz muss halt scho drauf passen)

damit erstelle ich regelmäßig Kopien meiner produktiven Instanzen.
Das tägliche FHEM Backup geht direkt auf den Fileserver.

[rcmcronny]

Ich speichere per NFS per DD und komprimiere dann per xz.  (und natürlich rückwärts dann auch dd von der Linux shell)

Das klappte bisher immer Problemlos und zur not kann man das Image ja auch mounten und Dateien so wiederherstellen, wenn es nötig ist.
Dein Problem, das er Platz zu klein auf ner neuen SD ist, hatte ich noch nie, sollte sich aber mit verkleinern des Dateisystems auch lösen lassen, solange es nicht randvoll mit Daten ist.

Für die VMs nutze ich da ggf auch teilweise mal zerofree als Tool (http://frippery.org/uml/index.html)

Man kann halt nicht eine generelle "Lösung" geben, die immer perfekt arbeitet, oft gibt es so kleine Problemchen, wo man dann halt etwas Wissen braucht um das zu lösen (daher auch kein Genereller Weg leider).

Ronny

[Dracolein]

Machen meine Anstrengungen eigentlich Sinn, FileLog-Device Einträge auf das Nötigste zu reduzieren, wenn gleichzeitig FHEM und Raspbian im Hintergrund werkeln? Das Logfile von FHEM selbst wird doch nahezu permanent geschrieben, oder?

[Waldmensch]

Ein Backup von der ganzen SD Karte zu machen, halte ich für Unsinn. Ich habe ein altes Synology NAS DS213 mit 2 1TB Platten. Das stellt mit ein NFS Share pi_backup zur Verfügung, welches ich per fstab auf allen pi's nach /media/backup mounte. Im Fall von FHEM packe ich dort nachts per cron ein tar Archiv des opt Verzeichnisses hin. Das ganze überschreibe ich nach 2 Tagen. Ich habe also immer ein Backup von gestern und von vorgestern.
Wenn die SD Karte hin ist, nehme ich eine Neue, ziehe mir ein aktuelles Raspbian, bringe alles auf neuesten Stand + fstab Backup Verzeichnis einbinden. Dann entpacke ich das Backup Archiv und FHEM ist wieder da. Am längsten dauert es, eine SD Karte zu besorgen. Der Rest ist in <1h erledigt. Ich habe 8 Pi's für diverse Aufgaben (one device for one job). Das o.g. Prinzip ist für Alle gleich.


Gesendet von iPhone mit Tapatalk

[Prof. Dr. Peter Henning]

Die Aussage,

Ein Backup von der ganzen SD Karte zu machen, halte ich für Unsinn

zeugt von wenig Verständnis. Das mag noch ok sein, wenn nur FHEM als Anwendung läuft. Ich habe auf meinen Raspberrys aber diverse andere Anwendungen, von der Genealogie bis zum Semantic MediaWiki. Dabei ändern sich Dateien durchaus auch an anderen Stellen, es gibt neue Plugins etc. Diesen Wust auf einem neuen Betriebssystem nachzuinstallieren kostet etliche Stunden - es ist daher viel ökonomischer, in regelmäßigen Abständen ein komplettes Image der SD-Karte zu erzeugen, das sich innerhalb von wenigen Minuten auf eine frische Karte schreiben lässt.

LG

pah

[Waldmensch]

Das Problem ist halt das ,,regelmäßig". Jede Nacht ein komplettes Image wegschreiben, nur weil sich wenige Dateien geändert haben, ist nicht sehr effizient. Kann man aber machen.
Bezüglich Raspi als Server für multiple Dienste: ich Rate davon ab. As said, one device one Job. Wenn so ein Raspi abschmiert ist dann erstmal alles lahmgelegt was darauf läuft. Der FHEM ist bei mir der ,,Ausfaller" schlechthin. Da würde ich nie den PiHole, die MariaDB oder den Mosquitto mit draufpacken.
Es gibt sicher viele Wege nach Rom und man muss letztlich für sich den Richtigen finden. Ich habe FHEM seit mehr als 10 Jahren laufen (kann das wirklich sein? ) Nach 2 maligem Komplettverlust der Config, habe ich für mich das Backup des opt Verzeichnisses für diese Raspi Instanz als optimal erkoren.


Gesendet von iPhone mit Tapatalk

[Prof. Dr. Peter Henning]

Alle Datenbanken liegen auf meiner NAS.

LG

pah

[Dracolein]

Kriege ich es als Laie hin, eine Verbindung zu meiner Synology herzustellen, sodass ich FHEM Logfiles dort abspeichern könnte?

Die entsprechende Konfiguration der Synology habe ich bereits gefunden, aber dem Linux Dateisystem beizubringen, wie es den freigegebenen Ordner der Syno mounten soll, bringt mich vermutlich sofort an meine Grenzen

[Waldmensch]

Du musst auf der Synology einen NFS Share freigeben und diesen auf dem Raspi mounten. Zu beidem liefert Google hunderte Treffer
Bsp. https://www.elektronik-kompendium.de/sites/raspberry-pi/2102211.htm

Gesendet von iPhone mit Tapatalk

[NewRasPi]

@NewRasPi

Unix mag es gar nicht, wenn eine Device im laufenden System nicht mehr schreibbar ist. Egal ob log oder root. Wenn der SUB-Stick defekt und damit reagiert Dein System nicht, machst Du (wie ich Dich einschätze) einen reboot und wunderst Dich, das "die Kiste" gar nicht mehr hochkommt.

Wie wahrscheinlich ist, das Du dann auf den Stick tippst?

Hallo @ Wernieman
Danke für Deine Antwort.
Mal so ein Gedankengang von einem Computer-Laien.
Bei so viel Kompetenz hier im Forum, könnte da nicht mal jemand sich Gedanken machen, ob es eine "Fall- Back- Funktion" für FHEM bei den Log Verzeichnis machbar wäre.
Quasi, liebes FHEM mach die Log-Dateien auf den Pfad xy und wenn dieser Pfad nicht verfügbar ist, dann leg die Log-Dateien ins Standartverzeichnis /opt/fhem/log/fhem-2019.log
Bei einem Programm das ohne seine Log-Datei nicht mehr startet wäre das für mich eine super Funktion.
So nebenbei, ich habs über eine ssh Verbindung mit dem Editieren der fhem.cfg auch schon mal geschaft den Pfad wieder zurück zu biegen und damit meinem FHEM wieder Leben eingehaucht.
Nun bin ich gespannt was die Spezialisten dazu meinen.
MfG NewRasPi

[Dracolein]

Du musst auf der Synology einen NFS Share freigeben und diesen auf dem Raspi mounten. Zu beidem liefert Google hunderte Treffer
Bsp. https://www.elektronik-kompendium.de/sites/raspberry-pi/2102211.htm

Gesendet von iPhone mit Tapatalk

Danke, habs inzwischen hinbekommen, recht problemfrei. Morgen teste ich mal, die Logfiles meiner Sensoren dorthin auszulagern.