Test Adapter ioBroker.backitup v3.1.x

[Tschak]

@thomas-braun hier nochmal von der richtigen Shell

root@iobroker-ix-chart-79695bb5d4-trftb:/opt/iobroker/backups# ls -la
total 464028
drwxrwxr-x 2 iobroker iobroker       37 Nov 18 11:09 .
drwxrwxr-x 8 iobroker iobroker       16 Nov 16 13:48 ..
-rw-r--r-- 1 iobroker iobroker 15167910 Nov 11 03:00 iobroker_2022_11_11-03_00_10_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15173164 Nov 11 11:01 iobroker_2022_11_11-11_00_59_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15172979 Nov 11 11:06 iobroker_2022_11_11-11_06_39_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15173208 Nov 11 11:15 iobroker_2022_11_11-11_15_42_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15172956 Nov 11 11:23 iobroker_2022_11_11-11_23_28_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15172396 Nov 11 11:43 iobroker_2022_11_11-11_43_02_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15172107 Nov 11 12:34 iobroker_2022_11_11-12_34_18_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15175318 Nov 12 03:00 iobroker_2022_11_12-03_00_10_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15190821 Nov 12 08:57 iobroker_2022_11_12-08_57_11_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15191951 Nov 12 10:00 iobroker_2022_11_12-10_00_33_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15192116 Nov 12 10:07 iobroker_2022_11_12-10_07_25_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15194084 Nov 12 11:40 iobroker_2022_11_12-11_40_23_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15194555 Nov 12 11:51 iobroker_2022_11_12-11_51_12_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15198041 Nov 12 13:12 iobroker_2022_11_12-13_12_30_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15198423 Nov 12 14:07 iobroker_2022_11_12-14_07_12_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15200618 Nov 13 03:00 iobroker_2022_11_13-03_00_10_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15206664 Nov 14 03:00 iobroker_2022_11_14-03_00_10_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15222832 Nov 15 03:00 iobroker_2022_11_15-03_00_10_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 15250215 Nov 17 03:00 iobroker_2022_11_17-03_00_10_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 61599631 Nov 18 03:00 iobroker_2022_11_18-03_00_10_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 61599554 Nov 18 10:51 iobroker_2022_11_18-10_51_42_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker 61599409 Nov 18 11:08 iobroker_2022_11_18-11_08_43_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker     1098 Nov 18 10:51 mysql_2022_11_18-10_51_56_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker     1098 Nov 18 11:08 mysql_2022_11_18-11_08_56_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker   453041 Nov 12 11:51 redis-remote_2022_11_12-11_51_20_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker   457443 Nov 12 14:07 redis-remote_2022_11_12-14_07_19_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker   460080 Nov 13 03:00 redis-remote_2022_11_13-03_00_20_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker   463579 Nov 14 03:00 redis-remote_2022_11_14-03_00_19_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker   464421 Nov 15 03:00 redis-remote_2022_11_15-03_00_17_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker   471069 Nov 15 13:06 redis-remote_2022_11_15-13_06_27_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker   470425 Nov 16 03:00 redis-remote_2022_11_16-03_00_19_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker   471143 Nov 17 03:00 redis-remote_2022_11_17-03_00_31_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker   472584 Nov 18 03:00 redis-remote_2022_11_18-03_00_24_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker   472424 Nov 18 10:52 redis-remote_2022_11_18-10_51_57_docker_backupiobroker.tar.gz
-rw-r--r-- 1 iobroker iobroker   471034 Nov 18 11:09 redis-remote_2022_11_18-11_08_57_docker_backupiobroker.tar.gz

[andre]

@tschak sagte in Test Adapter ioBroker.backitup v2.5.x:

werden aber bei Wiederherstellen nicht angezeigt

Lies mal bitte die Doku zum backitup Adapter. Speziell den Teil zum redis Backup & Restore.

MfG,
André

[andre]

@tschak sagte in Test Adapter ioBroker.backitup v2.5.x:

wie kann man dir helfen, ich habe aktuell schon mal bei mir das MYSQL getestet und es hat funktioniert.

Meld dich mal im iobroker Discord unter "BETA TESTING & FEEDBACK" > "docker-image" .

MfG,
André

[andre]

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

~/backups
ist ja auch /home/iobroker/backups und nicht /opt/iobroker/backups

Ist nicht das home Verzeichnis vom iobroker user /opt/iobroker? Meine mal irgendwo gesehen zu haben, dass das beim setup so gesetzt wird...

MfG,
André

[Tschak]

@andre sagte in Test Adapter ioBroker.backitup v2.5.x:

Ist nicht das home Verzeichnis vom iobroker user /opt/iobroker? Meine mal irgendwo gesehen zu haben, dass das beim setup so gesetzt wird...

ja stimmt laut github von dir so erstellt

https://github.com/buanet/ioBroker.docker/blob/main/debian/node18/Dockerfile
Line 64

[Tschak]

@andre sagte in Test Adapter ioBroker.backitup v2.5.x:

Lies mal bitte die Doku zum backitup Adapter. Speziell den Teil zum redis Backup & Restore.

habs gefunden sorry bei so viel lesen was ich gerade mache, da kann das ein oder andere schon mal überlesen werden.

[biker1602]

@simatec said in Test Adapter ioBroker.backitup v2.5.x:

@biker1602 Das Backup vom 7.11. gibt es auch nicht lokal.
Lass mal den Fixer drüberlaufen und starte im Anschluss das System mal komplett neu.

Ich muss da bitte nochmal nachfragen. Es wurden jetzt 7 Backups ohne Fehlermeldung gemacht, danach gingen die gleichen Fehler für das ioBroker Backup wieder los.
Ich habe dann wieder den Fixer darüber laufen lassen und danach ist wieder alles OK. Es kann doch aber nicht sein, dass man jedes Mal, wenn die 7 Backups erreicht sind, die auch so im Adapter eingetragen sind, der gleiche Fehler auftritt.

[JB_Sullivan]

Was mache ich beim Restore falsch, das jedes mal, nach einem Restore der Admin nicht mehr startet?

Folgende Vorgehensweise:

System 1) ist ein Windows System von dem das Backup erzeugt wird. Neben dem ioB Backup werden Influxdb, Grafana, javaskript und zigbee auf Google Drive gesichert.

System2 ist das Restore System auf Linux Basis. Die Versionsstände aller relevanten Adapter (Backitup,Admin) /Systeme (Host) sind Identisch zum Windows System. Einzig nodejs (14.16.0 zu 14.21.1) und npm (6.14.11 zu 6.14.17) sind auf dem Restore System ein Stück neuer.

Das Restore wird nur für die ioB Sicherung ausgeführt. Die anderen Sicherungen werden erstmal nicht mit angestoßen.

Leider hängt sich dieses Restore jedesmal komplett auf und der Admin ist nicht mehr erreichbar (somit auch keine Fehler Logs)

Man gut das das ganze auf Proxmox läuft und der Grundzustand mit einem Clone schnell wieder hergestellt werden kann.

Aber wo liegt der Fehler?

[crunchip]

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

von dem das Backup erzeugt wird

und das liegt dann wo?

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

Leider hängt sich dieses Restore jedesmal komplett auf

und wo bleibt es stehen?

[JB_Sullivan]

@crunchip sagte in Test Adapter ioBroker.backitup v2.5.x:

und das liegt dann wo?

Wie ich oben geschrieben habe, wird die Sicherung auf Google Drive gespeichert und von dort wird auch das Restore geholt.

Bei der Wiederherstellung von den Adaptern. Ist immer an unterschiedlichen Stellen. Mal ist der letzte Eintrag in der Restore History Adapter X mal Adapter Y. Danach geht dann nix mehr und der "drehende Ring" vom gestoppten Admin würde bis zum Sankt Nimmerleinstag weiter drehen.

Aktualisiert man die Browser Seite, ist der Admin gar nicht mehr erreichbar.

[crunchip]

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

von dort wird auch das Restore geholt

hast du es mal probiert wenn du es lokal zur Verfügung stellst?

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

ist der Admin gar nicht mehr erreichbar

weil möglicherweise der restore noch läuft?, so nebenbei mal ins log gesehen?

[simatec]

@jb_sullivan
Jetzt erstmal sortieren, ob wir hier überhaupt im richtigen Thread sind.
Also du machst einen Restore aus der Cloud.
Würde an deiner Stelle immer die lokale Variante nehmen. Einfach Backup von Google runterladen und in den lokalen Backupordner packen.

So weiter… der Restore wird durchgeführt und iob danach gestartet.
Danach installieren sich die Adapter und er bleibt da irgendwo hängen.

Richtig soweit?

[JB_Sullivan]

@simatec Genau - soweit Richtig. Von lokal habe ich es noch nicht versucht, weil ich mit Linux nicht so firm bin und nicht weiß wie und vor allen Dingen wohin ich diese Sicherung kopieren soll.

[crunchip]

@jb_sullivan https://github.com/simatec/ioBroker.backitup/wiki/ioBroker.backitup-Wiki-Deutsch

Grundsätzlich ist aber der sicherste Weg, den Restore lokal auszuführen.

Wer den sichersten Weg wählt und den Restore lokal ausführen möchte, muss die Backupdatei im iobroker Backup-Ordner ablegen. Auf Linuxsystemen befindet sich dieser Ordner unter folgenden Pfad: /opt/iobroker/backups

[Andersmacher]

Ich nutze seit einiger Zeit backitup in der Version 2.5.9 und habe mir jetzt in VIS einen View gebastelt, in dem ich z. B. den Datenpunkt backitup.0.info.ccuNextTime in einem basic-Timestamp-Widget einblende. Obwohl im ioBroker Objektbaum das erwartete Datum korrekt angezeigt wird, steht in VIS immer der gleiche Wert, wie unter backitup.0.info.ccuLastTime.
Gleiches gilt für ...iobrokerNextTime.

Die Suche diesbezüglich hat bei mir keine Treffer ergeben. Ich kann mir allerdings auch nicht vorstellen, daß das bisher noch niemandem aufgefallen ist, falls das ein Adapter-Problem sein sollte. Daher nehme ich an, daß ich da was falsch mache!?

[simatec]

@jb_sullivan

So wie ich das sehe, hast du den Hostname geändert.
Führe auf der Konsole folgendes aus.

iob stop
iob host this
iob fix
iob start

[Homoran]

@simatec wir sind schon soweit

https://forum.iobroker.net/topic/61522/probleme-mit-admin-nach-restore

[Andersmacher]

@andersmacher Ich antworte mir mal selber:
Ich habe das Widget basic-Timestamp falsch interpretiert. Es zeigt den Datenpunkt nicht in Form/Format eines Timestamps an, sondern den Timestamp des Datenpunktes. Und backitup.0.info.ccuNextTime und backitup.0.info.ccuLastTime werden in der Regel ja am selben Tag gesetzt und haben somit dann natürlich auch den gleichen Timestamp.

Darstellung des Datenpunktes in einem basic-HTML-Widget zeigt dann die gewünschten Werte an. In einem basic-TimesValue-Widget klappt es nicht (oder höchstens mit zusätzlichem Bindingaufwand), da der Adapter den Wert als String liefert.

[DK43]

Ich hab da momentan ein Problem der dem von @JB_Sullivan ein bisschen ähnelt.

Ich habe einen Raspi 3b+ mit 2GB RAM der langsam Schwächelt.

Habe nun auf einem Mini pc Windows tiny10 installiert und auch iobroker mit dem neusten installer.

Grundsätzlich wäre ein System Umzug mit dem Backitup Adapter möglich oder? Gibt's da etwas zu beachten?

Da backitup schon vorinstalliert war habe ich die backup Datei (iobroker, zigbee und JavaScript) aus der Dropbox auf den Minipc geladen um eine Wiederherstellung durchzuführen .

Wenn ich jetzt mit iobroker anfange tut sich garnichts mehr. Die adminoberfäche lässt sich nicht mehr öffnen.

Mittels "obroker start" komme ich dann wieder drauf.

Hab nun den hostnamen des Mini PC auf den gleichen geändert wie beim Raspi in der Hoffnung dass es vielleicht daran liegen.
Es tut sich zwar immernoch nichts aber mittlerweile bleibt die Adminoberfäche erhalten.

Ist ein Systemumzug mit backitup etwa nicht möglich?

[Thomas Braun]

@dk43 sagte in Test Adapter ioBroker.backitup v2.5.x:

Ist ein Systemumzug mit backitup etwa nicht möglich?

Doch, geht grundsätzlich.
Schau ins Log, wo es da klemmt.

Wobei meiner Meinung nach ein Linux die bessere Basis für den Betrieb des ioBrokers darstellt.