Test Adapter ioBroker.backitup v3.0.x
-
@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 -
@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
-
@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
-
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 ... -
@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? -
@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/backupssagt?
Bitte vollständig, inkl. LogIn-Prompt. -
@thomas-braun sagte in Test Adapter ioBroker.backitup v2.6.x:
ls -lAh /opt/iobroker/backups
Soweit ich das sehe, nutzt ein Windows
-
ich habe heute einen Umzug von einer Backitup "Windows ioB" Sicherung auf eine Linux System gemacht.
Jein...
-
@thomas-braun Ahhh falsch gelesen
-
Adapter Version ist 2.6.16
Ich habe den DOWNLOAD - nicht die Uhr aus dem seitlichen Backitup Menü heraus angestoßen.
sully@ioBrokerNUC:~$ ls -lAh /opt/iobroker/backups insgesamt 4,8G -rw-rw-r--+ 1 iobroker iobroker 4,8G 1. Apr 15:33 influxDB_2023_04_01- -rw-rwxr--+ 1 iobroker iobroker 17M 1. Apr 13:04 iobroker_2023_04_01-02_00_10_backupiobroker.tar.gz -rw-rw-r--+ 1 iobroker iobroker 589K 1. Apr 15:26 javascripts_2023_04_01-02_18_38_backupiobroker.tar.gz drw-r--r--+ 2 iobroker iobroker 4,0K 1. Apr 02:18 tmpScripts drw-r--r--+ 2 iobroker iobroker 4,0K 1. Apr 02:14 zigbee_0 -rw-rw-r--+ 1 iobroker iobroker 4,2K 1. Apr 15:23 zigbee.0_2023_04_01-02_18_28_backupiobroker.tar.gzbzgl. Rechte - ich habe node und npm auf die aktuelle 18.xx / 9.5 Version hochgezogen und danach aber auch einen ioB fix laufen gelassen.
Erst als das alles fertig war, habe ich damit begonnen die anderen NICHT ioB Sicherungen einzuspielen (influx, Grafana, jsSkript und zigbee)
-
@jb_sullivan sagte in Test Adapter ioBroker.backitup v2.6.x:
sudo -u iobroker chmod 777 /opt/iobroker/backups/* -
@jb_sullivan sagte in Test Adapter ioBroker.backitup v2.6.x:
Ich habe den DOWNLOAD - nicht die Uhr aus dem seitlichen Backitup Menü heraus angestoßen.
Aber wie man auf dem Bild sieht, wird kein Restore gestartet. Es beginnt nur der Download.
-
@thomas-braun sagte in Test Adapter ioBroker.backitup v2.6.x:
ls -lAh /opt/iobroker/backups
sieht jetzt so aus:
sully@ioBrokerNUC:~$ ls -lAh /opt/iobroker/backups insgesamt 4,8G -rwxrwxrwx+ 1 iobroker iobroker 4,8G 1. Apr 15:33 influxDB_2023_04_01-02_00_39_backupiobroker.tar.gz -rwxrwxrwx+ 1 iobroker iobroker 17M 1. Apr 13:04 iobroker_2023_04_01-02_00_10_backupiobroker.tar.gz -rwxrwxrwx+ 1 iobroker iobroker 589K 1. Apr 15:26 javascripts_2023_04_01-02_18_38_backupiobroker.tar.gz drwxrwxrwx+ 2 iobroker iobroker 4,0K 1. Apr 02:18 tmpScripts drwxrwxrwx+ 2 iobroker iobroker 4,0K 1. Apr 02:14 zigbee_0 -rwxrwxrwx+ 1 iobroker iobroker 4,2K 1. Apr 15:23 zigbee.0_2023_04_01-02_18_28_backupiobroker.tar.gz@simatec - oben im Debug sieht man aber, das er nahtlos nach dem Download mit dem Restore anfängt.
-
@jb_sullivan sagte in Test Adapter ioBroker.backitup v2.6.x:
sieht jetzt so aus:
Dann versuch jetzt nochmal das lokale Zeug einzuspielen.
-
@thomas-braun Jetzt funktioniert es und am Ende des Downloads kommt die folgende Meldung - da war vorhin nicht der Fall.
-
@jb_sullivan Da haben dann sicher die Recht in /opt/iobroker/backups nicht gepasst
-
Hmmmm - da bin ich schon wieder. Die Downloads aus Goggle haben ja soweit geklappt, jedoch scheitert es nun an einer Wiederherstellung der Datei aus dem lokalen Verzeichnis heraus
{"errno":-13,"code":"EACCES","syscall":"open","path":"/opt/iobroker/backups/zigbee_0/dev_names.json"} {"errno":-13,"code":"EACCES","syscall":"mkdir","path":"/opt/iobroker/backups/grafana_tmp/dashboards"} {"errno":-13,"code":"EACCES","syscall":"open","path":"/opt/iobroker/backups/tmpScripts/script.json"} {"errno":-13,"code":"EACCES","syscall":"open","path":"/opt/iobroker/backups/influxDBtmp/20230401T000039Z.manifest"} -
@jb_sullivan sagte in Test Adapter ioBroker.backitup v2.6.x:
mkdir","path":"/opt/iobroker/backups/grafana_tmp/dashboards"
Ähnliche Nummer. Der user, der den Code ausführt darf offenbar in
/opt/iobroker/backups/grafana_tmp/dashboards keine Verzeichnisse anlegen. -
@thomas-braun sagte in Test Adapter ioBroker.backitup v2.6.x:
/opt/iobroker/backups/grafana_tmp/dashboards keine Verzeichnisse anlegen.
Das habe ich auch gesehen, genauso wie er die anderen Verzeichnisse nicht öffnen kann. Die Frage ist - warum nicht? Ich habe nochmal einen ioB fix rüber laufen lassen - hat aber nichts geändert.
Ich habe doch nur eine bestehende "Windows" Sicherung auf ein Linux System (Debian Bullseye) eingespielt. ioB und der Admin funktionieren auch soweit ohne Fehlermeldungen.
-
@jb_sullivan sagte in Test Adapter ioBroker.backitup v2.6.x:
Die Frage ist - warum nicht?
Wem gehören denn die Dateien und Verzeichnisse mit welchen Rechten?
