Test Adapter ioBroker.backitup v3.0.x

[simatec]

@keksn Dann kann es nicht sein, dass im lokalen Backupordner die gleichen Backups liegen.
Da ist der mount noch gesetzt.

Starte mal den Adapter neu und warte mal bis im Log nach dem Backup-Check der umount kommt.
Danach sollte der lokale Backup Ordner leer sein.

Die Synology kenne ich nicht. Von daher solltest du hier im Forum mal nach den korrekten CIFS Einstellungen für die Synology in Kombi mit Backitup suchen.

Für den Restore kannst du das Backup lokal ablegen (Achte darauf, dass kein mount ansteht)

[simatec]

@keksn Konfigureiere mal NFS und nutze die Infos aus dem Thread

[keksn]

@simatec kein Fehler mehr! Vielen Dank!!!

Ist es angemacht in Zukunft in den Adapter auch eine automatische Image Sicherung der SD(SSD) auf einem Nas einzubauen? LG

[simatec]

@keksn Nein ist nicht gewollt.
Backitup sichert den iobroker und die Systeme um den iobroker drumherum.

[keksn]

@simatec Danke für die Info.
Eine Frage noch zum Restore von influxdb. Die Wiederherstellung hat zwar jetzt gestartet, ich sehe aber im Verlauf seit 10 Min keinen Fortschritt. Das Backup ist ca. 370MB groß. Ist das normal?

[simatec]

@keksn Das benötigt eine ganze Weile
Wichtig beim Influx Restore ... die DB darf in deiner Influx Umgebung nicht existieren ....
Falls die vorhanden ist, bitte vorher ein drop database <Name der DB> ausführen

[keksn]

@simatec das wird es sein, leider bekomme ich immer -bash: drop: command not found"...

[keksn]

@simatec danke hat sich erledigt hat funktioniert! Nochmals Danke! LG

[Josh]

Nur zur Info:

Ich habe bei mir "Benachrichtigung nur bei Fehlern" eingestellt. Aufgrund einer Umkonfiguration hatte sich die IP-Adresse bei meiner Grafana-Installation verändert. Dies habe ich aber vergessen dem Backitup-Adapter mitzuteilen. Es konnten also keine Grafana-Backups erzeugt werden. Der Adapter brachte trotz obiger Einstellung keine Mail über den Fehler.

[simatec]

@josh
Bitte den Debuglog posten oder ein Issue aufmachen

[Josh]

@simatec Ich bin mit der Influxdb auf einen separaten LXC umgezogen. Seit dem funktioniert das Backup der InfluxDB nicht mehr. Die Fehlermail sagt folgendes:

BackItUp:
Your backup was not completely created. Please check the errors!!

influxDB: Error: Command failed: influxd backup -portable -database iobroker -host 192.168.178.184:8086 "/opt/iobroker/backups/influxDB_2022_01_01-02_00_25_Master_backupiobroker"
2022/01/01 02:00:25 Invalid metadata blob, ensure the metadata service is running (default port 8088)
backup: invalid metadata received

Der Port ist aber nicht 8088, sondern 8086.

Habe dann in der Adapterbeschreibgung folgendes gelesen:

Wenn die InfluxDB von einem entfernten Server gesichert werden soll, müssen in der influxdb.conf auf dem entfernten Server die Remote-Rechte für den RPC-Dienst angepasst werden.

Ich finde aber die influxdb.conf nicht. Sie sollte doch unter

/etc/influxdb/influxdb.conf

liegen, oder? Ist sie aber nicht.

Ich habe die Influxdb-Version 2.1. Weiß jemand, wo ich die Datei finde?

[Wal]

@josh,
schau mal in der Datei /etc/default/influxdb2 nach, da steht normal der Name der Config.
Bei mir "/etc/influxdb/config.toml"

[simatec]

@josh Die Unterstützung für das Backup von influxdb 2.x ist für Backitup 2.3.x geplant und in Arbeit.

Aktuell unterstützt Backitup Influxdb 2 noch nicht, da sich der Backupprozess hier geändert hat

[Josh]

@simatec @Wal Danke für die Resonanz. Ich habe jetzt das InfluxDB-Backup erst mal deaktiviert und sichere den ganzen LXC weg.

Ich freue mich schon auf die neue Version

[Wal]

@josh ,
so mache ich es immer, backitup habe ich deinstalliert.

[simatec]

@wal denke dein Beitrag passt hier nicht in den Thread ...

[Fenriswolf]

Moin,

seit langem habe ich mal wieder in den Adapter geguckt.
Er lief immer problemlos, daher war keine Notwendigkeit.
Nun habe ich erfreulicherweise festgestellt, dass auch YAHKA im Backup mit unterstützt wird. Also direkt das Häckchen gesetzt und ein Backup durchgeführt.
Und prompt trat ein Fehler auf.

Auszug aus dem Debug:

[DEBUG] [javascripts] - Try deleting the Javascript tmp directory: "/opt/iobroker/backups/tmpScripts"
[DEBUG] [javascripts] - Javascript tmp directory "/opt/iobroker/backups/tmpScripts" successfully deleted
[DEBUG] [javascripts] - Backup created: /opt/iobroker/backups/javascripts_2022_01_10-13_27_45_backupiobroker.tar.gz
[DEBUG] [javascripts] - done
[DEBUG] [yahka] - found yahka database: yahka.3,yahka.4,yahka.5

Das ist so prinzipiell auch richtig, nur habe ich bei mir noch ein "yahka.6", das hier schon nicht mehr aufgeführt wird.
Mein erster Gedanke war, das im Ordner "yahka.5.hapdata" etwas ist, das es abbrechen lässt.

-rw-rwxr--+ 1 iobroker iobroker   766 Jan 10 11:11 AccessoryInfo.F514.json
-rw-rwxr--+ 1 iobroker iobroker   469 Nov 24 13:55 AccessoryInfo.3299.json
-rw-rwxr--+ 1 iobroker iobroker   756 Feb 25  2021 AccessoryInfo.D771.json
-rw-rwxr--+ 1 iobroker iobroker   722 Dec  9  2020 AccessoryInfo.E771.json
-rw-rwxr--+ 1 iobroker iobroker   766 Mar  8  2021 AccessoryInfo.5522.json
-rw-rwxr--+ 1 iobroker iobroker   719 Jan 12  2021 AccessoryInfo.ECD1.json
-rw-rwxr--+ 1 iobroker iobroker   757 Jan 10 11:11 AccessoryInfo.ECD2.json
-rw-rwxr--+ 1 iobroker iobroker   756 Jan 10 11:11 AccessoryInfo.ECD3.json
-rw-rwxr--+ 1 iobroker iobroker   758 Jan 10 11:11 AccessoryInfo.ECD4.json
-rw-rwxr--+ 1 iobroker iobroker   759 Jan 10 11:11 AccessoryInfo.ECD5.json
-rw-rwxr--+ 1 iobroker iobroker   519 Nov 16  2020 AccessoryInfo.ECDD.json
-rw-rwxr--+ 1 iobroker iobroker   758 Jan 10 11:11 AccessoryInfo.ECD3.json
-rw-rwxr--+ 1 iobroker iobroker   430 Jan 11  2021 AccessoryInfo.1DF1.json
-rw-rwxr--+ 1 iobroker iobroker 49802 Jan  8 18:14 IdentifierCache.F514.json
-rw-rwxr--+ 1 iobroker iobroker  3069 Nov 24 13:53 IdentifierCache.3299.json
-rw-rwxr--+ 1 iobroker iobroker  3069 Jan 15  2021 IdentifierCache.D771.json
-rw-rwxr--+ 1 iobroker iobroker  3069 Dec  9  2020 IdentifierCache.E771.json
-rw-rwxr--+ 1 iobroker iobroker  3854 Mar  8  2021 IdentifierCache.5522.json
-rw-rwxr--+ 1 iobroker iobroker  3071 Nov 23  2020 IdentifierCache.ECD1.json
-rw-rwxr--+ 1 iobroker iobroker  3071 Jan 15  2021 IdentifierCache.ECD2.json
-rw-rwxr--+ 1 iobroker iobroker  3071 Jan 15  2021 IdentifierCache.ECD3.json
-rw-rwxr--+ 1 iobroker iobroker  3071 Jan 15  2021 IdentifierCache.ECD4.json
-rw-rwxr--+ 1 iobroker iobroker  3071 Jan 15  2021 IdentifierCache.ECD5.json
-rw-rwxr--+ 1 iobroker iobroker  1733 Nov 16  2020 IdentifierCache.ECDD.json
-rw-rwxr--+ 1 iobroker iobroker  3069 Jan 15  2021 IdentifierCache.ECD3.json
-rw-rwxr--+ 1 iobroker iobroker  3069 Jan 11  2021 IdentifierCache.1DF1.json

Die Daten wurden im letzten Teil des Dateinamens gekürzt.
In den anderen Ordnern sind jeweils nur 2 - 6 Dateien enthalten.

Für weitere Fragen, stehe ich gerne zur Verfügung.
mfg
Marc

[simatec]

@fenriswolf

Aktuell prüft der Adapter nur 5 Instanzen. Hätte nicht gedacht, dass jemand da mehr benötigt.
Darf ich fragen, warum du so viele Instanzen laufen hast?

Mach mal bitte ein Issue auf, dann passe ich das in der nächsten Version an

[simatec]

Ab sofort steht die Version 2.2.3 auf Github und im latest zur Verfügung.

Changelog

2.2.3 (2022-01-10)

• (simatec) Bugfix Error Message
• (simatec) dependencies updated

[Fenriswolf]

@simatec

Danke für deine schnelle Antwort.
Die Instanzen *.0 - *.2 existieren nicht mehr, die waren mal zum testen.
Unser Haus beinhaltet recht viel SmartHome Ich nutze die unterschiedlichen Instanzen für unterschiedliche Bereiche.

Frage: Wieso bleibt der Backitup-Adapter nach der 5ten Instanz stehen und führt das Backup nicht zuende ? Habe über eine Stunde gewartet und er blieb wie oben im Debug beschrieben stehen.

mfg
Marc