NEWS
Adapter: iobroker.backitup (stable Release)
-
@simatec sagte in Adapter: iobroker.backitup (stable Release):
Was sagt die Konsole bei folgenden Befehl?
sudo mount 192.168.178.39:/volume1/iobroker/standard /opt/iobroker/backups
Der sagt (siehe oben):
mount.nfs: access denied by server while mounting 192.168.178.39:/volume1/iobroker/standard
@Einstein67, das ist ein interessanter Hinweis, denn ich arbeitete mit Proxmox. Ich muss nachher mal schauen ob der privilegiert ist. Gesetzt dem Fall, dass er es nicht ist, dann bin ich auch ratlos (zu wenig knowhow mit Proxmox).
-
Ich hoffe die Frage wurde hier schon nicht gestellt, aber da der Thread sowas von lang ist, will ich nicht wirklich über 2000 Kommentare lesen. Denke das kann jeder nachvollziehen.
Ich habe folgendes vor:
Umzug mit ioBroker von Raspberry PI 3B+ (damals mit dem fertigen Image "ioBroker_Image_RPi_2-3_20180401_stretch" installiert) auf eine Hyper-V VM mit Debian.Habe in der Anleitung vom backitup Adapter und auch im Forum mal was von einem "root fix" gelesen. Diesen habe ich noch nie ausgeführt. Ist also alles so wie damals im Image mit den Benutzern und Rechten.
-
- Frage: Muss/sollte ich diesen Fix ausführen um den backitup Adapert nutzen zu können bzw. sollte ich den Fix ausführen bevor ich das System wechseln will?
Im Forum habe ich gelesen, dass für einen Systemwechsel das "Standard Backup" gemacht werden soll. Werde ich so auch machen wollen.
-
- Frage: Was speichert das "Standard Backup"? Ich habe eigene Datenpunkte angelegt. Werden diese mit gespeichert?
-
- Frage: Desweiteren habe ich einige Adapter von GitHub in bestimmten Versionen installiert. Werden diese Adapter (oder auch generell alle Adapter) in den Version installiert die man hatte, oder "merkt" sich backitup nur welche Adapter installiert waren und installiert dann jeweils die letzte Version aus dem "stable channel"?
-
- Frage (eigentlich total doof): Speichert backitup auch die Einstellungen von den Adaptern?
Im Prinzip will ich einen Systemwechsel machen ohne irgendwelche Einstellungen (Adapter, eigene Datenpunkte usw.) machen zu müssen. Dafür ist ein Backup ja schließlich da.
Wäre super wenn mir jemand (oder am besten auch @simatec ) die Fragen beantworten könnte.
Vielen Dank schon mal. -
-
@el_malto
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.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.
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.
-
@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