Raspberry Pi Influxdb Backup – Datenbank ganz einfach sichern

Raspberry Pi Influxdb Backup & Restore

Warum ein influxdb Backup?

Das beantworte ich mal ganz kurz und knapp: Weil es deine Daten sind und du sie nicht verlieren willst!
Es stellt sich nicht die Frage ob jemals ein Datencrash auftauchen wird, sondern nur die Frage WANN er auftaucht. Und ob du dann ein Backup zur Stelle hast….
Falls du noch mehr Gründe benötigst:

• Schutz vor Datenverlust: Backups schützen deine Datenbank vor Datenverlust, falls Hardwareprobleme, Stromausfälle oder andere unvorhergesehene Ereignisse auftreten.
• Wiederherstellungsmöglichkeit: Wenn deine Datenbank durch ein unvorhergesehenes Ereignis beschädigt wird, kannst du sie mit Hilfe eines Backups wiederherstellen.
• Redundanz: Backups können dazu verwendet werden, eine redundante Kopie deiner Datenbank zu erstellen, die auf einer anderen Maschine oder einem anderen Datenträger gespeichert wird. Dadurch wird sichergestellt, dass deine Daten immer verfügbar sind, auch wenn die primäre Speicherlösung ausfällt.
• Archivierung: Wenn du gesetzliche Anforderungen oder Datenschutzbestimmungen einhalten musst, kann das Archivieren von Backups eine wichtige Maßnahme sein, um sicherzustellen, dass deine Daten langfristig verfügbar und sicher aufbewahrt werden.
• Migration: Du kannst über ein Backup deine Daten auch auf eine andere Umgebung migrieren. Zum Beispiel von einem 32bit Raspberry auf einen neuen 64bit Raspberry.

Raspberry Pi – Influxdb Backup für v1.8

Es gibt Unterschiede zwischen Influxdb v1.8 und Influxdb v2.x – auch beim Backup – daher achte auf die von dir genutzte Version.

Hier geht es jetzt erst einmal um das Backup der Influxdb v1.8.

Da sich meine anderen Artikel fast immer auf eine Docker-Installation beziehen, werde ich auch hier die notwendigen Schritte für ein solches Szenario aufzeigen und erklären.
Allerdings sind die Befehle für die influxdb auch innerhalb des Docker-Container dieselben. Solltest du also deine Datenbank direkt installiert haben, denke dir einfach die Docker Befehle weg und es sollte dann auch funktionieren 😉

Beginnen wir also mit dem üblichen “ersten” Schritt: SSH-Verbindung zu deinem Raspberry/Linux System aufbauen. Wer mich kennt weiß was jetzt kommt: Ich empfehle dafür MobaXterm! Es ist einfach ein wirklich geniales Tool. Und nein, ich bekomme kein Geld dafür!
Natürlich kannst du auch Putty oder irgend ein anderes Tool benutzen.

Sobald du auf deinem System bist, wo Docker und influxdb v1.8 installiert ist, schauen wir uns zuerst die laufenden Container an:

docker ps

Je nach laufenden Container kann das sehr schnell unübersichtlich werden.
Da wir aber nur den Namen, bzw. die ContainerID benötigen, lassen wir uns einfach weniger Informationen anzeigen:

docker ps --format "{{.ID}} : {{.Names}} : {{.Image}} : {{.State}}"

Suche dir jetzt die influxdb heraus und merke dir die ID. In meinem Fall wäre es die 4128eabecdc2.
Mit dieser ContainerID starten wir jetzt gleich das Backup. Es gibt hier zwei Varianten wie du dieses durchführen kannst.

Alle Datenbanken im influxdb Backup sichern

Die Backups erzeugen einzelne Dateien und werden innerhalb des Containers gespeichert. Ich nehme hier den Pfad /opt/influxdb/data/backup/. Keine Sorge sollte dieser bei dir nicht vorhanden sein, denn der Backup-Prozess würde ihn anlegen.

Um alle eingerichteten (eigene und von influxdb benötigte) Datenbanken in einem Rutsch zu sichern, genügt folgender Befehl. Bedenke aber, dass je nach Menge von Datenbanken und Daten, dieser Vorgang einiges an Zeit benötigen könnte. Außerdem musst du natürlich die ID deiner influxdb nehmen:

docker exec -it 4128eabecdc2 influxd backup -portable /opt/influxdb/data/backup/

Nur bestimmte Datenbanken im influxdb Backup sichern

Du kannst auch nur ein Backup einer bestimmten Datenbank starten.
Solltest du genau wissen wie diese heißt, dann überspringe den nächsten Schritt einfach.
Ansonsten schauen wir uns jetzt erst einmal an, wie wir herausfinden können, wie unsere Datenbanken eigentlich heißen.

Auch hierzu benötigen wir die ContainerID von dem influxdb-Container.
In meinem Fall ist das die 4128eabecdc2. Mit dieser starten wir jetzt einfach eine influx-Shell:

docker exec -it 4128eabecdc2 influx

Du bist dann auch schon direkt in der influxdb-Umgebung. Zu erkennen an dem “ > “.
Hier kannst du jetzt show databases eingeben und mit Return abschicken. Du siehst dann alle angelegten Datenbanken:

Merke dir den Namen deiner Datenbank die du sichern willst, und verlasse die Umgebung mit exit.

Jetzt wo wir alle notwendigen Informationen zusammen haben, können wir auch endlich den influxdb Backup-Prozess starten.

Wie weiter oben schon erwähnt, wird das Backup innerhalb des Containers gespeichert. In meinem Beispiel unter /opt/influxdb/data/backup/. Sollte dies bei dir nicht existieren, werden die Ordner automatisch angelegt.
Und denke bitte daran, dass du die ContainerID und den Namen der Datenbank an deine Umgebung anpassen musst:

docker exec -it 4128eabecdc2 influxd backup -portable -database raspberry_live /opt/influxdb/data/backup/

Je nach Menge der Daten kann der Vorgang ein wenig Zeit in Anspruch nehmen.

Die influxdb Backup Daten aus dem Container holen

Egal ob du jetzt eine bestimmte oder alle Datenbanken gesichert hast, die Daten liegen aktuell noch in dem influxdb Container. Hier nützen sie uns aber nicht wirklich was und wären bei einem Ausfall / Neustart des Containers einfach weg.

Daher holen wir sie jetzt aus dem Container heraus und sichern sie wo wir wollen.
Als Beispiel nehme ich den Ordner /home/pi/backup auf dem Host.
Du kannst natürlich auch jeden anderen verfügbaren Ordner bei dir benutzen. Vielleicht sogar direkt auf einem externen Speicherplatz? Einer Synology NAS? Der Mount muss natürlich vorhanden sein 😉

Der folgende Befehl wird unsere Backup-Daten aus dem Docker-Container lokal auf unseren Host kopieren. Solltest du meinen Beispielen bisher gefolgt sein, kannst du den Pfad /opt/influxdb/data/backup/ so übernehmen. Lokal lege ich die Daten unter: /home/pi/backup ab. Falls diese Pfade bei dir abweichen, musst du sie dann natürlich in dem Befehl anpassen.
Auch die ContainerID wird bei dir eine andere sein:

docker cp 4128eabecdc2:/opt/influxdb/data/backup/ /home/pi/backup

Sobald alle Dateien kopiert wurden kannst du dich glücklich schätzen, denn jetzt hast du ein influxdb Backup deiner Datenbanken. Herzlichen Glückwunsch! 😛

Aber halt… was wäre ein Backup ohne ein Restore? Natürlich kannst du ab jetzt einfach ab und an Backups erstellen, und dich erst bei einem Datenverlust schlau machen, wie du deine Daten aus dem Backup zurück in die Datenbank bekommst.

Allerdings wäre das keine gute Taktik. Denn du solltest immer wieder mal prüfen, ob der Restore Prozess auch wirklich funktioniert. Was nützt dir ein Backup, wenn vielleicht bei diesem Prozess etwas schief gelaufen ist und sich gar nicht mehr widerherstellen lässt?

Der influxdb Restore Prozess – Auch ohne Crash wichtig

Wie prüft man jetzt ob die Backup-Daten soweit ok sind und der Restore-Prozess auch funktioniert?
Da wir Docker benutzen, ist dies sogar sehr einfach und schnell erledigt. Ich liebe diese Container 🙂

Denn wir wollen jetzt gar nicht erst alles löschen und dann wieder in die Datenbank einspielen – das wäre extrem blöd wenn die Backup-Daten doch nicht zu gebrauchen sind – sondern erstellen uns einfach ganz fix einen neuen influxdb-Container und führen da den Restore-Prozess aus.

Die Docker Testumgebung

Auf deiner Umgebung, wo Docker installiert ist, werden wir jetzt einen neuen Container erzeugen. Hier führen wir unseren influxdb Restore-Prozess durch und prüfen ob alles gut aussieht.
Dazu ändern wir lediglich den Port etwas ab, denn die dürfen nicht bereits verwendet werden. Solltest du einen Fehler mit den von mir genannten Port erhalten, ändere diesen einfach in dem Befehl ab:

docker run -p 8089:8089 \
-e INFLUXDB_ADMIN_USER="" \
-e INFLUXDB_ADMIN_PASSWORD="" \
-v influxdb:"/var/lib/test/" \
influxdb:1.8

Danach suchen wir uns die entsprechende ContainerID heraus…:

docker ps --format "{{.ID}} : {{.Names}} : {{.Image}} : {{.State}}"

…und kopieren unsere influxdb Backup-Daten in diesen Container (achte auf die Pfade und passe die ID an):

/home/pi/backup/backup/ = Der Pfad wo du auf deinem Host die Backup Dateien gespeichert hast
06cb7da18126 = Passe diese ContainerID entsprechend an. Es muss die ID von dem gerade angelegten Container sein. NICHT die von deiner eigentlichen influxdb!
/home/user/ = ist relativ egal. Dies ist der Pfad wo wir die Dateien in den Container ablegen. Die Ordner werden entsprechend erstellt

docker cp /home/pi/backup/backup/ 06cb7da18126:/home/user/

Jetzt folgt der eigentliche “Restore”-Befehl. Dieser fügt die gesicherten Daten in die influxdb hinein.
Bei nur einer direkt angegebenen Datenbank wäre es folgender Befehl:

06cb7da18126 = ID deines Test-Container
-db raspberry_live = Name der Datenbank die du gesichert hast. Hast du weiter oben ALLE gesichert nimm den nächsten Befehl.
/home/user/ = Der Pfad zu den Backup-Dateien IN dem Test-Container

docker exec -it 06cb7da18126 influxd restore -portable -db raspberry_live /home/user/

Und falls du keine bestimmte Datenbank, sondern alle, gesichert hast:

docker exec -it 06cb7da18126 influxd restore -portable /home/user/

Auch dies wird je nach Anzahl der Datenbanken und der eigentlichen Daten ein wenig Zeit in Anspruch nehmen. Sobald der Vorgang beendet wurde, prüfen wir auch direkt ob es funktioniert hat.

Dazu starten wir, in dem Test-Container, die influxdb Umgebung (denk an die richtige ContainerID) und lassen uns erstmal alle Datenbanken anzeigen:

docker exec -it 06cb7da18126 influx
show databases

Sind deine hier nicht vorhanden = doof gelaufen. Dann hat was nicht geklappt und du solltest nochmal alle Schritte überprüfen. Vielleicht sogar das influxdb Backup wiederholen. Bei Problemen kannst du aber auch gerne hier oder in Discord fragen.

Deine Datenbanken sind da? Perfekt. Dennoch prüfen wir auch noch, ob wirklich Daten vorhanden sind. Dazu aktivieren wir jetzt die entsprechende Datenbank:

use raspberry_live

Falls du nicht genau weißt wonach du jetzt suchen könntest, kannst du dir alle Measurements anzeigen lassen:

show measurements

Wir suchen jetzt einfach mal nach cpu_temperature Daten der letzten 2 Tage (Zeitraum musst du natürlich auf deine Gegebenheiten anpassen):

SELECT * FROM cpu_temperature WHERE time > now() - 2d

Mit exit verlässt du den Container wieder.

So kannst du, zumindest grob, überprüfen ob dein influxdb Backup erstellt wurde und der Restore Prozess auch funktioniert hat.
Dies solltest du immer wieder mal durchführen. Einfach um sicherzustellen, dass dein influxdb Backup auch weiterhin funktioniert.

Zum Schluss werden wir den Test-Container wieder löschen (GANZ WICHTIG! Nimm die richtige Container-ID von dem Test-Container!):

docker stop 06cb7da18126
docker rm 06cb7da18126

Schritt für Schritt zum Backup

• SSH zu deinem Raspberry / Linux
• docker ps
• docker exec -it ID_DEINER_INFLUXDB influx
• optional – show databases (falls du nur eine Datenbank sichern willst)
  Dann deren Namen merken und exit eingeben
• docker exec -it ID_DEINER_INFLUXDB influxd backup -portable /opt/influxdb/data/backup/ (speichert das Backup innerhalb des Containers)
• optional – docker exec -it ID_DEINER_INFLUXDB influxd backup -portable -database NAME_DER_DATENBANK /opt/influxdb/data/backup/ (falls du nur eine bestimmte Datenbank sichern willst)
• docker cp ID_DEINER_INFLUXDB:/opt/influxdb/data/backup/ /home/pi/backup (kopiert das gesicherte influxdb Backup aus dem Container lokal zum Host)

Das influxdb Backup Script für v1.x

Du möchtest das influxdb Backup ein wenig automatisieren und es vielleicht sogar regelmäßig starten lassen? Kein Problem. Ein ganz einfaches Skript, welches dir bei dem Backup deiner influxdb v1.8 hilft, stelle ich dir jetzt vor.

Du kannst das sh-Script zum Beispiel in dein Crontab hinterlegen und es jede Nacht ausführen lassen. Wie genau ist allerdings ein anderes Thema.
Hier geht es lediglich um das influxdb Backup Script:

#!/bin/bash

# Variablen anlegen

host_local="/home/pi/backup/" #Pfad wo deine Backup-Datein lokal auf deinem Host gespeichert werden sollen

NOW=$(date +"%d%m%Y")
RED='\033[31m'
NC='\033[0m'


# Docker listet die Container auf und wir schränken die Ausgabe auf influxdb:1. ein.
# Da wir nur Container mit einem influxdb v1.x haben möchten. Für die v2.x würde dieses Skript nicht funktionieren

ps_output=$(docker ps --format "{{.ID}}:{{.Names}}:{{.Image}}:{{.State}}" | grep "influxdb:1.")

# prüfen ob überhaupt eine influxdb v1.x gefunden wurde
if [ -z "$ps_output" ]; then
  echo "Keine passenden Container gefunden"
  exit 1
fi

# Schleife über jede Zeile der Ausgabe
while IFS=: read -r id name image status; do
  # Speichern der Werte in separaten Variablen
  container_id="$id"
  container_name="$name"
  container_image="$image"
  container_status="$status"
  backup_folder="${container_id}_${NOW}_backup"

  echo "$backup_folder"
  echo -e "Starte Backup-Prozess für ContainerID: ${RED}$container_id ${NC} mit dem Namen: ${RED}$container_name${NC}"
  echo "Bitte warten, erstelle Backup...."
  docker exec $container_id influxd backup -portable -db raspberry_lab /opt/influxdb/data/$backup_folder/
  echo "Backup erstellt!"
  echo -e "Kopiere Backup aus Container: ${RED}$container_id ${NC} nach: ${RED}$host_local ${NC}  Bitte warten...."
  docker cp $container_id:/opt/influxdb/data/$backup_folder/ $host_local

  num_files_container=$(docker exec ${container_id} find /opt/influxdb/data/${backup_folder}/ -type f | wc -l)
  num_files_host=$(find ${host_local}${backup_folder} -type f | wc -l)

echo $num_files_container
echo $num_files_host

  if [ $num_files_container -eq $num_files_host ]; then
        echo "Kopieren erfolgreich"
        echo -e "Lösche Backup in Container:${RED}$container_id ${NC}-${RED}$container_name${NC}-Pfad:/opt/influxdb/data/$backup_folder/"
        docker exec $container_id rm -r /opt/influxdb/data/$backup_folder/
        echo "Löschen erfolgreich"
  else
        echo "Die Ordner haben eine unterschiedliche Anzahl an Dateien. Bitte manuell prüfen!"
        echo -e "${RED} Pfad:/opt/influxdb/data/$backup_folder/ enthält $num_files_container Dateien${NC}"
        echo -e "${RED} und Pfad: $host_local/$backup_folder enthält $num_files_host Dateien${NC}"
        exit 1
  fi

  echo "Backup erfolgreich"

done <<< "$ps_output"

Influxdb Backup für v2.x

Es gibt influxdb in Versionen v1.x und v2.x – diese unterscheiden sich grundlegend! Hier wurde zwischen den Versionen die SQL-Language komplett geändert. Somit funktionieren zum Beispiel auch alte Grafana-Dashboards nicht mehr und auch einige Scripte, die nur für v1.x geschrieben wurden, sind mit der v2.x dann nicht mehr funktionstüchtig.
Daher habe ich dazu auch einen eigenen Artikel geschrieben und ein Grafana-Dashboard für v2.x angepasst.

Bei dem Backup und Restore Prozess sieht es ähnlich aus. Aber keine Sorge, auch da versuche ich dir Schritt für Schritt aufzuzeigen was du machen musst.

Beginnen wir mit dem wichtigsten: Du brauchst einen Token! Da du dich über ein Backup schlau machst, wirst du also schon Daten auf einer influxdb v2.x Datenbank haben. Somit hast du auch irgendwo bereits einen Token hinterlegt.
Denn einmal generiert, kannst du ihn dir nicht mehr auf der WebGui anzeigen lassen!

Falls es dir so geht wie mir…und du ihn auch nicht mehr weißt, oder vergessen hast WO du ihn notiert hast….gibt es eine Möglichkeit. In der Regel wirst du irgendwo telegraf eingesetzt haben, um Daten an deine influxdb zu senden. Und in derer config-Datei ist der Token hinterlegt.

Also verbinde dich per SSH mit deinem System wo du telegraf installiert hast.
Dort wechselst du in das Verzeichnis /etc/telegraf und suchst nach “token“:

cd /etc/telegraf/
cat telegraf.conf | grep "token"

Jetzt solltest du deinen Token sehen und kopieren können:

Wechsel nun wieder zurück zu deinem System auf dem Docker und die influxdb v2.x läuft.
Hier suchen wir uns die entsprechende ContainerID heraus:

docker ps --format "{{.ID}}:{{.Names}}:{{.Image}}:{{.State}}" 

In meinem Fall wäre es die “0478cefca792“, bei dir musst du die entsprechende ID kopieren.
Bevor wir das influxdb Backup starten werden, solltest du dir überlegen an welchem Ort du die Dateien sichern möchtest.

Hast du vielleicht sogar beim Einrichten des influxdb-Containers bereits ein Verzeichnis eingebunden? Prüfen kannst du es mit diesem Befehl und deiner ContainerID:

docker inspect 0478cefca792 | grep -A 2 "Binds"

Die Ausgabe sollte in etwas so aussehen:

In meinem Fall habe ich bereits den Container-Pfad /var/lib/influxdb2 mit meinem lokalen Pfad (außerhalb des Containers) /opt/influxdb_2x verbunden. Somit gebe ich bei dem influxdb Backup-Befehl einfach den entsprechenden Container-Pfad an und werde die Daten außerhalb des Containers sehen. Hast du keinen Mount angelegt, auch nicht schlimm, überspringe den nächsten Schritt und schaue weiter unten nach.

Wir starten jetzt mit der richtigen ContainerID, deinem Token und dem gemounteten Pfad das influxdb Backup

docker exec 0478cefca792 influx backup /var/lib/influxdb2/backups \
  -t DEIN-TOKEN-FÜR-DIE-INFLUXDB-V2.x

Im Idealfall startet jetzt das Backup, dies benötigt einige Zeit und du findest die Dateien auch außerhalb deines Containers.

Auf meinem Host unter /opt/influxdb_2x/ wurde jetzt ein Ordner mit dem Namen backups erstellt und die gesicherten Daten abgelegt:

Falls du bei dem “mount” leer ausgegangen bist, kannst du folgender Weise vorgehen. Natürlich wieder mit deiner ContainerID für influxdb v2.x und deinem Token. Der Pfad wird dann innerhalb des Containers angelegt, sollte er nicht existieren:

docker exec 0478cefca792 influx backup /home/backups \
-t DEIN-TOKEN-FÜR-DIE-INFLUXDB-V2.x

Da wir unser influxdb Backup aber außerhalb des Containers haben wollen, kopieren wir diese einfach lokal auf unseren Host. In Dem Beispiel nach /home/pi/backup/ auf dem Host:

docker cp 0478cefca792:/home/backups/ /home/pi/backup

Damit der Container nicht irgendwann “platzt” solltest du die Backup Dateien in dem Container wieder löschen: (Nimm die richtige ContainerID und den richtigen Pfad – weg ist weg….)

docker exec 0478cefca792 rm -r /home/backups/

Wie ich schon bei dem influxdb Backup für v1.x geschrieben habe, nützt dir ein Backup gar nichts, wenn es kaputt ist. Daher solltest du in regelmäßigen Abständen deine Backup-Dateien und den Restore-Prozess überprüfen.

Restore für influxdb v2.x und prüfen des Backups

Auch hier machen wir es uns einfach – dank Docker – und starten einfach einen neuen Test-Container mit einem influxdb v2.x Image:

docker run --name test_restore -p 8089:8089 influxdb:2.6.1

Jetzt bleibt der Container in deinem Terminal geöffnet bist du STRG+C drückst. Du kannst das jetzt so lassen und mit einem zweiten Terminal-Fenster weiterarbeiten oder du gibst nach dem STRG+C dann nochmal docker start test_restore ein.

Wir könnten zwar einfach mit dem Namen “test_restore” weitermachen, aber es schadet nie einige Befehle zu vertiefen und uns die ContainerID herauszusuchen:

docker ps --format "{{.ID}} : {{.Names}} : {{.Image}} : {{.State}}" 

In meinem Fall wäre das die ContainerID: 24457a588aef für die neue test_restore Umgebung.
Damit wir gleich überhaupt erfolgreich Daten einspielen können, müssen wir influxdb v2.x erst einmal “Pseudo-Initialisieren” (du kannst das WIRKLICH so übernehmen und musst bis auf die ContainerID nichts anpassen):

docker exec 24457a588aef influx setup \
  --username "TestUser" \
  --password "TestPasswd" \
  --org "TestOrg" \
  --bucket "TestBucket" \
  --skip-verify \
  --force \
  --token MySecR37t0keNForTh3T3stDatabas3

Keine Fehlermeldung erhalten? Prima! Dann kopieren wir jetzt unser Backup in den neuen Container. Auch hier mit deiner ContainerID des Test-Containers und dem Pfad wo du auf deinem Host die Backup-Dateien liegen hast. In meinem Beispiel wäre das /home/pi/backup/:

docker cp /home/pi/backup/ 24457a588aef:/home/user/backups/

Jetzt starten wir endlich den eigentlichen influxdb Restore-Prozess:

docker exec 24457a588aef influx restore \
  /home/user/backups/ \
  --full

Es wird auch der Token und alle anderen Config-Einstellungen überschrieben!
Alle weiteren Schritte müssen ab jetzt wieder mit deinem “echten” Token aus dem Backup durchgeführt werden!

Also legen wir los und schauen uns an, ob auch wirklich Daten eingespielt wurden.
Wir lassen uns erst einmal alle Measurements anzeigen. Dafür musst du deinen Token, deine org und dein Bucket angeben.

Du kennst deine org nicht mehr? Kein Problem: (mit deiner ContainerID und deinem echten Token)

docker exec 24457a588aef influx org ls --token DEIN-TOKEN-FÜR-DIE-INFLUXDB-V2.x

Dein Bucket kennst du auch nicht mehr? Auch kein Thema, einfach deine gerade herausgefundene org hier eintragen und die ID und den Token anpassen:

docker exec 24457a588aef influx bucket ls --org dwc --token DEIN-TOKEN-FÜR-DIE-INFLUXDB-V2.x

Jetzt haben wir alle Informationen zusammen um uns die Measurements anzeigen lassen zu können. Du musst hier anpassen:
– die Container ID
– org (siehe zwei Schritte höher)
– token (DEIN-TOKEN-FÜR-DIE-INFLUXDB-V2.x)
– bucket (siehe einen Schritt höher)

docker exec 24457a588aef influx query \
--org dwc \
--token DEIN-TOKEN-FÜR-DIE-INFLUXDB-V2.x \
'import "influxdata/influxdb/schema" schema.measurements(bucket: "dwc")'

Wir schauen uns an, ob für cpu_temperature Daten vorhanden sind. Hier musst du das natürlich auf deine Bedürfnisse anpassen. Sammelst du keine CPU Temperatur Daten, findest du hier natürlich nichts. Auch den Zeitrahmen musst du vielleicht ändern:

docker exec 24457a588aef influx query \
--org dwc \
--token DEIN-TOKEN-FÜR-DIE-INFLUXDB-V2.x \
'from(bucket: "dwc") |> range(start: -1d) |> filter(fn: (r) => r._measurement == "cpu_temperature")'

Herzlichen Glückwunsch, du hast erfolgreich ein Backup durchgeführt und bestätigt, dass es funktioniert hat und Daten enthält.

Zum Schluss werden wir den Test-Container wieder löschen (GANZ WICHTIG! Nimm die richtige Container-ID von dem Test-Container!):

docker stop 24457a588aef
docker rm 24457a588aef