UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[fila612]

@simatec said in Test Adapter Backitup v2.0.x:

chmod 755 /opt/iobroker/backups

Danke dir,
ich habs jetzt zumindest teilweise hinbekommen.

Also die chwon bzw. chmod Befehle schienen wirkungslos zu sein, da sich der Benutzt immer noch root war.
ich hab dann versucht als root benutzter (sudo -i) den Besitzer zu ändern, leider auch erfolglos.
dann versuchte ich den Ordner zu löschen (rm -f): auch nicht möglich aber jetzt erhielt ich zumindest eine Fehlermeldung (device busy).

Dann habe ich den RPi komplett neugestartet (sudo reboot) und dann waren auf einmal die Anzeige wie folgt:

Vorher waren alle Sicherungsdaten ersichtlich, jetzt nur die lokalen.
=> Alle Sicherungsdaten: ich sicherer auf einem NAS und diese wurden mir auch im Terminal angezeigt. Vermute daher, dass der mount nicht aktiv war (siehe oben Fehlermeldung: device busy).

Wo ich grad noch einen Knoten im Kopf habe:
Der NAS mount klappt bei mir nur wenn ich den Haken bei "als root mounten" setze. Ich vermute das die Daten deshalb als root anzeigt werden. Ich bräuchte den root nicht, jedoch erhalte ich beim Mount folgende Fehlermeldung wenn ich den Haken entferne:

backitup.0	2021-03-08 12:25:41.849	error	(2621) Error: Command failed: mount -t cifs -o username=iobroker,password=****,rw,file_mode=0777,dir_mode=0777 //10.10.10.100/home/backitup /opt/iobroker/backups mount: only root can use "--options" o

[Thomas Braun]

@fila612 sagte in Test Adapter Backitup v2.0.x:

Das ist richtig, nur root (bzw. ein user mit sudo-Recht) darf mit zusätzlichen Optionen Dateisysteme einhängen.
Durch die Optionen

file_mode=0777,dir_mode=0777

kann aber dann jeder 'Hinz-und-Kunz'-user dort reinschreiben.
Deswegen sollten da dann auch keine Dateien drin liegen die root gehören, der Backupprozess läuft ja unter dem iobroker user.

[simatec]

@fila612
Ich denke da stimmt noch was mit deinen Rechten auf dem NAS nicht und deshalb können die tmp Files für den restore nicht auf dem NAS entpackt werden.

Die Bezeichnung root mount werde ich mal ändern, da sie Irreführend ist.
Tatsächlich benötigt der User iobroker für den mount sudo.
Und mit dem Häckchen bei root mount erhält er beim mount sudo Rechte.

Also am Ende wird das so benötigt.

Bitte prüfe mal die Rechte auf deinem NAS nochmal oder stelle influx lokal wieder her

[fila612]

@simatec

danke dir, jedoch kann ich da gar nicht so viel prüfen bzw. sollte das passen.
Ich habe eine Synology DS918+ auf welcher ich extra einen User iobroker angelegt habe.
In dessen Home-Verzeichnis werden die Backups geschrieben, was auch mit der root Haken wunderbar funktioniert.
ich vermute grad, dass der umount nicht sauber läuft:
vorhin konnte ich lokal wieder restoren und konnte beobachten, dass während des Backups der Ordner "backups" laut Anzeige root:root zugeordnet war (passt ja auch wegen dem mount) und die hintergundfarbe des Ordners grün war.

Danach war diese Farbe weg und die Zuordnung war iobroker:iobroker => auch richtig.

Dann habe ich nochmals eine Sicherung angestoßen und nun ist Ordner backups immer nicht grün und root:root.

Auch ein manueller umount zeigt folgendes an:

[HAL]

@simatec ich habe inzwischen meine neu Installation auf dem Raspi4 komplett zum laufen gebracht und auch die Rechte an den Backup Verzeichnissen eingestellt.
Aber sowohl der influxDB restore von NAS als auch lokal laufen auf den gleichen Fehler.

2021-03-08 13:11:35.242 - debug: backitup.0 (30726) telegram-instance:
2021-03-08 13:11:42.304 - debug: backitup.0 (30726) Backup list be read ...
2021-03-08 13:11:44.307 - debug: backitup.0 (30726) sendTo "list" to system.adapter.admin.0 from system.adapter.backitup.0
2021-03-08 13:11:58.602 - debug: backitup.0 (30726) [influxDB] Try deleting the old InfluxDB tmp directory
2021-03-08 13:11:58.606 - debug: backitup.0 (30726) [influxDB] InfluxDB old tmp directory was successfully deleted
2021-03-08 13:11:58.609 - debug: backitup.0 (30726) [influxDB] Created tmp directory
2021-03-08 13:11:58.610 - debug: backitup.0 (30726) [influxDB] Start infuxDB Restore ...
2021-03-08 13:11:58.619 - error: backitup.0 (30726) [influxDB] Error: EPERM: operation not permitted, utime '/opt/iobroker/backups/influxDBtmp/'
2021-03-08 13:11:58.620 - error: backitup.0 (30726) [influxDB] infuxDB Restore not completed
2021-03-08 13:11:58.621 - debug: backitup.0 (30726) sendTo "restore" to system.adapter.admin.0 from system.adapter.backitup.0
2021-03-08 13:12:00.086 - info: host.raspberrypi instance system.adapter.powerfox.0 started with pid 8646
2021-03-08 13:12:01.726 - info: powerfox.0 (8646) starting. Version 0.0.2-4 in /opt/iobroker/node_modules/iobroker.powerfox, node: v12.21.0, js-controller: 3.2.16
2021-03-08 13:12:01.887 - info: powerfox.0 (8646) Terminated (NO_ERROR): Without reason
2021-03-08 13:12:02.463 - info: host.raspberrypi instance system.adapter.powerfox.0 terminated with code 0 (NO_ERROR)
2021-03-08 13:12:09.002 - debug: backitup.0 (30726) telegram-instance:

[fila612]

@simatec

Noch ein Punkt:
Die lokale Wiederherstellung scheint bei mir leider auch nicht richtig zu laufen:

backitup.0	2021-03-08 13:26:29.247	error	(2856) [influxDB] restore: DB metadata not changed. database may already exist
backitup.0	2021-03-08 13:26:29.246	error	(2856) [influxDB] 2021/03/08 13:26:29 error updating meta: DB metadata not changed. database may already exist

Sorry für die vielen nervigen Punkte :/

[simatec]

@fila612 Ja hier ist es bei InfluxDB im Gegensatz zu mysql etwas blöd.
Du musst zuerst die Datenbank löschen

Also über Konsole folgendes:

sudo influx
DROP DATABASE "DeineDatenbank"
exit

[fila612]

@simatec PERFEKT :)

Das hat geklappt - vielen Dank, jetzt sind zumindest mal alle alten Werte wieder drin..

[Altersrentner]

Hallo,
Folgendes Problem beim Restore mittels Backitup
Situation: Umzug von ioBroker, InfluxDB und Grafana
von einer HDD auf eine SSD.
Die Sicherung der HDD und das Restore auf der SSD erfolgte mit Backitup.
IoBroker läuft, influxDB ebenfalls und Grafana nicht so gut.

Heißt die Dashboards wurden nicht gesichert, warum auch immer,
Habe mehrere Sicherungen durchgeführt, ohne Erfolg.
Der letzte versuch an die Graphischen Darstellungen zu gelangen war,
ein Export der Dashboardes von der HDD und anschließendem Import auf die SSD.

Wie zu sehen ist die Datei jetzt vorhanden aber die
Graphen nicht.

Wie Ist es Möglich die Daten sichtbar zu machen.
Mit freundlichen Grüßen
Michael

[simatec]

@altersrentner Bitte die Logausgaben nicht als Bild.
Aber steht doch im Log ... Deine Logindaten sind nicht korrekt und wenn die Dashboards nicht gesichert werden, dann hast du keinen oder einen falschen Apikey angelegt bzw. in backitup eingetragen.

https://github.com/simatec/ioBroker.backitup/blob/master/docs/de/backitup.md#Grafana-Backup

[Altersrentner]

@simatec
Danke für die Schnelle Antwort.
Den API Key habe ich angelegtund auch übertragen.
Wenn der jetzt falsch ist wie kann ich doch noch an die
Graphen kommen.
Mit freundlichen Grüßen
Michael

[simatec]

@altersrentner
Hast du denn in deiner neuen Installation von Grafana die gleichen Benutzerdaten und auch dort einen ApiKey angelegt
Laut Log stimmen bei deinem Restore weder Username und Passwort als auch ApiKey nicht.
Konfiguriere Backitup mit den Benutzerdaten aus grafana (inkl. ApiKey) und führe im Anschluss den restore durch

[Altersrentner]

@simatec
Wieder das selbe Ergebnis:

Started restore ...
[DEBUG] [grafana] - Start Grafana Restore ...
[DEBUG] [grafana] - filename for restore: /opt/iobroker/backups/grafana_2021_03_08-02_18_32_backupiobroker.tar.gz
[DEBUG] [grafana] - Grafana tmp directory created: /opt/iobroker/backups/grafana_tmp
[DEBUG] [grafana] - start decompress
[DEBUG] [grafana] - Grafana request started
[DEBUG] [grafana] - Grafana is available ... Status: 200
[DEBUG] [grafana] - Try to Restore: /opt/iobroker/backups/grafana_tmp/datasource/InfluxDB-1.json
[DEBUG] [grafana] - Try to Restore: /opt/iobroker/backups/grafana_tmp/datasource/InfluxDB.json
[DEBUG] [grafana] - cannot restore datasource "InfluxDB": "data source with the same name already exists"
[DEBUG] [grafana] - cannot restore datasource "InfluxDB-1": "data source with the same name already exists"
[DEBUG] [grafana] - Try to Restore: /opt/iobroker/backups/grafana_tmp/dashboards/n1-aussen-wz.json
[DEBUG] [grafana] - cannot restore dashboard "n1-aussen-wz": {"message":"invalid API key"}
[DEBUG] [grafana] - Grafana request ended
[DEBUG] [grafana] - Try deleting the Grafana tmp directory
[DEBUG] [grafana] - Grafana tmp directory was successfully deleted
[DEBUG] [grafana] - Grafana Restore completed successfully
[EXIT] Grafana restore done

Das ist der Key, oberste Zeile

eyJrIjoiUkNLdUFsa0JReUppazAwS3RUN0tYWjAwbGtGbFVDMFAiLCJuIjoiaW9Ccm9rZXIiLCJpZCI6MX0=

curl -H "Authorization: Bearer eyJrIjoiUkNLdUFsa0JReUppazAwS3RUN0tYWjAwbGtGbFVDMFAiLCJuIjoiaW9Ccm9rZXIiLCJpZCI6MX0=" http://192.168.178.41:3000/api/dashboards/home

[simatec]

@altersrentner sagte in Test Adapter Backitup v2.0.x:

cannot restore dashboard "n1-aussen-wz": {"message":"invalid API key"}

Hast du den Key mit Adminrechten angelegt?

[Altersrentner]

@simatec
Werde ich sofort in der alten HDD überprüfen.
Danke für den Hinweis
MfG Michael

[simatec]

@altersrentner
Denke aber bitte daran, dass du in deiner neuen Umgebung auch einen neuen ApiKey benötigst, der natürlich dann auch in Backitup aktualisiert werden muss

[Altersrentner]

@simatec
Bin jetzt auf de alten HDD
werde einen neuen API Key als admin generieren
Dann ein Backup erstellen
Platte tauschen
Auf der SSD unter Backitup den neuen Key, Login un Passwort eintragen
Und Restore machen
Ist das so OK
Danke
MfG Michael

[simatec]

@altersrentner Login und ApiKey müssen mit den Grafana System auf deiner SDD passen.
Also lege den ApiKey dort an.
Der alte ApiKey von dem HDD System ist für den restore nicht relevant

[Altersrentner]

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

dass du in deiner neuen Umgebung auch einen neuen ApiKey benötigst

Auch oder den neu generierten Key? der alten Platte

[simatec]

@altersrentner Nein den auf deinem neuen System generierten Key