Disaster Recovery¶

enconf kann bei einem kompletten Systemausfall in wenigen Minuten vollständig wiederhergestellt werden — auf einem frischen, leeren Server. Die einzige Voraussetzung: Du hast vorher mindestens ein Panel-Backup angelegt und den Verschlüsselungskey extern gesichert.

Was Disaster Recovery wiederherstellt¶

Ein Panel-Backup enthält alles, was zur vollständigen Wiederherstellung notwendig ist:

Bereich	Inhalt
Panel-Datenbank	Alle Kunden, Subscriptions, Webseiten, DNS-Zonen, Mail-Konten, Permissions, Webhooks, Lizenzstatus, verschlüsselte Secrets
MariaDB komplett	Alle Datenbanken inklusive Kunden-DBs, mit Usern, Grants, Stored Procedures, Triggers, Events
PowerDNS-Backend	Alle DNS-Zonen und -Records (auto-erkannt: MySQL/PostgreSQL/SQLite)
Roundcube	Identitäten, Kontakte, Sieve-Filter
Konfiguration	Nginx, PHP-FPM (alle Versionen), Postfix, Dovecot, ProFTPD, Cron, Let's Encrypt, fail2ban, nftables, ModSecurity, Unbound, rspamd
Linux-User	Stammdaten mit UID/GID und Passwort-Hashes — FTP/SFTP-Logins der Kunden funktionieren danach ohne Reset
rspamd Bayes	Gelernte Spam-Statistik bleibt erhalten
fail2ban Runtime	Laufende Bans bleiben erhalten
Netzwerk-Identität	Hostname, /etc/hosts, /etc/resolv.conf, Netplan

Vorbereitung (jetzt, bevor etwas passiert)¶

Im Admin-Panel auf Backups wechseln
Zeitplan anlegen klicken
Als Backup-Typ Panel-Backup wählen
Frequenz, Aufbewahrung und Ziel (S3, FTP oder lokal) konfigurieren
Erstellen
Auf das Schlüssel-Symbol in der Zeitplan-Tabelle klicken
Als Datei herunterladen — Datei extern sichern (Passwort-Manager, USB-Stick, Tresor)
Bei externem Ziel auch S3-/FTP-Zugangsdaten notieren

Ohne Verschlüsselungskey keine Wiederherstellung

Der Verschlüsselungskey ist die einzige Möglichkeit, das Backup zu lesen. Ohne ihn ist das Backup unbrauchbar. Sichere ihn an einem Ort, der nicht auf demselben Server liegt.

Wiederherstellung im Notfall¶

Voraussetzungen¶

Frischer Debian 12/13 oder Ubuntu 24.04 Server (gleiche Major-Version wie der ursprüngliche, gleiche oder neuere PostgreSQL-Version)
Mindestens so viel Festplattenspeicher wie das ursprüngliche System
Zugangsdaten zum Backup-Ziel (S3 Endpoint, Bucket, Access Key, Secret Key — oder FTP Host/User/Passwort)
Verschlüsselungskey aus der vorherigen externen Sicherung

Ablauf¶

enconf installieren auf dem frischen Server:

apt update
apt install netcell-webpanel

Setup-Wizard öffnen im Browser unter https://<server>:3443
Im ersten Schritt erscheinen zwei Karten — wähle Disaster Recovery
Backup-Quelle eingeben:
Quelle: S3, FTP oder Lokal
Verbindungsdaten
Verschlüsselungskey (aus der vorher gesicherten Datei)
Verbinden und Snapshots laden — der Wizard listet alle verfügbaren Panel-Snapshots
Snapshot auswählen — standardmäßig der neueste
Vorschau prüfen — der Wizard zeigt Hostname, IP, Anzahl Kunden, Datenbanken und installierte Dienste des Backup-Stands
Zum Bestätigen RESTORE eintippen und Wiederherstellung starten klicken
Der Restore läuft in 10 Schritten (Live-Progress + Log):
Zielsystem prüfen (verhindert versehentliches Überschreiben)
Snapshot extrahieren
Metadaten validieren
Dienste stoppen
Linux-User wiederherstellen (mit Passwort-Hashes)
Konfigurationen einspielen
PostgreSQL wiederherstellen
MariaDB wiederherstellen
Dienste starten
Abschluss
Login mit altem Admin-Passwort — Panel ist zurück
Phase B: Nach dem Login erscheint oben ein gelber Banner „Disaster Recovery — Phase B ausstehend". Klick auf Kunden-Daten wiederherstellen öffnet ein Modal mit allen Customer-Backup-Zeitplänen. Alle wiederherstellen spielt die Web-Roots, Maildirs, SSL-Zertifikate und Customer-Datenbanken sequenziell aus den Customer-Backups ein. Einzelne fehlgeschlagene Zeitpläne können separat erneut versucht werden.

Nach der Wiederherstellung¶

Punkt	Beschreibung
Lizenz reaktivieren	Lizenzen sind hardware-gebunden. Nach einem Hardware-Wechsel im NetCell Licensing Portal die alte Aktivierung deaktivieren und neu aktivieren.
Hostname	Hat der neue Server einen anderen Hostnamen, sollten Postfix/Dovecot manuell aktualisiert werden.
IP-Adresse	Bei IP-Wechsel zeigen DNS-A-Records noch auf die alte IP — bei Bedarf in der DNS-Verwaltung umstellen.
Customer-Daten	Webdateien, Mailboxen und SSL-Zertifikate werden im Kunden-Backup wiederhergestellt — nach erfolgreichem Panel-Restore über die Backup-Verwaltung restoreable.

Multi-Server-Setups¶

enconf kann auch in Multi-Server-Topologien betrieben werden, bei denen Web-, DB-, Mail- und DNS-Dienste auf separaten Servern laufen. Für solche Setups gibt es einen zusätzlichen Backup-Typ: Node-Backup.

Konzept¶

Backup-Typ	Wo läuft er?	Was sichert er?
Panel-Backup	Panel-Host	PG Panel-DB + Configs/State aller Rollen, die auf dem Panel-Host liegen
Node-Backup (neu)	Beliebiger Remote-Server	Nur die rollen-spezifischen Configs und Stateful-Daten dieses einen Servers (z. B. nur Postfix/Dovecot bei einem Mail-Server, nur PowerDNS bei einem DNS-Server)

Pro Server in deinem Cluster legst du ein Node-Backup-Schedule an. Der Agent auf dem Ziel-Server erkennt automatisch über SERVER_ROLES welche Configs er sichern muss — kein Web-Server tarballt unnötig PowerDNS-Configs, kein DNS-Server kümmert sich um Mail.

Einrichtung¶

Backups → Zeitplan anlegen
Backup-Typ: Node-Backup
Ziel-Server aus der Liste auswählen
Frequenz, Aufbewahrung, Ziel (S3 / FTP / lokal), Verschlüsselungskey extern sichern
Wiederholen für jeden Server in deinem Cluster

Die Schedules landen in separaten Repository-Segmenten: - <bucket>/<path>/_panel — Panel-Backup - <bucket>/<path>/_node_2 — Node-Backup für Server-ID 2 - <bucket>/<path>/_node_3 — Node-Backup für Server-ID 3 - <bucket>/<path>/server — Customer-Daten (server-wide)

Multi-Server Recovery-Ablauf¶

Bei einem Komplettausfall eines Multi-Server-Setups:

Phase A — Panel-Host wiederherstellen

Frischer Server für den Panel-Host
apt install netcell-webpanel
Setup-Wizard → Disaster Recovery → Panel-Backup-Quelle eingeben → Restore läuft
Login mit altem Admin-Passwort

Phase B — Remote-Server wiederherstellen

Für jeden Remote-Server (Web/DB/Mail/DNS) aus dem ursprünglichen Setup:

Frischer Server bereitstellen
apt install netcell-agent
Im Panel: Server → Server hinzufügen → den neuen Server registrieren mit derselben Server-ID wie zuvor (so passt der _node_<id> Repo-Segment)
Im Panel das Node-Backup-Schedule für diesen Server öffnen → Wiederherstellen → Snapshot wählen
Der Agent auf dem neuen Remote-Server bekommt die Anweisung restore-node mit der node_server_id, holt sich aus dem _node_<id> Segment alle Configs + Stateful-Daten und spielt sie ein

Phase C — Customer-Daten verteilen

Das Customer-Backup ist server-wide und enthält Web-Roots, Maildirs und SSL-Zertifikate aller Kunden. Nach dem Login wird es ganz normal über die Backup-Verwaltung wiederhergestellt — agentForSchedule routet automatisch jeden Customer auf seinen ursprünglich zugewiesenen Server (basierend auf Site.ServerID aus der wiederhergestellten Panel-DB).

Node-Backup Inhalt nach Rolle¶

Rolle	Im Node-Backup
`web`	Nginx, PHP-FPM (alle Versionen), ModSecurity, fail2ban, ProFTPD, Linux-User mit Hashes
`mail_storage`	Dovecot Configs + lib (Auth-Cache, Indexes), Let's Encrypt Mail-Certs
`mail_gateway`	Postfix Configs, rspamd Configs + Bayes-DB
`dns`	PowerDNS Configs + lib, Unbound Configs + DNSSEC Trust Anchor
(alle Rollen)	Cron-Tabs, Hostname/Network-Identität, Agent-Token

Bekannte Einschränkungen¶

PostgreSQL-Major-Version: Der Restore funktioniert auf gleicher oder neuerer PG-Major-Version. Ein Downgrade (z. B. PG17 → PG14) wird nicht unterstützt.
OS-Familie: Nur zwischen Debian/Ubuntu Versionen mit gleicher Service-Layout-Konvention getestet.
Hostname-Wechsel: Postfix/Dovecot-Konfiguration enthält den ursprünglichen Hostnamen — manuelle Anpassung empfohlen.
MariaDB Major-Sprung: Bei Authentication-Plugin-Wechseln (10.x → 11.x) können einzelne User-Grants angepasst werden müssen.