Adapter: iobroker.backitup (stable Release)

[Mic]

Vielen Dank für den Adapter, läuft soweit gut. Zur History habe ich einen Verbesserungsvorschlag, https://github.com/simatec/ioBroker.backitup/issues/24.

Nun zu meiner Frage:

Ich mache das Backup via CIFS auf ein Synology-NAS, das funktioniert auch sehr gut.

Was hat es denn mit der Einstellung "alte Standard-Backups löschen nach X-Tagen" auf sich?
<list type="decimal">4. Wenn ich hier eine "1" eintrage, und z.B. das Datum des Dateinamens von "minimal-2018_08_06-03_00_10_backupiobroker.tar" auf ""minimal-2018_08_02-03_00_10_backupiobroker.tar" setze auf Server (/opt/iobroker/backups) und NAS, also 4 Tage alt, dann wird weder auf dem Server (Raspberry) noch auf der NAS die Datei gelöscht.

7. Sollen durch die Funktion die Dateien auf dem Server (/opt/iobroker/backups), auf der NAS, oder auf beiden gelöscht werden?

Mic-M created this issue in simatec/ioBroker.backitup

closed History States updated on start of backup, and not after successful backup #24

[foxriver76]

@Mic:

Vielen Dank für den Adapter, läuft soweit gut. Zur History habe ich einen Verbesserungsvorschlag, https://github.com/simatec/ioBroker.backitup/issues/24.

Nun zu meiner Frage:

Ich mache das Backup via CIFS auf ein Synology-NAS, das funktioniert auch sehr gut.

Was hat es denn mit der Einstellung "alte Standard-Backups löschen nach X-Tagen" auf sich?
<list type="decimal">4. Wenn ich hier eine "1" eintrage, und z.B. das Datum des Dateinamens von "minimal-2018_08_06-03_00_10_backupiobroker.tar" auf ""minimal-2018_08_02-03_00_10_backupiobroker.tar" setze auf Server (/opt/iobroker/backups) und NAS, also 4 Tage alt, dann wird weder auf dem Server (Raspberry) noch auf der NAS die Datei gelöscht.

7. Sollen durch die Funktion die Dateien auf dem Server (/opt/iobroker/backups), auf der NAS, oder auf beiden gelöscht werden? `

Zu 1: gehe ich stark davon aus, dass auf das Erstellungsdatum zurückgegriffen wird, wie es auch schon im Backup Script war.

[Mic]

@foxriver76:

Zu 1: gehe ich stark davon aus, dass auf das Erstellungsdatum zurückgegriffen wird, wie es auch schon im Backup Script war. `

Danke, das würde Sinn machen, also die https://linux-club.de/wiki/opensuse/Zeitstempel_von_Dateien#Change_Time_.28ctime.29 wohl.

[simatec]

@Chaot:

Irgendwie funktioniert seit dem letzten Update bei mir das Ganze nicht so richtig.

Die Backups werden mittlerweile erstellt und per FTP auf Fritz-Nas geschoben.

Allerdings wird in der History nichts eingetragen. Der letzte Eintrag ist das letzte Backup vor dem Adapterupdate.

Mittlerweile habe ich 2 manuelle Backups und 2 automatische Backups ohne Fehler ausgeführt. Lediglich die History Einträge scheinen nicht geschrieben zu werden. `

Lege mal bitte eine neue html an für die history.

Der Datenpunkt hat sich geändert.

Es reicht nicht den Datenpunkt in der html zu ändern.

Die html muss neu on der vis erstellt werden

Gesendet von iPhone mit Tapatalk

[simatec]

Gelöscht wird nach Änderungsdatum.

Gesendet von iPhone mit Tapatalk

[Peoples]

@Mic:

Vielen Dank für den Adapter, läuft soweit gut. Zur History habe ich einen Verbesserungsvorschlag, https://github.com/simatec/ioBroker.backitup/issues/24. `

Das streben wir in der Javascript-Version an. Ist aber derzeit noch nicht spruchreif

[Chaot]

ok,

wie gehe ich da vor?

Ich habe den Datenpunkt History gelöscht und ein manuelles Backup gestartet. Dann sollte ja der Datenpunkt neu geschrieben werden oder sehe ich das falsch?

[simatec]

Nein das muss du in der VIS machen

Gesendet von iPhone mit Tapatalk

[Chaot]

Ich denke mal das das letzte Update komplett in die Hose ging.

Ich kann per Button in VIS keine Updates mehr machen,

History ist weg

Schade wenn alles geändert wird und es keiner für nötig hält das irgendwo zu dokumentieren.

Alleine schon das plötzlich die FTP Einstellungen weg waren sollte zumindest klar kommuniziert werden.

Ich habe das erst durch Zufall gemerkt.

• Ja, ich lese Cangelogs

• nein, ich suche nicht nach jedem Update eines Adapters mehrere Stunden in Foren ob irgendwas wesentliches verändert wurde.

[simatec]

Ich verstehe deinen Unmut, aber der Adapter ist noch Beta und da kann es zu Änderungen kommen.

Installiere dir die 0.2.7.

Das ist der letzte Stand, der sauber läuft.

Gesendet von iPhone mit Tapatalk

[Chaot]

Klar, mir ist der Beta Status schon bekannt, aber solche Änderungen sollten doch auch in die Changelog damit man wesentliche Infos doch sofort hat.

Dazu ist ja auch die Changelog da (zumindest war das früher mal so) das man dort auch vermerkt hat "Datenpunkte geändert" "Zugriffsmodus geändert - muss neu konfiguriert werden"

Bitte versteht mich nicht falsch. Ich ärgere mich eigentlich über eine Kleinigkeit die nicht sein müsste.

Ich finde eure Arbeit wirklich toll und bin echt dankbar das ihr so hinter dem Projekt steht.

[Peoples]

@Chaot:

Bitte versteht mich nicht falsch. `

Tut keiner! Ich sehe das als konstruktive Kritik und wir werden das zukünftig so machen. Das spart viel Arbeit.

Nur oft geht sowas unwichtiges WICHTIGES einfach in der Summe unter

[Chaot]

Ok, zurück zum Thema.

Ich habe jetzt den ganzen Adapter gelöscht und neu installiert. Daraufhin wurden dann alle Objekte neu erstellt und ich konnte sie entsprechend in der VIS ändern.

Meine vorherigen manuellen Tests habe ich nämlich blöderweise nicht vom Objektreiter (da hätte ich das gleich gemerkt) sondern aus dem Adapter gestartet.

Die Objekte wurden nach dem Update nicht neu geschrieben sondern es waren auch nach mehrmaligem Neustart des Adapters keine geänderten Namen vorhanden.

Das Problem ist jetzt zwar weg, aber das sollte man eventuell im Hinterkopf behalten das alte Installationen die Objekte nicht neu schreiben. Das könnte die ein- oder andere Fehlerquelle erklären.

[Mic]

@Chaot:

Das Problem ist jetzt zwar weg, aber das sollte man eventuell im Hinterkopf behalten das alte Installationen die Objekte nicht neu schreiben. Das könnte die ein- oder andere Fehlerquelle erklären. `

Ich kenne die Problematik von anderen Systemen bei der Plugin-Programmierung.

Die Lösung ist hier, dass im Plugin die aktuell zu installierende Version in eine Konstante kommt, z.B. '3.17'. Dann wird im Skript im Bereich "Plugin-Installation" die derzeit installierte Version abgefragt. Wenn man dann hier z.B. "< '3.11'" hat, dann wird bei bestehenden Installationen kleiner Version 3.11 was durchgeführt, in diesem Fall könnten die Objektinhalte in die neue Objektstruktur übertragen - oder falls nicht relevant - alle alten Objekte gelöscht werden.

Nur meine 2 Cents… Wäre gegebenfalls auch was für ein Adapter-Framework.

[Röstkartoffel]

Ich benutze das Backup schon seit dem Script V1 und bin schlicht weg begeistert. Danke an allen die dabei mitgewirkt haben.

Aber vorgestern fiel mir auf, das seit dem letzten Update auf 0.2.7 keine Backups mehr ausgeführt wurden. Es fiel mir auf, da ich keine Meldung per Telegram erhalten habe und die History sich nicht geändert hat. Alle Einträge im Adapter waren leer. Genauso wie "Chaot" dieses weiter oben beschrieben hat.

Ein erneutes Eintragen führte nicht zum Erfolg, also habe ich wie auch vorgeschrieben, den (Beta)-Adapter und die Instanz gelöscht und neu angelegt.

Der Test-Button ist wunderbar, man sieht gleich ob die Einstellungen korrekt sind, dieses waren sie auch, die Backups wurden erstellt und das Mounten funktioniert.

Aber die Widgets gingen alle nicht, da sich die Datenpunkte geändert haben. Also diese auf die neuen Datenpunkte geändert, das ging auch nicht. Erst ein Löschen und Neuanlegen, sowie die neuen CCS-Formatierung des History-Logs wie in der Doku beschrieben, zeigte einen Erfolg.
@simatec:

@Chaot:

Irgendwie funktioniert seit dem letzten Update bei mir das Ganze nicht so richtig.

Die Backups werden mittlerweile erstellt und per FTP auf Fritz-Nas geschoben.

Allerdings wird in der History nichts eingetragen. Der letzte Eintrag ist das letzte Backup vor dem Adapterupdate.

Mittlerweile habe ich 2 manuelle Backups und 2 automatische Backups ohne Fehler ausgeführt. Lediglich die History Einträge scheinen nicht geschrieben zu werden. `

Lege mal bitte eine neue html an für die history.

Der Datenpunkt hat sich geändert.

Es reicht nicht den Datenpunkt in der html zu ändern.

Die html muss neu on der vis erstellt werden

Gesendet von iPhone mit Tapatalk `
Das funktioniert, hatte ich aber auch schon Stunden vorher gemacht, bevor hier die Lösung kam.

Was leider noch nicht ging, war der Text der Buttons für OneClick in der VIS.

Ich habe wie immer den Code aus der Doku genommen:

{wert: backitup.0.oneClick.minimal; wert === "true" || wert === true ? "Minimal Backup 
 wird erstellt" : "Minimal Backup 
 starten"}

Da zeigt er immer den Button-Text "undefined" an.

Erst als ich das Binding wie von "Prinzeisenherz1" beschrieben geändert habe, läuft alles wie es soll:

{wert:backitup.0.oneClick.minimal;wert === "true" || wert === true || wert === 1 ? "Minimal Backup 
 wird erstellt" : "Minimal Backup 
 starten"}

Und wie schon gesagt, es ist ein toller Adapter und die Gewissheit, ein paar Backups auf der externen NAS zu haben, beruhigt ungemein.

Gruß

Volker

[greyhound]

Habe bei mir den Adapter nun auch installiert, bin dabei auf ein paar Probleme gestoßen.

• Konfigurationsseite "NAS-Einstellungen". Ich habe keinen Hinweis gefunden, dass der Pfad nicht mit Slash beginnen darf, habe das erst aus dem Skript entnommen.

• Der ioBroker läuft bei mir nicht unter root sondern unter einem Useraccount. D. h., bei Ausführung von "mount -t cifs -o username= …" bekomme ich folgenden Fehler: "mount: only root can use "--options" option" mittels sudo klappt es dann. Könnte sudo bei mount im Skript nicht generell genutzt werden?

• Die Ermittlung ob "cifs-utils" installiert ist, hat bei mir nicht funktioniert, habe es manuell nachinstalliert. Ich weiß auch nicht, ob "type -p mount" die richtige Abfrage ist. Bei mir liefert die Abfrage "/bin/mount". Besser wäre ggf. "apt -qq list cifs-utils", welches bei mir "cifs-utils/oldstable,oldstable,now 2:6.4-1 armhf [installed]" liefert, wenn nicht installiert: ""

• Im Backupskript bin ich der Meinung, dass beim Stoppen des iobroker der sleep-Befehl nach "iobroker stop" stehen sollte oder?

• In backitup.0.history.totalLastTime wurde ein Datum geschrieben und in backitup.0.history.html ein Eintrag vorgenommen, obwohl wegen dem Mounten das Backup fehlgeschlagen war. In backitup.0.output.line stand der Fehlercode. Über das Datum kann man "streiten", aber im Log hätte ich dann doch den Fehlercode erwartet, zumal der Wert in backitup.0.output.line beim nächsten Start des Adapters bzw. der nächsten Aktion überschrieben wird.

• Laut main.js wird der ein Backup auslösende Datenpunkt nach dem Backup wieder auf false gesetzt. Bei mir ist dies nicht geschehen (Vollbackup), ich denke, dass der Adapter nach dem Neustart (Stop ioBroker bei Backup aktiv) nichts mehr von dem laufenden Skript weiß. Eine Lösung wäre ggf. beim Start des Adapters zu ermitteln, ob das bash-Skript noch läuft und dann auf das Beenden des Skriptes zu warten (Abfrage per scheduler?) oder das Rücksetzen gleich via bash-Skript und SimpleAPI zu machen.

Ansonsten hat es wunderbar funktioniert, ein tolles lehrreiches Beispiel einer Skriptintegration in einen Adapter.

Danke

[simatec]

Es stehen gerade größere Veränderungen beim Adapter an.

shell wird komplett entfallen.

das mit sudo mount schauen wir uns noch einmal genauer an.

[HomeTed]

Kann mir einer sagen wie ich mich bei einer Multihost Umgebung richtig verhalte?

Brauche ich nur eine Instanz auf dem Master?

Oder brauche ich eine Instanz von Backitup auf jeden Raspberry?

[simatec]

Das Minimal sichert vom Master auch den Slave

Das komplette Backup sichert den kompletten iobroker Ordner auf dem die Instanz läuft

Gesendet von iPhone mit Tapatalk

[Segway]

Um meine MySQL Datenbank auf meinem NAS zu sichern über "backitup" kommt folgende Fehlermeldung ?

User und Passwort sind aber richtig:

backitup.0	2018-08-08 19:41:10.642	error	[minimal] mysqldump: Got error: 2003: Can't connect to MySQL server on '192.168.xxx.xxx' (111) when trying to connect
backitup.0	2018-08-08 19:41:10.479	error	[minimal] Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
backitup.0	2018-08-08 19:41:10.477	error	[minimal] mount error(16): Device or resource busy
backitup.0	2018-08-08 19:41:10.286	error	[minimal] use the device is found by lsof(8) or fuser(1).)
backitup.0	2018-08-08 19:41:10.285	error	[minimal] (In some cases useful info about processes that
backitup.0	2018-08-08 19:41:10.280	error	[minimal] umount: /opt/iobroker/backups: target is busy