InfluxDB - Daten weg / Wiederherstellung [gelöst]

[Naturfreund]

@marc-berg

Die Frage hab ich noch nicht gestellt, lag mir aber schon auf der Zunge. Ich arbeite aktuell noch mit 32 Bit BS. Kann ich da überhaupt auf die V2.x hoch?
Meines Wissens nach ist dafür ein 64 Bit BS notwendig.

Und dann gleich die Folgefrage: Backup einer alten 1.8.x DB Version kann dann mit einer neuen 2.x zusammengeführt werden?

[Glasfaser]

@naturfreund sagte in InfluxDB - Daten weg / Wiederherstellung:

Meines Wissens nach ist dafür ein 64 Bit BS notwendig.

Richtig !

[Glasfaser]

@naturfreund sagte in InfluxDB - Daten weg / Wiederherstellung:

Und dann gleich die Folgefrage: Backup einer alten 1.8.x DB Version kann dann mit einer neuen 2.x zusammengeführt werden?

so habe ich es gemacht :

Datenpunkt von alt 1.8 als lp exportieren

Beispiel einer Datenbank : Solaredge

influx_inspect export -database Solaredge -datadir /var/lib/influxdb/data -waldir /var/lib/influxdb/wal -retention autogen  -out /mnt/influxv1backup.lp -lponly

influx write   --bucket iobroker  --file /var/lib/influxdb2/influxv1backup.lp

[crunchip]

@naturfreund ich möcht auch nicht streiten, aber das ist vom Dezember
nu mal so am Rande

@naturfreund sagte in InfluxDB - Daten weg / Wiederherstellung:

Hab gerade nochmal versucht den InfluxDB Backup vom 06.01. wiederzustellen:

und was du da zwischenzeitlich sonst noch probiert hast, keine Ahnung.

ich spreche von deinem Januar Beitrag https://forum.iobroker.net/post/926727
und wenn du nun mal nen ganzen Tag

error: influxdb.0 (13722) Error: connect ECONNREFUSED 127.0.0.1:8086

in Log stehen hast, sind da definitiv keine Daten für den Zeitraum
das was du zeigst ist Grafana,
wenn dann müsstest du dich schon auf die Datenbank aufschalten und die Daten anhand der Zeitstempel vergleichen

[Naturfreund]

@crunchip

Das Backup ist ja fehl geschlagen, ergo arbeite ich noch auf "Main". Sonst habe ich nichts weiter probiert bezüglich Wiederherstellung.

In Grafana hab ich nur die InfluxDB eingebunden.
Die Daten die mir angezeigt wurden und jetzt weg sind müssen ja zwischenzeitlich irgendwo existiert haben. Vielleicht wurden diese während des gesamten Zeitraums nicht weg geschrieben. Und als der "Cach" voll war, waren se weg. Ich kann hier nur spekulieren, da ich die Architektur dahinter nicht kenne.
Dann wären die in den Backups auch nicht drin.

Kann ich die Daten aus den Backups nicht einfach in eine neue Datenbank speichern und die dann erst mal mit Grafana analysieren?
Würde mir vollkommen ausreichen.
Nur erstelle ich gerade ein Tagesgenaue Statistik des Primärenergieverbrauchs unseres Hauses über ein ganzes Jahr. Da tur das schon weh wenn solche Zeiträume fehlen.

[Glasfaser]

@naturfreund sagte in InfluxDB - Daten weg / Wiederherstellung:

Kann ich die Daten aus den Backups nicht einfach in eine neue Datenbank speichern und die dann erst mal mit Grafana analysieren?
Würde mir vollkommen ausreichen.

Beispiel :

influxd restore -portable -db NamederaltenDatenbank -newdb NeuerDatenbankname  /tmp/MeinBackup

https://docs.influxdata.com/influxdb/v1.8/administration/backup_and_restore/

[crunchip]

@naturfreund da du noch influx 1.x verwendest, kannst du zumindest mit InfluxDBStudio arbeiten.

[Naturfreund]

@glasfaser

Sorry, das geht mir noch zu schnell. Ich würde jetzt gerne eines der folgenden Backups wiederstellen:

pi@raspberrypi:/opt/iobroker/backups $ dir
2022_03_04-15_37_18_backupiobroker.tar.gz
influxDB_2023_01_03-02_40_18_backupiobroker.tar.gz
influxDB_2023_01_04-02_40_18_backupiobroker.tar.gz
influxDB_2023_01_05-02_40_18_backupiobroker.tar.gz
influxDB_2023_01_06-02_40_18_backupiobroker.tar.gz
influxDB_2023_01_07-02_40_18_backupiobroker.tar.gz
influxDB_2023_01_08-02_40_18_backupiobroker.tar.gz
influxDB_2023_01_09-02_40_18_backupiobroker.tar.gz
influxDB_2023_01_10-02_40_18_backupiobroker.tar.gz
influxDB_2023_01_11-02_40_18_backupiobroker.tar.gz
influxDB_2023_01_12-02_40_18_backupiobroker.tar.gz

zum Beipsiel:

influxd restore - portable -db influxDB_2023_01_09-02_40_18_backupiobroker.tar.gz - newdb ioBroker_2023_01_09 /tmp/InfluxBackup

Und schon liegt unter /tmp/InfluxBackup die Datenbank? Woher kennt er denn den Pfad der Sicherungsquelle?

[Naturfreund]

@crunchip

Wäre auch eine Option.

[Glasfaser]

@naturfreund

gz zip entpacken ( welches Backup du haben möchtest ) und dann am Ende den Pfad im Code dazu angeben

Beispiel:

influxd restore -portable -db NamederaltenDatenbank -newdb NeuerDatenbankname  /opt/iobroker/backups/influxDB_2023_01_12-02_40_18_backupiobroker

NamederaltenDatenbank ist die alte Datenbank von Influx gemeint
NeuerDatenbankname ist deine neuen Datenbank zum testen gemeint

EDIT :
siehe oben

[Naturfreund]

@glasfaser

Ich hab aktuell nur eine Datenbank. Mit NamederaltenDatenbank ist dann iobroker gemeint?

pi@raspberrypi:~ $ influx
Connected to http://localhost:8086 version 1.8.10
InfluxDB shell version: 1.8.10
> show databases
name: databases
name
----
_internal
iobroker

[Glasfaser]

@naturfreund

ist dann iobroker gemeint?

ja

[Naturfreund]

@glasfaser

pi@raspberrypi:/tmp $ tar xfvz iobroker_2023_01_09-02_40_10_backupiobroker.tar.gz
backup/
backup/backup.json
backup/files/
backup/files/0_userdata.0/
backup/files/admin.0/
backup/files/lovelace.0/
backup/files/shelly.0/
backup/files/web.0/
backup/files/shelly.0/scripts/

Soweit so gut
Och mist, ich sehe ich hab die falsche Datei erwischt

[Glasfaser]

@naturfreund sagte in InfluxDB - Daten weg / Wiederherstellung:

iobroker_2023

???

[Naturfreund]

@glasfaser

pi@raspberrypi:/tmp $ tar xfvz influxDB_2023_01_09-02_40_18_backupiobroker.tar.gz
...
tar: .: Funktion utime fehlgeschlagen: Die Operation ist nicht erlaubt
tar: .: Kann Zugriffsrechte nicht zu rwxr-xr-t ändern: Die Operation ist nicht erlaubt
tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler

Was hab ich jetzt wieder falsch gemacht?

mit sudo hat es geklappt:

pi@raspberrypi:/tmp/backup $ dir
20230109T014018Z.manifest     20230109T014018Z.s494.tar.gz  20230109T014018Z.s726.tar.gz
20230109T014018Z.meta         20230109T014018Z.s502.tar.gz  20230109T014018Z.s734.tar.gz
20230109T014018Z.s278.tar.gz  20230109T014018Z.s510.tar.gz  20230109T014018Z.s742.tar.gz
20230109T014018Z.s286.tar.gz  20230109T014018Z.s518.tar.gz  20230109T014018Z.s750.tar.gz
20230109T014018Z.s294.tar.gz  20230109T014018Z.s526.tar.gz  20230109T014018Z.s758.tar.gz
20230109T014018Z.s302.tar.gz  20230109T014018Z.s534.tar.gz  20230109T014018Z.s766.tar.gz
20230109T014018Z.s310.tar.gz  20230109T014018Z.s542.tar.gz  20230109T014018Z.s774.tar.gz
20230109T014018Z.s318.tar.gz  20230109T014018Z.s550.tar.gz  20230109T014018Z.s782.tar.gz
20230109T014018Z.s326.tar.gz  20230109T014018Z.s558.tar.gz  20230109T014018Z.s790.tar.gz
20230109T014018Z.s334.tar.gz  20230109T014018Z.s566.tar.gz  20230109T014018Z.s798.tar.gz
20230109T014018Z.s342.tar.gz  20230109T014018Z.s574.tar.gz  20230109T014018Z.s806.tar.gz
20230109T014018Z.s350.tar.gz  20230109T014018Z.s582.tar.gz  20230109T014018Z.s814.tar.gz
20230109T014018Z.s358.tar.gz  20230109T014018Z.s590.tar.gz  20230109T014018Z.s822.tar.gz
20230109T014018Z.s366.tar.gz  20230109T014018Z.s598.tar.gz  20230109T014018Z.s830.tar.gz
20230109T014018Z.s374.tar.gz  20230109T014018Z.s606.tar.gz  20230109T014018Z.s838.tar.gz
20230109T014018Z.s382.tar.gz  20230109T014018Z.s614.tar.gz  20230109T014018Z.s846.tar.gz
20230109T014018Z.s390.tar.gz  20230109T014018Z.s622.tar.gz  20230109T014018Z.s854.tar.gz
20230109T014018Z.s398.tar.gz  20230109T014018Z.s630.tar.gz  20230109T014018Z.s862.tar.gz
20230109T014018Z.s406.tar.gz  20230109T014018Z.s638.tar.gz  20230109T014018Z.s870.tar.gz
20230109T014018Z.s414.tar.gz  20230109T014018Z.s646.tar.gz  20230109T014018Z.s878.tar.gz
20230109T014018Z.s422.tar.gz  20230109T014018Z.s654.tar.gz  20230109T014018Z.s886.tar.gz
20230109T014018Z.s430.tar.gz  20230109T014018Z.s662.tar.gz  20230109T014018Z.s894.tar.gz
20230109T014018Z.s438.tar.gz  20230109T014018Z.s670.tar.gz  20230109T014018Z.s902.tar.gz
20230109T014018Z.s446.tar.gz  20230109T014018Z.s678.tar.gz  20230109T014018Z.s910.tar.gz
20230109T014018Z.s454.tar.gz  20230109T014018Z.s686.tar.gz  20230109T014018Z.s918.tar.gz
20230109T014018Z.s462.tar.gz  20230109T014018Z.s694.tar.gz  20230109T014018Z.s926.tar.gz
20230109T014018Z.s470.tar.gz  20230109T014018Z.s702.tar.gz  20230109T014018Z.s934.tar.gz
20230109T014018Z.s478.tar.gz  20230109T014018Z.s710.tar.gz  20230109T014018Z.s942.tar.gz
20230109T014018Z.s486.tar.gz  20230109T014018Z.s718.tar.gz  influxDB_2023_01_09-02_40_18_backupiobroker.tar.gz

[Naturfreund]

@glasfaser said in InfluxDB - Daten weg / Wiederherstellung:

@naturfreund

gz zip entpacken ( welches Backup du haben möchtest ) und dann am Ende den Pfad im Code dazu angeben

Beispiel:

influxd restore -portable -db NamederaltenDatenbank -newdb NeuerDatenbankname  /opt/iobroker/backups/influxDB_2023_01_12-02_40_18_backupiobroker

NamederaltenDatenbank ist die alte Datenbank von Influx gemeint
NeuerDatenbankname ist deine neuen Datenbank zum testen gemeint

EDIT :
siehe oben

War schon zu spät gestern, hab nicht gesehen, dass du es durchgestrichen hattest.

[Naturfreund]

So, heute hab ich Zeit gehabt und hab die alte Datenbank wiedergestellt:

pi@raspberrypi:~ $ influx
Connected to http://localhost:8086 version 1.8.10
InfluxDB shell version: 1.8.10
> show databases
name: databases
name
----
_internal
iobroker
iobroker20230109

Hab mir mit InfluxDBStudio die Daten aus der Datenbank iobroker20230109 angesehen, bekomme aber keine "results":

Gleiches Query für die aktive ioBroker Datenbank fördert folgendes zu Tage:

Die Sicherung scheint für den Zeitraum gar keine Daten zu enthalten.

Auch für andere Datenpunkte sind in dem Backup Daten teilweise nur bis Februar vorhanden (Stichprobe):

Das verunsichert mich jetzt. Ich mache die Backups damit ich die Daten wieder herstellen kann. Die scheinen aber gar nicht enthalten zu sein

[Naturfreund]

Gestern war der Log leer, also keine warns oder errors influxdb betreffend. Heute wieder ein Eintrag:

2023-01-15 13:05:16.797 - info: shelly.0 (19859) [MQTT] Device 192.168.1.111 (shellyht / shellyht-A4CF12F40446 / SHHT-1#A4CF12F40446#1) connected! Polltime set to 5 sec.
2023-01-15 13:05:23.543 - info: influxdb.0 (19727) Store 1001 buffered influxDB history points
2023-01-15 13:05:23.640 - warn: influxdb.0 (19727) Error on writeSeries: Error: connect ECONNREFUSED 127.0.0.1:8086
2023-01-15 13:05:23.641 - info: influxdb.0 (19727) Host not available, move all points back in the Buffer
2023-01-15 13:05:33.645 - info: influxdb.0 (19727) Connecting http://localhost:8086/ ...
2023-01-15 13:05:33.645 - info: influxdb.0 (19727) Influx DB Version used: 1.x
2023-01-15 13:05:33.657 - error: influxdb.0 (19727) Error: connect ECONNREFUSED 127.0.0.1:8086
2023-01-15 13:05:43.657 - info: influxdb.0 (19727) Connecting http://localhost:8086/ ...
2023-01-15 13:05:43.658 - info: influxdb.0 (19727) Influx DB Version used: 1.x
2023-01-15 13:05:43.684 - info: influxdb.0 (19727) Store 1209 buffered influxDB history points

[crunchip]

@naturfreund noch irgendwelche anderen verdächtigen Meldungen vor dieser Zeit im log?
lief ein backup?

so am Rande wie voll ist die Platte?
wenn du da sämtliche Backups local liegen hast und ne Datenbank, könnte auch sein das die Platte voll ist und keine Daten gespeichert werden

[Naturfreund]

@crunchip

Auf der SD Karte sind noch 4,6 GB frei.
Ein Grund warum ich auf Google Drive umgestiegen bin, ich wollte die Backups nicht lokal liegen haben und die SD zusätzlich mit Schreibzyklen quälen.
Das hat nicht funktioniert, da er immer erst auf SD schreibt und dann ans Drive verschickt.

Hab die Anzahl an Datenpunkten im Buffer von 50 auf 1000 erhöht, siehst du auch im Log.
Macht absolut Sinn so viele wie möglich zu puffern.

Ich werde jetzt noch ein neueres Backup (> 09.01.23) wieder herstellen und nachsehen ob die Daten der letzten Tage da enthalten sind.

Wenn das auch nichts drin hat, stoße ich direkt ein Backup über Influxd an.