Monatsrückblick Januar/Februar 2026 ist online!

[iobroker2001]

@marc-berg Habe den Haken gesetzt, beim Restore kommt identische Meldung, aber auch die gute Bestätigung wie beim 1. Mal, s. auch oben!

[DEBUG] [influxDB] - infuxDB Restore completed successfully

[EXIT] influxDB restore done

[DEBUG] [influxDB] - influxdb.0 started

Das Restore scheint also funktioniert zu haben, aber nicht den gewünschten Effekt zu haben. Habe Raspi schon neu gestartet. Den Bucket "influx-statistikdaten" versuche ich testweise, wieder auf ewig zu setzen, wird zwar mit OK-Meldung ("was successfully updated") quittiert, aber Anzeige bleibt auf 7 Tage, auch nach Neustart. Grrrr..

Im influx-statistikdaten finde ich Einträge wie boltdb_reads_total, go_memstats...., service_ etc.

[Marc Berg]

@iobroker2001
Alles etwas seltsam. Was heißt denn konkret "Das Restore scheint also funktioniert zu haben, aber nicht den gewünschten Effekt zu haben."

[iobroker2001]

@marc-berg Ich meine damit, BackItUp meint, Restore wäre ok gewesen...;-)

[Marc Berg]

@iobroker2001
Sind jetzt gar keine Daten mehr da, oder wie?

[iobroker2001]

@marc-berg Es sind nur noch die Daten der letzten 7 Tage da.

[Marc Berg]

@iobroker2001
Ok, dann schau mal in deine Influxdb-Instanz:

[iobroker2001]

@marc-berg Sieht bei mir genauso aus:

[Marc Berg]

@iobroker2001

Dann bin ich jetzt auch ratlos. Irgendwo scheint ja die Retention Time von 7 Tagen gespeichert zu sein. Ich würde mich jetzt durchprobieren: Influxdb-Instanzen stoppen, das Bucket über die InfluxDb Web UI löschen und das Restore über die Kommandozeile machen. Ist zwar alles nicht logisch, aber eine andere Idee habe ich im Moment nicht.

[iobroker2001]

@marc-berg Ich glaube, ich muss mich von den Daten verabschieden - sie haben sich ja selbst schon von mir verabschiedet ;-)
Ausgerechnet dieses Mal hatte ich kein SD-Karten-Image-Backup gemacht...
Ich werde am Wochenende Deinen Vorschlag mal probieren.

Wie auch immer:

@marc-berg VIELEN VIELEN DANK!!!!

@dp20eic VIELEN VIELEN DANK!!!!

Wünsche Euch frohe Ostern!!

[Ein ehemaliger Benutzer]

@iobroker2001 sagte in InfluxDB 2: Welcher Wert müllt die DB voll?:

@marc-berg Ich glaube, ich muss mich von den Daten verabschieden - sie haben sich ja selbst schon von mir verabschiedet ;-)
Ausgerechnet dieses Mal hatte ich kein SD-Karten-Image-Backup gemacht...
Ich werde am Wochenende Deinen Vorschlag mal probieren.

Wie auch immer:

@marc-berg VIELEN VIELEN DANK!!!!

@dp20eic VIELEN VIELEN DANK!!!!

Wünsche Euch frohe Ostern!!

Moin,

ich glaube da ist das Restore nicht korrekt gelaufen und Du siehst immer noch das Bucket, als Du es versehentlich auf 7 Tage eingestellt hast.
Geh mal in die WEB UI von influxDB und benenne das iobroker Bucket um in iobroker_old oder so und versuch es dann noch mal mit dem Restore.

Es ist immer besser, wenn Du Log Files immer komplett postest, war den der Delete erfolgreich?

VG
Bernd

[iobroker2001]

@dp20eic

ich glaube da ist das Restore nicht korrekt gelaufen und Du siehst immer noch das Bucket, als Du es versehentlich auf 7 Tage eingestellt hast.
Geh mal in die WEB UI von influxDB und benenne das iobroker Bucket um in iobroker_old oder so und versuch es dann noch mal mit dem Restore.

Hallo Bernd,
schön, dass Du Dich trotz meiner Resignation noch gemeldet hast, und es hat sich gelohnt!!
Habe Deine Anweisungen befolgt, es hat geklappt, ich habe meine Daten wieder!
Das Restore von iobroker hat dann geklappt, es lag daran, dass es den Bucket schon gab.
Erschwerend kam noch hinzu, dass es per Web-UI auf Github schon als Bug vermerkt ist, dass das Ändern der Retention-Zeit manchmal nicht klappt. Per CLI funktionierte es dann auch.
Die DB ist jetzt wesentlich kleiner:

sudo du -s /var/lib/influxdb/engine/data
1158868	/var/lib/influxdb/engine/data

Mal sehen, wie sie sich jetzt entwickelt.
Auf jeden Fall hat das Happy-End mein Vertrauen in die InfluxDB wieder gestärkt.

Danke noch einmal, Dir und Marc-Berg wünsche ich Frohe Ostern!

[Rushmed]

@marc-berg sagte in [gelöst] InfluxDB 2: Welcher Wert müllt die DB voll?:

@iobroker2001
Unter dem /data -Verzeichnis liegen ja die einzelnen Buckets. Was möglich sein KÖNNTE, dass das "Monitoring" Bucket sehr viele Daten enthält.

Die ID des Buckets findet sich unter dem /data Verzeichnis wieder. Ggf. lohnt es sich, die Verzeichnisse noch einzeln mit "du" auszuwerten.

Hier hab ich mal ne Frage.
Der Ordner data\6228c6c48973b58d\autogen war bei mir auch mal auf 27 GB angewachsen.
Wenn ich mir den Inhalt von Data ansehe:

passt das nicht ganz zu meinen Buckets.

Ich finde meine ioBroker DB und _monitoring als Ordner wieder.
Für _tasks habe ich keinen Ordner in /data aber das eigentliche Problem ist dass ich für den Ordner 6228c6c48973b58d der Speicher frisst keine DB habe.
Wie ist denn da der Zusammenhang oder was frisst hier meinen Speicher?

[Marc Berg]

@rushmed sagte in [gelöst] InfluxDB 2: Welcher Wert müllt die DB voll?:

Wie ist denn da der Zusammenhang oder was frisst hier meinen Speicher?

Mit den Informationen schwer zu sagen. Vielleicht gibt es bei Dir mehr als eine Organisation? Sind die Daten in dem Verzeichnis aktuell oder vielleicht ein Überbleibsel einer älteren Installation?

[Rushmed]

@marc-berg Es gibt keine weitere Organisation und die Installation war damals frisch als ich auf 64 Bit gewechselt bin.
In dem Ordner werden auch immernoch Daten geschrieben.

[Marc Berg]

@rushmed sagte in [gelöst] InfluxDB 2: Welcher Wert müllt die DB voll?:

@marc-berg Es gibt keine weitere Organisation und die Installation war damals frisch als ich auf 64 Bit gewechselt bin.
In dem Ordner werden auch immernoch Daten geschrieben.

Das ist seltsam, denn selbst in der offiziellen Doku steht, dass die Unterverzeichnisse nach den Bucket-IDs benannt werden.

Aber schau mal hier: https://community.influxdata.com/t/hidden-bucket-occupying-a-lot-of-disk-size/26837

Also einfach mal prüfen, ob irgendwelche Tasks/Scrapers eingerichtet sind.