NEWS
Mini-HowTo: Cannot find view "system" for search "host"
-
@apollon77 Da hast du natürlich recht. Gefühlt tauchen hier aber ständig Personen mit eben diesem Problem auf.
Klar, der Host muss stabil laufen.@bananajoe sagte in Mini-HowTo: Cannot find view "system" for search "host":
Gefühlt tauchen hier aber ständig Personen mit eben diesem Problem auf.
und da fragen wir uns, wieso diese User immer wieder "Stromausfall" haben. und das mehrfach
-
@apollon77 Da hast du natürlich recht. Gefühlt tauchen hier aber ständig Personen mit eben diesem Problem auf.
Klar, der Host muss stabil laufen.@bananajoe Und wie gesagt - alle diese hatten bisher js-controller 3.2 am Start der hier (zugegeben) Buggy war
-
@bananajoe Und wie gesagt - alle diese hatten bisher js-controller 3.2 am Start der hier (zugegeben) Buggy war
Ich bekomme nach dem Befehl aus dem 1. Post folgendes zu sehen.
-rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:54 2022-02-11_14-54_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:55 2022-02-11_14-55_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:56 2022-02-11_14-56_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:57 2022-02-11_14-57_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:58 2022-02-11_14-58_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:59 2022-02-11_14-59_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:00 2022-02-11_15-00_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:01 2022-02-11_15-01_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:02 2022-02-11_15-02_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:03 2022-02-11_15-03_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:04 2022-02-11_15-04_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:05 2022-02-11_15-05_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:06 2022-02-11_15-06_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:07 2022-02-11_15-07_objects.json.gzobjects ist in rot geschrieben. Ist da noch was zu retten?
-
Ich bekomme nach dem Befehl aus dem 1. Post folgendes zu sehen.
-rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:54 2022-02-11_14-54_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:55 2022-02-11_14-55_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:56 2022-02-11_14-56_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:57 2022-02-11_14-57_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:58 2022-02-11_14-58_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:59 2022-02-11_14-59_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:00 2022-02-11_15-00_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:01 2022-02-11_15-01_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:02 2022-02-11_15-02_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:03 2022-02-11_15-03_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:04 2022-02-11_15-04_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:05 2022-02-11_15-05_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:06 2022-02-11_15-06_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:07 2022-02-11_15-07_objects.json.gzobjects ist in rot geschrieben. Ist da noch was zu retten?
1,1K dürfte zu klein sein. Da ist nur das Fragment drin.
-
Ich bekomme nach dem Befehl aus dem 1. Post folgendes zu sehen.
-rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:54 2022-02-11_14-54_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:55 2022-02-11_14-55_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:56 2022-02-11_14-56_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:57 2022-02-11_14-57_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:58 2022-02-11_14-58_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 14:59 2022-02-11_14-59_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:00 2022-02-11_15-00_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:01 2022-02-11_15-01_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:02 2022-02-11_15-02_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:03 2022-02-11_15-03_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:04 2022-02-11_15-04_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:05 2022-02-11_15-05_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:06 2022-02-11_15-06_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1,1K Feb 11 15:07 2022-02-11_15-07_objects.json.gzobjects ist in rot geschrieben. Ist da noch was zu retten?
-
1,1K dürfte zu klein sein. Da ist nur das Fragment drin.
@thomas-braun Also keine Chance mehr was zu retten, oder?
-
@thomas-braun Also keine Chance mehr was zu retten, oder?
Nö, da ist keine intakte Version mehr vorhanden.
-
@thomas-braun Also keine Chance mehr was zu retten, oder?
-
@lustig29 Wenn DU kein Backup mehr hast dann blöd. Aber schau af jeden Fall warum da jede Minute ein Backup passiert
@apollon77 Ja, leider kein Backup. Ist der Raspberry meiner Eltern. Wollte den Backup Adapter schon öfters einrichten, immer wieder verschoben...
Jetzt ist der schlimmste Fall eingetroffen. 🤦🏼♂️
Naja, wird mir eine Lehre sein...Die Verbindung über Putty habe ich ja noch. Kann ich den Iobroker jetzt einfach neu installieren, oder muss ich die komplette Karte löschen?
-
@apollon77 Ja, leider kein Backup. Ist der Raspberry meiner Eltern. Wollte den Backup Adapter schon öfters einrichten, immer wieder verschoben...
Jetzt ist der schlimmste Fall eingetroffen. 🤦🏼♂️
Naja, wird mir eine Lehre sein...Die Verbindung über Putty habe ich ja noch. Kann ich den Iobroker jetzt einfach neu installieren, oder muss ich die komplette Karte löschen?
-
@bananajoe Naja die erste Thematik ist: Warum sollte ein Host überhaupt abstürzen? Weiterhin ist es ja so das die 3.2 suboptimal war aber die 3.3 hier klar aufgeräumt hat. Ich kennen keinen einigermaßen normalen Fall wo mit dem js-controller 3.3 so ein Fall aufgetreten ist weil hier mit dem Backup File gearbeitet wird als Fallback.
Der einzige Fall wo es eine 3.3 erwisch hat war etwas weiter oben wo durch crashes seeeehr kurz nacheiander und seeehr kurz nach dem Start am Ende beides Files einen knacks hatten.
Das Hochsetzen des Schreibintervalls verringert die Schreibfrequenz - korrekt ... ABER sorgt auch bei Crashes für einen größeren Datenverlust weil bei einem Crash halt alles seit dem letzten Schreiben "weg" ist ... Also von daher ist das eine Ballance die jeder selbst wissen muss.
Es gibt als Alterative die "jsonl" Datenbank die anders schreibt und so ein Problem bei einzelnen Datensätzen besser verkraftet. Mit js-controller 3.3. ist Sie experimentell nutzbar und im kommenden js-controller 4.0 wird es die neue Standarddatenbank werden.
ABER: Wenn ein Server abstürzt dann hast Du ein anderes Problem :-)
ABER: Wenn ein Server abstürzt dann hast Du ein anderes Problem 🙂
Da hast Du sicherlich recht, aber das Problem habe ich auch.
Das Problem ist immer Stromausfall der hier gelegentlich mal vorkommt.
Es hilft nur ein Restore und danach startet IOB wieder ohne Probleme.
Danach wieder alle Adapter manuell aktivieren...Sowas ist echt ein riesiges Problem wenn man eben nicht mal eben eingreifen kann wie im Urlaub, Dienstreise etc.
Ein Smarthomesystem soll stabil laufen, was KEINE Vorwurf gegen irgendwen ist.
Allerdings wäre es wünschenswert wenn es möglich wäre so etwas abzufangen und zwar da wo das Problem liegt.
Sicherlich ist eine USV ein Punkt den man inbetracht ziehen kann, dennoch sollte man über das Problem ansich
nachdenken.Übrigens ist das auf den Raspberry PI3+ EXT4 Standalone und auch im Master/Slave Modus nie vorgekommen.
Erst nach der Umstellung auf PI4 EXT4 + Slave PI3+ EXT4 hab ich dieses Problem. -
@bavarian sagte in Mini-HowTo: Cannot find view "system" for search "host":
Übrigens ist das auf den Raspberry PI3+ EXT4 Standalone und auch im Master/Slave Modus nie vorgekommen.
Doch, das wäre dort auch vorgekommen, die Bedingungen sind genau die gleichen.
-
ABER: Wenn ein Server abstürzt dann hast Du ein anderes Problem 🙂
Da hast Du sicherlich recht, aber das Problem habe ich auch.
Das Problem ist immer Stromausfall der hier gelegentlich mal vorkommt.
Es hilft nur ein Restore und danach startet IOB wieder ohne Probleme.
Danach wieder alle Adapter manuell aktivieren...Sowas ist echt ein riesiges Problem wenn man eben nicht mal eben eingreifen kann wie im Urlaub, Dienstreise etc.
Ein Smarthomesystem soll stabil laufen, was KEINE Vorwurf gegen irgendwen ist.
Allerdings wäre es wünschenswert wenn es möglich wäre so etwas abzufangen und zwar da wo das Problem liegt.
Sicherlich ist eine USV ein Punkt den man inbetracht ziehen kann, dennoch sollte man über das Problem ansich
nachdenken.Übrigens ist das auf den Raspberry PI3+ EXT4 Standalone und auch im Master/Slave Modus nie vorgekommen.
Erst nach der Umstellung auf PI4 EXT4 + Slave PI3+ EXT4 hab ich dieses Problem.@bavarian dir ist aber schon klar das es Betriebssystemproblem ist.. wenn bei schreibzugriff der strom weg ist.. DANN IST DAS SO
was soll der Host dann machen.. kein grundsatz problem UNSERSEITS. DU musst DAFÜR SORGEN dass die schreibzugriffe bis zu ende laufen ..
da ist eine USV nützlich..
das bekommen WIR nicht in Griff
-
@arteck
Das mit der GROßSCHREIBUNG lass mal sein, sowas ist unfreundlich, gehört sich nicht!
Ich habe extra geschrieben ich will niemanden Angreifen, dann verhalte Dich doch bitte professioneller.Fakt ist, ich betreibe in einem privaten Hobby Projekt Raspberry PI2 und Raspberry PI3+ welche kalt
ausgeschaltet werden weil es anders nicht ging. Dieses Projekt läuft bei gut 300 Leuten stabil ohne
dass es jemals zu Problemen kam, das ist Tatsache und keine Geschichte. Natürlich ohne IOB.Die Frage ist doch, warum es mit den PI3+ reproduzierbar eben nicht zu diesen Problemen kam.
Es liegt nicht am PI selbst, soviel ist klar, es liegt am Schreibvorgang während des Stromausfalls.
Hätte man das nicht mit einer Art Schattenkopie lösen können welche im Falle eines Stromausfalls
hätte genommen werden können, X Sekunden / Minuten vor dem unterbrochenen Schreibvorgang?
Ein Vergleich der Aktuellen Datei / DB und einer Schattenkopie mit passenden Parametern ist
doch problemlos realisierbar.Wie gesagt, es braucht hier keine Hitzige Diskusion und es ist kein Angriff, lediglich eine Objektive
Beobachtung eine Benutzers der nicht ganz unbedarft im Umgang mit der Technik ist. -
ABER: Wenn ein Server abstürzt dann hast Du ein anderes Problem 🙂
Da hast Du sicherlich recht, aber das Problem habe ich auch.
Das Problem ist immer Stromausfall der hier gelegentlich mal vorkommt.
Es hilft nur ein Restore und danach startet IOB wieder ohne Probleme.
Danach wieder alle Adapter manuell aktivieren...Sowas ist echt ein riesiges Problem wenn man eben nicht mal eben eingreifen kann wie im Urlaub, Dienstreise etc.
Ein Smarthomesystem soll stabil laufen, was KEINE Vorwurf gegen irgendwen ist.
Allerdings wäre es wünschenswert wenn es möglich wäre so etwas abzufangen und zwar da wo das Problem liegt.
Sicherlich ist eine USV ein Punkt den man inbetracht ziehen kann, dennoch sollte man über das Problem ansich
nachdenken.Übrigens ist das auf den Raspberry PI3+ EXT4 Standalone und auch im Master/Slave Modus nie vorgekommen.
Erst nach der Umstellung auf PI4 EXT4 + Slave PI3+ EXT4 hab ich dieses Problem.@bavarian Jetzt müssen wir das mal strukturiert auseinandernehmen (und nein fühle mich nicht angegriffen oder so, alles gut):
1.) Es ist bekannt und in diesem thread mehrfach gesagt worden das der js-controller 3.2 etwas anfällig ist für solche Probleme, aber seit js-controller 3.3 das Problem an sich nicht mehr auftritt - es gab bisher einen berichteten Sonderfall wo nach einem Crash dann beim Start sehr schnell ein weiterer crash passiert ist und durch sehr schlechtes Timing in dem Fall es Probleme gab auch mit Controller 3.3. ... Von daher: Problem bekannt, Lösung ebenfalls ... Damit ist es für mich sehr einfach: Falls Du noch js-controller 3.2 hast dann updaten und dein Problem sollte Geschichte sein. Und mit controller 4 und JSONL als DB sollte das ganze noch unproblematischer werden. Falls Controller 3.3 und es passiert regelmäßig dann würden mich da mal die Logs interessieren ... weil das würde ich gern verstehen wollen.
2.) Wenn du regelmäßige Stromausfälle hast und ein stabiles Smart-Home System brauchst dann investiere in eine USV ... weil mal ehrlich: Zu erwarten das jegliche Software mit harten crashes umgehen kann (und übrigens sei Froh wenn es dir dabei "nur" den ioBroker crasht und nicht das Dateisystem - weil wenn das passiert hast Du viel größere issues) ist etwas utopisch. Das garantiert dir niemand - vor allem wenn Du an Urlaub oder Dienstreisen denkst.
Aus meiner Sicht musst Du entscheiden was Du willst ... und dann das tun was du brauchst um das Ziel zu erreichen. :-) Die Optionen für ein Stabiles System liegen alle auf dem Tisch liegen
-
@arteck
Das mit der GROßSCHREIBUNG lass mal sein, sowas ist unfreundlich, gehört sich nicht!
Ich habe extra geschrieben ich will niemanden Angreifen, dann verhalte Dich doch bitte professioneller.Fakt ist, ich betreibe in einem privaten Hobby Projekt Raspberry PI2 und Raspberry PI3+ welche kalt
ausgeschaltet werden weil es anders nicht ging. Dieses Projekt läuft bei gut 300 Leuten stabil ohne
dass es jemals zu Problemen kam, das ist Tatsache und keine Geschichte. Natürlich ohne IOB.Die Frage ist doch, warum es mit den PI3+ reproduzierbar eben nicht zu diesen Problemen kam.
Es liegt nicht am PI selbst, soviel ist klar, es liegt am Schreibvorgang während des Stromausfalls.
Hätte man das nicht mit einer Art Schattenkopie lösen können welche im Falle eines Stromausfalls
hätte genommen werden können, X Sekunden / Minuten vor dem unterbrochenen Schreibvorgang?
Ein Vergleich der Aktuellen Datei / DB und einer Schattenkopie mit passenden Parametern ist
doch problemlos realisierbar.Wie gesagt, es braucht hier keine Hitzige Diskusion und es ist kein Angriff, lediglich eine Objektive
Beobachtung eine Benutzers der nicht ganz unbedarft im Umgang mit der Technik ist.@bavarian sagte in Mini-HowTo: Cannot find view "system" for search "host":
Fakt ist, ich betreibe in einem privaten Hobby Projekt Raspberry PI2 und Raspberry PI3+ welche kalt
ausgeschaltet werden weil es anders nicht ging. Dieses Projekt läuft bei gut 300 Leuten stabil ohne
dass es jemals zu Problemen kam, das ist Tatsache und keine Geschichte. Natürlich ohne IOB.Interessehalber: Und wie stellst Du das sicher das es nicht die SD Karte bzw das Dateisystem dabei zerreisst? Ja sowas kann man "bauen" mit nem Read only Filesystem als eigene Partition für den Statischen Teil und RAM Disks für den dynamischen Teil mit regelmäßigem Sync auf die Karte und damit "seltene kleine Zeitfenster" oder anderen aufwändigen Konstruktionen. Und ja wenn das einzig Dynamische Logfiles sind geht das ggf auch so ...
Wenn Du sowas nicht machst und das ein Standard SD image mit einer partition ist wo alles läuft dann haben die 300 User bisher in meinen Augen und meinen Erfahrungen nach großes Glück gehabt :-)
-
@arteck
Das mit der GROßSCHREIBUNG lass mal sein, sowas ist unfreundlich, gehört sich nicht!
Ich habe extra geschrieben ich will niemanden Angreifen, dann verhalte Dich doch bitte professioneller.Fakt ist, ich betreibe in einem privaten Hobby Projekt Raspberry PI2 und Raspberry PI3+ welche kalt
ausgeschaltet werden weil es anders nicht ging. Dieses Projekt läuft bei gut 300 Leuten stabil ohne
dass es jemals zu Problemen kam, das ist Tatsache und keine Geschichte. Natürlich ohne IOB.Die Frage ist doch, warum es mit den PI3+ reproduzierbar eben nicht zu diesen Problemen kam.
Es liegt nicht am PI selbst, soviel ist klar, es liegt am Schreibvorgang während des Stromausfalls.
Hätte man das nicht mit einer Art Schattenkopie lösen können welche im Falle eines Stromausfalls
hätte genommen werden können, X Sekunden / Minuten vor dem unterbrochenen Schreibvorgang?
Ein Vergleich der Aktuellen Datei / DB und einer Schattenkopie mit passenden Parametern ist
doch problemlos realisierbar.Wie gesagt, es braucht hier keine Hitzige Diskusion und es ist kein Angriff, lediglich eine Objektive
Beobachtung eine Benutzers der nicht ganz unbedarft im Umgang mit der Technik ist.@bavarian wow moment.. die Grossschreibung sollte DIR klar machen, dass DU für das laufende System verantworlich bist..
wenn dir Daten flöten gehen was hier der Fall ist bis DU dafür verantwortlich dies zu verhindern (hier mit einer USV)wenn DU selber weisst dass es zur Stromausfällen kommt dann verstehe ich die Aufregung nicht.. DU weisst doch wo das Problem ist und wir haben DIR die Lösung dazu geliefert ..
gefällt dir die Lösung nicht ?? oder wie soll ich das verstehen ??
wenn du schon 300 installationen durchgeführt hast und du so technick affin bist dann verstehe ich es erst recht nicht.. vor allem wenn man ein System an einen anderen User ausliefert sollte dieser so sicher sein wie möglich.. also USV davor (ja grossgeschrieben)
wie schon apollon77 geschrieben hat
Wenn Du sowas nicht machst dann haben die 300 User bisher in meinen Augen und meinen Erfahrungen nach großes Glück gehabt
nochmal ich greife DICH hier nicht an.. ich möchte dir nur aufzeigen dass das was du machst technisch nicht korrekt ist
-
User, die plötzlich nicht mehr in den ioBroker kommen und auf der Kommandozeile auf ein freundliches
iobroker statusso frech begrüßt werden:
iobroker status Cannot read system.config: null (OK when migrating or restoring) Cannot find view "system" for search "host" iobroker is running on this host.können mal folgendes versuchen:
Mit
ls -lh /opt/iobroker/iobroker-data/backup-objects/ | grep objectsbekommt man so etwas in der Art zu sehen:
ls -lh /opt/iobroker/iobroker-data/backup-objects/ total 19240 -rw-rwxr--+ 1 iobroker iobroker 895277 Mar 16 16:23 2021-03-16_16-23_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 113674 Mar 16 16:23 2021-03-16_16-23_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 113571 Mar 16 16:47 2021-03-16_16-47_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 895066 Mar 16 16:48 2021-03-16_16-48_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 112795 Mar 16 16:51 2021-03-16_16-51_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 0 Mar 16 16:53 2021-03-16_16-53_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 3505 Mar 16 16:56 2021-03-16_16-56_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 0 Mar 16 16:56 2021-03-16_16-56_states.json.gz -rw-rwxr--+ 1 iobroker iobroker 3505 Mar 16 16:57 2021-03-16_16-57_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 112864 Mar 16 16:57 2021-03-16_16-57_states.json.gzMan schaut wann zuerst 'auffällige' Dateien mit Dateigröße 0 oder auffälligem Schwund zwischen zwei Dateien auftauchen, wie hier:
-rw-rw-r--+ 1 iobroker iobroker 1681373 Mar 16 18:00 2021-03-16_18-00_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 3504 Mar 16 18:11 2021-03-16_18-11_objects.json.gzund guckt sich die letzten intakten Dateien davor aus. Im Beispiel diese:
-rw-rwxr--+ 1 iobroker iobroker 895066 Mar 16 16:48 2021-03-16_16-48_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 112795 Mar 16 16:51 2021-03-16_16-51_states.json.gzDie gleiche Übung muss ggf. auch für die states-Datenbank durchgeführt werden.
Mit
ls -lh /opt/iobroker/iobroker-data/backup-objects/ | grep statessieht man die, dann weiter wie oben mit den objects schon geschehen.
Mit folgender Befehlsfolge kann man u. U. den ioBroker wieder beleben:
(Bei Verwendung von jsonl ändern sich die Dateinamen entsprechend! Dann also json durch jsonl ersetzen!)iobroker stop cd /opt/iobroker/iobroker-data/ mv objects.json objects.json.old mv states.json states.json.old cd backup-objects/ gunzip -ck INTAKTE_DATEI_objects.json.gz > /opt/iobroker/iobroker-data/objects.json gunzip -ck INTAKTE_DATEI_states.json.gz > /opt/iobroker/iobroker-data/states.json iobroker startINTAKTE_DATEI dabei mit dem zuvor ausgeguckten Dateinamen ersetzen.
Mit freundlicher Empfehlung von @wendy2702
Mich hat nach einem Stromausfall auch erwischt. Mein Master Slave-System will nicht mehr
Master Raspi3
Slave Raspi4
(Die Master/Slave Zuordnung war eigentlich umgekehrt geplant, hat sich aber so "ergeben")Ich habe mit dem Backups-Adapter aktuelle Backups auf meinem NAS (iobroker + javascripts) liegen.
Also kein großes Problem habe ich gehofft.Es sah nach einem Problem auf dem Master auf, da der Slave keine Verbindung bekam.
Habe daher auf dem Raspi3 ein "iobroker restore 0" durchgeführt, dabei wurde unbeabsichtigt eine lokale Version von vor einem Jahr benutzt, (bevor ich auf die NAS-Speicherung umgestellt habe). Es tat sich danach auch etwas, zumindest der admin-adapter lief.
Dann habe ich das aktuelle Backup von NAS in das Raspi3-Backup-Verzeichnis kopiert und wieder "ein iobroker restore 0" durchgeführt. Das lief auch durch. Ich konnte beide iobroker auf beiden Raspis starten und die haben sich wohl auch gefunden.
Es sind nun aber keine Instanzen per "iobroker list instances" sichtbar.
Auch ein "ps -A | grep iobroker" zeigt keine Ausgabe, obwohl der iobroker angeblich läuft.Ich habe jetzt Angst das ich das weiter verpfusche.
Wie kann ich das Backup sauber einspielen ?Raspi 4
pi@Raspi4:~ $ node -v v12.21.0 pi@Raspi4:~ $ npm -v 6.14.11 pi@Raspi4:~ $ iobroker -version 3.3.22 pi@Raspi4:iobroker status iobroker is running on this host. At least one iobroker host is running. Objects type: file States type: file pi@Raspi4:~ $ ps -A | grep iobroker pi@Raspi4:~ $ ls -lh /opt/iobroker/iobroker-data/backup-objects/ | grep objects .. -rw-rwxr--+ 1 iobroker iobroker 604K Mar 15 2021 2021-03-15_23-29_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 539K Mar 16 2021 2021-03-16_21-30_objects.json.gz pi@Raspi4:~ $ iobroker list instances + instance is alive pi@Raspi4:~ $Raspi 3
pi@Raspi3:/opt/iobroker $ node -v v12.20.1 pi@Raspi3:/opt/iobroker $ npm -v 6.14.10 pi@Raspi3:/opt/iobroker $ iobroker status iobroker is running on this host. Objects type: file States type: file pi@Raspi3:/opt/iobroker $ sudo iobroker list instances + instance is alive pi@Raspi3:/opt/iobroker $ ps -A | grep iobroker pi@Raspi3: pi@Raspi3:/opt/iobroker $ ls -lh /opt/iobroker/iobroker-data/backup-objects/ | grep objects -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 02:33 2022-03-13_02-33_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 04:34 2022-03-13_04-34_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 06:35 2022-03-13_06-34_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 08:35 2022-03-13_08-35_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.1K Mar 13 10:17 2022-03-13_10-17_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.1K Mar 13 10:18 2022-03-13_10-18_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.1K Mar 13 11:02 2022-03-13_11-02_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:03 2022-03-13_11-03_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:04 2022-03-13_11-04_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:05 2022-03-13_11-05_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:06 2022-03-13_11-06_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:07 2022-03-13_11-07_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.9K Mar 13 11:08 2022-03-13_11-08_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.9K Mar 13 11:09 2022-03-13_11-09_objects.json.gz .... -rw-rw-r--+ 1 iobroker iobroker 1.9K Mar 13 12:05 2022-03-13_12-05_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 27K Mar 13 12:06 2022-03-13_12-06_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.8M Mar 13 12:16 2022-03-13_12-16_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.8M Mar 13 12:22 2022-03-13_12-22_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:28 2022-03-13_12-28_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:44 2022-03-13_12-44_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:45 2022-03-13_12-45_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:48 2022-03-13_12-48_objects.json.gzUpdate: Im Raspi4 (Slave) Backup-Verzeichnis liegen die neuesten Backups, weil dort der Adapter läuft.
Dort kann das "iobroker restore 0" nicht starten.pi@Raspi4:~ $ iobroker restore 0 Stop iobroker first! pi@Raspi4:~ $ iobroker stop pi@Raspi4:~ $ iobroker restore 0 Stop iobroker first! ### => (iobroker auf Master gestoppt) pi@Raspi4:~ $ iobroker restore 0 No connection to databases possible ... pi@Raspi4:~ $ -
Mich hat nach einem Stromausfall auch erwischt. Mein Master Slave-System will nicht mehr
Master Raspi3
Slave Raspi4
(Die Master/Slave Zuordnung war eigentlich umgekehrt geplant, hat sich aber so "ergeben")Ich habe mit dem Backups-Adapter aktuelle Backups auf meinem NAS (iobroker + javascripts) liegen.
Also kein großes Problem habe ich gehofft.Es sah nach einem Problem auf dem Master auf, da der Slave keine Verbindung bekam.
Habe daher auf dem Raspi3 ein "iobroker restore 0" durchgeführt, dabei wurde unbeabsichtigt eine lokale Version von vor einem Jahr benutzt, (bevor ich auf die NAS-Speicherung umgestellt habe). Es tat sich danach auch etwas, zumindest der admin-adapter lief.
Dann habe ich das aktuelle Backup von NAS in das Raspi3-Backup-Verzeichnis kopiert und wieder "ein iobroker restore 0" durchgeführt. Das lief auch durch. Ich konnte beide iobroker auf beiden Raspis starten und die haben sich wohl auch gefunden.
Es sind nun aber keine Instanzen per "iobroker list instances" sichtbar.
Auch ein "ps -A | grep iobroker" zeigt keine Ausgabe, obwohl der iobroker angeblich läuft.Ich habe jetzt Angst das ich das weiter verpfusche.
Wie kann ich das Backup sauber einspielen ?Raspi 4
pi@Raspi4:~ $ node -v v12.21.0 pi@Raspi4:~ $ npm -v 6.14.11 pi@Raspi4:~ $ iobroker -version 3.3.22 pi@Raspi4:iobroker status iobroker is running on this host. At least one iobroker host is running. Objects type: file States type: file pi@Raspi4:~ $ ps -A | grep iobroker pi@Raspi4:~ $ ls -lh /opt/iobroker/iobroker-data/backup-objects/ | grep objects .. -rw-rwxr--+ 1 iobroker iobroker 604K Mar 15 2021 2021-03-15_23-29_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 539K Mar 16 2021 2021-03-16_21-30_objects.json.gz pi@Raspi4:~ $ iobroker list instances + instance is alive pi@Raspi4:~ $Raspi 3
pi@Raspi3:/opt/iobroker $ node -v v12.20.1 pi@Raspi3:/opt/iobroker $ npm -v 6.14.10 pi@Raspi3:/opt/iobroker $ iobroker status iobroker is running on this host. Objects type: file States type: file pi@Raspi3:/opt/iobroker $ sudo iobroker list instances + instance is alive pi@Raspi3:/opt/iobroker $ ps -A | grep iobroker pi@Raspi3: pi@Raspi3:/opt/iobroker $ ls -lh /opt/iobroker/iobroker-data/backup-objects/ | grep objects -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 02:33 2022-03-13_02-33_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 04:34 2022-03-13_04-34_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 06:35 2022-03-13_06-34_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 2.1M Mar 13 08:35 2022-03-13_08-35_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.1K Mar 13 10:17 2022-03-13_10-17_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.1K Mar 13 10:18 2022-03-13_10-18_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.1K Mar 13 11:02 2022-03-13_11-02_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:03 2022-03-13_11-03_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:04 2022-03-13_11-04_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:05 2022-03-13_11-05_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:06 2022-03-13_11-06_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.2K Mar 13 11:07 2022-03-13_11-07_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.9K Mar 13 11:08 2022-03-13_11-08_objects.json.gz -rw-rwxr--+ 1 iobroker iobroker 1.9K Mar 13 11:09 2022-03-13_11-09_objects.json.gz .... -rw-rw-r--+ 1 iobroker iobroker 1.9K Mar 13 12:05 2022-03-13_12-05_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 27K Mar 13 12:06 2022-03-13_12-06_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.8M Mar 13 12:16 2022-03-13_12-16_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.8M Mar 13 12:22 2022-03-13_12-22_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:28 2022-03-13_12-28_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:44 2022-03-13_12-44_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:45 2022-03-13_12-45_objects.json.gz -rw-rw-r--+ 1 iobroker iobroker 1.4M Mar 13 12:48 2022-03-13_12-48_objects.json.gzUpdate: Im Raspi4 (Slave) Backup-Verzeichnis liegen die neuesten Backups, weil dort der Adapter läuft.
Dort kann das "iobroker restore 0" nicht starten.pi@Raspi4:~ $ iobroker restore 0 Stop iobroker first! pi@Raspi4:~ $ iobroker stop pi@Raspi4:~ $ iobroker restore 0 Stop iobroker first! ### => (iobroker auf Master gestoppt) pi@Raspi4:~ $ iobroker restore 0 No connection to databases possible ... pi@Raspi4:~ $@tottbeck Jetzt mal gaaaanz langsam .....
Ein Slave hat faktisch keine eigenen Daten die ein Backup restoren kann ... der Master ist der EINZIGE mit einer DB. EIn Restore auf dem Slave hat keine Ahnung was angerichtet ...
Jetzt müssen wir erstmal rausfinden was bei Dir genau los ist!!
Also fangen wir mit dem Master an ... Es sieht ja so aus also ob du von der DB noch ein Objects-Backup hast von "Mar 13 12:16 2022-03-13_12-16_objects.json.gz" ,mit 1,8MB .... War das vor dem stromausfall? Dann wäre es viel einfacher gewesen einfach dieses File wiederherzustellen anstelle wilf ein Backup zu restoren ...
Hast Du auch noch ein states Backup dort von ungefähr gleicher zeit? Wenn ja. Master (und slave - den am besten eh gestoppt lassen!) stoppen. Dann die objects und states Backups entpacken und ersetzen. Dann Master starten und ins Log schauen ... passt da alles wieder??
Wenn das so ist .. Slave starten ... Dort Log schauen ... wie sieht es da aus?
Was natürlich jetzt sein kann durch deine restores das User-eigene Files von Visus oder so fehlen ... da musste schauen ...
-
@tottbeck Jetzt mal gaaaanz langsam .....
Ein Slave hat faktisch keine eigenen Daten die ein Backup restoren kann ... der Master ist der EINZIGE mit einer DB. EIn Restore auf dem Slave hat keine Ahnung was angerichtet ...
Jetzt müssen wir erstmal rausfinden was bei Dir genau los ist!!
Also fangen wir mit dem Master an ... Es sieht ja so aus also ob du von der DB noch ein Objects-Backup hast von "Mar 13 12:16 2022-03-13_12-16_objects.json.gz" ,mit 1,8MB .... War das vor dem stromausfall? Dann wäre es viel einfacher gewesen einfach dieses File wiederherzustellen anstelle wilf ein Backup zu restoren ...
Hast Du auch noch ein states Backup dort von ungefähr gleicher zeit? Wenn ja. Master (und slave - den am besten eh gestoppt lassen!) stoppen. Dann die objects und states Backups entpacken und ersetzen. Dann Master starten und ins Log schauen ... passt da alles wieder??
Wenn das so ist .. Slave starten ... Dort Log schauen ... wie sieht es da aus?
Was natürlich jetzt sein kann durch deine restores das User-eigene Files von Visus oder so fehlen ... da musste schauen ...
@apollon77
Danke schonmal für die schnelle Reaktion.Ich habe das Backup schon auf dem Master(Raspi) gemacht. Das hat es dann aber eine lokale Version genommen, die ein Jahr alt ist.
Danach habe ich die Sicherung, die der BackitUp-Adapter (der läuft auf dem performanteren Slave-Raspi4 und legt da die lokalen Kopien ab, evtl ist das das Problem) auf meinem NAS ablegt, in den Raspi3 backup-Ordner kopiert und restored. Danach ging aber nichts mehr.Jetzt habe ich wieder den alten Backup eingespielt, das läuft prinzipiell, ist aber ein Jahr alt. Ich habe jetzt versucht ein Restore über den BackitUpAdatper zu machen. Der wird mir zwar als installiert angezeigt (Ver. 2.3.3), aber erscheint nicht unter Instanzen. Um eine neue Instanz kann ich nicht anlegen. (host.Raspi4 Invalid version of "admin". Installed "4.2.1", required ">=5.1.0", obwohl der Admin eigentlich Version 5.3.1 hat.
Der Stromausfall war um ca. 10:00, d.h. die 2.1M-Files waren wohl die vollständigen.
Ich habe nun die objects und states von 8:00 genommen. Damit startet er auch. Durch das alte Backup habe ich mir da aber jetzt etwas durcheinander gebracht.
Ich muss doch jetzt "nur" noch ein aktuelles Backup einspielen können.
761
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge