[Fehler] Backup und Restore

[Oekel]

Hi,

ich habe gerade etwas (erster Versuch) mit den Dateirechten zu kämpfen.
Folgendes ist passiert:

Code: Alles auswählen

openhabian@openhabian:/ $ sudo $OPENHAB_RUNTIME/bin/backup
...
Success! Backup made in /var/lib/openhab/backups/openhab-backup-21_11_06-13_23_02.zip

Dann in einem Ordner auf meinem Ubuntu 20.04:

Code: Alles auswählen

scp -r openhabian@192.168.1.11:/var/lib/openhab/backups /test/OpenHAB_Raspi_Backup

Neuen Raspi hergenommen und mit etcher das Image auf eine 64GB Karte gebügelt.
einige Minuten laufen lassen und auf dem Browser drauf zugegriffen.

Code: Alles auswählen

sudo /bin/systemctl stop openhab.service

Dann bekam ich mittels scp die Datei schon mal nicht zurückgespielt (access denied)
Also SD-Karte wieder an den Laptop und die Datei über Nautilus kopiert.

Wieder in den Raspberry 4 und mittls SSH verbunden:

Code: Alles auswählen

###############################################################################
###############  openhabian  ##################################################
###############################################################################
##        Ip = 192.168.1.11
##   Release = Raspbian GNU/Linux 10 (buster)
##    Kernel = Linux 5.10.63-v7l+
##  Platform = Raspberry Pi 4 Model B Rev 1.1
##    Uptime = 0 day(s). 0:0:36
## CPU Usage = 51.76% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
##  CPU Load = 1m: 0.96, 5m: 0.26, 15m: 0.09
##    Memory = Free: 3.32GB (88%), Used: 0.46GB (12%), Total: 3.79GB
##      Swap = Free: 2.43GB (100%), Used: 0.00GB (0%), Total: 2.43GB
##      Root = Free: 51.26GB (91%), Used: 4.59GB (9%), Total: 58.26GB
##   Updates = 0 apt updates available.
##  Sessions = 1 session(s)
## Processes = 132 running processes of 32768 maximum processes
###############################################################################

(Die Vergabe einen ersten Benutzers unter http://192.168.1.11:8080/auth habe ich nun beim zweiten Versuch übersprungen)

Code: Alles auswählen

sudo $OPENHAB_RUNTIME/bin/backup

openhabian@openhabian:/var/lib/openhab/backups $ ls -l
total 2724
-rw-rw-rw- 1 root    root    2568399 Nov  6 13:33 openhab-backup-21_11_06-13_23_02.zip
-rw-r--r-- 1 openhab openhab  215665 Nov  6 17:03 openhab-backup-21_11_06-17_03_55.zip

sudo $OPENHAB_RUNTIME/bin/restore $OPENHAB_BACKUPS/openhab-backup-21_11_06-17_03_55.zip
Success!!

sudo chown openhab:openhab openhab-backup-21_11_06-13_23_02.zip
sudo $OPENHAB_RUNTIME/bin/restore $OPENHAB_BACKUPS/openhab-backup-21_11_06-13_23_02.zip
...
cp: cannot create ..... no space left on device.
...
sudo $OPENHAB_RUNTIME/bin/restore $OPENHAB_BACKUPS/openhab-backup-21_11_06-13_23_02.zip
cp: cannot remove ...: Read-only file system

Was geht hier alles verkehrt?
Laut login hat er die SD-Karte doch erfolgreich erweitert. Wieso dann kein Platz mehr?
Und wieso das Read-only beim unmittelbaren zweiten Versuch das Backup herzustellen?
(wie man sieht ist das script ok, da sich ein openhab-backup-21_11_06-17_03_55.zip (gleich nach dem ersten login) auch wieder einspielen lässt.

Verzweifelte Grüße
David

[Oekel]

https://community.openhab.org/t/could-n ... m/117867/2
sudo openhabian-config menu option 38 (zram) endet in

Code: Alles auswählen

There was an error or interruption during the execution of:                  │ 
                                                             │   "30 | System Settings"

[Oekel]

Ich denke folgendes ist wohl falsch:

Code: Alles auswählen

openhabian@openhabian:/var/lib/openhab $ ls -l
total 864
drwxr-xr-x 2 openhab openhab   4096 Nov  6 17:06 backups
drwxr-xr-x 4 root    root      4096 Nov  6 13:23 config
drwxr-xr-x 3 root    root      4096 Nov  6 13:23 etc
-rw-r--r-- 1 root    root    105058 Nov  6 13:23 hs_err_pid11086.log
-rw-r--r-- 1 root    root     99958 Nov  6 13:23 hs_err_pid12378.log
-rw-r--r-- 1 root    root    105258 Nov  6 13:23 hs_err_pid30011.log
-rw-r--r-- 1 root    root    100502 Nov  6 13:23 hs_err_pid30966.log
-rw-r--r-- 1 root    root    103037 Nov  6 13:23 hs_err_pid3978.log
-rw-r--r-- 1 root    root    102098 Nov  6 13:23 hs_err_pid5043.log
-rw-r--r-- 1 root    root    113827 Nov  6 13:23 hs_err_pid660.log
-rw-r--r-- 1 root    root    100555 Nov  6 13:23 hs_err_pid8305.log
drwxr-xr-x 3 root    root      4096 Nov  6 13:23 jsondb
drwxr-xr-x 2 root    root      4096 Nov  6 13:23 kar
drwxr-xr-x 2 root    root      4096 Nov  6 13:23 log
drwxr-xr-x 1 root    root      4096 Nov  6 13:23 persistence
drwxr-xr-x 2 root    root      4096 Nov  6 13:23 secrets
drwxr-xr-x 2 root    root      4096 Nov  6 13:23 zwave

Daher:

Code: Alles auswählen

sudo chown -R openhab:openhab /var/lib/openhab
chown: changing ownership of '/var/lib/openhab/persistence/rrd4j/outdoor_ForecastHours06_Cloudiness.rrd': Read-only file system

Zwischenzeitlich hatte ich neu gestartet und da ging chown openhab:openhab openhab noch.
Dann nach dem gescheiterten Einspielen den Backups mit

Code: Alles auswählen

Okay to Continue? [y/N]: y
Moving system files in userdata to temporary folder
Deleting old userdata folder...
rm: cannot remove '/var/lib/openhab/persistence': Device or resource busy
Restoring system files in userdata...
Deleting old conf folder...
Restoring openHAB with backup configuration...
cp: error writing '/var/lib/openhab/persistence/rrd4j/outdoor_ForecastHours12_Rain.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/LocalWeatherandForecast_ForecastHours12_Humidity.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/ZWaveNode004SpiritThermostaticValve_Batterieladung.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/ZWaveNode006SpiritThermostaticValve_Dimmer.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/LocalWeatherandForecast_ForecastHours21_Apparenttemperature.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/outdoor_ForecastHours24_Pressure.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/ZWaveNode002SpiritThermostaticValve_Batterieladung.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/OneCallAPIWeatherandForecast_ForecastHours02_Apparenttemperature.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/ZWaveNode003SpiritThermostaticValve_Alarmpower.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/outdoor_ForecastHours24_Maxtemperature.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/ZWaveNode020FGMS001MotionSensor_MotionAlarm.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/OneCallAPIWeatherandForecast_ForecastHours04_Winddirection.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/outdoor_ForecastHours06_Apparenttemperature.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/ZWaveNode021SpiritThermostaticValve_Thermostatmode.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/OneCallAPIWeatherandForecast_Current_Windspeed.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/OneCallAPIWeatherandForecast_ForecastHours03_Visibility.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/LocalWeatherandForecast_ForecastHours09_Maxtemperature.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/OneCallAPIWeatherandForecast_ForecastHours10_Precipprobability.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/outdoor_ForecastHours09_Winddirection.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/LocalWeatherandForecast_ForecastHours21_Mintemperature.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/outdoor_Bewolkung.rrd': No space left on device
cp: error writing '/var/lib/openhab/persistence/rrd4j/OneCallAPIWeatherandForecast_ForecastHours08_Winddirection.rrd': No space left on device
Failed to copy /tmp/openhab/restore/userdata/ to /var/lib/openhab/...

Waren die Dateien alle wieder root:root
Irgendetwas läuft da mächtig schief. Ich werde jetzt wieder den Pi3B hochfahren, auf dem noch alles richtig ist und das Projekt mit dem 4B vertagen....

[udo1toni]

Also, Du musst openHABian schon seine Arbeit erledigen lassen. das heißt, es reicht nicht, ein paar Minuten zu warten, nachdem Du das Image zum ersten Mal gestartet hast.
Gewöhnlich kommen sich zwei laufende openHAB Instanzen nicht in die Quere, solange eine von beiden noch nicht konfiguriert ist. Soll heißen: Flashe die SD-Karte noch mal neu und starte den Pi4. Lass ihn einfach laufen.
Wenn Du Dich einloggst, prüfe zunächst, ob openHABian fertig mit der Arbeit ist. z.B. mit

Code: Alles auswählen

ps -aux | grep openhabian

da sollte es keine Ausgabe geben (außer die eine Zeile mit dem grep-Befehl).

Erzeuge ein Backup der aktuellen (leeren) Konfiguration. Prüfe, ob die Rechte für das Dateisystem passen. Kopiere das Backup des alten Systems ins neue System. Aber bitte nicht direkt nach /var/lib/openhab/backups, sondern kopiere die Datei ins home-Verzeichnis. Tue das vom Pi4 aus gerne auch direkt aus dem alten System abgreifen, der User ist ja der gleiche.
Anschließend verschiebst Du die Datei mit root-Rechten aus dem home-Verzeichnis von openhabian ins Zielverzeichnis (also /var/lib/openhab/backups/). Wechsele in das Verzeichnis und prüfe, dass die Besitzrechte stimmen. Falls nicht, passe sie an (mit chown und chgrp).
Anschließend solltest Du sowohl openHAB beenden als auch ZRAM deaktivieren. Das Zurückspielen des Backups benötigt meines Wissens immer root-Rechte.
Wenn Du soweit gekommen bist, kannst Du noch mit

Code: Alles auswählen

openhab-cli reset-ownership

sicherstellen, dass alle Besitzrechte korrekt sind. Auch dieser Befehl benötigt root-Rechte.

Erst jetzt solltest Du das Altsystem herunterfahren müssen, damit sich die beiden Instanzen nicht ins Gehege kommen. Abschließend ist es das Einfachste, den Raspberry durchzustarten. Du kannst aber natürlich auch die verschiedenen Dienste von Hand wieder einschalten.

Ich nutze selbst kein ZRAM, deshalb bin ich mir etwas unsicher, was das Deaktivieren von ZRAM betrifft. geht das einfach über das Beenden des Dienstes? falls ja, sollte ZRAM automatisch wieder hochkommen. Falls Du es explizit über openhabian-config deaktivieren musst, musst Du es natürlich auch wieder einschalten...

[Oekel]

Danke Udo!

Erzeuge ein Backup der aktuellen (leeren) Konfiguration. Prüfe, ob die Rechte für das Dateisystem passen. Kopiere das Backup des alten Systems ins neue System. Aber bitte nicht direkt nach /var/lib/openhab/backups, sondern kopiere die Datei ins home-Verzeichnis. Tue das vom Pi4 aus gerne auch direkt aus dem alten System abgreifen, der User ist ja der gleiche.
Anschließend verschiebst Du die Datei mit root-Rechten aus dem home-Verzeichnis von openhabian ins Zielverzeichnis (also /var/lib/openhab/backups/). Wechsele in das Verzeichnis und prüfe, dass die Besitzrechte stimmen. Falls nicht, passe sie an (mit chown und chgrp).

Ich vermute die leere Konfiguration benötige ich, damit OpenHAB das /backups Verzeichnis erstellt?
Wieso darf ich nicht direkt ins /var/lib/openhab/backups kopieren?
Welche sind den die korrekten Nutzerrechte? openhab:openhab? Und muss das Zip bereits diese haben?

Anschließend solltest Du sowohl openHAB beenden als auch ZRAM deaktivieren. Das Zurückspielen des Backups benötigt meines Wissens immer root-Rechte.
[...]
Ich nutze selbst kein ZRAM, deshalb bin ich mir etwas unsicher, was das Deaktivieren von ZRAM betrifft. geht das einfach über das Beenden des Dienstes? falls ja, sollte ZRAM automatisch wieder hochkommen. Falls Du es explizit über openhabian-config deaktivieren musst, musst Du es natürlich auch wieder einschalten...

Die Scripte benötigen alle root, das ist korrekt.
Das deaktiviern von ZRAM (siehe config 38) hat wie gesagt nicht geklappt.

Trotzdem habe ich mitlerweile ein wieder funktionierendes openHAB auf dem 4er. Scheinbar hat genug geklappt.

ABER ich möchte natürlich den Prozess VOLLSTÄNDIG verstehen und min 1x durchlaufen, um es für die Zukunft zu haben

[udo1toni]

Das Verzeichnis /var/lib/openhab/backups wird bestimmt direkt existieren, aber ein vorhandenes Backup erleichtert die Kontrolle der Dateiattribute.
Von außen kannst Du nicht in das Verzeichnis schreiben, es sei denn, Du hast dafür Vorkehrungen getroffen. Man kann das Backup auch von außerhalb des Verzeichnisses einspielen, aber wenn die Datei dort liegt, wo das System sie gewöhnlich selbst ablegt, sind die wenigsten Probleme zu erwarten.

Was beim Deaktivieren von ZRAM schief läuft, kann ich nicht beantworten...

[Oekel]

ok, ich verstehe.
Bleibt nur noch die Frage, ob es irgendwo eine Liste mit den Usern:Gruppen gibt, die standardgemäß auf den Ordnern gesetzt sind.
Also was ist/muss root:root openhab:openhab sein?

[int5749]

Also was ist/muss root:root openhab:openhab sein?

Hier einmal Screenshots von meinem System, default mit openHABian aufgesetzt

Backups-Folder.JPG

Backups-Files.JPG

Evtl. hilft dies Dir weiter.

VG

[udo1toni]

Das ist eine ganz einfache Sache. Alle openHAB-Verzeichnisse gehören grundsätzlich mit allem, was sich darin befindet dem User openhab.
Dem User openhabian gehören nur die Dateien, die sich im Verzeichnis /home/openhabian/ befinden.

Warum ist das so? openhabian-config läuft immer mit root-Rechten. Wenn openhabian-config also Änderungen am System vornimmt, so geschieht dies als User root.
Aus dem gleichen Grund gehört das Backup auch dem User root, denn openhab-cli backup wird gewöhnlich ebenfalls mit dem User root ausgeführt. Allerdings ist das nicht zwingend, zumindest gehe ich davon aus, dass man den Befehl ebenfalls erfolgreich als User openhab ausführen könnte:

Code: Alles auswählen

sudo -u openhab openhab-cli backup

Es kann aber sein, dass der Programmierer des Tools hier übereifrig war und auf root testet, was, wie gesagt, eigentlich nicht notwendig sein sollte (zumindest zum Anfertigen des Backups). Aber Rechtemanagement ist eh so eine Sache... da tun sich viele schwer. Schon allein die Existenz des Paramaeters -u beim Befehl sudo erzeugt manchmal Fragezeichen in den Gesichtern...