NEWS
[gelöst] backitup und influxdbv2
-
@manrum1 sagte in [gelöst] backitup und influxdbv2:
warum er im Influx Data Explorer keine mearurements anzeigt bleibt ein Rätsel.
@marc-berg sagte in [gelöst] backitup und influxdbv2:
hast du dich mal an der InfluxDB Gui neu angemeldet?
-
@marc-berg ja, habe ich
-
@manrum1 Hallo, Marc, habe heute meinen iobroker ganz normal upgedated, es wurde nur der js-controller auf neuesten Stand (5.0.17) gebracht. Nun habe ich plötzlich "Lücken" in meiner influx Datenbank. Man sieht es sehr gut auf folgendem Screenshot:
Zwischen 26.11. und 12. 4. sind alle Daten weg, kannst Du dir erklären, wie das durch den update passieren kann?Nun wollte ich meinen Backup einspielen, geht aber nicht, da ich folgende Meldung erhalte:
Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [DEBUG] [influxDB] - influxdb.0 is stopped [ERROR] [influxDB] - 2023/12/17 13:14:39 INFO: Restoring bucket "8e0e9c529c6510f7" as "iobold" Error: failed to restore bucket "iobold": 422 Unprocessable Entity: bucket with name iobold already exists [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore done [DEBUG] [influxDB] - influxdb.0 started
Das hatten wir schon mal, da ich die alte (iobold) DB für Auswertung alter Daten nutze.
Meine Frage: Wie kann ich mein restore so reparieren, dass er nur die iobroker-data DB verwendet und bei Bedarf restauriert?Schon mal Danke im Voraus!
-
@manrum1 sagte in [gelöst] backitup und influxdbv2:
Zwischen 26.11. und 12. 4. sind alle Daten weg, kannst Du dir erklären, wie das durch den update passieren kann?
Ich kann nur mit Sicherheit sagen, dass es nicht direkt durch das Update ausgelöst wurde. Da besteht keinerlei Zusammenhang.
Es fehlt exakt eine Woche, wie es aussieht. InfluxDB organisiert seine Daten in so genannten "Shards". Ein Shard ist genau 7 Tage lang, wenn die Aufbewahrungsdauer > 6 Monate ist. Also gehe ich davon aus, dass eine dieser Datendateien defekt ist oder gelöscht wurde. Als Ursache würde ich Datenträgerprobleme vermuten, die durch den Restart zu Tage getreten sind. Wo liegen die Daten?Error: failed to restore bucket "iobold": 422 Unprocessable Entity: bucket with name iobold already exists
Das hatten wir schon mal, da ich die alte (iobold) DB für Auswertung alter Daten nutze.
Meine Frage: Wie kann ich mein restore so reparieren, dass er nur die iobroker-data DB verwendet und bei Bedarf restauriert?Das verstehe ich nicht. Alle deine Daten (historische und aktuelle) liegen doch jetzt in einem Bucket, oder? (außer die jetzt gelöschten
)
EDIT: außerdem solltest du mal die Datumsformate in der grafana.ini anpassen, damit die deutschen angezeigt werden:
[date_formats] # For information on what formatting patterns that are supported https://momentjs.com/docs/#/displaying/ # Default system date format used in time range picker and other places where full time is displayed full_date = DD.MM.YYYY HH:mm:ss # Used by graph and other places where we only show small intervals interval_second = HH:mm:ss interval_minute = HH:mm interval_hour = DD.MM. HH:mm interval_day = DD.MM. interval_month = MM.YYYY interval_year = YYYY
-
@marc-berg Danke für die schnelle Antwort. Das mit dem Datenverlust bleibt wohl ein Rätsel. Aber inzwischen wei ich, warum er die alte Datenbank (iobold) anmeckert. Liegt an der damaligen Einstelllung:
Wenn mans nicht gleich wieder zurückstellt, dann vergisst mans halt
Kannst mir noch einen Tipp geben, wie ich die fehlende Woche wieder restauriere, backup habe ich ja. -
@manrum1 sagte in [gelöst] backitup und influxdbv2:
Kannst mir noch einen Tipp geben, wie ich die fehlende Woche wieder restauriere, backup habe ich ja.
Das geht zum Beispiel so:
- Wiederherstellen der Sicherung in ein neues Bucket "iobroker_temp" oder wie auch immer du das nennst. Die Verfahrensweise sind wir oben schon durchgegangen.
- Kopieren der Daten mit folgender Query:
from(bucket: "iobroker_temp") |> range(start: -2mo) |> to(bucket: "iobold")
Den Range kannst du ruhig großzügig wählen, gleiche Daten werden einfach drübergebügelt, es entstehen keine doppelten Datensätze.
- Bucket "iobroker_temp" wieder löschen.
-
@marc-berg Ah ok, ich zerstöre also keine Daten, da er gleiche (vorhandene) Einträge nicht überschreibt.
-
@manrum1 sagte in [gelöst] backitup und influxdbv2:
Ah ok, ich zerstöre also keine Daten, da er gleiche (vorhandene) Einträge nicht überschreibt.
Es werden Daten überschrieben, aber wenn du nach der Sicherung keine Daten geändert oder gelöscht hast, erfolgt lediglich ein 1:1 Ersatz. Wenn du aber unsicher bist, dann wähle den range (start: ... , stop ...) einfach genau so, dass der fehlende Zeitraum exakt wiederhergestellt wird.
-
@marc-berg Leider klappt es nicht. Habe Backup extrahiert:
/opt/iobroker/backups/tmp/
Daraufhin führe ich folgendes Kommando aus:
influx restore --bucket iobroker-data --org home --new-bucket iobroker-data-2H23 --new-org home --token xxx /opt/iobroker/backups/tmp/
Passieren tut danach nichts, keine Fehlermeldung. Hattest du nicht mal gesagt, dass ein restore nur funktioniert, wenn das Bucket nicht existiert (in meinem Fall iobroker-data)?
-
@manrum1 sagte in [gelöst] backitup und influxdbv2:
Hattest du nicht mal gesagt, dass ein restore nur funktioniert, wenn das Bucket nicht existiert (in meinem Fall iobroker-data)?
Habe gerade den Überblick verloren, wie deine Bucket(s) heißen, und ob du eins oder mehrere hast. Vielleicht fasst du das nochmal zusammen.
In diesem Beispiel wird ein Bucket, das im Original "iobroker" heißt und so gesichert wurde in ein neues Bucket "iobroker_tmp" restored:
influx restore --new-bucket iobroker_tmp --bucket iobroker -t xxx /var/lib/influxdb2/backup
"iobroker_tmp" darf dann natürlich noch nicht existieren.
-
@marc-berg Also mein aktives Bucket für iobroker heißt iobroker-data, diese wird auch gebackuped. Daneben nutze ich in meiner Org:
Nun wollte ich wie vorher beschrieben ein neues Bucket erzeugen iobroker-data-2H23
influx restore --bucket iobroker-data --org home --new-bucket iobroker-data-2H23 --new-org home --token xxx /opt/iobroker/backups/tmp/
-
Also wenn überhaupt keine Meldung erscheint, ist das i.d.R. ein Zeichen dafür, dass das Bucket, welches im Backup enthalten ist, nicht so heißt, wie du angegeben hast (iobroker-data).
Schau mal in die "manifest" Datei, dort gibt es einen Schlüssel "bucketName". Und dort auch prüfen, ob die "organization" passt.
-
@marc-berg Genau so ist es. Da ich den Eintrag "mehrere Systeme sichern" auf iobold gesetzt und nicht gelöscht hatte, hat er nur die iobold gesichert.
Bin natürlich selbst Schuld. Bin davon ausgegangen, dass die DB in der Backitup-Einstellung (bei mir iobroker-data) immer gesichert wird. Allerdings sollte man im Konfigurationsdialog auf diese Tatsache hinweisen.
-
@manrum1 sagte in [gelöst] backitup und influxdbv2:
Da ich den Eintrag "mehrere Systeme sichern" auf iobold gesetzt und nicht gelöscht hatte, hat er nur die iobold gesichert.
Das verstehe ich nicht.
Bin natürlich selbst Schuld. Bin davon ausgegangen, dass die DB in der Backitup-Einstellung (bei mir *iobroker-data) immer gesichert wird. Allerdings sollte man im Konfigurationsdialog auf diese Tatsache hinweisen.
Wenn du der Meinung bist, da gibt es ein Problem, dann kannst du hier:
https://github.com/simatec/ioBroker.backitup/issues/new/choose
einen neuen Bug-Report erstellen.
-
Um sicher zu sein, dass wir nicht aneinander vorbeireden, folgendes ist meine Einstellung:
Bis heute Vormittag war folgendes eingestellt:
Ich hätte also dort zusätzlich die iobroker-data eintragen müssen. Sag ja - selbst schuld. War mir halt nicht klar.
Danke für Deine kompetente und vor allem prompte Hilfe!!
-
@manrum1 sagte in [gelöst] backitup und influxdbv2:
War mir halt nicht klar.
Ach jetzt verstehe ich es. Du bist davon ausgegangen, dass beim Anhaken "Sicherung mehrerer Systeme" das Bucket, welches unten eingetragen wird, ZUSÄTZLICH gesichert wird!?
Letztlich hat Backitup aber genau das gemacht, was in der Config angezeigt wird.
-
@marc-berg c'est la vie