iob diag - Skript
-
-
Putz den Nikotin-Film mal runter!
-
@thomas-braun @Homoran
Ahhh und ich dachte es liegt an der Auflösung von 3200x1800 -
@mickym
Hier ist der Kram zum iob_diag besser aufgehoben als in dem anderen Thread...Also eigentlich sollte das so aussehen:
Bzw. in CodeTags dann so:
======================= SUMMARY ======================= v.0.0.6 Operatingsystem: Debian GNU/Linux 11 (bullseye) Installation: Native Timezone: Europe/Berlin User-ID: 1000 X-Server: false Pending OS-Updates: 0 Nodejs-Installation: /usr/bin/nodejs v19.0.1 /usr/bin/node v19.0.1 /usr/bin/npm 8.19.2 ioBroker Core: js-controller 4.0.23 admin 6.2.23 Pending iob updates: 0 Active repo(s): beta Objects: 8452 States: 6600 Size of iob-Database: 30M /opt/iobroker/iobroker-data/objects.jsonl 4.5M /opt/iobroker/iobroker-data/states.jsonl ====================== END OF SUMMARY ================== -
OK Lag an mir.
Ich hab den chmod für das Skript nicht eingegeben.
Macht nun genau, was Du sagst. - Also mein Fehler:
======================= SUMMARY ======================= v.0.0.6 Operatingsystem: Debian GNU/Linux 11 (bullseye) Installation: Native Timezone: Europe/Berlin User-ID: 1000 X-Server: true Pending OS-Updates: 0 Nodejs-Installation: /usr/bin/nodejs v16.18.1 /usr/bin/node v16.18.1 /usr/bin/npm 8.19.2 ioBroker Core: js-controller 4.0.23 admin 6.2.23 Pending iob updates: 0 Active repo(s): Stable (default) Objects: 10078 States: 9705 Size of iob-Database: 19M /opt/iobroker/iobroker-data/objects.jsonl 8.0M /opt/iobroker/iobroker-data/states.jsonl ====================== END OF SUMMARY ==================Sorry, sorry. Aber ich hatte den Thread gar nicht auf dem Schirm.
Das mit dem Link kommt nun auch raus:
Show mounted filesystems (real ones only): TARGET SOURCE FSTYPE OPTIONS / /dev/mmcblk0p2 ext4 rw,noatime |-/boot /dev/mmcblk0p1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,flush,errors=remount-ro `-/data /dev/sda ext4 rw,relatime backups directory is linked to a different directorykommt grafisch schöner raus - wollte nur nicht die ganze Ausgabe posten.
auch im Windows- Terminal
Also tut mir leid, wenn ich da einen Schreck verursacht habe.
-
@mickym sagte in iob diag - Skript:
Also tut mir leid, wenn ich da einen Schreck verursacht habe.
Mach sowas NIE NIE NIE WIEDER!!!
-
Und jetzt kannste auch @simatec fragen, ob man so eine Abfrage nach dem Dateityp nicht auch in JavaScript machen kann und dich der BAckitup-Adapter dann nicht mehr 'nervt' mit dem Hinweis auf lokales Speichern. g
-
@thomas-braun Das Problem - was passiert war, dass ich den chmod nicht ausgeführt hatte und deshalb natürlich, das Skript nicht direkt ausführbar war.
Ich hatte das Skript (also mit eigener Shell aufgerufen) also so aufgerufen:
sh ./iob_diagdann scheint das wohl mit den Steuerbefehlen nicht mehr zu funktionieren. Du kannst das sicher besser erklären.
Formatierte Ausgabe funzt auch im Terminalfenster des Debian Desktops. -
@thomas-braun sagte in iob diag - Skript:
Und jetzt kannste auch @simatec fragen, ob man so eine Abfrage nach dem Dateityp nicht auch in JavaScript machen kann und dich der BAckitup-Adapter dann nicht mehr 'nervt' mit dem Hinweis auf lokales Speichern. g
Na ja so schlimm ist das ja nicht - und solange man sowas wegdrücken kann und sich nicht verunsichern lässt, weil man auch nicht alles für bare Münze nimmt, was ein Programm ausspuckt ...
@simatec hätte in meinen Augen mehr am Backup von NodeRed zu tun. Das Issue ist mE viel wichtiger.
-
Das ist klar... Das ist ja bei mir ein Skript für die sog. 'bash'
Bash (auch BASH oder bash), die Bourne-again shell
die ist etwas 'mächtiger' als die 'sh' shell (die originale Bourne shell).
Wenn mein skript einfach nur ausgeführt wird, dann sorgt die allererste Zeile, die sog. 'shebang' dafür, dass das skript in die richtige shell gekippt wird:
#!/bin/bashschüttet den Code also in /bin/bash rein. Wenn du aber explizit sagst, liebe 'sh' shell, führ mal den folgenden Code aus, dann kann die arme kleine Oma da nicht immer was mit anfangen, mit dem neumodischen Zeug und versucht ihr Bestes...
Und dann kommt da sowas rudimentäres wie bei deinem ersten Aufruf ums Eck. -
@mickym Wobei die Aussage bzgl. des lokalen Dateisystems auch bei einem symlink weiterhin richtig ist. Wenn da der Stromausfällt, während die Backup-Datei gerade beackert wird kann die auch über den Jordan gehen. Die Gefahr ist allerdings geringer als bei direktem schreiben in das backups-Verzeichnis.
-
@thomas-braun Ja das habe ich schon mal gehört, dass man die Shell in der 1. Zeile des Skripts angibt. Aber da habe ich natürlich nicht dran gedacht, dass ich das damit außer Kraft gesetzt habe. Aber vielleicht hilft es ja, wenn mancher in Zukunft, der Dein Skript ausführt, den gleichen Fehler wie ich macht.
-
@thomas-braun sagte in iob diag - Skript:
@mickym Wobei die Aussage bzgl. des lokalen Dateisystems auch bei einem symlink weiterhin richtig ist. Wenn da der Stromausfällt, während die Backup-Datei gerade beackert wird kann die auch über den Jordan gehen. Die Gefahr ist allerdings geringer als bei direktem schreiben in das backups-Verzeichnis.
Der Vorteil ist halt auch, wenn ich die SD-karten wechsle (Ich arbeite ja mit Images) - dann habe ich trotzdem immer die aktuellen Backups zur Verfügung.
Und die Gefahr, dass es gerade in den 10 Minuten des backups kaputt geht, ist eher unwahrscheinlich. Allerdings hat der Stick schon manchmal Dateisystemfehler, aber das checke ich halt hin und wieder.Im Prinzip ist das Backup doch immer kaputt, wenn der Strom während des Backups ausfällt - deswegen geht aber nicht gleich das Dateisystem kaputt.
Wichtig ist doch, dass selbst wenn ich ein neues System aufbauen müsste, dass ich mit einem Link/Mount sofort wieder Zugriff auf die Backups habe. -
Wenn der Stick allerdings exklusiv für iob-Backups vorgesehen ist würde ich den direkt nach /opt/iobroker/backups hängen und nicht verlinken.
-
@thomas-braun Nee - da sind auch andere Daten drauf - Also MariaDB, NodeRed Resourcen - also einfach Dinge, die nicht so zeitkritisch sind und aber die SD karte sowohl von den Schreibzugriffen entlastet. Ich bin ja nach wie vor ein Anhänger die root Partition klein zu halten, damit ich meine Images schnell ziehen kann und diese auch nicht so viel Speicherplatz auf den Backup-Medien beanprucht.
Das sind dann die Dinge, warum ich einen Neuaufbau nicht mag, weil man all die Schritte, um die Daten auf anderen Partitionen zu schieben, immer wieder neu machen muss und das ist nicht immer trivial. Hab das auch mit einer influx gemacht - aber ich finde es halt besser, Daten nicht auf der "System-Partition" zu halten. Das war schon immer eine Maxime in meiner "IT-" Karriere oder Erfahrung.
-
@mickym sagte in iob diag - Skript:
weil man all die Schritte, um die Daten auf anderen Partitionen zu schieben,
Eigentlich macht man genau das ja nicht (zumidenst nicht unter Unix/Linux).
Da lege ich den file tree über die Partitionen einfach drüber. Deswegen gibt es ja hier auch nicht sowas wie Laufwerksbuchstaben drüben bei den Fenstern. Da muss ich wissen, ach, das liegt ja auf dem XYZ-Laufwerk, stimmt ja.
Bei einem 'file tree' ist das wurscht, da kippe ich immer in den gleichen Pfad, es ändert sich ggf. nur die Hardware unten drunter. -
@thomas-braun sagte in iob diag - Skript:
Bei einem 'file tree' ist da wurscht, da kippe ich immer in den gleichen Pfad, es ändert sich ggf. nur die Hardware untendrunter.
Na ja - das ist ja auch gut und ich mag das ja auch alles unter einem Baum zu haben. So sind halt alle meine Daten bei mir unter /data und das ist halt ein externer Datenträger und belastet somit die Systempartition nicht.
Die /var/xx directories auf externe Datenträger zu verlinken, in das die Programme oft standardmäßig ihre Daten reinschreiben, das mag ich halt nicht, weil da halt auch viele systemrelevante Daten und Logs liegen.
-
Ich weiß ja nicht wie groß der Stick ist, aber ich würde den in entsprechende Partitionen einteilen und die dann an passender Stelle einhängen.
- Partition für /wo/auch/immer/mariadb-daten liegen
- Partition für /wo/auch/immer/node-red/sein/zeug/hinwirft
- Partionen für /opt/iobroker/backups
Dann brauchste nur die /etc/fstab sichern und hast direkt wieder den Lageplan wie das alles zusammengehört. Muss man sich nur einmal überlegen.
-
@thomas-braun Ok ja das ist auch ein Lösung. Allerdings haben verschiedene Partitionen auch den Nachteil, dass Du halt den Speicherplatz sehr genau planen musst. So teilen sich die verschiedenen Systeme, den Platz dynamisch. (Natürlich können sich dann die verschiedenen Systeme auch gegenseitig negativ beeinflussen.
)Aber das wird etwas philosophisch.
Aber wichtig bleibt, dass die Daten den Systemdatenträger nicht belasten. Wir kennen doch beide Kandidaten, dessen Backups die Systempartition so zugemüllt haben, dass das System bald nicht mehr hochgekommen ist. Jedenfalls kann mir das nicht passieren. Aber ich hab auch nicht alle Daten ausgelagert. Die Objekte und States des iob sind ja weiterhin auf dem Systemdatenträger.
Im Moment siehst ja wie die Auslastung der Datenträger ist:
*** FILESYSTEM *** Filesystem Type Size Used Avail Use% Mounted on /dev/root ext4 14G 9.3G 4.0G 71% / /dev/mmcblk0p1 vfat 253M 31M 222M 13% /boot /dev/sda ext4 29G 3.6G 24G 14% /dataIch nutze die Datenbanken im Moment auch nicht richtig - geschweige denn produktiv. Das steht noch auf meiner Agenda, aber da muss ich noch bissi lernen und die Frage ist halt auch immer, was man mit diesen Graphen und Daten macht. Zieht man daraus wirklich Schlußfolgerungen oder freut man sich nur an dem Zick-Zack.
Ich glaube aber - wir diskutieren hier - an dem Threadthema etwas vorbei.
- Aber man kann ja mal so einen allgemeinen Diskussionsthread machen, um verschiedene Ansichten auszutauschen. Ich weiß, wir sind da nicht immer einer Meinung. -
https://de.wikipedia.org/wiki/Logical_Volume_Manager
Da biste dann auch aus den Partitionsgrößen raus. Spielt dann nämlich keine Rolle mehr. Gut, bei einem USB-Stick wäre das mit einem Schlachtschiff auf Spatzen geschossen...
