Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

[ub.privat]

@mickym
@Thomas-Braun

nun scheint es zu funktionieren - manuell!
Alle Datein erscheinen und sind nicht mehr 0kB groß.

Habe in der DB noch einmal das Kennwort neu eingegeben und auf Groß- und Kleinschreibung geachtet.

Jetzt kommt diese Meldung:

[DEBUG] [mysql] - MySql-Backup started ...
[ERROR] [mysql] - [IGNORED] Error: ENOENT: no such file or directory, lstat '/opt/iobroker/backups/mysql_2021_12_14-19_27_16_backupiobroker.sql'

Damit kann ich für heute leben, schaue, ob die automatische Sicherung funktioniert.

Erst einmal allen vielen Dank!

[mickym]

@ub-privat Diese Fehlermeldungen verschwinden von alleine - damit versucht der Backit-Up Adapter ältere Sicherungsdateien zu löschen. Vielleicht hast Du die mit 0 kB selbst gelöscht.

[simatec]

@ub-privat sorry ich kann dir keinen Support hier bieten und bitte nicht hier im test Thread posten.
Du hast an dem Code von Backitup Änderungen vorgenommen und das kann hier keiner supporten.

Des Weiteren bitte ich dich sentry abzuschalten, da ich ein Haufen Fehler deiner Code Basteleien im Sentry gemeldet bekomme.

Danke für dein Verständnis

[ub.privat]

@simatec

Sorry wenn ich etwas "falsches" getan habe. Wenn dann definitiv unbewußt und mangelnder Kenntnisse.
Die Frage sei erlaubt - Sentry abschalten? Ich bin mir gar nicht bewußt am Code gebastelt zu haben und wo schalte ich Sentry ab!?
Ich bin eher blutiger Anfänger, der versucht sich Dinge zu erlesen.

Nochmals sorry, war definitv keine böse Absicht!

[ub.privat]

@mickym

Du hast Recht, habe die 0kB Datein manuell gelöscht. Nochmals Danke für die Hilfe. Wieder viel gelernt!

[simatec]

@ub-privat hmmm also in deinen Postings waren Debuglogs, die in der offiziellen Version nicht vorhanden sind.

Wenn du keine Version aus dem Github aus irgendwelchen Forks installier hast, wundert mich das sehr

[ub.privat]

@simatec

ich habe ganz normal den Adapter installiert und regelmäßig geupdatet. Sowie alle Adatpter und die iobroker Grundlagen.
Ganz ehrlich, ich bin froh das es so läuft. Von anderen Quellen lasse ich schon aus Unwissenheit die Finger...

Also wie gesagt, es ist der offizielle Adapter, nix dran herum gebastelt oder gar 'optimiert'.

[simatec]

@ub-privat Dann nehme ich alles zurück … Irgendwie sahen die Log Meldungen komisch aus und parallel bekam ich im Sentry Fehler-Meldungen, die nicht aus dem Backitup Adapter der offiziellen Repo stammen.

Da Sentry aber Anonym ist, kann ich natürlich nicht nachvollziehen, wer da was bastelt und Sentry dabei nicht ausschaltet.

Konnte dein Problem gelöst werden?

Sonst schreibe bitte nochmal ne kurze Zusammenfassung über dein Problem.

Sind schon wieder zu viele Post dazwischen und einige stehen auf gelöscht.

[ub.privat]

@simatec

JA, meine "Probleme" wurden Dank der Hilfe von @Thomas-Braun und @mickym gelöst.
Backups wurden erfolgreich automatisiert erstellt! Alles iO.

[simatec]

@ub-privat Sehr gut ... dann viel Spaß mit iobroker

[skokarl]

@simatec

Hi Simatec, ich hab jetzt hier nicht alles durchgelesen, aber eine kurze Frage mal bitte.
Ich fange gerade mit Node Red an, versuche mich mal daran, und macht auch höllisch Spass.

Werden beim backup eigentlich die erstellten Flows auch mitgesichert ?

Danke und Gruß

[simatec]

@skokarl Wenn die mit in den iobroker Objects und States enthalten sind, dann ja.
Kann ich dir aber ehrlich gesagt nicht genau beantworten.

Dafür müsste ich mir mal den Node Red Adapter anschauen.

[mickym]

@simatec die Datei flows.json muss gesichert werden, um die Flows zu sichern.

[simatec]

@mickym Wo liegt die flows.json?

[mickym]

@simatec Direkt unter /opt/iobroker/iobroker-data/node-red
und in allen Unterverzeichnissen (falls mit Projekten gearbeitet wird) unter projects - Verzeichnisname.

Um eine richtige Sicherung zu machen, müsste man diese 4 Dateien sichern:

Die settings.js liegt immer nur dort muss aber beim Zurücksichern an diesen Ort gesichert werden: /opt/iobroker/node_modules/iobroker.node-red/
da bei jedem Neustart von dort die settings.js geholt wird.

Die 3 Dateien, die zu jedem Projekt oder Standard gehören sind diese:

Die flow.json - enthält die eigentlichen Flows und ist die Wichtigste von allen 3.
Die flows_cred.json hab ich noch nie gebraucht - das wird wohl verwendet, wenn man NodeRed mit Authentifizierung nutzt.
Die package.json gibt Abhängigkeiten zu weiter installierten Nodes an - was man wohl versucht hat über den Adapter nachzubilden, wenn man den Palettenmanager nicht nutzt. Das ist aber viel unbequemer und man kann damit auch keine Versionsüberprüfung machen.

Ich nutze also im iobroker lieber weiterhin den Palettenmanager - auch wenn dann die zusätzlich installierten Nodes über den backitup nicht wiederhergestellt werden.

Viel geschickter wäre es gewesen, wenn man statt entweder oder - die 3. Datei package.json mitgesichert hätte und dann bei Wiederherstellung die ganzen Nodes automatisch wieder installiert hätte. Die stehen nämlich unter package.json drin - dann müssen sich die Leute nämlich nicht entscheiden ob sie den Palettenmanager nutzen wollen oder nicht:

Hier mal der Inhalt einer package.json.

{
    "name": "node-red-project",
    "description": "A Node-RED Project",
    "version": "0.0.1",
    "private": true,
    "dependencies": {
        "@mdi/font": "^5.9.55",
        "node-red-contrib-bigtimer": "~2.7.5",
        "node-red-contrib-buffer-parser": "~3.1.7",
        "node-red-contrib-cron-plus": "~1.5.4",
        "node-red-contrib-crypto-js": "~0.1.1",
        "node-red-contrib-fs-ops": "~1.6.0",
        "node-red-contrib-harmony-websocket": "~2.2.6",
        "node-red-contrib-light-scheduler": "0.0.18",
        "node-red-contrib-moment": "~4.0.0",
        "node-red-contrib-tail-file": "~1.2.6",
        "node-red-contrib-ui-contextmenu": "~2.0.1",
        "node-red-contrib-ui-time-scheduler": "~1.16.2",
        "node-red-dashboard": "~3.1.2",
        "node-red-node-email": "~1.12.3",
        "node-red-node-feedparser": "~0.2.1",
        "node-red-node-mysql": "~0.3.0",
        "node-red-node-ping": "~0.3.1",
        "node-red-node-rbe": "~0.5.0",
        "node-red-node-sentiment": "~0.1.6",
        "node-red-node-snmp": "0.0.25",
        "node-red-node-ui-table": "~0.3.11"
    }
}

Wie gesagt die flows.json ist die Wichtigste - die anderen Nodes kann man sich ggf. wieder herstellen. Es müsste halt auf jeden Fall die flow.json auch aus allen projects Unterverzeichnissen gesichert werden.

[mickym]

@skokarl Um jetzt eine Sicherung zu machen, gehst Du einfach in NodeRed unter Export:

und lädst die flows.json so runter - dann musst Du nicht durch das Dateisystem und sicherst die Datei, die dann ja im Downloadverzeichnis Deines Browsers steht - einfach weg.

Wiederherstellen dann einfach mit der Import-Funktion - aber enthält wie gesagt dann den Flow - die zusätzlich installierten Nodes musst Du halt manuell nachinstallieren.

[simatec]

@mickym Laut dem Verzeichnis Pfad müssten die im normalen iobroker Backup enthalten sein.

[mickym]

@simatec sagte in Test Adapter Backitup v2.2.x:

@mickym Laut dem Verzeichnis Pfad müssten die im normalen iobroker Backup enthalten sein.

Ok - dann ist ja alles gut. Das weißt Du besser als ich. Wenn alles unter /opt/iobroker/iobroker-data gesichert wird, dann ist alles dabei.

[keksn]

@simatec Hallo, hast Du eine Tip für mich warum es beim restore von influxdb zu diesem Fehler kommt.

Ich habe zwar irgendwann mal. im Forum darüber gelesen aber kam damals auch zu keinem Ergebnis.

Error: {"errno":-1,"code":"EPERM","syscall":"utime","path":"/opt/iobroker/backups/influxDBtmp/"}

Danke!

[simatec]

@keksn Dein NAS User hat nicht alle benötigen Rechte
Er muss auch Rechte für Unterordner bekommen.
Alternativ kannst du das Backup auch lokal ablegen (via SFTP) und dann lokal herstellen.

Was hast du denn für ein NAS?