NEWS
Test Adapter ioBroker.backitup v3.1.x
-
@thomas-braun Es geht um das Problem, dass man erst die Sicherung auf das Zielgerät zurück kopieren muss, damit man eine Jarvis-Sicherung als restore wieder einspielen kann. Siehe oben.
Haben wir letztens noch besprochen: https://forum.iobroker.net/topic/27267/test-adapter-backitup-v2-1-x/1225@mcu Ja, auch da hat simatec ja schon vermutet, dass das intiale Backup schon falsche Rechte hatte.
-
@mcu Ja, auch da hat simatec ja schon vermutet, dass das intiale Backup schon falsche Rechte hatte.
Wenn ich das Archiv manuell in das Backupverzeichnis /jarvis_0 kopiere und dann mit tar -xvzf entpacke erhalte ich folgendes Ergebnis:
. _BACKUP_DEVICES.json tar: _BACKUP_DEVICES.json: Cannot utime: Operation not permitted _BACKUP_LAYOUT.json tar: _BACKUP_LAYOUT.json: Cannot utime: Operation not permitted _BACKUP_SETTINGS.json tar: _BACKUP_SETTINGS.json: Cannot utime: Operation not permitted tar: .: Cannot utime: Operation not permitted tar: .: Cannot change mode to rwxr-xr-x: Operation not permitted tar: Exiting with failure status due to previous errorsDeine Vermutung scheint richtig zu sein. Das wird bestimmt mit den root Rechten auf dem backups Verzeichnis liegen. Ich kann mir nur nicht vorstellen
woher diese kommen. Ich arbeite wie bereits gesagt nie mit root. -
Wenn ich das Archiv manuell in das Backupverzeichnis /jarvis_0 kopiere und dann mit tar -xvzf entpacke erhalte ich folgendes Ergebnis:
. _BACKUP_DEVICES.json tar: _BACKUP_DEVICES.json: Cannot utime: Operation not permitted _BACKUP_LAYOUT.json tar: _BACKUP_LAYOUT.json: Cannot utime: Operation not permitted _BACKUP_SETTINGS.json tar: _BACKUP_SETTINGS.json: Cannot utime: Operation not permitted tar: .: Cannot utime: Operation not permitted tar: .: Cannot change mode to rwxr-xr-x: Operation not permitted tar: Exiting with failure status due to previous errorsDeine Vermutung scheint richtig zu sein. Das wird bestimmt mit den root Rechten auf dem backups Verzeichnis liegen. Ich kann mir nur nicht vorstellen
woher diese kommen. Ich arbeite wie bereits gesagt nie mit root.@msiemers
Das hängt ggf. davon ab wo du das Backup mit welchen Aktionen/Optionen zurückholst.
Liegt das auf einer Freigabe? NAS? Mit welchem Protokoll? SMB? NFS?Am Rande: Für MongoDB hast du 100% das falsche Repo in deinem Focal drin.
-
@msiemers
Das hängt ggf. davon ab wo du das Backup mit welchen Aktionen/Optionen zurückholst.
Liegt das auf einer Freigabe? NAS? Mit welchem Protokoll? SMB? NFS?Am Rande: Für MongoDB hast du 100% das falsche Repo in deinem Focal drin.
Grundsätzlich sollte das doch durch den BackitUp Adapter zurückgeholt werden, oder?
Wenn ich das von Hand mache, kopiere ich das einfach vom NAS auf meinen Mac und von dort dann per SFTP auf den ioBroker.Folgende Einstellungen habe ich in der Instanz:
Was meinst Du bezüglich der MongoDB?
Ich sehe gerade das der Haken "Als root Benutzer mounten (sudo)" gesetzt ist. Könnte der das Problem verursachen bzw. das Backup falsch erstellt haben?
-
Grundsätzlich sollte das doch durch den BackitUp Adapter zurückgeholt werden, oder?
Wenn ich das von Hand mache, kopiere ich das einfach vom NAS auf meinen Mac und von dort dann per SFTP auf den ioBroker.Folgende Einstellungen habe ich in der Instanz:
Was meinst Du bezüglich der MongoDB?
Ich sehe gerade das der Haken "Als root Benutzer mounten (sudo)" gesetzt ist. Könnte der das Problem verursachen bzw. das Backup falsch erstellt haben?
Mach mal die noserverino-Option weg.
Als root/sudo muss gemountet werden, weil nur der 'mit Optionen' mounten darf, muss also bleiben. @simatec wollte das glaube ich auch mal umbenennen, wenn ich mich recht entsinne.
Zu MongoDB:
https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4
ist das Repo für xenial, ubuntu 16.04
Du fährst aber offenbar focal, ubuntu 20.04.
Du schraubst also ein Bauteil von einem Golf 3 in deinen Golf 8. Kann funktionieren, muss aber nicht. Besser passende Teile verbauen, bzw. Repo anpassen. -
Mach mal die noserverino-Option weg.
Als root/sudo muss gemountet werden, weil nur der 'mit Optionen' mounten darf, muss also bleiben. @simatec wollte das glaube ich auch mal umbenennen, wenn ich mich recht entsinne.
Zu MongoDB:
https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4
ist das Repo für xenial, ubuntu 16.04
Du fährst aber offenbar focal, ubuntu 20.04.
Du schraubst also ein Bauteil von einem Golf 3 in deinen Golf 8. Kann funktionieren, muss aber nicht. Besser passende Teile verbauen, bzw. Repo anpassen.Wie ändere ich das mit der Mongo. Das andere werde ich mal testen.
Aber macht das Sinn wenn das manuelle kopieren und entpacken auch nicht funktioniert? -
Wie ändere ich das mit der Mongo. Das andere werde ich mal testen.
Aber macht das Sinn wenn das manuelle kopieren und entpacken auch nicht funktioniert?@msiemers sagte in Test Adapter Backitup v2.1.x:
Aber macht das Sinn wenn das manuelle kopieren und entpacken auch nicht funktioniert?
Beim mounten werden über masks und options die Rechte des frisch eingehängten Dateisystems angepasst, wenn es ein 'fremdes' Dateisystem ist, was die Unix-Rechte nicht kennt.
Wenn jetzt das Backup schon mit falscher/anderer Einstellung angelegt wurde, dann wird das beim mounten auch wieder so falsch zur Verfügung gestellt.
Kann sein, dass hier die Datei dem root gehört, weil das masking falsch ist und deswegen der iobroker da dann nicht zugreifen darf, weil der keine Rechte hat (siehe die Meldung zu 'utime') -
@msiemers sagte in Test Adapter Backitup v2.1.x:
Aber macht das Sinn wenn das manuelle kopieren und entpacken auch nicht funktioniert?
Beim mounten werden über masks und options die Rechte des frisch eingehängten Dateisystems angepasst, wenn es ein 'fremdes' Dateisystem ist, was die Unix-Rechte nicht kennt.
Wenn jetzt das Backup schon mit falscher/anderer Einstellung angelegt wurde, dann wird das beim mounten auch wieder so falsch zur Verfügung gestellt.
Kann sein, dass hier die Datei dem root gehört, weil das masking falsch ist und deswegen der iobroker da dann nicht zugreifen darf, weil der keine Rechte hat (siehe die Meldung zu 'utime')Was kann ich tun?
-
Wie ändere ich das mit der Mongo. Das andere werde ich mal testen.
Aber macht das Sinn wenn das manuelle kopieren und entpacken auch nicht funktioniert?@msiemers sagte in Test Adapter Backitup v2.1.x:
Wie ändere ich das mit der Mongo.
Es dürfte eine Datei
/etc/apt/sources.list.d/mongodb.list
(oder ganz ähnlich) auf dem System geben. In der wird xenial drin stehen. Das einfach duch focal ersetzen.sudo apt updateund es sollte passen.
-
@msiemers sagte in Test Adapter Backitup v2.1.x:
Wie ändere ich das mit der Mongo.
Es dürfte eine Datei
/etc/apt/sources.list.d/mongodb.list
(oder ganz ähnlich) auf dem System geben. In der wird xenial drin stehen. Das einfach duch focal ersetzen.sudo apt updateund es sollte passen.
Ok, und was mache ich mit meinem nicht funktionieren zurückwichen der Daten?
Ich hätte gern mein altes konfiguriertes Jarvis zurück. -
Ok, und was mache ich mit meinem nicht funktionieren zurückwichen der Daten?
Ich hätte gern mein altes konfiguriertes Jarvis zurück. -
@msiemers Hast du die Sicherung von jarvis als einzelne Datei ?
jarvis.0_2021_03_31-02_02_11_backupiobroker.tar.gzIst jetzt schon ein Restore gemacht worden?
-
@msiemers sagte in Test Adapter Backitup v2.1.x:
Wie ändere ich das mit der Mongo.
Es dürfte eine Datei
/etc/apt/sources.list.d/mongodb.list
(oder ganz ähnlich) auf dem System geben. In der wird xenial drin stehen. Das einfach duch focal ersetzen.sudo apt updateund es sollte passen.
-
Das mit der MongoDB ist wohl etwas umfangreicher . Nun meckert er irgendwelche gPG Schlüssel an.
@msiemers Mach 'nen eigenen Thread dafür auf.
Hat ja mit dem Backitup nix zu tun.
Und poste dort die vollständigen Meldungen rein. Meine Glaskugel ist ein wenig milchig. -
Ja die Datei vom NAS habe ich. Ich hatte mal versucht diese in das Verzeichnis is Backups/Jarvis_0 zu legen und die Wiederherstellung durchzuführen. Leider ohne Erfolg.
@msiemers Diese jarvis kopierst du in das Verzeichnis /opt/iobroker/backups.
Dann in dem Verzeichnis den Befehl ausführen:ls -lSollte so aussehen, wichtig "iobroker iobroker"! NATÜRLICH für DEINE JARVIS-DATEI
-rw-rwxr--+ 1 iobroker iobroker 27717050 Mär 17 02:01 historyDB_2021_03_17-02_00_44_backupiobroker.tar.gz -Falls das nicht so da drin steht, dann:
sudo chown -R iobroker:iobroker /opt/iobroker/backupsMelde Dich , wenn du soweit bist.
-
@msiemers Diese jarvis kopierst du in das Verzeichnis /opt/iobroker/backups.
Dann in dem Verzeichnis den Befehl ausführen:ls -lSollte so aussehen, wichtig "iobroker iobroker"! NATÜRLICH für DEINE JARVIS-DATEI
-rw-rwxr--+ 1 iobroker iobroker 27717050 Mär 17 02:01 historyDB_2021_03_17-02_00_44_backupiobroker.tar.gz -Falls das nicht so da drin steht, dann:
sudo chown -R iobroker:iobroker /opt/iobroker/backupsMelde Dich , wenn du soweit bist.
@mcu sagte in Test Adapter Backitup v2.1.x:
sudo chown -R iobroker:iobroker /opt/iobroker/backups
Habe ich gemacht. Der Befehl das Verzeichnis auf iobroker:iobroker umzuschreiben wird zwar ohne Fehlermeldung durchgeführt aber wenn ich dann wieder ls -ali mache ist wieder root:root drin.
-
@mcu sagte in Test Adapter Backitup v2.1.x:
sudo chown -R iobroker:iobroker /opt/iobroker/backups
Habe ich gemacht. Der Befehl das Verzeichnis auf iobroker:iobroker umzuschreiben wird zwar ohne Fehlermeldung durchgeführt aber wenn ich dann wieder ls -ali mache ist wieder root:root drin.
-
@msiemers sagte in Test Adapter Backitup v2.1.x:
ls -ali
Du bist vorher einmal aus dem Verzeichnis raus gegangen?
cd .. und dann sudo chown -R iobroker:iobroker /opt/iobroker/backups -
@mcu Ja bin ich. Ich habe schon alles versucht. Auch mal mit dem root User, mit dem ich eigentlich nicht arbeite kann ich die Besitzerrechte nicht ändern.
Support us
999
Online32.4k
Users81.5k
Topics1.3m
Posts