Test Adapter ioBroker.backitup v3.1.x
-
Started restore ... [DEBUG] [jarvis] - Start Jarvis Restore ... [DEBUG] [jarvis] - filename for restore: /opt/iobroker/backups/jarvis.0_2021_05_06-02_00_27_backupiobroker.tar.gz [DEBUG] [jarvis] - jarvis tmp directory created: /opt/iobroker/backups/jarvis_0 [DEBUG] [jarvis] - old jarvis database directory was successfully deleted [DEBUG] [jarvis] - jarvis.0 stopped [ERROR] [jarvis] - jarvis restore not completed [ERROR] [jarvis] - Error: EPERM: operation not permitted, utime '/opt/iobroker/backups/jarvis_0/' [EXIT] 0Restore vom Synology NAS
-
@msiemers sagte in Test Adapter Backitup v2.1.x:
operation not permitted, utime
Da fehlen Rechte bzw. sind verbogen worden.
iobroker stop iobroker fixUnd nicht als root oder so rum hampeln.
-
Das habe ich schon gemacht. Ich arbeite nie mit dem root User.
-
========================================================================== Welcome to the ioBroker installation fixer! Script version: 2021-04-07 You might need to enter your password a couple of times. ========================================================================== ========================================================================== Installing prerequisites (1/3) ========================================================================== [sudo] password for xxxxxx: Hit:1 http://phoscon.de/apt/deconz focal InRelease Hit:2 http://archive.ubuntu.com/ubuntu focal InRelease Hit:3 https://repos.influxdata.com/ubuntu focal InRelease Ign:4 https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 InRelease Get:5 http://archive.ubuntu.com/ubuntu focal-updates InRelease [114 kB] Hit:6 https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release Hit:7 https://packages.grafana.com/oss/deb stable InRelease Hit:8 https://deb.nodesource.com/node_12.x focal InRelease Get:9 http://archive.ubuntu.com/ubuntu focal-security InRelease [114 kB] Get:11 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages [988 kB] Hit:12 https://dl.ubnt.com/unifi/debian stable InRelease Get:13 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages [777 kB] Fetched 1993 kB in 1s (1585 kB/s) Reading package lists... Done Installed gcc-c++ Installed python-dev ========================================================================== Checking ioBroker user and directory permissions (2/3) ========================================================================== Created /etc/sudoers.d/iobroker Fixing directory permissions... This system does not support setting default permissions. Do not use npm to manually install adapters unless you know what you are doing! ========================================================================== Checking autostart (3/3) ========================================================================== Enabling autostart... Autostart enabled! ========================================================================== Your installation was fixed successfully Run iobroker start to start ioBroker again! ========================================================================== -
@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.
-
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.
-
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. -
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') -
Was kann ich tun?
-
@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. -
@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?
-
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.
-
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. -
@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.
