UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Thomas Braun]

@herby217

Die von Backitup erstellten Backups sind keine inkrementellen sondern immer volle Backups.
Lokal abgelegte Backupdateien sind auch ungünstig, sowas legt man immer (auch) extern ab. Raucht dir das Dateisystem fatal ab kommst du an die Daten ja auch nicht mehr ran.

Hier fungiert das Backupverzeichnis z. B. nur als mount Punkt und ist ansonsten leer:

echad@chet:~ $ ls -l /opt/iobroker/backups/
total 0
echad@chet:~ $ 

[herby217]

@marc-berg
da liegt wohl ein Fehler bei den Backupeinstellungen vor. Auf dem USB-Stick ist schon länger nichts mehr angekommen.

[Homoran]

@herby217

@thomas-braun sagte in Wie kann ich meine Daten retten?:

Dann hangel dich durch /var durch und schau dich weiter um.

und wenn

@marc-berg sagte in Wie kann ich meine Daten retten?:

Einfach löschen kann man aus dieser Struktur nichts, ohne Gefahr zu laufen, dass die Datenbank nicht mehr hoch kommt.

solltest du jns auch mal den inhalt von /opt zeigen

du brauchst ja nur soviel Platz um ein aktuelles Backup zu erstellen, damit du neu aufbauen kannst

[OliverIO]

@homoran

die datenbank hat 40GB, die müsste er mitsichern.
ich glaube der Ansatz mit neuer/größerer SD-Karte ist besser und dann
die Datenbank analysieren und verkleinern.
/opt hat ja auch nur 6.7GB
Da gibts nix was er noch löschen könnte.
Ausser er sagt, den Inhalt der Datenbank braucht er nicht und löscht die.

[Homoran]

@oliverio ich bin davon ausgegangen dass er im Moment gar nichts machen kann, weil SD zu voll.

[herby217]

@homoran
so, ich bin jetzt wieder dabei. Bei uns war gerade ein Unwetter. Da hab ich den Rechner lieber vom Netz getrennt.
So, wie ich die Sache jetzt verstehe, sind die 40 GB das Ergebnis von 25 Backups, von denen ich eigentlich nur die letzten paar benötige. Über den ssh-Zugang kann ich über Powershell auf den Raspi zugreifen. Lediglich der iobroker ist nicht mehr angelaufen, was wohl an der vollen SD liegt.

[Thomas Braun]

@herby217 sagte in Wie kann ich meine Daten retten?:

So, wie ich die Sache jetzt verstehe, sind die 40 GB das Ergebnis von 25 Backups, von denen ich eigentlich nur die letzten paar benötige.

Nein, da wird die Datenbank als solche aufgebläht sein. Die Backups würden nicht im Verzeichnis /var/lib/influxdb/engine/data liegen.

[OliverIO]

@herby217 sagte in Wie kann ich meine Daten retten?:

So, wie ich die Sache jetzt verstehe, sind die 40 GB das Ergebnis von 25 Backups

Nein.
Die Influx-datenbank alleine ist über 40GB groß
gemäß dieser Ausgabe
https://forum.iobroker.net/topic/81217/wie-kann-ich-meine-daten-retten/31?_=1748704398432

Vorgeschlagener Weg wäre:

• Neuen DAtenträger kaufen, evtl gleich eine kleine SSD, da SD-Karten unter Linux nicht so lange halten.
• Dann SD-Karte nach SD/SSD klonen
• Dann die Partition vergrößern
• Dann startet das System wieder.
• Dann Datenbank analysieren warum die so groß geworden ist. Hast du zuviele DAtenpunkte geloggt? Dann verkleinern.
• Wenn das System eine annehmbare Größe hat mit Backitup ein ordentlichen Backup anlegen
• System komplett neu aufsetzen
• Backup einspielen

[herby217]

@oliverio
OK, das versuche ich. Danke!

[Homoran]

@oliverio sagte in Wie kann ich meine Daten retten?:

da SD-Karten unter Linux nicht so lange halten.

das kann man sooo nicht sagen.
Hat erstens nix mit Linux zu tun, und zweitens dort ioBroker "spezifisch" wegen der vielen Schreibvorgängen von ioBroker.

...und ich habe noch nie eine SD Karte im laufenden Betrieb auf irgendeinem SBC verloren!
nicht in 10 Jahren und nicht bei bis zu 10 parallelen Testinstallationen.

Auch nicht mit einer 56GB großen History mit viel zu vielen Schreibvorgängen.

dafür 2x SSD im nuc :latin_cross:

[herby217]

@oliverio
Ich hab den iobroker mit der bisherigen SD wieder zum Laufen bekommen, indem ich den Speicherplatz etwas erweitern konnte.
pi@raspi2:~ $ sudo raspi-config
==> advanced options
==> expand filesystem
Das hat für 171MB freien Speicherplatz auf /dev/mmcblk0p2 gesorgt. Damit kann der iobroker wieder starten. Jetzt geht es darum, das Backup korrekt einzurichten und alte Daten zu löschen.

pi@raspi2:~ $ df -h
Filesystem      Size  Used **Avail** Use% Mounted on
udev            3.6G     0  3.6G   0% /dev
tmpfs           781M  1.2M  780M   1% /run
**/dev/mmcblk0p2**   59G   55G  **171M** 100% /
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           5.0M   16K  5.0M   1% /run/lock
/dev/mmcblk0p1  510M   66M  445M  13% /boot/firmware
/dev/sda1       116G  3.5G  112G   4% /mnt/usb0
tmpfs           781M     0  781M   0% /run/user/1000

Mod Edit: log in Code Tags </> gesetzt

[OliverIO]

@homoran

ja, es scheint ausnahmen zu geben.
letztens hab ich mal nachgeschaut wieviel lebenszeit meine ssd nach 5 Jahren noch hat.
Auf dem NUC läuft docker mit iobroker und noch weitere 20 container. nach 5 Jahren waren gerade mal 5% TBW weg.

[herby217]

@oliverio
So wie es aussieht, war mein Problem, dass die InfluxDB2 den Speicher mit "metrics"-Daten vollgeschrieben hat. Mit Hilfe eines Tutorials von Matthias Kleine habe ich in der Config-Datei "metrics-disabled" auf "true" setzen können. Ich hoffe, das hat das Problem des Speichervolllaufens gelöst.