Update, Backup & Zurücksetzen

Ein Update ist bei Node64 ein normaler Image-Wechsel, die Datenbank zieht automatisch nach. Für den Ernstfall gibt es ein vollständiges, verschlüsseltes Backup, das sich auch auf einer neuen Maschine einspielen lässt.

Update

Node64 aktualisiert sich nicht selbst. Du holst das neue Image und erstellst den Container neu – deine Daten im Volume /data bleiben dabei erhalten.

Mit docker compose

bash
docker compose pull && docker compose up -d

Mit docker run

Neues Image holen, alten Container entfernen und mit demselben Befehl wie bei der Installation neu starten:

bash
docker pull ghcr.io/ipv64net/node64:latest
docker stop node64 && docker rm node64
docker run -d --name node64 \
  -p 8080:8080 \
  -v node64-data:/data \
  --restart unless-stopped \
  ghcr.io/ipv64net/node64:latest

Versionen und Image-Tags

Das Image gibt es für linux/amd64, linux/arm64 und linux/arm/v7 (Raspberry Pi, auch 32 Bit). Jede Version wird vor dem Bau automatisch getestet.

TagBedeutung
latestimmer die neueste stabile Version
0.12neueste Version der Reihe 0.12 – Fehlerbehebungen ja, größere Sprünge nein
0.12.0genau diese Version, ändert sich nie
0.12.0-alpha.4Vorabversion zum Testen – latest und 0.12 zeigen nie auf Vorabversionen

Wer Updates bewusst steuern will, nimmt statt latest eine feste Reihe oder Version und hebt sie von Hand an. Welche Version läuft, zeigt GET /api/health. Die Versionsnummern in der Tabelle sind Beispiele.

Was beim Start nach einem Update passiert

  • Migrationen laufen automatisch. Die Datenbank wird je Bereich (Kern, Benachrichtigungen, Zertifikate, Module …) auf den neuen Stand gebracht.
  • Vorher wird gesichert. Vor jeder Migration schreibt Node64 automatisch ein Backup nach /data/backups. Die letzten 5 bleiben erhalten.
  • Modulversionen: Jedes Modul hat eine eigene Version mit Änderungsprotokoll auf Deutsch und Englisch – zu sehen unter Einstellungen → Module.
Über neue Versionen informiert werden

In den Einstellungen kannst du Täglich auf neue Versionen prüfen einschalten (standardmäßig aus). Node64 ruft dann einmal am Tag nur eine Versionsdatei bei ipv64.net ab – es werden keine Daten gesendet.

Die Backup-Wege im Überblick

Backup, Export, Wiederherstellung, Datenhaltung und Zurücksetzen findest du gesammelt unter Einstellungen → Daten & Sicherung.

WegInhaltGeeignet für
Vollständiges Backup (.n64backup)Datenbank aller Module, secret.key, die Dateien der Module unter /data, optional Statistik – mit Passwort verschlüsseltWiederherstellung auf derselben oder einer neuen Maschine
Nur Datenbank (.db)nur node64.db, ohne SchlüsselWiederherstellung auf derselben Node
Volume-Sicherung (tar.gz)das komplette Verzeichnis /dataSicherung von außen, z. B. per Cronjob auf dem Host
Konfigurations-Export (JSON)Einstellungen der Node, Kanäle und die Konfiguration der eingeschalteten Module – ohne MessdatenKonfiguration auf eine andere Node übertragen

Vollständiges Backup herunterladen

  1. Öffne Einstellungen → Daten & Sicherung und dort die Karte Backup und Wiederherstellung.
  2. Unter Vollständiges Backup (mit Passwort verschlüsselt) vergibst du ein Passwort mit mindestens 8 Zeichen.
  3. Optional: Haken bei Statistik mitsichern – dann kommen das DNS64-Abfrage-Log und die PROXY64-Zugriffe mit. Das Backup wird dadurch größer.
  4. Auf Backup herunterladen klicken. Du bekommst eine Datei wie node64-20261019-1504.n64backup.

Im Backup enthalten: die Datenbank mit allen Tabellen aller Module – auch Honeypot-Ereignisse und Proxmox-Verlauf –, konsistent im laufenden Betrieb kopiert; der Schlüssel der Node (secret.key, nötig für API-Key, Zugangsdaten und Zertifikate) und die Dateien der Module unter /data, etwa DNS64-Freigaben und -Zertifikate, Hostschlüssel, Zertifikat und Sensor-Kennung von Honeypot64 sowie das Zertifikat der Oberfläche. Nicht enthalten sind Zwischenspeicher, die die Node neu lädt (Blocklisten, Länderdaten), die automatischen Sicherungen unter /data/backups und temporäre Dateien.

Passwort gut aufbewahren

Das Archiv ist verschlüsselt (XChaCha20-Poly1305, Schlüssel per Argon2id aus deinem Passwort abgeleitet). Ohne das Passwort lässt es sich nicht öffnen – auch nicht von uns. Veränderte oder abgeschnittene Dateien werden beim Einspielen erkannt.

Per API, z. B. für ein nächtliches Skript

bash
curl -X POST http://localhost:8080/api/backup \
  -H "Authorization: Bearer DEIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"password": "DEIN_BACKUP_PASSWORT", "stats": false}' \
  -o node64-$(date +%Y%m%d).n64backup

Einen API-Key legst du in der Node unter API an – siehe Lokale API.

Nur die Datenbank sichern

Unter Backup und Konfiguration gibt es auch Nur die Datenbank herunterladen (node64-JJJJMMTT-HHMM.db), per API mit GET /api/backup:

bash
curl -H "Authorization: Bearer DEIN_API_KEY" -o node64.db http://localhost:8080/api/backup

Diese Datei enthält nicht den Schlüssel secret.key. Auf derselben Node ist sie vollständig nutzbar. Auf einer neuen Installation lassen sich die verschlüsselten Geheimnisse darin (Kanal-Tokens, SMTP-Passwörter, ipv64-API-Key, Zertifikatsschlüssel) ohne den alten Schlüssel nicht mehr lesen.

Wichtig: /data/secret.key mitsichern

Ohne secret.key keine Geheimnisse

Alle Geheimnisse in der Datenbank sind mit /data/secret.key verschlüsselt (AES-256-GCM). Das vollständige Backup enthält ihn automatisch. Sicherst du nur die Datenbank oder eigene Dateien, sichere /data/secret.key immer zusätzlich – und bewahre ihn so sicher auf wie ein Passwort.

Das ganze Volume sichern

Unabhängig von der Oberfläche kannst du das komplette Volume als Archiv sichern. Damit die SQLite-Datenbanken in einem sauberen Zustand sind, stoppst du den Container kurz:

bash
docker stop node64
docker run --rm -v node64-data:/data -v $(pwd):/backup alpine \
  tar czf /backup/node64-data-$(date +%Y%m%d).tar.gz -C /data .
docker start node64

Zurückspielen in ein (leeres) Volume:

bash
docker stop node64
docker run --rm -v node64-data:/data -v $(pwd):/backup alpine \
  tar xzf /backup/node64-data-20261019.tar.gz -C /data
docker start node64

Docker Compose stellt dem Volume-Namen meist den Projektnamen voran (z. B. node64_node64-data). Den genauen Namen zeigt docker volume ls.

Backup wiederherstellen

  1. Öffne Einstellungen → Daten & Sicherung → Backup wiederherstellen.
  2. Wähle die Datei: ein .n64backup (mit Passwort) oder eine Datenbank .db (ohne Passwort). Node64 erkennt die Art selbst und prüft die Datei vorher.
  3. Bestätige die Rückfrage. Die aktuellen Daten werden ersetzt, und die Node startet neu.
  4. Nach ein paar Sekunden meldest du dich neu an – mit den Zugangsdaten aus dem Backup.

Was ersetzt wurde, bleibt unter /data/backups erhalten – die letzten fünf Stände je Art, ältere räumt Node64 selbst auf. Ebenso bleiben dort die letzten fünf Sicherungen, die vor jeder Migration entstehen. Für den Neustart muss der Container mit restart: unless-stopped (bzw. --restart unless-stopped) laufen – Node64 beendet sich nach dem Einspielen selbst, und Docker startet ihn neu.

Umzug auf eine neue Maschine

  1. Node64 auf der neuen Maschine installieren.
  2. Den Setup-Assistenten mit einem vorläufigen Konto durchlaufen.
  3. Das vollständige Backup (.n64backup) mit Passwort einspielen. Nach dem Neustart gelten Daten, Schlüssel und Benutzer aus dem Backup.

Per API

bash
curl -X POST http://localhost:8080/api/backup/restore \
  -H "Authorization: Bearer DEIN_API_KEY" \
  -F file=@node64-20261019.n64backup \
  -F password=DEIN_BACKUP_PASSWORT

Alternativ geht die Datei roh im Body und das Passwort im Kopf X-Backup-Password.

Konfiguration exportieren und importieren

Der Export ist kein Backup, sondern eine JSON-Datei mit deiner Konfiguration: Einstellungen der Node (Name, Ort, Zeitzone, Ruhezeiten, Datenhaltung, Schalter der KI-Schnittstelle), Kanäle, Zertifikate (nur mit Passwort) und je eingeschaltetem Modul dessen Konfiguration – ohne Messdaten. Ideal, um eine zweite Node gleich einzurichten.

  • Exportieren unter Einstellungen → Daten & Sicherung → Konfiguration exportieren und importieren: wahlweise ohne Geheimnisse (Tokens, Passwörter) oder Geheimnisse mit Passwort verschlüsselt (mindestens 8 Zeichen).
  • Importieren unter Konfiguration importieren: Checks werden über ihren Token abgeglichen, Kanäle und Wartungsfenster über den Namen, Statusseiten über den Slug. Es wird nichts gelöscht. Benötigte Module werden dafür eingeschaltet. Passt das Passwort nicht, wird nichts übernommen.
  • DynDNS: Der Export enthält keine Tokens; beim Import holt die Node sie mit dem ipv64-API-Key neu.
  • Healthchecks: Checks samt Gruppe und Ausführungsort (Nodes), Wartungsfenster und die Zuordnung der Kanäle; nach dem Import zeigen die Checks auf die mitimportierten Kanäle der neuen Node. Dazu die Proxmox-Systeme, die Docker-Hosts und die Statusseiten mit Einträgen und Logo; den Passwort-Hash einer geschützten Seite nur im Export mit Passwort, sonst kommt sie ausgeschaltet an. Ankündigungen bleiben auf der Node.
  • DNS64: Einstellungen, Freigaben, eigene Einträge, lokale Zonen, Weiterleitungen, Umschreiben, das gewählte Zertifikat und die Gerätegruppen (Mitglieder, Regeln, Freigaben/Sperren, Zeitpläne – ohne den Zustand der Knöpfe Sperren/Frei) sind dabei. Gleichnamige Gruppen auf der Ziel-Node bleiben erhalten.
  • PROXY64: Proxy-Hosts, Weiterleitungen, 404-Hosts, Streams, Zugriffslisten, Blocklisten-, Limit- und Log-Einstellungen und die Honeypot-Schalter (Köder, Zugriffe an den Log-Sensor, Sofort-Sperre mit Dauer); fest gewählte Zertifikate werden über ihre Namen zugeordnet. Die Sperrliste selbst bleibt auf der Node. Hosts der Art „Statusseite“ werden über den Slug der Seite zugeordnet; fehlt sie auf der Ziel-Node, wird der Host ausgeschaltet angelegt.
  • Honeypot64: Dienste, Log-Sensor und Syslog.
  • Zertifikate: nur im Export mit Passwort – Zertifikate mit Schlüssel, DNS-Zugänge, eigene CAs und ACME-Stellen als verschlüsselter Block. Beim Import werden die Verweise der Module (DNS64, PROXY64) auf die neuen Zertifikate umgestellt. Ohne Passwort fehlt der Block.
  • Nicht enthalten: Messdaten, Verläufe und Logs, Benutzer, Sitzungen, API- und MCP-Schlüssel, Passkeys, SSO, der gemeinsame Eingang (80/443), die Netze der Frühwarnung (liegen bei ipv64) und CDN64 (gehört zur Node).
  • API: POST /api/export und POST /api/import.

Datenhaltung

Wie lange die Node Daten lokal aufbewahrt, stellst du unter Einstellungen → Daten & Sicherung → Datenhaltung (lokal) ein:

DatenAufbewahrung
Einzelmessungen der Checks, Proxmox- und Docker-Verlauf (5 min)Einzelmessungen aufbewahren (Standard 30 Tage)
Stundenwerte, Ereignisse, abgeschlossene Störungen, Proxmox-StundenwerteStundenwerte aufbewahren (Standard 365 Tage, auch unbegrenzt)
Proxmox-Minutenwerte48 Stunden
Tageswerte der Checksunbegrenzt
Audit-Log (auch die Aufrufe über MCP)Audit-Log aufbewahren: 90, 180, 365 (Standard), 730 Tage oder unbegrenzt
Zustellungen der Benachrichtigungen90 Tage

Honeypot64 (Aufbewahrung und Obergrenze der Ereignisse), DNS64 (Abfrage-Log), PROXY64 (Zugriffs-Log, Stundenstatistik 90 Tage) und DynDNS (Verlauf) haben eigene Einstellungen in ihren Modulen. Per API: GET und PUT /api/retention, für das Audit-Log das Feld audit_days (0 = unbegrenzt).

Node zurücksetzen (Werksreset)

Unter Einstellungen → Daten & Sicherung → Node zurücksetzen setzt du die Node auf den Auslieferungszustand zurück. Dafür gibst du dein Passwort ein und bestätigst eine Rückfrage.

  • Vorher meldet sich die Node online ab: Die Verknüpfung mit ipv64 wird getrennt, Namen von CDN64 und der Tunnel werden bei ipv64 ausgetragen (auch wenn PROXY64 gerade ausgeschaltet ist), und die Node verlässt den Cluster. Klappt dabei etwas nicht (z. B. ohne Internet), läuft der Reset trotzdem weiter; die Probleme stehen im Audit-Log.
  • Nach dem Neustart ist /data leer: die Datenbank mit allen Tabellen (Checks, Messwerte, Kanäle, Benutzer, Einstellungen …), Schlüssel, Zertifikate, die Dateien der Module wie Honeypot-Schlüssel und Sensor-Kennung, Zwischenspeicher und Backups sind weg. Ein automatischer Test stellt sicher, dass der Reset wirklich alles löscht.
  • Die Einrichtung beginnt mit dem Setup-Assistenten neu.
  • Ein eigenes Zertifikat (NODE64_TLS_CERT/NODE64_TLS_KEY) unter /data bleibt erhalten. Eigene Mounts unterhalb von /data werden geleert, nicht entfernt.
  • Vor dem Löschen des Containers lohnt sich der Reset: Ohne Abmeldung entfernt ipv64 verwaiste CDN64-Tunnel erst nach 14 Tagen.
  • Per API: POST /api/reset – nur mit dem Passwort des Benutzers im Aufruf, auch bei Anmeldung per API-Key.
Unwiderruflich

Das Zurücksetzen löscht auch die automatischen Sicherungen unter /data/backups. Lade vorher ein vollständiges Backup herunter, wenn du irgendetwas davon noch brauchen könntest. Auch hier gilt: Der Container braucht restart: unless-stopped, damit er danach von selbst wieder startet.

Etwas unklar, fehlt etwas oder hast du eine Frage zu Node64? Frag im offiziellen Forum v64.tech.

Fragen zu Node64?
Für alle Fragen zum Produkt gibt es das offizielle Forum: Einrichtung, Fehlersuche, Ideen und Austausch mit der Community und dem ipv64.net-Team.
Zum Forum v64.tech