So sichern Sie einen InfluxDB-Docker-Container (2026)
Der richtige Weg, einen InfluxDB-Container zu sichern, ist ein logischer Dump, keine Datei-Kopie. Führen Sie `influx backup /backup/influx # (v2; v1 uses influxd backup -portable /backup)` im Container aus und sichern Sie dessen Ausgabe. Das Kopieren von /var/lib/influxdb2, während influx schreibt, erzeugt einen inkonsistenten Schnappschuss; der Backup-Befehl friert TSM-Shards und Metadaten über die Engine ein — die Hintergrund-Kompaktierung hinterlässt Ihnen so nie eine zerrissene Platten-Kopie.
Was Dockstash erkennt
| Erkannte Env-Keys | DOCKER_INFLUXDB_INIT_USERNAME, DOCKER_INFLUXDB_INIT_PASSWORD, DOCKER_INFLUXDB_INIT_ORG, INFLUXDB_HTTP_AUTH_ENABLED |
|---|---|
| Standard-Port | 8086 |
| Live-Datenpfade (nie im Betrieb kopiert) | /var/lib/influxdb2, /var/lib/influxdb |
| Beispiel-Images | influxdb:2.7, influxdb:2, influxdb:1.8, influxdb |
InfluxDB mit Dockstash sichern, Schritt für Schritt
Dockstash-Konto anlegen und das Dashboard öffnen
Registrieren Sie sich kostenlos auf app.dockstash.com/register. Der einmalige Einrichtungsassistent fragt nach Ihrem Storage-VPS (der Maschine, die die verschlüsselten Backups aufnimmt) und generiert ein Verschlüsselungspasswort — speichern Sie es sofort in einem Passwort-Manager, es wird genau einmal angezeigt.
Das Docker-Projekt mit InfluxDB hinzufügen
Auf dem Projects-Bildschirm erkennt Dockstash automatisch jeden Compose-Projektordner des Servers (standardmäßig unter /var/www). Wählen Sie das Projekt mit Ihrem InfluxDB-Service. Noch wird nichts gesichert — Sie sagen Dockstash nur, wo das Projekt liegt.
Prüfen, dass InfluxDB erkannt wurde
Öffnen Sie das Projekt und schauen Sie auf den Plan-Tab. Dockstash liest docker-compose.yml, erkennt das influxdb-Image samt Hauptversion und fügt eine Datenbank-Ebene mit dem richtigen Backup-Befehl hinzu — influx backup für v2, influxd backup -portable für v1 — samt aufgelöstem Containernamen und den gefundenen Env-Keys (DOCKER_INFLUXDB_INIT_USERNAME, DOCKER_INFLUXDB_INIT_PASSWORD, DOCKER_INFLUXDB_INIT_ORG). Dateien, Datenbanken und Proxy-Configs lassen sich vor dem Speichern umschalten.
Optional: den Backup-Befehl von Hand gegenprüfen
Wenn Sie vor der Automatisierung einen Beweis wollen, führen Sie influx backup in einen temporären Pfad im Container aus. Sie sehen, wie es Shard- und Metadaten-Dateien schreibt, während es jeden Bucket über die HTTP-API snapshottet — genau dieser Engine-koordinierte Schnappschuss wird gesichert, nie das laufende TSM-Verzeichnis.
docker exec <influxdb-container> influx backup /tmp/influx-testSpeicherziel bestätigen
Backups liegen als verschlüsselte restic-Snapshots auf Ihrem eigenen Storage-VPS, übertragen per SSH. Haben Sie den Assistenten abgeschlossen, ist das bereits konfiguriert; Host, Benutzer, Port oder SSH-Key ändern Sie jederzeit unter Settings → Storage.
Backup-Zeitplan festlegen
Wählen Sie im Schedule-Tab täglich, wöchentlich oder einen eigenen Cron-Ausdruck (inline validiert). Zeitreihendaten sammeln sich schnell — täglich ist der richtige Standard, stündlich bei geschäftskritischen Metriken. Ergänzen Sie einen wöchentlichen Prune-Zeitplan mit Ihrer Aufbewahrungsrichtlinie.
Das erste Backup jetzt ausführen
Klicken Sie auf Backup Now auf der Projektkarte. Dockstash führt den versionsrichtigen Backup-Befehl im Container aus — influx backup über die HTTP-API bei v2, influxd backup -portable bei v1 — und streamt den Schnappschuss direkt in restic. Die Live-Ausgabe verfolgen Sie im Log-Panel.
Snapshot bestätigen
Nach dem Lauf zeigt die Projektkarte die neue letzte Backup-Zeit, die Snapshot-Anzahl und die Repository-Größe. Öffnen Sie den Snapshots-Bildschirm: Der Wiederherstellungspunkt erscheint in der Zeitleiste — Ihr Beweis, dass das Backup off-site angekommen ist.
Der Dump-Befehl
influx backup /backup/influx # (v2; v1 uses influxd backup -portable /backup)Der Restore-Befehl
influx restore /backup/influx # (v1 uses influxd restore -portable /backup)der Backup-Befehl friert TSM-Shards und Metadaten über die Engine ein — die Hintergrund-Kompaktierung hinterlässt Ihnen so nie eine zerrissene Platten-Kopie.
Ein InfluxDB-Backup wiederherstellen und beweisen, dass es funktioniert
Ein InfluxDB-Backup wird erst real, wenn es wiederhergestellt wurde. Dockstash-Restores überschreiben Ihre laufenden Zeitreihendaten standardmäßig nie — Sie stellen zuerst an einen frischen Ort wieder her, prüfen die Buckets und befördern bewusst.
Wiederherstellungspunkt wählen
Öffnen Sie Snapshots, wählen Sie das Projekt und durchstöbern Sie die Zeitleiste. Jede Zeile ist ein konsistenter Engine-Schnappschuss Ihrer TSM-Shards und Metadaten — Buckets, Retention-Policies und Benutzer — plus die Projektdateien desselben Laufs.
An einen neuen Ort wiederherstellen
Klicken Sie auf Restore und behalten Sie den Standardmodus „Restore to new location". Tippen Sie den Projektnamen zur Bestätigung. Die Backup-Dateien landen im gewählten Zielpfad; das Live-Projekt bleibt unberührt.
Wiederhergestellte Daten prüfen
Laden Sie das Backup mit influx restore (v1: influxd restore -portable) in einen InfluxDB-Testcontainer und listen Sie die Buckets. Jeder erwartete Bucket muss mit seiner Retention-Policy erscheinen; eine schnelle Abfrage über einen jüngsten Zeitraum bestätigt, dass die neuesten Punkte drin sind.
docker exec <influxdb-container> influx bucket listBei Erfolg befördern
Wenn die Daten stimmen, richten Sie Ihre App darauf aus (oder wiederholen den Restore mit „Overwrite existing" — ein expliziter Opt-in). Besser: der wöchentliche Restore-Drill erbringt den Beweis automatisch.
Stolperfallen vermeiden
- Führen Sie restic nie auf dem laufenden TSM/WAL-Verzeichnis aus — Shards werden im Hintergrund kompaktiert, eine rohe Kopie ist inkonsistent.
- InfluxDB v2 nutzt `influx backup` (HTTP-API + Token); v1 nutzt `influxd backup -portable`. Dockstash erkennt die Hauptversion.
- v2-Backups brauchen ein Operator-Token mit Lesezugriff; ohne ist der Backup-Aufruf unautorisiert.
Häufige InfluxDB-Backup-Probleme
- Symptom
- Der Backup-Befehl scheitert mit „unknown command" oder unbekannten Flags.
- Ursache
- Die Kommandozeilen von v1 und v2 sind völlig verschieden: v2 nutzt influx backup gegen die HTTP-API, v1 nutzt influxd backup -portable. Der Befehl der einen Generation scheitert gegen die andere sofort — häufig nach einem Upgrade des Image-Tags.
- Lösung
- Prüfen Sie die Hauptversion des Containers (influxd version) und nutzen Sie den passenden Befehl. Dockstash erkennt die Hauptversion am Image und wählt automatisch richtig; nach einem Upgrade die Erkennung im Plan-Tab neu laufen lassen.
- Symptom
- influx backup scheitert mit „unauthorized" oder einem 401 der API.
- Ursache
- v2-Backups laufen über die HTTP-API und brauchen ein Operator-Token (all-access). Ein normales Lese-Token — oder gar keins bei aktivierter Auth — reicht nicht.
- Lösung
- Ein Operator-Token mit Lesezugriff auf die Buckets bereitstellen. Mit den DOCKER_INFLUXDB_INIT_*-Variablen funktioniert das Init-Admin-Token; sonst eins mit influx auth create --all-access anlegen und in die Plan-Zugangsdaten aufnehmen.
- Symptom
- Ein durch Kopieren von /var/lib/influxdb2 erstelltes Backup startet nicht, oder Abfragen liefern Teil-Daten.
- Ursache
- InfluxDB kompaktiert TSM-Shards im Hintergrund. Eine rohe Kopie des laufenden Verzeichnisses erwischt Shards mitten in der Kompaktierung — einige Dateien von davor, andere von danach — und erzeugt einen zerrissenen, inkonsistenten Store.
- Lösung
- Nie das laufende Datenverzeichnis kopieren. Nutzen Sie den Backup-Befehl der Engine, der Shards und Metadaten konsistent snapshottet — genau das führt Dockstash aus. Eine zerrissene Roh-Kopie ist meist nicht mehr zu retten; aus einem echten Backup wiederherstellen.
Mit Dockstash in einem Klick
Dockstash führt exakt den obigen Dump aus, übergibt ihn off-site an restic und drill-testet den Restore automatisch — kein Skript zu pflegen.
Zuletzt aktualisiert: July 2026
Häufig gestellte Fragen
Welcher Befehl sichert InfluxDB korrekt?
Für v2: `influx backup` gegen die HTTP-API mit Operator-Token. Für v1: `influxd backup -portable`. Beide snapshotten TSM-Shards und Metadaten konsistent. Dockstash erkennt die Version und führt den richtigen aus.
Kann ich die Shard-Dateien direkt kopieren?
Nein. InfluxDB kompaktiert TSM-Shards im Hintergrund; eine Kopie des laufenden Verzeichnisses ist inkonsistent. Nutzen Sie den Backup-Befehl, der über die Engine einen konsistenten Schnappschuss koordiniert.
Welches Token braucht das v2-Backup?
Ein Operator-Token (all-access) mit Leserecht auf die Buckets. Dockstash erkennt die Init-Token-Env-Keys; bei aktivierter Auth ein Token bereitstellen.
Wie stelle ich ein Zeitreihen-Backup wieder her?
Mit `influx restore` (v2) oder `influxd restore -portable` (v1) gegen eine frische Instanz. Dockstash stellt vor jedem Überschreiben zuerst in eine Staging-Instanz wieder her.
Wie oft sollte ich InfluxDB sichern?
Täglich reicht für die meisten Metrik-Workloads; stündlich, wenn eine verlorene Stunde an Punkten schmerzt. Im Free-Tarif sind Backups manuell (Backup Now); Pro ergänzt Zeitpläne bis stündlich, Business erlaubt jeden Cron-Ausdruck. Kombinieren Sie den Zeitplan mit einem wöchentlichen Restore-Drill.
Blockiert das Backup Schreibzugriffe auf InfluxDB?
Nein. Der Backup-Befehl snapshottet Shards über die Engine, während der Server weiter Schreibzugriffe annimmt — Ihre Collector und Dashboards laufen während des Backups weiter.
Wo liegen die Backups eigentlich?
Auf Ihrem eigenen Storage-VPS, als verschlüsselte restic-Snapshots per SSH übertragen. Dockstash hält Ihre Daten nie in einer Dritt-Cloud — Sie zeigen auf eine Maschine unter Ihrer Kontrolle, und das Repository ist mit einem Passwort verschlüsselt, das nur Sie besitzen.
Woher weiß ich ohne manuellen Restore, dass das Backup wiederherstellbar ist?
Planen Sie einen Restore-Drill. Dockstash stellt den neuesten Snapshot in einen isolierten Arbeitsbereich wieder her, vergleicht jede Datei byteweise mit der Quelle und prüft den Dump — dann stempelt es ein Bestanden/Fehlgeschlagen-Badge aufs Projekt. Ein wöchentlicher Drill heißt: immer frischer Beweis.