Suche optimalen ioBroker Systemaufbau mittels RaspberryPi

[BananaJoe]

@mickym sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

Also brauch ich hier in keinem Fall über 100 GB Speicherplatz.

Das stimmt. Aber bevor ich 4 Karten mit 16G kaufe und für das gleiche Geld eine 128er kriege würde ich persönlich lieber eine große Karte nehmen.
Alles steht und fällt mit der Qualität der SD-Karten. In meiner Firma haben wir mal als "Überwachungsproxys" ich meine 30 Raspberry Pi's eingesetzt. Alle gleichzeitig gekauft = alle die gleiche SD-Karte. Die sind dann auch alle etwas nach einem Jahr gestorben weil SD-Karte defekt. War halt Pech mit der Qualität - oder wir haben zu viel geschrieben. Leider sieht man den Dinger vorher nicht an wie gut die sich machen - und auch die Markenhersteller haben da mal nicht so gute Chargen.

Inzwischen lege ich, wenn ich viel schreiben muss das alles in eine RAM-Disk (für meine Anwendungen reichen 4MByte, das kann auch ein Pi) und sichere was zu sichern ist dann einmal am Tag auf die SD.

Ganz genau genommen würde ich es noch anders machen: Raspi 4 mit 8GB, ESXi ARM-Edition drauf und Backup der ganzen VM (habe ich, allerdings nicht mit ioBroker, schon am laufen). Ich steh prinzipiell auf virtuelle Maschinen und deren Backup. Und das ich ich Snapshots machen kann bevor ich schweinereien wie Upgrades mache.

[Jan1]

@mickym sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

Ich empfehle übrigens entgegen meinen Vorpostern keine großen SD Karten

Das musst aber mal erklären, warum Du das machst, da das gegen die Logik geht die dahinter steckt
Jede Zelle hat ein max. an Schreibzyklen und auch ein Lesezugriff kann sich auf benachbarte Zellen negativ auswirken. Somit hast bei ner 32er schon mal doppelt soviel Reserve wie bei einer 16er und der Preis ist auch nicht wirklich mehr. Es macht also überhaupt kein Sinn eine 16er zu verwenden.

[Homoran]

@matzeit
was willst du da für einen Riesenaufwand treiben?
einfach ein regelmäßiges Backup mit backitup machen und gut ist.

im worst case setzt du in 15-30 Minuten ein flammneues aktuelles System auf und spiels das Backup zurück.

Dein größtes "Problem" dürfte der

@matzeit sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

Pi 2

mit nur 1GB RAM sein.

Da kann es schon mal zu Speichermangel kommen, was erst zum Swapping und damit zu erheblichen Schreibzugriffen, führt und irgendwann greift der OOM-Reaper sich irgendwelche Prozesse und killt diese.

Während des Swappings, bei dem Inhalte, die eigentlich im RAM liegen sollten, auf die Karte geschrieben werden, ist das System natürlich noch anfälliger auf Abstürze.
Wenn dann noch ein zu schwaches Netzteil - insbesondere wenn noch

@matzeit sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

deconz zigbee Stick
Stick für enocean

am RasPi hängen dazu kommt. kann dies zu undervoltage führen, was zum plötzlichen Reboot führt.

[Jan1]

@homoran
Da will einer eben von Beginn an alles richtig machen und wählt ein Pi2 dafür

[mickym]

@jan1 sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

@mickym sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

Ich empfehle übrigens entgegen meinen Vorpostern keine großen SD Karten

Das musst aber mal erklären, warum Du das machst, da das gegen die Logik geht die dahinter steckt

Ich dachte eigentlich, dass ich das mit meinem 1. erklärt hätte.

Ich mache mit dem backitup Adapter meine backups. Das /opt/iobroker/backups Verzeichnis ist auf den USB Stick gelinkt.

Ein Image der SD Karte mache ich nicht regelmäßig, sondern nur vor größeren Updates oder kritischen Adapterupdates.
Das dauert bei 16Gb ca. 5-10 Minuten.
Ein Schreiben eines Images kann aber auch schon mal 30-40 Minunten dauern.

Schon bei einer 32 GB Karte würden sich die Zeiten verdoppeln. Also dass das überhaupt keinen Sinn macht, bestreite ich deshalb auf das Heftigste.

Dann gibt es noch einen weiteren Vorteil. Falls der Platz mal wirklich zu eng werden soll kann ich das Image einer 16GB Karte leicht auf eine 32GB Karte schreiben und dann die Partition vergrößern - umgekehrt get das nicht.

Ich habe auch keine SWAP Datei um überflüssiges Schreiben zu unterbinden und auch mit 4GB RAM alles ausreichend.

Der Preis von 5-10 € - egal ob 16GB oder 32 GB das ist doch kein Argument. Das ist eine Pizza oder was weiß ich. Natürlich bekommst Du im Verhältnis mehr GB pro € - aber das ist doch nicht das Ziel.

Von mir aus könnte die SD Karte jeden Monat kaputt (was sie ja nicht tun) gehen, aber die 5 € sollten dann drin sein. Und wenn sie nach allgemeiner Erfahrung nach ca 1,5 Jahren kaputt gehen - 5€ ???? Da gibts aber kostspieligere Hobbies.
EDIT:
Und für den Preis einer externen SSD kann ich wahrscheinlich einiges SD Karten kaufen, da könnte man mal überprüfen, was eher kaputt geht - die SSD oder der Vorat meiner SD Karten.

[Homoran]

@mickym das sollten wir mal in aller Ruhe bei einigen Bierchen diskutieren

Ich stehe auch zu der Aussage, dass eine größere Karte immer besser ist als eine kleine

Ein komplettes Image einer SD Karte halte ich sowieso für Blödsinn.
Alleine schon weil mit den üblichen Verdächtigen wie Win32Diskimager oder Balena Etcher (also für "Normal"-User) das "Backup" nur 1 Byte größer sein muss als die zu bespielende Karte (die Varianzen bei angeblich gleich großen Karten sind erheblich!), damit es nicht mehr auf eine "gleich" große Karte passt

[mickym]

@homoran Na bei einem Bierchen bin ich immer dabei -

und ja ich nutze den Win32Diskimager und habe bislang noch nie ein Problem gehabt, ein Image wieder zurückzuspielen.

Dabei fällt mir aber noch ein Vorteil für die kleineren Karten ein. Ich würde ja sonst doppelt soviel Platz auf meiner Windows Maschine verbrauchen, wenn ich größere Images hätte.

[Homoran]

@mickym sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

habe bislang noch nie ein Problem gehabt, ein Image wieder zurückzuspielen.

Da hast du dann wirklich Glück gehabt!
(oder die Qualität der Karten hat sich verbessert)

@mickym sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

ch würde ja sonst doppelt soviel Platz auf meiner Windows Maschine verbrauchen, wenn ich größere Images hätte.

das ist korrekt, aber IMHO kein echter Grund, wenn man auf Sicherheit des ioBroker-Servers bedacht ist.

Aber wie ich bereits schrob, halte ich auch ein normales Backup und im Fall der Fälle eine saubere Neuinstallation für die beste Option

[mickym]

@homoran sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

Aber wie ich bereits schrob, halte ich auch ein normales Backup und im Fall der Fälle eine saubere Neuinstallation für die beste Option

Da hast Du schon Recht. Ich oute mich hier auch, dass ich leider bei meinem System nicht alles immer sauber dokumentiert habe.

Und auch bei einem reinen iobroker System gebe ich Dir völlig recht.

aber ...

1. da läuft auch noch ein fhem auf der Maschine
2. da läuft ein mosquitto auf der Maschine
3. da läuft ein mysql auf der Maschine

alleine was mich das an Recherche und Zeit gekostet hat, dass ich das Datenbankverzeichnis auf einen anderen Pfad umzubiegen. Ich habe momentan wirklich Angst, wenn ich das System neu aufbauen müsste. Aber ich habs mir vorgenommen.

Aber ich finde so ein Thread lebt ja davon, dass man unterschiedliche Meinungen austauscht und der TE kann das ja dann für sich einordnen.

Ich will auch keinesfalls sagen, dass andere es genauso machen sollen, aber wollte halt mal meine Argumente kundtun, warum ich es so mache.

Ich hab ja auch einen Monitior an meiner Raspberry als Statusanzeige - schäm

Also kann mein System schon mal für NIEMAND ein Vorbild sein.

[Darth2010]

@matzeit
Ich habe auf meinem Pi ioBroker, Debmatic, mysql und grafana laufen.
Da der Pi4 genug Power dafür hat, möchte ich es auch weiterhin alles auf einem System laufen lassen.

Nachdem mir jedoch dieses Jahr ein fehlerhaftes

apt upgrade

das System komplettt zerschossen hat, hatte ich, als Linux Anfägner, einige Abende zu tuen, um wieder alles zu konfigurieren.
Der ioBroker war das kleineste Problem, da per Backup schnell wieder einsatzbereit, aber die Datenbank und die Homematic Bridge wieder an laufen zu bekommen hat etwas gedauert.

Daher sieht meine Backup-Strategie nun wie folgt aus:

1x pro Woche ein dd Image der SSD
1x pro Tag ein BackitUp Backup (ioBroker + mysql + redis)
1x pro Tag ein Backup des "/home"und "etc"-Verzeichnisses (für die Konfigurationsdateien)

Die Backup landen auf meinem NAS, das nachts per WOL geweckt wird.
Von jedem Backup werden je nach Typ die letzten 14 Versionen aufbewart.

Damit habe ich Fall der Fälle, alles um das System wieder flott zusammenzusetzen.

Gruß
Thomas

[Matzeit]

puh wahnsinn die Diskussion und alle haben irgendwo recht!

ich in Recherchen schon öfters gelesen, dass ein sudo apt upgrade oder sudo apt dist-upgrade sehr sehr heikel ist. Und das ist aktuell mein Aufhänger warum ich hier ein komplettes System sichern möchte. Denn:
Angenommen ich bin auf Geschäftsreise oder im Krankenhaus oder oder und daheim macht das System einen "crash". Dann kann ich meiner Frau einfacher erklären, dass Sie nur die SD Karte wechseln muss.

Aber ich werde auf jedenFall alle eure Tipps beherzigen und versuchen die Schreibzugriffe zu minimieren.
Man glaubt gar nicht wie man sich an einfachste Automatismen gewöhnt (hier: automatisches Nachtlicht) und wenn das mal ausfällt was es heißt da wieder durchzusteigen! Bei mir ists schon paar Jährchen her, dass ich mit Linux usw. zu tun hatte. Und im Alter und mit Familie ists doppelt schwer hier volle Konzentraton zu fahren

[Thomas Braun]

@matzeit sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

sudo apt upgrade oder sudo apt dist-upgrade sehr sehr heikel ist.

Quark. Das ist nur 'sehr sehr heikel' wenn da komische Quellen drin sind.

[Jan1]

@matzeit sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

sudo apt upgrade

Wie machst Du denn ein System Update wenn nicht mit dem Befehl? Ist der 08/15 Linux System Update Befehl dafür

Ein gepflegtes System und dazu zählen regelmäßige Updates ist recht unanfällig, deshalb sind übertriebene Maßnahmen hier eher schlecht als recht. Ich bastle sehr viel an meinem System und habs noch nicht wirklich geschafft es zu killen. Läuft aber auch nicht auf nem Pi und SD Karte. Mein Beelink ist aber auch nicht wirklich viel darüber

[da_Woody]

@mickym sorry, aber speicherplatz auf einer windose ist heutzutage IMHO keine ausrede mehr...
ich mein, mir ist auch noch keine SD gestorben. und ich kenn da bei meinen 3d-druckern keine gnade. da wird nix runtergefahren, raspi wird stromlos gemacht, genauso, wie der rp4 hin und wieder wegen undervoltage mekkert. noch nie ein reboot. (hängen an SP112 USB, der drucker an der schuko) einzig verweigert octoprint ein update von plugins.

[David G.]

Wollt mal kurz berichten wie ich es mit dem
Backup mache (Funktioniert nur unter Raspbian).
Ist zwar auch nicht das Gelbe vom Ei, jedoch für mich sehr praktikabel.

Habe am Raspberry ioBroker, einen Nut-Server und Maria-DB am laufen.
Also 2 Dinge die mit dem iobroker Backup nicht komplett neu eingerichtet werden.

Ich lasse täglich ein Backup mit den Backup-Adapter erstellen (1x auf mein NAS und 1x zu Google).
Zusätzlich erstelle ich ca. einmal im Monat (oder bei Bedarf) ein Backup mit "SD card copier".
Einfach einen Cardreader an den Rasparry, Karte rein und kopieren. Die große der Zielkarte ist vollkommen egal.
SD card copier erreicht man unter der GUI von Raspbian.
Aus diesem Grund habe ich das System mit GUI installiert.
Verbinde mich zum sichern dann mittels VNC zum System.

So habe ich immer ein komplettes fertiges System, wo ich ggf noch das iobroker Backup einspielen kann.

[Homoran]

@matzeit sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

herchen schon öfters gelesen, dass ein sudo apt upgrade oder sudo apt dist-upgrade sehr sehr heikel ist.

wo steht denn so ein Blödsinn?

ist nicht heikler als ein windoof update

[mickym]

@da_woody sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

@mickym sorry, aber speicherplatz auf einer windose ist heutzutage IMHO keine ausrede mehr...
ich mein, mir ist auch noch keine SD gestorben. und ich kenn da bei meinen 3d-druckern keine gnade. da wird nix runtergefahren, raspi wird stromlos gemacht, genauso, wie der rp4 hin und wieder wegen undervoltage mekkert. noch nie ein reboot. (hängen an SP112 USB, der drucker an der schuko) einzig verweigert octoprint ein update von plugins.

Also das sehe ich einfach anders. Es geht mir auch nicht darum, dass eine SD Karte crasht, als vielmehr hier verschiedene Zustände zu sichern, die sind sonst nur mit viel Zeitaufwand wiederherzustellen sind. Und Speicherplatz ist in dem Fall schon ein Thema. Wenn ich trotz 1,5 TB ca. 20 Images von 2 PI s gespeichert habe, dann sind das 320 GB, statt 740 GB. Wenn ich dann noch bedenke, dass ich bei 16 GB und meiner Systemgröße noch 30% zur Verfügung habe, wären das bei 32 GB ca. 400 GB verschwendeter Speicherplatz und das ist sehr wohl ein Argument, wenn man keine lärmendes NAS oder keinen Desktop in seiner Wohnung betreiben will.
Vom Zeit und Energieaufwand ganz zu schweigen. Was das Schreiben und ggf. Wiederherstellen von SD Karten über Images an Zeit kostet habe ich ja unten schon beschrieben und meine ca 1,3 TB auf externen Platten zu sichern kostet mich ca. 6 Std. . Mal abgesehen davon, dass ich dann auf die Hälfte der Images verzichten müsste, meine Platten mehr als voll sind, ist das doch schnell dahin gesagt, dass heute Speicherplatz kein Thema ist.
Trotz aller technischer Weiterentwicklung davon zu reden, dass 400 GB unnütz verbrauchter Speicherplatz kein Thema oder Ausrede ist, halte ich dann auch heutzutage für fraglich bzw. falsch.

Und glaub mir, es gibt so einige „Updates“, die Du nicht mehr so schnell rückgängig bekommst, wo Du froh bist, das System schnell wiederzuhaben. Unabhängig vom iobroker, aber ein neues System aufzubauen und auch nur eine Wiederherstellung aus einer backitup Sicherung dauert ein Vielfaches der Zeit, als ein Image zurückzuspielen.

[Jan1]

@mickym
Du hast recht, wenn Du von ganzen Images der SD Karte ausgehst, aber genau das ist doch das was eigentlich schon overkill ist
Eine komplett Sicherung ist eben etwas viel wenn man bedenkt wie lange das Sichern und wiederherstellen dauert. In der Zeit setzt ich Dir ein sauberes Buster im aktuellsten Zustand auf, bügel das IOBroker Backup drauf und schau Dir bei nem Bierchen bei Deine Restor Versuch zu

[mickym]

@jan1 sagte in Suche optimalen ioBroker Systemaufbau mittels RaspberryPi:

@mickym
Du hast recht, wenn Du von ganzen Images der SD Karte ausgehst, aber genau das ist doch das was eigentlich schon overkill ist
Eine komplett Sicherung ist eben etwas viel wenn man bedenkt wie lange das Sichern und wiederherstellen dauert. In der Zeit setzt ich Dir ein sauberes Buster im aktuellsten Zustand auf, bügel das IOBroker Backup drauf und schau Dir bei nem Bierchen bei Deine Restor Versuch zu

Mal abgesehen, dass eine Wiederherstellung mit dem iobroker Backup, was ich so lese auch mal mehr als 1 Kasten Bier dauern kann ist ja wie ich geschrieben habe nicht nur der ioBroker und das System auf der Karte. Und im Moment heb ich halt verschiedene Zustände auf.

Egal jeder soll das so machen, wie er oder sie es für richtig hält. Allerdings ist mir bei der erhöhten Stabilität der SD Karten hier noch kein wirkliches Argument begegnet, warum ich auf größere SD Karten umsteigen müsste. So wenig sind 16 GB auch nicht, insbesondere auf einem Linuxsystem ohne GUI. Vielleicht sollte ich noch paar Adapter installieren

Wahrscheinlich werde oder bin ich einfach alt🤪

[Jan1]

@mickym
Eben, nur muss man auch sehen was nötig ist und was nicht. Du vertrittst recht hartnäckig die Image Variante (hatte ich zu Beginn auch), aber das ist eben in den meisten Fällen etwas zu viel des Guten.
Ich mach ab und an mal ein komplett IOBroker Restor, einfach um sauber zu sein, wobei das recht flott geht obwohl ich recht viel laufen habe (was für ein Pi eh zu viel wäre um den es hier geht).

Das Argument für ne größere SD habe ich oben schon deutlich beschrieben. Kostet nicht mehr und ich hatte noch nie ein Problem mit ner 32er. OK, davon ein Image ziehen dauert eben wirklich etwas länger. Genau deshalb ist diese Methode auch overkill