Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Marc Berg]

@hukio

Ob das Ganze sinnvoll ist, solange du nicht weißt, warum Daten einfach so "verschwinden", steht auf einem anderen Blatt ...

[hukio]

@marc-berg
Wie gesagt, ich weiß, wie ich ein normales restore der Influxdb mache (habe ich schon mehrfach gemacht). Aber dies war immer die gesamte Datenbank. Jetzt geht es darum, wie ich die alten Werte in eine existierende einfügen kann. Was passiert, wenn ich ein restore mit Backitup in eine existierende Datenbank mit gleichem Aufbau und Namen mache? Geht das überhaupt?
HUK

[Marc Berg]

@hukio

Stimmt, da habe ich nicht richtig gelesen.

Du kannst das Backup in eine neue Datenbank (auf dem gleichen Server) zurückspielen:

influxd restore -portable -db <AKTUELLERDBNAME> -newdb <TEMPORÄRER_DB_NAME> path-to-backup

Und dann die Daten in die bestehende DB kopieren:

SELECT *
    INTO "<AKTUELLERDBNAME>".autogen.:MEASUREMENT
    FROM "<TEMPORÄRER_DB_NAME>".autogen./.*/ GROUP BY *

Zum Schluss die temporäre DB löschen:

DROP DATABASE "<TEMPORÄRER_DB_NAME>"

[hukio]

@marc-berg
OK, wie komme ich an das influxd verständliche backup der alten Datenbank? Ich habe ja nur die vom Backitup produzierte Datei (z.B. influxDB_2023_08_25-02_05_32_backupiobroker.tar.gz). Oder kann influxd diese Datei von Backitup direkt restaurieren? Kann ich diese Datei in den influxd restore ... Befehl für <AKTUELLERDBNAME> einsetzen?
Danke für Deine Hilfe
HUK

[Marc Berg]

@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:

OK, wie komme ich an das influxd verständliche backup der alten Datenbank? Ich habe ja nur die vom Backitup produzierte Datei (z.B. influxDB_2023_08_25-02_05_32_backupiobroker.tar.gz). Oder kann influxd diese Datei von Backitup direkt restaurieren?

Ich habe das mal durchgespielt, bei mir heißt die Datenbank "iobroker1".

Du musst die Backup-Datei zunächst auspacken. Zum Beispiel direkt auf der Kommandozeile:

influxdb1:/var/lib/influxdb/backup# tar -xvzf influxDB_2023_09_01-18_17_13_backupiobroker.tar.gz

In diesem Beispiel werden die Daten direkt in .../backup entpackt.

Weiter geht's mit dem Restore-Befehl in die temporäre DB:

influxdb1:~# influxd restore -portable -db iobroker1 -newdb iobroker1_tmp /var/lib/influxdb/backup
2023/09/02 07:29:52 Restoring shard 128 live from backup 20230901T161713Z.s128.tar.gz
2023/09/02 07:29:52 Restoring shard 132 live from backup 20230901T161713Z.s132.tar.gz
2023/09/02 07:29:52 Restoring shard 134 live from backup 20230901T161713Z.s134.tar.gz
2023/09/02 07:29:52 Restoring shard 136 live from backup 20230901T161713Z.s136.tar.gz
2023/09/02 07:29:52 Restoring shard 143 live from backup 20230901T161713Z.s143.tar.gz
2023/09/02 07:29:52 Restoring shard 151 live from backup 20230901T161713Z.s151.tar.gz

Dann die Daten kopieren:

influxdb1:~# influx
Connected to http://localhost:8086 version 1.8.10
InfluxDB shell version: 1.8.10
> select * INTO "iobroker1".autogen.:MEASUREMENT FROM "iobroker1_tmp".autogen./.*/ GROUP BY *
name: result
time written
---- -------
0    41265

und temporäre DB löschen:

> DROP DATABASE "iobroker1_tmp"

Kann ich diese Datei in den influxd restore ... Befehl für <AKTUELLERDBNAME> einsetzen?

nein

[hukio]

@marc-berg
Hat teilweise geklappt.
Nach dem select Befehl kam nach einiger Zeit:
ERR: timeout
Warning: It is possible this error is due to not setting a database.
Please set a database with the command "use <database>".

Daraufhin habe use iobroker (Name meiner Datei) eingegeben und den select Befehl wiederholt. Es kam wieder der ERR: timeout

Wenn ich mit Grafana die Datenbank ansehe gibt es Diagramme, die die älteren Daten zeigen. Die meisten aber nicht.

Wie kann ich dem timeout Fehler begegnen?
Hab vielen Dank für Deine explizite Anleitung, die ich offensichtlich brauche.
HUK

[Marc Berg]

@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:

Nach dem select Befehl kam nach einiger Zeit:
ERR: timeout

Da wird deine Datenbank zu groß sein, bzw. die Hardware zu langsam, sodass das Timeout erreicht wird. Wahrscheinlich wirst du die "SELECT" Query in kleinere zeitliche Häppchen aufteilen müssen. Also die Query ergänzen z.B. um

where time >= '2021-01-01 00:00:00' and time < '2022-01-01 00:00:00'

oder noch kleinere zeitliche Intervalle, wenn der Timeout immer noch auftritt.

[Ein ehemaliger Benutzer]

@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:

Nach dem select Befehl kam nach einiger Zeit:

Moin,

bitte nicht aus dem Kopf, irgendwelche Fehler zitieren, immer alles zeigen, von der Eingabezeile, bis hin zum neuen Prompt. Nätürlich als Text in Code Tags </>

VG
Bernd

[Marc Berg]

@marc-berg sagte in Influxdb: Wie altes backup in neuere DB einspielen:

oder noch kleinere zeitliche Intervalle, wenn der Timeout immer noch auftritt.

Ein anderer Ansatz wäre, die Datenbank komplett zu löschen und dein "großes" Backup per normalen Backitup-Restore zurückzuspielen. Danach nur noch den kleinen Teil (der nach dem Crash entstanden ist) per o.g. Methode einfügen. Das würde ich machen, wenn das Timeout auch bei kleinen Häppchen auftritt und der Aufwand zu hoch wäre, tausend "Mini-Häppchen" zurückzuspielen.

[hukio]

@marc-berg
Das ist eine gute Idee.
Mit dem where stehe ich noch auf Kriegsfuß:

> select * INTO "iobroker".autogen.:MEASUREMENT FROM "iobroker_tmp".autogen./.*/ GROUP BY * where time >= '2023-06-01 00:00:00' and time < '2023-06-30 00:00:00'

ERR: error parsing query: found WHERE, expected ; at line 1, char 91

HUK

[Marc Berg]

@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:

Mit dem where stehe ich noch auf Kriegsfuß:

Bin jetzt nicht wirklich fit in InfluxQL, aber ich glaube die "where" Clause muss vor "group".

[hukio]

@marc-berg
Habe dies so versucht mit delta t = 1 Monat

> select * INTO "iobroker".autogen.:MEASUREMENT FROM "iobroker_tmp".autogen./.*/  where time >= '2023-06-01 00:00:00' and time < '2023-06-30 00:00:00' GROUP BY *
ERR: timeout
> select * INTO "iobroker".autogen.:MEASUREMENT FROM "iobroker_tmp".autogen./.*/  where time >= '2023-06-01 00:00:00' and time < '2023-06-30 00:00:00' GROUP BY *
ERR: partial write: points beyond retention policy dropped=155

Dann noch einmal, mit neuem Fehler. Die alte Datenbank ist nur 18.905 KB groß als GZ Datei (für ca. 9 Monate). Die jetzige ist 422 KB für ca. 7 Tage. Beide wirklich nicht groß würde ich denken. Werde die Umkehrung versuchen.
HUK

[Marc Berg]

@hukio Wenn du mit unterschiedlichen Retention policies arbeitest, musst du natürlich "autogen" durch den Namen der policy ersetzen.

[hukio]

@marc-berg
Bei mir ist alles default, wüßte nicht, wie ich die retention policy beeinflussen kann.
HUK

[Ein ehemaliger Benutzer]

@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:

Habe dies so versucht mit delta t = 1 Monat

Moin,

lese nur noch am Rande mit, aber wie ist denn die Retention der Datenbank, sagen wir mal, die steht auf 30 Tage, dann kannst Du keine Daten einfügen, die älter als 30 Tage sind.
Wie gesagt, lese hier nur noch sporadisch mit, falls das schon beantwortet wurde, sorry.

VG
Bernd

P.S.: @Marc-Berg war schneller :)

[Ein ehemaliger Benutzer]

@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:

Bei mir ist alles default, wüßte nicht, wie ich die retention policy beeinflussen kann.

Moin,

und wieder mal die schöne Dokumentation vom Hersteller https://docs.influxdata.com/influxdb/v1.8/query_language/explore-schema/#show-retention-policies

VG
Bernd

P.S.: und wenn Du das ändern möchtest https://docs.influxdata.com/influxdb/v1.8/query_language/manage-database/#modify-retention-policies-with-alter-retention-policy

[Marc Berg]

@dp20eic sagte in Influxdb: Wie altes backup in neuere DB einspielen:

lese nur noch am Rande mit, aber wie ist denn die Retention der Datenbank, sagen wir mal, die steht auf 30 Tage, dann kannst Du keine Daten einfügen, die älter als 30 Tage sind.

Ja, das sieht für mich auch so aus, dass nach dem Crash eine Retention policy ungleich "unendlich" angelegt wurde. Aber dann ist der umgekehrte Weg der Wiederherstellung wahrscheinlich sowieso der bessere.

Edit:

Aber die Überlegung wirft nochmal ein anderes Licht auf das "Verschwinden" der Daten. Vielleicht wurden durch das Verstellen der Retention policy Daten gelöscht.

[hukio]

@marc-berg

 SHOW RETENTION POLICIES
name    duration   shardGroupDuration replicaN default
----    --------   ------------------ -------- -------
autogen 17520h0m0s 168h0m0s           1        true

Ist offensichtlich nicht unendlich, wäre 0 h für duration denke ich.
HUK

[Ein ehemaliger Benutzer]

@marc-berg sagte in Influxdb: Wie altes backup in neuere DB einspielen:

Ja, das sieht für mich auch so aus, dass nach dem Crash eine Retention policy

Moin,

ich müsste mich erst durch den Thread lesen, bevor ich mir da ein Urteil erlauben kann, ich wäre gleich auf influxDB V2.x gegangen, vielleicht auch parallel zur V 1.8 und hätte dann nach einer Zeit des parallelen Befüllens, eine Migration der Altdaten gemacht.
Stecke da aber nicht im Detail, was der TE haben/erreichen möchte.

VG
Bernd

@hukio sagte in Influxdb: Wie altes backup in neuere DB einspielen:

Ist offensichtlich nicht unendlich, wäre 0 h für duration denke ich.

Ja, steht nicht auf Unendlich, aber auf ~ 2 Jahre -> 17520 Std.

duration

The attribute of the retention policy that determines how long InfluxDB stores data. 
Data older than the duration are automatically dropped from the database. See Database 
Management for how to set duration.

Warum da dann die Daten nicht hineinlaufen, keine Ahnung.

VG
Bernd

[hukio]

@marc-berg und andere,
Ich habe jetzt den umgekehrten Ansatz durchgeführt, neue kurze Datenbank in alte lange eingefügt. Gleiches Verhalten. timeout error wie vorher. Habe dann Zeitintervall auf einen Tag eingeschränkt, von Tag zu Tag. Das ging ohne Fehler.
War ein langer Weg. Vielen Dank für die ausführliche Unterstützung. Geht das alles mit der Version 2.x besser?
HUK
PS: die retention time autogen war auch in der "intakten" DB auf den gleichen Wert gesetzt. Wo das herkommt? Habe sie auf INF gesetzt.