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
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:
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.
| Tag | Bedeutung |
|---|---|
latest | immer die neueste stabile Version |
0.12 | neueste Version der Reihe 0.12 – Fehlerbehebungen ja, größere Sprünge nein |
0.12.0 | genau diese Version, ändert sich nie |
0.12.0-alpha.4 | Vorabversion 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.
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.
| Weg | Inhalt | Geeignet für |
|---|---|---|
Vollständiges Backup (.n64backup) | Datenbank aller Module, secret.key, die Dateien der Module unter /data, optional Statistik – mit Passwort verschlüsselt | Wiederherstellung auf derselben oder einer neuen Maschine |
Nur Datenbank (.db) | nur node64.db, ohne Schlüssel | Wiederherstellung auf derselben Node |
Volume-Sicherung (tar.gz) | das komplette Verzeichnis /data | Sicherung 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 Messdaten | Konfiguration auf eine andere Node übertragen |
Vollständiges Backup herunterladen
- Öffne Einstellungen → Daten & Sicherung und dort die Karte Backup und Wiederherstellung.
- Unter Vollständiges Backup (mit Passwort verschlüsselt) vergibst du ein Passwort mit mindestens 8 Zeichen.
- Optional: Haken bei Statistik mitsichern – dann kommen das DNS64-Abfrage-Log und die PROXY64-Zugriffe mit. Das Backup wird dadurch größer.
- 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.
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
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:
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
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:
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:
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
- Öffne Einstellungen → Daten & Sicherung → Backup wiederherstellen.
- 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. - Bestätige die Rückfrage. Die aktuellen Daten werden ersetzt, und die Node startet neu.
- 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
- Node64 auf der neuen Maschine installieren.
- Den Setup-Assistenten mit einem vorläufigen Konto durchlaufen.
- Das vollständige Backup (
.n64backup) mit Passwort einspielen. Nach dem Neustart gelten Daten, Schlüssel und Benutzer aus dem Backup.
Per API
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/exportundPOST /api/import.
Datenhaltung
Wie lange die Node Daten lokal aufbewahrt, stellst du unter Einstellungen → Daten & Sicherung → Datenhaltung (lokal) ein:
| Daten | Aufbewahrung |
|---|---|
| Einzelmessungen der Checks, Proxmox- und Docker-Verlauf (5 min) | Einzelmessungen aufbewahren (Standard 30 Tage) |
| Stundenwerte, Ereignisse, abgeschlossene Störungen, Proxmox-Stundenwerte | Stundenwerte aufbewahren (Standard 365 Tage, auch unbegrenzt) |
| Proxmox-Minutenwerte | 48 Stunden |
| Tageswerte der Checks | unbegrenzt |
| Audit-Log (auch die Aufrufe über MCP) | Audit-Log aufbewahren: 90, 180, 365 (Standard), 730 Tage oder unbegrenzt |
| Zustellungen der Benachrichtigungen | 90 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
/dataleer: 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/datableibt erhalten. Eigene Mounts unterhalb von/datawerden 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.
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.