Backup und Restore der Influx Datenbank

[PV-Wolf]

Es ist alles nicht so einfach:

Geschafft habe ich: sudo influxd backup -portable -database solaranzeige /tmp/solaranzeige_backup

Sehe ich aber auch nur, wenn ich mich als root anmelde

Darin finde ich dann u.a. eine Datei mit dem Namen: 20220530T093251Z.s17.tar.gz - Der Name enthält vermutlich das Tagesdatum.

Darin ein Verzeichnis: Solaranzeige\autogen\17 und die Datei: 000000001-000000001.tsm !

Ist dies die Sicherungsdatei der InfluxdB ?

Dann würde ich o.g. sudo Befehl zunächst einmal wöchentlich händisch ausführen, da ich am USB Stick mounten der Fritz!Bos scheitere.

Spannend wäre dann zu wissen, wie ich die Daten wieder zurück kopieren kann ?!?!

[andreas_n]

da ich am USB Stick mounten der Fritz!Bos scheitere.

schaust du da mal,

https://www.andwil.de/weblog/linux-frit ... unten-cifs

gruss

[limatango]

Guten Tag zusammen.

Ich habe zwecks stündlicher Sicherung der Datenbank einen Backup-Ordner auf meiner Synology eingerichtet und mittels nfs und fstab auf dem Raspi gemountet.
Über cronjob wird dann stündlich das Backup der drei Datenbanken "master", "slave" und "solaranzeige" erstellt.
Das funktioniert soweit auch gut.
Allerdings musste ich feststellen, dass bei der Datenbank "master" eine Datei mehr erstellt wird als bei den anderen beiden.
Es wird jeweils eine .manifest, eine .meta und eine .tar.gz erstellt.
Nur bei der Datenbank "master" wird eine zusätzliche .tar.gz erstellt.

Womit könnte das zusammenhängen?

[TeamO]

Das liegt an der Größe der zu sichernden Datenbank. Bei mir werden aktuell in der Hauptdatenbank 137 X.tar.gz Dateien erstellt.

[limatango]

Danke schön.
Gut zu wissen.
Hatte eher erwartet, dass die einzelnen Dateien größer wären.

Wie verhält es sich bei der Wiederherstellung, wenn ich so viele Einzeldateien habe?

[TeamO]

Das macht nichts aus

[olabre]

ich kann nur jedem raten auf eine SSD zu wechseln. Die Stabilität der SD Karten ist bekanntermaßen beschränkt. Ich habe jetzt nach ca. einem Jahr SD Karte die Situation, dass nach einem normalen InfluxDB Backup Daten fehlen. Im Backup sind sie noch da - in der DB selber fehlen teilweise mehrere Monate. Dies kann/muss mit der SD Karte zu tun haben. Auf meinem neuen System mit SSD klappt das Backup sehr gut. Das Restore der Daten klappt gemäß Anleitung in eine parallel DB und dem folgenden Abgleich per SQL Befehl.

auf der Bash:
influxd restore -portable \
-db example-db \
-newdb example-new-db \
/path/to/backup-directory

gefolgt von im InfluxDB Prompt:

SELECT *
INTO "example-db".autogen.:MEASUREMENT
FROM "example-tmp-db".autogen./.*/ GROUP BY *

So tut es bei mir auf jeden Fall. Meine Backups sind aber leider trotzdem nicht vollständig, sodass auch meine Statistik nicht vollständig ist. Das ist dann blöd, wenn man mal Auswertungen fahren will.
Ich backupe in einen Mount meiner Synology.

Olaf

P.S. Da die Dashboard vom Grafana auch im Influx liegen, sind diese dann auch weg. Ich backupe die Dashboard parallel per json File. Scripte dazu gibt es ausreichend.

[andreas_n]

Moin Olaf,

der Pi auf SSD tuts schon, SD hält nicht, ich hab aber andere Anwendungen, wo ein pi2 als Heizungsüberwachung mit SD/USB Stick schon seit zig Jahren durchläuft.Jeden Tag einmal rebootet.Bei Bekannten läuft ein pi2 mit 64er SD als "Briefkastenmonitor" und speichert alle paar sek ein Bild, auch ohne Fehler

Was mir nach fast 3 Jahren Solaranzeige ,und damit pi4, auffällt ist eigenartig. Hab neulich erst wieder einen satten Absturz gehabt, wo der pi samt SSD nicht mehr ansprechbar war und auch nach mehrmaligem Reboot und Stecker raus..nicht mehr wollte...zu guter Letzt kam dann im Browser auch keine IP mehr sondern die MAC Adresse raus..
ich hab für solche "Launen" einen Reserve Pi samt SSD da liegen, fahr den hoch und ergänze dann die fehlenden Daten so gut es geht aus den Backups.

MEINE Vermutung: Die Fritzbox(en) verschlucken sich ab und an so alle paar Monate an DHCP, wie anders kann es sein, da ich den regulären Pi aus der Box löschen muss, dem neuen Pi die gleiche IP zuweise..und wenige Tage später, wenn sich alles wieder "beruhigt" hat (meine Nerven vor allem *gg* ), kann ich, als wär nix gewesen, das alles wieder retour stöpseln.

Auch eigenartig, die Pi 's werden täglich 05:20 rebootet, sollte ein Pi Schluckauf haben, müsste ja danach wieder Ruhe einkehren, tut es aber nie. den Pi3 den ich hier mal zum Testen da angestöpselt hab, lief durch..zumindest zeigte er keine Ausfälle in 2 Monaten.

Ich hab jetzt die max Stromstärke des USB Ports für den Pi hoch gesetzt, original kann der nur 600mA, für ALLE Ports in Summe!
Die kleine 120er SSD hier hat zwar nur 300mA Peak laut Datenblatt, aber im Keller wo der zweite Pi werkelt, hängen zusätzlich noch 3 rs485 Wandler, sollte rein theoretisch auch nix passieren. Und: ich hab überall das "..local.." gegen die IP ausgetauscht. Im Keller war zeitweise sogar ne HDD dran
-geht aber nicht jede,vmtl Anlaufstrom zu hoch

Warum genau sich der Pi so böse aufhängt, hab ich noch immer nicht herausgefunden, aber bisher war jedes backup inkl aller Datenbanken vorhanden.

Ich tippe immer mehr auf die Fritzen....