NEWS
Adapter: iobroker.backitup (stable Release)
-
nur eine Verständnisfrage:
Auf dem produktiven System habe ich im Moment keine Zigbee-Devices am laufen,
da ich es erst am Teststystem probieren will.
Spricht etwas dagegen, daß ich nur die Zigbee-Database sichere und dann ins produktive System übeernehme?
Der Coordinator bleibt ja der selbe. Nur der Platz auf dem das Testsystem
steht soll der Platz für das produktive System werden.IObroker auf dem NUC als VM.
Da ich noch keine Aktoren habe, wird momentan via Radar nur der AB der Fritzbox ein- und ausgeschaltet.
Welches Smarthome-System es letztendlich wird, weiß ich noch nicht. Vielleicht kommen auch nur Zigbee-Geräte ins Haus. -
nur eine Verständnisfrage:
Auf dem produktiven System habe ich im Moment keine Zigbee-Devices am laufen,
da ich es erst am Teststystem probieren will.
Spricht etwas dagegen, daß ich nur die Zigbee-Database sichere und dann ins produktive System übeernehme?
Der Coordinator bleibt ja der selbe. Nur der Platz auf dem das Testsystem
steht soll der Platz für das produktive System werden. -
Nabend.
Nach meinem Umstieg von 2x Raspi im Mulithost auf ein Multihostsystem bestehend aus einem NUC mit Debian (auf Proxmox) und einem Raspi (zum GPIO Abgriff) bekomme ich per Telegramm keine Nachrichten nach Abschluss des Backups mehr. Das Backup selber funktioniert aber. Auch vorher bei den 2x Raspi) kamen die Meldungen per Telegramm nicht immer.
Bei mir läuft je eine Instanz von backitup auf Master und Slave. Backupziel ist ein Synology NAS.Das normale Versenden von Telegrammeldungen per Javascript funktioniert problemlos.
Was ich bisher getan habe:
- backitup und Telegramm auf debug gestellt. Leider ohne nennenswerte Aussagen im Log.
- backitup Adapter auf beiden Geräten de- und wieder neuinstalliert
- Telegramm Adapter neu installiert
Alles bisher ohne Ergebnis...
Iobroker unter Debian:
debian@iobroker-server:~$ node -v
v10.15.3
debian@iobroker-server:~$ nodejs -v
v10.15.3
debian@iobroker-server:~$ npm -v
6.9.0iobroker auf dem Raspi:
pi@iobroker-Pi:~ $ node -v
v8.16.0
pi@iobroker-Pi:~ $ nodejs -v
v8.16.0
pi@iobroker-Pi:~ $ npm -v
6.4.1Hier mal das Log der manuellen Ausführung eines minimalen Backups:
...Update 20:31 Uhr: Nach dem Deaktivieren von "Zigbee-Datenbank speichern (Standard)" läuft es nun... ;-)
-
Nabend.
Nach meinem Umstieg von 2x Raspi im Mulithost auf ein Multihostsystem bestehend aus einem NUC mit Debian (auf Proxmox) und einem Raspi (zum GPIO Abgriff) bekomme ich per Telegramm keine Nachrichten nach Abschluss des Backups mehr. Das Backup selber funktioniert aber. Auch vorher bei den 2x Raspi) kamen die Meldungen per Telegramm nicht immer.
Bei mir läuft je eine Instanz von backitup auf Master und Slave. Backupziel ist ein Synology NAS.Das normale Versenden von Telegrammeldungen per Javascript funktioniert problemlos.
Was ich bisher getan habe:
- backitup und Telegramm auf debug gestellt. Leider ohne nennenswerte Aussagen im Log.
- backitup Adapter auf beiden Geräten de- und wieder neuinstalliert
- Telegramm Adapter neu installiert
Alles bisher ohne Ergebnis...
Iobroker unter Debian:
debian@iobroker-server:~$ node -v
v10.15.3
debian@iobroker-server:~$ nodejs -v
v10.15.3
debian@iobroker-server:~$ npm -v
6.9.0iobroker auf dem Raspi:
pi@iobroker-Pi:~ $ node -v
v8.16.0
pi@iobroker-Pi:~ $ nodejs -v
v8.16.0
pi@iobroker-Pi:~ $ npm -v
6.4.1Hier mal das Log der manuellen Ausführung eines minimalen Backups:
...Update 20:31 Uhr: Nach dem Deaktivieren von "Zigbee-Datenbank speichern (Standard)" läuft es nun... ;-)
@eumats
Welche Benachrichtigung kam nicht? Vom Master oder Slave?
Wo läuft deine Telegram Instanz auf dem Master oder Slave? -
@eumats
Welche Benachrichtigung kam nicht? Vom Master oder Slave?
Wo läuft deine Telegram Instanz auf dem Master oder Slave? -
Hi zusammen,
habe gerade versucht Backitup mit Sicherung auf meinem Synology NAS einzurichten.
Die Sicherungen werden angelegt und im Ordner /opt/iobroker/backups abgelegt. Aber das Verschieben auf das NAS funktioniert nicht. Der user iobroker sollte bei mir eigentlich root rechte haben.
Folgenden LOG bekomme ich:backitup.0 2019-06-01 21:48:26.484 debug system.adapter.admin.0: logging true
backitup.0 2019-06-01 21:47:42.252 debug [minimal/history] backitup.0.history.html
backitup.0 2019-06-01 21:47:42.220 debug [minimal/clean] done
backitup.0 2019-06-01 21:47:42.219 debug [minimal/clean] Backup files not deleted from /opt/iobroker/backups because some errors.
backitup.0 2019-06-01 21:47:42.216 debug [minimal/cifs] done
backitup.0 2019-06-01 21:47:42.209 debug [minimal/minimal] done
backitup.0 2019-06-01 21:47:42.193 debug [minimal/minimal] Backup created: /opt/iobroker/backups/minimal_2019_06_01-21_47_38_backupiobroker.tar.gz
backitup.0 2019-06-01 21:47:38.685 debug [minimal/mount] mount: only root can use "--options" option
backitup.0 2019-06-01 21:47:38.684 debug [minimal/mount] [IGNORED] Error: Command failed: mount -t cifs -o username=xxx xxx,password=xxx,rw,file_mode=0777,dir_mode=0777 //ipi.pip.i.pip/Familie/03_SmartHome/Backup/ioBroker Stand
backitup.0 2019-06-01 21:47:38.673 debug [minimal/mount] [undefined mount: only root can use "--options" option -
Hi zusammen,
habe gerade versucht Backitup mit Sicherung auf meinem Synology NAS einzurichten.
Die Sicherungen werden angelegt und im Ordner /opt/iobroker/backups abgelegt. Aber das Verschieben auf das NAS funktioniert nicht. Der user iobroker sollte bei mir eigentlich root rechte haben.
Folgenden LOG bekomme ich:backitup.0 2019-06-01 21:48:26.484 debug system.adapter.admin.0: logging true
backitup.0 2019-06-01 21:47:42.252 debug [minimal/history] backitup.0.history.html
backitup.0 2019-06-01 21:47:42.220 debug [minimal/clean] done
backitup.0 2019-06-01 21:47:42.219 debug [minimal/clean] Backup files not deleted from /opt/iobroker/backups because some errors.
backitup.0 2019-06-01 21:47:42.216 debug [minimal/cifs] done
backitup.0 2019-06-01 21:47:42.209 debug [minimal/minimal] done
backitup.0 2019-06-01 21:47:42.193 debug [minimal/minimal] Backup created: /opt/iobroker/backups/minimal_2019_06_01-21_47_38_backupiobroker.tar.gz
backitup.0 2019-06-01 21:47:38.685 debug [minimal/mount] mount: only root can use "--options" option
backitup.0 2019-06-01 21:47:38.684 debug [minimal/mount] [IGNORED] Error: Command failed: mount -t cifs -o username=xxx xxx,password=xxx,rw,file_mode=0777,dir_mode=0777 //ipi.pip.i.pip/Familie/03_SmartHome/Backup/ioBroker Stand
backitup.0 2019-06-01 21:47:38.673 debug [minimal/mount] [undefined mount: only root can use "--options" option -
habe ich beides nochmal geprüft mein User ist in der gruppe root und cifs-utils sind jetzt auch installiert.
ohne root mount gleicher log.
Kann das Problem eventuell daran liegen das meine NAS Benutzer ein ö im Namen hat?
mit root mount bekomme ich jetzt folgendes: -
habe ich beides nochmal geprüft mein User ist in der gruppe root und cifs-utils sind jetzt auch installiert.
ohne root mount gleicher log.
Kann das Problem eventuell daran liegen das meine NAS Benutzer ein ö im Namen hat?
mit root mount bekomme ich jetzt folgendes: -
Hallo,
habe jetzt auf einen Windows Rechner migriert. Jetzt wäre es praktisch, wenn man die history-Daten ebenfals täglich auf die Synology sichern könnte. Beim Orange Pi habe ich das über ein rsync gemacht, lange bevor es diesen praktischen Adapter hier gab. Bevor ich jetzt wieder eine Lösung für Windows schnitze, frage ih mal, ob hiermit so etwas möglich oder geplant ist. -
Hallo,
habe jetzt auf einen Windows Rechner migriert. Jetzt wäre es praktisch, wenn man die history-Daten ebenfals täglich auf die Synology sichern könnte. Beim Orange Pi habe ich das über ein rsync gemacht, lange bevor es diesen praktischen Adapter hier gab. Bevor ich jetzt wieder eine Lösung für Windows schnitze, frage ih mal, ob hiermit so etwas möglich oder geplant ist.@klassisch
Das sichern der History Daten ist für backitup geplant.
Kommt sicher in der der nächsten Versionen. -
Klasse, vielen Dank für die Info! Dann muß ich nichts rumfrickeln. In der Zwischenzeit mache ich dann die history Backups einmal die Woche manuell über den TC, oder so..
-
@simatec
ich habe mir anderem Benutzer auf dem NAS und kurzen Passwort immernoch den gleichen Fehler.
Was könnte noch die Ursache seien? -
Ich habe heute einen Umzug vom Raspi3b auf den 4er vollzogen. Hat alles ganz gut geklappt. Das einzige Problem was ich noch habe ist, dass ich das mysql backup nicht wiederherstellen kann. Das Backup liegt auf einem FTP Server. Wenn ich das gewünschte sql backup auswähle und dann auf wiederherstellen klicke, dann kommt noch der hinweis, dass iobroker gestoppt und wieder gestartet wird. Nach dem Bestätigen passiert aber nichts. Hab dann Backitup auf Debug gestellt und das einzige was im Log erscheint ist:
backitup.0 2019-07-15 14:17:24.213 debug system.adapter.admin.0: logging true backitup.0 2019-07-15 14:17:14.482 debug Test: mysql_2019_07_15-13_43_29_backupiobroker.tar.gz statistics.0 2019-07-15 14:17:09.550 debug system.adapter.admin.0: logging false backitup.0 2019-07-15 14:17:09.550 debug system.adapter.admin.0: logging false backitup.0 2019-07-15 14:17:07.759 debug sendTo "list" to system.adapter.admin.0 from system.adapter.backitup.0 backitup.0 2019-07-15 14:17:05.723 debug FTP connected.Mehr passiert leider nicht. Auch meine geloggten Werte erscheinen z.B. im flot nicht. Nur die neuen die aktuell wieder geloggt werden
-
Ich habe heute einen Umzug vom Raspi3b auf den 4er vollzogen. Hat alles ganz gut geklappt. Das einzige Problem was ich noch habe ist, dass ich das mysql backup nicht wiederherstellen kann. Das Backup liegt auf einem FTP Server. Wenn ich das gewünschte sql backup auswähle und dann auf wiederherstellen klicke, dann kommt noch der hinweis, dass iobroker gestoppt und wieder gestartet wird. Nach dem Bestätigen passiert aber nichts. Hab dann Backitup auf Debug gestellt und das einzige was im Log erscheint ist:
backitup.0 2019-07-15 14:17:24.213 debug system.adapter.admin.0: logging true backitup.0 2019-07-15 14:17:14.482 debug Test: mysql_2019_07_15-13_43_29_backupiobroker.tar.gz statistics.0 2019-07-15 14:17:09.550 debug system.adapter.admin.0: logging false backitup.0 2019-07-15 14:17:09.550 debug system.adapter.admin.0: logging false backitup.0 2019-07-15 14:17:07.759 debug sendTo "list" to system.adapter.admin.0 from system.adapter.backitup.0 backitup.0 2019-07-15 14:17:05.723 debug FTP connected.Mehr passiert leider nicht. Auch meine geloggten Werte erscheinen z.B. im flot nicht. Nur die neuen die aktuell wieder geloggt werden
@daniel_iobroker
Hast du mysqldump installiert und den richtigen Pfad zu mysqldump in den backitup Einstellungen angegeben? -
@simatec Pfad habe ich keinen eingestellt, da hier immer der Standardpfad passte. Bin jetzt aber draufgekommen, warum das restore nicht klappte. Meine Backups werden ja über einen FTP Server übertragen. Das standard bzw. komplett Backup funktioniert hier einwandfrei. Bei dem Backup der sql Datenbank gibt es hier jedoch ein Problem. Das Backup wird anscheinend zuerst auf die SD Karte gemacht (gleich wie bei standard bzw. komplett Backup) und erst dann übertragen. Die SQL Datei wird jedoch IMMER fehlerhaft übertragen. Die Datei ist unvollständig und hat immer nur ein paar kb. Hab nun den alten Raspi nochmal gestartet und hab direkt über ftp auf den Pi zugegriffen und dort die Datei zuerst auf einen Rechner kopiert - kontrolliert - und dann wieder auf den neuen Pi aufgespielt. Hier klappte dann nun das einspielen des Backups über den Backitup Adapter ohne Probleme.
Leider wurden dadurch die neuen Daten überschrieben. Somit fehlen mir jetzt 1,5 Tage in der Aufzeichnung.
Vor dem Wiederherstellen habe ich vom neuen Pi auch ein Backup gemacht. Wollte danach auch diese sql Daten wiederherstellen (Damit die Lücke von Gestern auf Heute wieder vorhanden ist) dann werden jedoch wieder die Daten von davor gelöscht. Habe jetzt wieder die alten Daten wiederhergestellt, so habe ich die alten Daten wieder und mir fehlen "nur" die Daten von den letzten 1,5 Tagen.
-
@simatec Pfad habe ich keinen eingestellt, da hier immer der Standardpfad passte. Bin jetzt aber draufgekommen, warum das restore nicht klappte. Meine Backups werden ja über einen FTP Server übertragen. Das standard bzw. komplett Backup funktioniert hier einwandfrei. Bei dem Backup der sql Datenbank gibt es hier jedoch ein Problem. Das Backup wird anscheinend zuerst auf die SD Karte gemacht (gleich wie bei standard bzw. komplett Backup) und erst dann übertragen. Die SQL Datei wird jedoch IMMER fehlerhaft übertragen. Die Datei ist unvollständig und hat immer nur ein paar kb. Hab nun den alten Raspi nochmal gestartet und hab direkt über ftp auf den Pi zugegriffen und dort die Datei zuerst auf einen Rechner kopiert - kontrolliert - und dann wieder auf den neuen Pi aufgespielt. Hier klappte dann nun das einspielen des Backups über den Backitup Adapter ohne Probleme.
Leider wurden dadurch die neuen Daten überschrieben. Somit fehlen mir jetzt 1,5 Tage in der Aufzeichnung.
Vor dem Wiederherstellen habe ich vom neuen Pi auch ein Backup gemacht. Wollte danach auch diese sql Daten wiederherstellen (Damit die Lücke von Gestern auf Heute wieder vorhanden ist) dann werden jedoch wieder die Daten von davor gelöscht. Habe jetzt wieder die alten Daten wiederhergestellt, so habe ich die alten Daten wieder und mir fehlen "nur" die Daten von den letzten 1,5 Tagen.
@daniel_iobroker
Danke für dein Feedback. Schaue ich mir mal an. -
@daniel_iobroker
Vielen Dank für die Fehlersuche.
Ich habe das fehlerhafte Restore zuletzt am 20.4.2019 bemängelt, hatte aber keinen Erfolg damit.
Jetzt hast Du den Beweis erbracht, daß tatsächlich ein Fehler vorliegt.
Hoffentlich wird das jetzt gefixt.
327
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge