Influxdb2 fehlge. Umzug auf neue Hardware, noch zu retten?

[Lucifor1976]

Hello ihrs,

ich fang mal ganz vorne an, könnte etwas mehr werden.

Ich bin irgendwann von einem NUC mit nativer iobroker+influxdb1+grafana installation auf einen HP Proliant DL380Gen9 mit Unraid umgezogen.
Auf Unraid iobroker in einer VM, Grafana und Influx in einem Docker, zu dem Zeitpunkt auch gleich auf Influxdb2 gegangen, das ganze ist knapp drei Jahre her.
Irgendwann hat Unraid angefangen mich zu ärgern, mal waren docker einfach offline, dann mal die ein oder andere VM einfach aus, irgendwann hats auch das Docker File gekillt und alle Docker waren weg.
Im Endeffekt war es wohl eine Hardwareinkompatibilität von Unraid, dem Raidcontroller (HBA-Mode), ZFS und den SSD. Es lief nicht ordentlich und ich hab es immer nur "gerettet" wenn irgendwas war.
Die InfluxDB1 ist beim Umzug auf DB2 schon "verloren" gegangen, beim abhandenkommen des Docker Images auf Unraid dann ein zweites mal.
Unraid ging mir zuletzt so auf den Keks das ich am Wochenende radikal umgebaut habe.
Da ich zwei von den DL380G9 Servern habe, ist der Unraid noch funktionsfähig und nicht platt gemacht.

Jetzt nutze ich Proxmox 8.4.0 (um Welten besser, schneller und unkomplizierter als Unraid, muss ich an der Stelle mal sagen.
iobroker läuft nun in einer VM und beherbergt wieder grafana (Debian 12.11), influxDB2 ebenfalls in einer eigenen VM (Debian 12.11).
pi-hole, tasmoadmin, firefly, wikijs ect. als LCX Container.
Der Umzug von iobroker auf die neue VM per backitup war mega und ging problemlos.

Ärger macht -natürlich- influxdb2 -
Unraid Dock:

1. Versuch: Replication von der alten DB auf die neue, Replication wurde eingerichtet, streamt aber nur neue Daten und synct nicht die vollständige DB. War also nix.

2. Versuch: Backup per CLI, schlägt fehl auch nach mehren Versuchen (Datencontainer gelöscht während des Backups) Fehlermeldung singemäß, Backups wurden nicht koerrekt angelegt. War also auch nix.

3. Versuch: Backup per backitup, Backup läuft durch, schon gefreut, immerhin ein Erfolgserlebnis.
   Restore auf neuer VM, schlägt fehl, erst wegen unauth. Key. Hab dann irgendwann gemerkt das ein neu erstellter Key mit full access dazu nicht berechtigt ist.
   Also restore mit "Masterkey" (der der bei der erstinstallation eh angelegt wird.
   Restore bricht mittendrinn ab, keine Fehlermeldung, nichts, Backitup bleibt einfach stehen.

Jetzt hab ich heute gelesen das sich die Org auf keinen fall ändern darf, klasse. Mit der Erfahrung das auch die Org ect Key sensitiv sind, dämmert mir nun warum das alles nicht gehen will.

Die Org der alten DB und der neuen DB sind worttechnisch gleich, aber auf der alten mit einem Großuchstaben am Anfang, auf der neuen alle klein geschrieben.
Sauber
Jetzt läuft seit Samstag eine frische InfluxDB2 in der VM und sammelt Daten.
Hab ich nun in iregndeiner Weise noch eine Möglichkeit die alte DB in die neue zu bekommen, ohne das mir die seit Samstag geschriebenen Daten wieder verliere? Ja ich bin Datenjunky, mich ärgert es das bereits Daten seit drei Jahren weg sind. Die "alte" aktuelle DB lief seit Crash des Dockerfiles im Dezember.

Ich hoffe hier blickt jemand durch und hat eine Idee

Gruß
Lucifor

P.S. ich habe die alte DB lauffähig auf dem unraid Docker Container, und als Hardcopy auf meinem Mac (Verzeichnis eiskalt kopiert, falls es ein "export-script" gibt.

[Marc Berg]

@lucifor1976 sagte in Influxdb2 fehlge. Umzug auf neue Hardware, noch zu retten?:

Hab ich nun in iregndeiner Weise noch eine Möglichkeit die alte DB in die neue zu bekommen, ohne das mir die seit Samstag geschriebenen Daten wieder verliere? Ja ich bin Datenjunky, mich ärgert es das bereits Daten seit drei Jahren weg sind.

Du hast drei Jahre Daten verschlumpst und machst dir Sorgen um vier Tage?

Ich hoffe hier blickt jemand durch

Es fällt schwer.

P.S. ich habe die alte DB lauffähig auf dem unraid Docker Container, und als Hardcopy auf meinem Mac (Verzeichnis eiskalt kopiert, falls es ein "export-script" gibt.

• Backup der alten DB (hast du ja schon...)
• Auspacken des Backups

tar -xvzf /<irgendwo>/backups/influxDB_...._backupiobroker.tar.gz -C <zielverzeichnis>

• restore in ein temporäres Bucket

influx restore --new-bucket <tmp_bucketname> --bucket <Quellbucketname> <Verzeichnis wo das backup liegt> --t <token>

• danach Measurement für Measurement

influx query 'from(bucket:"<tmp_bucketname>"
|> range(start:-10y)
|> filter(fn: (r) => r._measurement == "<measurementname>") 
|> to(bucket: "<zielbucket>")'

So behältst du die vier Tage Daten.

Zum Schluss das temp. Bucket löschen.

[Lucifor1976]

@marc-berg

Dankeschön, werd ich in einer ganz ruhigen Stunde angehen.

Naja die vier Jahre hab ich unfreiwillig durch einen Docker Crash auf Unraid kassiert. Das war auch der punkt wo ich mir gedanken gemacht habe Unraid wieder zu verlassen.
Eines Morgens war das Docker File im System nur noch readonly, alle Container weg, die Daten zwar noch da, aber damals wusste ich nicht das nur der "Masterkey" zum Erfolg führt, oder per CLI der Key hätte gewechselt werden können. Was Backup/Restor/Sync bei Influx angeht, finde ich das sehr unflexible.
Na seins drumm, kannich eh nicht mehr ändern.

Dir sei gedankt..