NEWS
Adapter: iobroker.backitup (stable Release)
-
@simatec sagte in Adapter: iobroker.backitup (stable Release):
Also den Installer Fix laut meiner Signatur würde ich einfach mal zur Sicherheit im Vorfeld ausführen. Das rückt dir eventuell fehlende Rechte richtig.
Ok werde ich machen.
Backitup speichert selber nix. Für das Standard Backup wird im Prinzip die eingebaute Backupmethode von iobroker genutzt.
Es werden dort alle Einstellungen gespeichert, die VIS und sämtliche andere Daten außer History und zigbee Datenbank.Das hatte ich gelesen. History verwende ich nicht.
Bezügl. Zigbee Datenbank. Da kann man im Backitup Adapter ja einen Haken machen, dass die mit gespeichert wird. Ist das dann auch bei dem "Standard Backup" der fall?Für einen Umzug ist ein Standard Backup notwendig.
Bei einem Restore werden alle Adapter (außer über Github installierte) neu installiert und die Einstellungen übernommen.
Github Adapter musst du manuell installieren.
Ab JS-Controller 2.0 wird sich da aber auch was ändern, so dass ab dieser Version dann auch Adapter vom Github automatisch installiert werden. Die JS-Controller befindet sich aber aktuell noch in einer recht frühen Beta Phase.
Sichere dir von deinen installierten Github Adaptern am besten die Einstellungen über das Webinterface des Adapters über die Pfeil-Buttons und spiele sie dann auf dein neues System zurück.Danke für den Tipp mit den Einstellungen.
-
@el_malto
Ja die Zigbee Datenbank ist ein separates Backup und kann auch so wieder hergestellt werden. -
@simatec
Hab gerade im js-controller 2.0 Beta Thread gelesen, dass die 2.0 Anfang Oktober kommen soll. Das wäre ja nicht mehr so lange hin und ich könnte mit dem Umzug noch warten.
Macht es bezüglich deiner Aussage:@simatec sagte in Adapter: iobroker.backitup (stable Release):
Github Adapter musst du manuell installieren.
Ab JS-Controller 2.0 wird sich da aber auch was ändern, so dass ab dieser Version dann auch Adapter vom Github automatisch installiert werden. Die JS-Controller befindet sich aber aktuell noch in einer recht frühen Beta Phase.mehr Sinn auf 2.0 zu warten und dann den Systemwechsel zu machen? Dann hätte man ja alle Adapter so wie man die vorher auch hatte.
-
@Einstein67 sagte in Adapter: iobroker.backitup (stable Release):
Was mir zum Thema "mount as root"aufgefallen ist:
In Proxmox-Containern (mittlerweile sehr beliebt für IOBroker) funktioniert das mounten nur, wenn der Container kein "unprivilegierter Container" ist!!
In einem privilegierten Container funktioniert es aber zu 100% zuverlässig.Vielleicht hilft das irgend jemanden mal ...
So ich habe eben mal endlich schauen können . Also in den Optionen steht "Unprivileged Container = No". D. h. ich müsste doch einen privilegierten Container haben und somit sollte das kein Problem für das unmögliche Backup sein oder?
@simatec, kann ich dir noch weitere Informationen bereitstellen, damit wir der Ursache auf die Schliche kommen? Ich würde echt gerne den tollen Adapter verwenden
-
@Buddinski88
Wenn dein Server richtig konfiguriert ist, dann wäre noch die Möglichkeit anstelle der IP den Hostname für den Mount mal zu testen -
Leider die gleiche Meldung:
root@ioBroker-prod:~# sudo mount diskstation:/volume1/iobroker/standard /opt/iobroker/backups mount.nfs: access denied by server while mounting diskstation:/volume1/iobroker/standard
Mich wundert das er im Debug-Log auch immer ein User uns Passwort angibt. NFS benötigt das doch gar nicht bzw. im Adapter ist da nichts änderbar?
Sind das noch Informationen meines Tests mit CIFS? -
@Buddinski88
Passt die IP die du in der Diskstation freigegeben hast mit der 50 am Ende?
Was passiert, wenn du probierst nur auf /volume1/iobroker zu mounten.Ich kenne leider die Diskstation nicht und kann dir somit leider nicht sagen, ob deine Einstellungen korrekt sind.
-
@Buddinski88 said in Adapter: iobroker.backitup (stable Release):
Also in den Optionen steht "Unprivileged Container = No". D. h. ich müsste doch einen privilegierten Container haben und somit sollte das kein Problem für das unmögliche Backup sein oder?
Ja das passt so!
Bei der Diskstation musst du natürlich auch noch die NFS Berechtigung für IP des IOBroker machen.
... oder besser einfach CIFS verwenden, da brauchst da gar nichts machen.
-
@simatec sagte in Adapter: iobroker.backitup (stable Release):
@Buddinski88
Passt die IP die du in der Diskstation freigegeben hast mit der 50 am Ende?
Was passiert, wenn du probierst nur auf /volume1/iobroker zu mounten.Ich kenne leider die Diskstation nicht und kann dir somit leider nicht sagen, ob deine Einstellungen korrekt sind.
Hab es auch mal mit * probiert. Das interessante ist, dass ich von den Containern in Proxmox ein NFS-Backup machen kann.
Gibts hier noch weitere Cracks die ihre Diskstation damit verwenden?
-
@Einstein67 sagte in Adapter: iobroker.backitup (stable Release):
@Buddinski88 said in Adapter: iobroker.backitup (stable Release):
Also in den Optionen steht "Unprivileged Container = No". D. h. ich müsste doch einen privilegierten Container haben und somit sollte das kein Problem für das unmögliche Backup sein oder?
Ja das passt so!
Bei der Diskstation musst du natürlich auch noch die NFS Berechtigung für IP des IOBroker machen.
... oder besser einfach CIFS verwenden, da brauchst da gar nichts machen.
CIFS bekomme ich leider auch nicht eingerichtet
-
Yes! Jetzt hat es geklappt. Mittels ...
sudo mount -t cifs -o username=iobroker,password=XXXX //192.168.178.39/iobroker/standard /opt/iobroker/backups
Konnte ich über Console das mounten durchführen.
Ich musste bei CIFS die Version SMB3 auswählen. Mit SMB1 und 2 klappt es nicht.
Danke für eure Hilfe/Motivation den Fehler zu finden -
@Buddinski88
OK auch ne Möglichkeit ... Aber die Diskstation sollte auch NFS können. -
@simatec sagte in Adapter: iobroker.backitup (stable Release):
@Buddinski88
OK auch ne Möglichkeit ... Aber die Diskstation sollte auch NFS können.Ist sicher nicht die optimale Lösung, aber erst mal werden Backups gemacht.
Die Diskstation kann NFS, vor allem weil ich meine Container von Proxmox auf meiner DS backuppe ... hm. -
Guten Morgen,
hatte einen Systermausfall, und bis in dem Zuge von meinem Tinker Board auf den Raspi 4 mit GB RAM umgezogen.
Nun habe ich hier schon gelesen, und möchte gernew Eure Meinung einholen, denn ich möchte das neu aufgesetzte System nicht wieder zerschießen.
Der Raspi wurde mit dem neuesten Image für Raspi aufgesetzt. Die Installationsstrucktur des Tinker war von Stand 2018.
Zurück gespielt über den Backitup Adapter habe ich ein KOMPLETT BACKUP des Tinker! Nun habe ich hier gelesen, das hätte ich wohl lieber nicht gemacht. Es liegt kein Minimal Backup vor, ich kann vom alten System auch keins mehr machen, da die SD defekt ist.
Aufmerksam auf dies Thema hier bin ich geworden, da ich Probleme habe, wohl gerade mit rechten . Das sollte der Fix ja beheben, oder? Z.B. kann der SQL Adapter die Daten aus der SQL nicht laden, schreiben kann er augenscheinlich. IN einem anderen Thema hatte ich dort nach Hilfe gefragt, und @Glasfaser hat mich auf dies Thema hier aufmerksam gemacht.
Nun meine eigentliche Sorge, das vorangeschriebene soll einen Überblick der Situation verschaffen. Das System ist auf meinen Raspi auf eine externe SSD gemountet, wird es Probleme geben, wenn ich den Fix mache? Wird der Befehl direkt nach Einloggen per SSH eingegeben, oder muss ich erst in iobroker Verzeichnis wechseln?
Vielen Dank
-
@AxelF1977
Der Fix löst im Normalfall deine Rechteprobleme eigenständig.
Du kannst ihn bedenkenlos nach einloggen per ssh ausführen.curl -sL https://iobroker.net/fix.sh | bash -
Vorher bitte ein
iobroker stop
ausführen. -
@simatec said in Adapter: iobroker.backitup (stable Release):
@AxelF1977
Der Fix löst im Normalfall deine Rechteprobleme eigenständig.
Du kannst ihn bedenkenlos nach einloggen per ssh ausführen.curl -sL https://iobroker.net/fix.sh | bash -
Vorher bitte ein
iobroker stop
ausführen.Hallo, werde ich heute Abend probieren.
Vielen Dank für die schnelle Antwort
-
@AxelF1977 said in Adapter: iobroker.backitup (stable Release):
iobroker sto
@simatec ich kämpfe jetzt hier mit dem gleichen Problem, dass ich schon länger habe
pi@ioBroker-RasPi4:~ $ iobroker stop /usr/bin/env: „node\r“: Datei oder Verzeichnis nicht gefunden
das selbe wenn ich in den Ordner /opt/iobroker wechsel.
Wie gesagt, liegt alles auf einer externen SSD, die per mount eingebunden ist.
Was mich auch wundert, ich kann die "externe" Partition auch nicht ansprechen, das System läuft aber davon
Disk /dev/sda: 232,9 GiB, 250059350016 bytes, 488397168 sectors Disk model: Portable SSD T5 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 33553920 bytes pi@ioBroker-RasPi4:~ $ cd /dev/sda -bash: cd: /dev/sda: Ist kein Verzeichnis
Eine Idee was ich tun soll?
Danke
-
@AxelF1977 said in Adapter: iobroker.backitup (stable Release):
curl -sL https://iobroker.net/fix.sh | bash -
EDIT
Mit
sudo systemctl stop iobroker
konnte ich ioBroker stoppen, und der Fix wurde laut Konsole erfolgreich eingespielt
-
Moinsen,
ich habe das Problem, dass der Adapter keine Backups erstellt. Das liegt vermutlich am Hostname.Im Detail versucht der Adapter ständig "iobroker" als Hostname zu mounten. Dieser ist durch die installation auch ursprünglich eingestellt gewesen, doch habe ich diesen schon auf den Hostname meines Synology NAS geändert. Dennoch steht im debug immer "iobroker".
Hier noch ein paar Details zu meiner Umgebung.
- Synology NAS 412+ mit Docker
- ioBroker image gestern geladen und neu aufgesetzt. Hatte den hostname als ip ausprobiert, was durch die Punkte nicht sauber rückgängig zu machen war.
- Der Container läuft mit erhöten rechten und host Netzwerk
- Hostname wie folgt über die Konsole im DSM geändert
pkill io iobroker host set [hostname meines NAS] node node_modules/iobroker.js-controller/controller.js >/opt/scripts/docker_iobroker_log.txt 2>&1 &
In der Ausgabe nach dem Setzen des Hostnames wurden alle Adapter (>20) auch Korrekt mit dem neuen Hostname angezeigt. Auch die Weboberfläche zeigt den neuen Hostname an.
Hier noch ein debug Log des backitup adapters:
2019-10-06 11:10:41.157 - debug: backitup.0 [minimal/mount] [undefined sudo: Hostname iobroker kann nicht aufgelöst werden 2019-10-06 11:10:41.158 - debug: backitup.0 [minimal/mount] sudo: Die Audit-Nachricht kann nicht gesendet werden: Unbekannter Fehler -1 2019-10-06 11:10:41.158 - debug: backitup.0 [minimal/mount] sudo: pam_open_session: Systemfehler 2019-10-06 11:10:41.159 - debug: backitup.0 [minimal/mount] sudo: Regelwerks-Plugin konnte Sitzung nicht initialisieren 2019-10-06 11:10:41.161 - debug: backitup.0 [minimal/mount] [IGNORED] Error: Command failed: sudo mount -t cifs -o username=backup,password=thepassword,rw,file_mode=0777,dir_mode=0777 //nas-ip/backups/ioBroker /opt/iobroker/backups 2019-10-06 11:10:41.161 - debug: backitup.0 [minimal/mount] sudo: Hostname iobroker kann nicht aufgelöst werden 2019-10-06 11:10:41.162 - debug: backitup.0 [minimal/mount] sudo: Die Audit-Nachricht kann nicht gesendet werden: Unbekannter Fehler -1 2019-10-06 11:10:41.162 - debug: backitup.0 [minimal/mount] sudo: pam_open_session: Systemfehler 2019-10-06 11:10:41.165 - debug: backitup.0 [minimal/mount] sudo: Regelwerks-Plugin konnte Sitzung nicht initialisieren 2019-10-06 11:10:50.134 - debug: backitup.0 [minimal/minimal] Backup created: /opt/iobroker/backups/minimal_2019_10_06-11_10_41_backupiobroker.tar.gz 2019-10-06 11:10:50.186 - debug: backitup.0 [minimal/minimal] done 2019-10-06 11:10:50.195 - debug: backitup.0 [minimal/cifs] done 2019-10-06 11:10:50.200 - debug: backitup.0 [minimal/clean] Backup files not deleted from /opt/iobroker/backups because some errors. 2019-10-06 11:10:50.201 - debug: backitup.0 [minimal/clean] done 2019-10-06 11:10:50.258 - debug: backitup.0 [minimal/history] backitup.0.history.html
Hat jemand eine idee, wie der Adapter den Hostname richtig liest oder wo ich das ändern kann?
-
Ab sofort ist die Version 1.2.1 verfügbar ....
Changelog
1.2.1 (19.10.2019)
- (simatec) Fix CIFS password with special characters