Influxdb: Wie altes backup in neuere DB einspielen

[A Former User]

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

Für eine Anleitung wäre ich dankbar.

Moin,

ein guter Anlaufpunkt ist oft der Hersteller
https://docs.influxdata.com/influxdb/v1.8/administration/backup_and_restore/?t=Legacy+format#Copyright

Solltest Du mit den Beispielen nicht zurechtkommen, dann musst Du noch mal gezielt nachfragen.

Wenn ich das noch korrekt im Kopf habe, kannst Du das letzte Backup auch direkt in die aktuelle Datenbank einspielen, sollten im Backup Daten sein, die es auch schon in der Datenbank gibt, dann werden die Daten der Datenbank nicht überschrieben.

Hast Du den Adapter BackitUp am Laufen, denn dann könntest Du auch darüber das Backup wieder zurückspielen, so meine Vermutung, habe da nur Halbwissen, da ich das alles nicht nutze.

VG
Bernd

[hukio]

@dp20eic
Ich benutze den Backitup adapter. Das einfachste wäre, wenn ich das backup via dem Adapter in die jetzige Datenbank einspielen könnte. Ich weiß aber nicht, ob und wie dies geht. Normalerweise wird vor dem restore die existierende Datenbank gelöscht (das habe ich schon gemacht).
Wer weiß, was ich machen soll?
Danke
HUK

[Marc Berg]

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

Wer weiß, was ich machen soll?

1. den Backitup-Adapter korrekt konfigurieren (hängt davon ab, wie/wo deine DB installiert ist

Spoiler

2. Deine Backup-Dateien unter /opt/iobroker/backups ablegen

3. "Backup" starten

Spoiler

4. Sicherungen abrufen

Spoiler

5. Datei auswählen und auf "wiederherstellen" klicken

Spoiler

[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.

[A Former User]

@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

[A Former User]

@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

[A Former User]

@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.