Test Adapter ioBroker.backitup v3.0.x

[bob der 1.]

@thomas-braun sagte in Test Adapter ioBroker.backitup v2.6.x:

@bob-der-1

Steht oben angepinnt

Was heisst hier OBEN ANGEPINNT...

[Thomas Braun]

@bob-der-1

Das heißt, das Thema ist so wichtig/häufig, dass es im Forumkopf festgetackert wurde

[bob der 1.]

@thomas-braun

Ach das meinste.....ok,stand schön auf dem Schlauch

[heinhan]

@simatec Aktuell wird für die Influxdb2 kein Backup 2.6.8 erstellt. Hier die LOG:

[DEBUG] [iobroker] - host.Iobroker 30504 objects saved

[DEBUG] [iobroker] - Backup created: /opt/iobroker/backups/iobroker_2023_03_08-16_21_34_backupiobroker.tar.gz

[DEBUG] [iobroker] - done
[DEBUG] [influxDB] - InfluxDB-Backup started ...
[DEBUG] [influxDB] - Start InfluxDB Backup ...
[DEBUG] [influxDB] - InfluxDB Backup tmp directory created 
[DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory
[DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted
[DEBUG] [influxDB] - 
[ERROR] [influxDB] - Error: Command failed: influx backup --bucket iobroker -t Token gelöscht "/opt/iobroker/backups/influxDB_2023_03_08-16_22_22_backupiobroker"
2023/03/08 16:22:23 INFO: Downloading metadata snapshot
Error: failed to backup metadata: failed to download metadata snapshot: 401 Unauthorized: read:authorizations is unauthorized

Läuft auf einen Raspi4; armd64. System und Adapter auf dem neuesten "Beta" Stand. Waran kann das liegen?

[simatec]

@heinhan Hat es mit einer vorigen Version funktioniert?

[heinhan]

@simatec Habe ich erst heute mit angeklickt, um den Datenbestand für einen Restore zur Verfügung zu haben

[simatec]

@heinhan sagte in Test Adapter ioBroker.backitup v2.6.x:

Error: failed to backup metadata: failed to download metadata snapshot: 401 Unauthorized: read:authorizations is unauthorized

Laut dem Log bist du nicht berechtigt ... Ist ein Token Thema... Da gab es hier im Forum schon Beiträge für.
Soweit ich weiß, wird ein Admin Token benötigt.

Schaue mal hier im Forum nach Beiträgen dazu... Ist jetzt nix für den Bereich hier, da es nicht den Adapter direkt betrifft

[heinhan]

@simatec Danke. Da scheint etwas nicht zu stimmen mit den Berechtigungen.

pi@Iobroker:~ $ influx auth list --token value
Error: could not find authorization with given parameters: 401 Unauthorized: unauthorized access

[JB_Sullivan]

Gibt es eigentlich ein Limit für die Dateigröße bei Influxdb?

Seit gestern (26.03.23) wird aus den Influxdb Daten keine gepackte Datei mehr erzeugt. Der Influxdb Ordner von 2:00 Uhr ist komplett leer. Ich habe das Backup dann heute nochmal händisch angestoßen. Dieses mal ist was im Ordner drin, aber es wird keine gepackte Datei daraus erzeugt.

Adapter ist letzter GIT Stand

Der Admin ist befindet sich nach gut 2 Stunden immer noch im "gestoppt" Zustand.

[simatec]

@jb_sullivan Wie Admin gestoppt? Das hat aber nichts mit Backitup zu tun.
Git Stand ist halt immer auf eigene Verantwortung. Debuglog sagt was?

[JB_Sullivan]

@simatec Ich dachte der Adapter stoppt evtl. im Laufe des Sicherungsprozess ioB. Nachts um 2:00 Uhr bekommt man das ja nicht mit.

Da ich aber nun den Update händisch angestoßen habe, habe ich auch das Debug Fenster gesehen - solange bis die "drehenden Kreise" des gestoppten Admin zu sehen waren. Ich dachte das dass das Werk des BackItUp Adapter ist.

Nach mehreren Stunden warten passierte immer noch nichts. Habe nun gesehen, das der ioB Dienst (ist eine Windows Installation) gestoppt ist. Händischer Start des Dienstes brachte das hier. Aktuell geht gar nichts mehr. ioB beendet sich nach dem Start des Dienstes permanent selber

Screenshot dient nur der Info

[simatec]

@jb_sullivan Hmm das finde ich sehr komisch... Backitup hat nichts mit dem Admin zu tun.
Geht dir hier eventuell der RAM aus und die Kiste geht in die Knie

[JB_Sullivan]

@simatec sagte in Test Adapter ioBroker.backitup v2.6.x:

Geht dir hier eventuell der RAM aus und die Kiste geht in die Knie

Genau das ist es - hatte ich nicht im Blick. Wird zum packen der Sicherungsdateien eine temporäre Auslagerungsdatei erstellt? Wenn ja, wo liegt diese? Vielleicht sind da noch irgend welche alte Leichen in dem gleichen Ordner.

Es ist zwar nur eine 128GB Festplatte, aber diese wird ausschließlich für ioB / Grafana und Influx genutzt.

OK, wenn ich sehe, das die Sicherung von Influxdb 5GB hat, sollte ich da drin vielleicht auch mal ausmisten. Das Zeitlimit was man im Influxdb Adapter einstellen kann (bei mir 2J) scheint ja nicht zu funktionieren, wenn ich sehe, das es da Daten gibt die schon 4 Jahre alt sind

[simatec]

@jb_sullivan sagte in Test Adapter ioBroker.backitup v2.6.x:

Wird zum packen der Sicherungsdateien eine temporäre Auslagerungsdatei erstellt?

Das geht in den RAM ... Darum meine Bedenken, dass dir bei den Mengen an Influx Daten dein RAM ausgeht

[JB_Sullivan]

Nächste Frage - ich habe heute einen Umzug von einer Backitup "Windows ioB" Sicherung auf eine Linux System gemacht.

Dabei habe ich die Sicherungsdateien die auf Google lagen NUR runtergeladen. Dabei kam es dann zu der folgenden Meldung.

Irgend eine Idee - es war ja nur ein Download, damit die Sicherung Lokal liegt. Das Restore wollte ich von dem lokalen Speicherort anstoßen.

Nach dem Download wurde scheinbar automatisch ein Restore angestoßen, welcher dann auch noch fehl geschlagen ist.

Das gleiche ist bei der Javaskript Sicherung passiert.

Auch habe ich festgestellt, das nach dem eigentlichen ioB Restore der VIS Adapter nicht mehr nach installiert wurde. Hier musste man wieder den auf GIT beschriebenen Weg gehen.

npm i iobroker.vis@1.4.6
iob install vis@1.4.6

{"errno":-13,"code":"EACCES","syscall":"open","path":"/opt/iobroker/backups/tmpScripts/script.json"}

backitup.0
2023-04-01 15:23:41.164	error	[zigbee] Error: EACCES: permission denied, open '/opt/iobroker/backups/zigbee_0/dev_names.json'

backitup.0
2023-04-01 15:23:41.164	error	[zigbee] Zigbee Restore not completed

backitup.0
2023-04-01 15:23:38.072	debug	[zigbee] old Zigbee database was successfully deleted

backitup.0
2023-04-01 15:23:38.069	debug	[zigbee] zigbee tmp directory created: /opt/iobroker/backups/zigbee_0

backitup.0
2023-04-01 15:23:38.068	debug	[zigbee] Filename for Restore: /opt/iobroker/backups/zigbee.0_2023_04_01-02_18_28_backupiobroker.tar.gz

backitup.0
2023-04-01 15:23:38.067	debug	[zigbee] Start Zigbee Restore ...

backitup.0
2023-04-01 15:23:38.064	debug	Download of "zigbee.0_2023_04_01-02_18_28_backupiobroker.tar.gz" done

backitup.0
2023-04-01 15:23:35.905	debug	Download of "zigbee.0_2023_04_01-02_18_28_backupiobroker.tar.gz" started

backitup.0
2023-04-01 15:23:19.491	debug	Backup list be read ...

[simatec]

@jb_sullivan VIS hat bei einem Restore aktuell Probleme. Dafür gibt es bei VIS ein Issue.
Zum Download die Frage, welchen Button hast du betätigt. Es gibt einen Download Button und einen Restore Button.

Wo hast du den Download gemacht? Im Tab Menü oder im Config Menü des Adapters?

Was ich beim restore von Zigbee sehe, dass deine Rechte nicht stimmen.
Was hast du denn für eine Version des Adapters laufen?

[Thomas Braun]

@jb_sullivan sagte in Test Adapter ioBroker.backitup v2.6.x:

Dabei habe ich die Sicherungsdateien die auf Google lagen NUR runtergeladen. Dabei kam es dann zu der folgenden Meldung.

Sieht nach klassischem Rechte-Konflikt aus.
Wem gehört das File nach dem Download mit welchen Rechten?

ls -lAh /opt/iobroker/backups

sagt?
Bitte vollständig, inkl. LogIn-Prompt.

[simatec]

@thomas-braun sagte in Test Adapter ioBroker.backitup v2.6.x:

ls -lAh /opt/iobroker/backups

Soweit ich das sehe, nutzt ein Windows

[Thomas Braun]

@simatec

ich habe heute einen Umzug von einer Backitup "Windows ioB" Sicherung auf eine Linux System gemacht.

Jein...

[simatec]

@thomas-braun Ahhh falsch gelesen