3CX Backup & Remote-Speicher: Vollständiger Admin Guide

Warum ein lokales Backup kein Backup ist

Ein Backup, das nur lokal auf demselben Server liegt wie die Telefonanlage selbst, ist kein Backup im eigentlichen Sinn — es ist eine zweite Kopie am selben Ausfallpunkt. Fällt der Server aus, sind Konfiguration und Sicherung gemeinsam weg.

Ein konkretes Beispiel aus der Praxis: Die Diagnose einer produktiven 3CX-Anlage mit 51 Nutzern ergab, dass das einzige vorhandene Backup 13 MB groß, sechs Tage alt und ausschließlich lokal auf demselben Server abgelegt war. Remote-Speicher war nicht konfiguriert. 3CX weist genau davor selbst im Systemübersicht-Dashboard hin:

„Der Remote-Speicher ist nicht konfiguriert. Es ist erforderlich, damit Ihr System leistungsfähig und leicht aktualisierbar bleibt.“

Wäre in diesem Fall der Server ausgefallen, wäre die komplette Telefonanlage weg gewesen — Nutzer, Trunks, Warteschlangen, Aufzeichnungen, alles hätte von Hand neu aufgesetzt werden müssen. Das ist kein Randfall, sondern nach unserer Erfahrung der häufigste und folgenschwerste Konfigurationsfehler im 3CX-Betrieb: Ein Backup existiert, wird aber nie dort abgelegt, wo ein Serverausfall es nicht mitreißt.

Die Konsequenz ist eindeutig: Externe Speicherung (System > Speicher, siehe unten) ist keine Kür, sondern die Voraussetzung dafür, dass ein Backup im Ernstfall überhaupt etwas rettet. Ein gut implementiertes Backup-System reduziert zusätzlich die Recovery Time Objective (RTO) und Recovery Point Objective (RPO) erheblich und ermöglicht schnelle Wiederherstellungen nach Hardware-Ausfällen.

Was ein 3CX Backup enthält — und was nicht

Die vollständige Komponentenliste ergibt sich aus den offiziellen 3CX-Backup-Kommandozeilenoptionen (BackupCmd --options=ALL bzw. einzeln CH, LIC, FQDN, PROMPTS, FW, REC, VM) sowie den Checkboxen im GUI-Backup-Dialog. Nicht alles, was man erwarten würde, ist tatsächlich enthalten:

Backup-Zeitplan konfigurieren: Backup > Backup planen

Automatisierte Backups sind das Rückgrat jeder soliden Datensicherungsstrategie. Sie beseitigen menschliche Fehler und stellen sicher, dass regelmäßige Sicherungen ohne manuelle Eingriffe durchgeführt werden.

Schritt-für-Schritt Konfiguration:

1. Als Administrator in der 3CX Admin Console anmelden
2. Zum Tab Backup navigieren
3. Backup planen anklicken
4. Zeitplan-Typ wählen (z. B. Wöchentlich/Sonntag) und ein passendes Intervall festlegen — außerhalb der Geschäftszeiten
5. Checkbox Lokale/temporäre Aufzeichnungen einbeziehen je nach Bedarf setzen — ohne sie fehlen Aufzeichnungen im Backup
6. Checkbox Deaktivieren der Backup-Komprimierung in der Regel deaktiviert lassen (spart Speicherplatz)
7. Feld Verschlüsseltes Passwort für die Sicherung setzen (siehe Verschlüsselung)
8. Rotation festlegen, also wie viele Backup-Generationen aufbewahrt werden, bevor die älteste überschrieben wird
9. Konfiguration speichern

Best Practice: Tägliches Backup für Produktionssysteme mit häufigen Änderungen, wöchentlich ist für die meisten aktiv genutzten Systeme zu selten — mehr dazu unter Wiederherstellung testen und in den häufigen Fehlern.

Manuelle Backup-Erstellung: Jetzt sichern

Zusätzlich zu geplanten Backups sollten Administratoren jederzeit manuelle Backups erstellen können – besonders vor großen Systemänderungen, Updates oder Konfigurationsänderungen.

Manuelle Backup-Schritte:

1. 3CX Admin Console öffnen
2. Zum Tab Backup navigieren
3. Jetzt sichern anklicken
4. Backup-Namen vergeben
5. Optional: Checkbox für lokale/temporäre Aufzeichnungen setzen
6. Optional, aber empfohlen: Verschlüsseltes Passwort für die Sicherung setzen
7. Bestätigen und Abschluss abwarten — Systemadministrator und Systembesitzer werden per E-Mail benachrichtigt

Im selben Tab stehen für vorhandene Backups außerdem Wiederherstellen, Herunterladen und Löschen zur Verfügung. Der Backup-Prozess dauert je nach Systemgröße und Datenvolumen typischerweise 5-30 Minuten. Große Systeme mit umfangreichen Anrufaufzeichnungen können länger dauern.

Remote-Speicher einrichten: System > Speicher

Die Wahl des richtigen Speicherorts ist entscheidend für die Verfügbarkeit und Sicherheit deiner Backups.

Lokaler Speicher

Backup → Backup planen legt standardmäßig lokal ab (bzw. unter Backup → Einstellungen ein anderes lokales Verzeichnis). Vorteil: schnelle Wiederherstellung. Nachteil: Wie im Praxisfall oben beschrieben schützt ein rein lokales Backup nicht vor einem Ausfall des Servers, auf dem es liegt. BitBlade empfiehlt lokalen Speicher nur als schnelle Zusatzoption, nie als einzigen Backup-Ort.

Remote-Speicher per FTP/FTPS/FTPES

1. Admin Console → System → Speicher öffnen
2. Remote-Speicher aktivieren
3. Zielpfad als URL mit einem der unterstützten Schemes eintragen — der Platzhaltertext im Pfadfeld nennt ftp://, ftps:// und ftpes://
4. Zugangsdaten hinterlegen und Verbindung testen

Der Unterschied zwischen den drei Schemes ist keine Formsache: ftp:// überträgt Zugangsdaten und später das gesamte Backup-Archiv — inklusive Konfiguration, Lizenzschlüssel und Anrufverlauf, ggf. auch Voicemail und Aufzeichnungen — unverschlüsselt über das Netzwerk. ftps:// (FTP über implizites TLS) baut die Verschlüsselung von Beginn an auf, ftpes:// (FTP über explizites TLS) startet unverschlüsselt und wechselt dann per AUTH TLS in eine verschlüsselte Verbindung. Für eine Telefonanlage, deren Backup Zugangsdaten und potenziell Gesprächsdaten enthält, ist unverschlüsseltes FTP die falsche Wahl — ein Mitleser im Netzwerkpfad käme sonst an genau diese Daten. Praktisch bedeutet das: ftps:// oder ftpes:// verwenden, ftp:// höchstens in einem isolierten Testnetz ohne echte Daten.

Versionshinweis: Auf der geprüften Live-Anlage (V20 Update 9) akzeptiert das Pfadfeld unter System → Speicher ausschließlich diese drei FTP-Schemes — kein S3, kein Azure, kein Google-Cloud-Storage, kein SMB. Die aktuelle offizielle 3CX-Dokumentation beschreibt für System → Speicher zusätzlich einen separaten Auswahl-Dialog „Location Type“ mit weiteren Backends (u. a. Google Cloud Storage, SMB, SFTP, Amazon S3, Microsoft SharePoint). Ob diese Optionen in einer konkreten Installation erscheinen, hängt vom Versionsstand ab — im Zweifel direkt am eigenen System prüfen, welche Auswahl das Pfadfeld tatsächlich anbietet. Ein NAS-Gerät lässt sich in jedem Fall als Ziel verwenden, wenn es selbst einen FTP(S)-Dienst bereitstellt (z. B. Synology oder QNAP bieten das nativ an) — die 3CX-Seite spricht dann weiterhin nur ftp://, ftps:// oder ftpes:// und keine SMB-Freigabe direkt an.

BitBlade Empfehlung: Remote-Speicher per ftps:// oder ftpes:// kombiniert mit Verschlüsselung (siehe unten) und mehreren aufbewahrten Backup-Generationen gemäß der 3-2-1 Regel (siehe unten).

Verschlüsselung: Verschlüsseltes Passwort für die Sicherung

Sowohl beim manuellen Backup (Jetzt sichern) als auch im Zeitplan (Backup planen) gibt es das Feld „Verschlüsseltes Passwort für die Sicherung“. Es gehört bei jedem Backup gesetzt, das den Server verlässt — es ist die letzte Schutzschicht, falls das FTP(S)-Ziel selbst kompromittiert wird oder eine Kopie des Archivs in falsche Hände gerät.

Die Kehrseite: Ohne das korrekte Passwort ist ein verschlüsseltes Backup nicht wiederherstellbar. Es gibt keinen Wiederherstellungsmechanismus, kein Zurücksetzen, keinen Support-Trick, der ein vergessenes Backup-Passwort umgeht. Das Passwort gehört deshalb in einen Passwort-Manager — getrennt von den FTP-Zugangsdaten und getrennt vom Backup-Ziel selbst notiert, nie in derselben Datei oder demselben Ordner wie die Backups.

Wiederherstellung von Backups

Die Fähigkeit, schnell und zuverlässig von einem Backup wiederherzustellen, ist mindestens so wichtig wie die Erstellung selbst. 3CX stellt dabei das komplette Backup-Archiv wieder her — es gibt in der Admin Console keine Funktion, um einzelne Nutzer, Aufzeichnungen oder Voicemails isoliert aus einem Archiv zurückzuholen, ohne das gesamte System zu überschreiben.

Wiederherstellung durchführen

1. Bei Bedarf 3CX neu auf dem System oder auf einem neuen Server installieren
2. 3CX Admin Console öffnen
3. Zum Tab Backup navigieren, gewünschte Backup-Datei auswählen (lokal vorhanden oder von extern hochladen)
4. Wiederherstellen anklicken
5. Bei verschlüsselten Backups: Passwort eingeben
6. Wiederherstellung bestätigen — alle 3CX-Dienste werden während des Vorgangs gestoppt und neu gestartet
7. Nach Abschluss Kernfunktionen prüfen: eingehende Anrufe, SIP-Trunk-Status, Nutzer, Warteschlangen

Wiederherstellung testen

Ein Backup, das nie wiederhergestellt wurde, ist eine Vermutung, keine Absicherung. Das ist der Schritt, den fast alle auslassen — und genau der Schritt, der im Ernstfall entscheidet, ob eine Wiederherstellung in Minuten oder gar nicht funktioniert.

So testen, ohne die Produktivanlage zu gefährden

1. Eine separate Testinstanz aufsetzen — eigene FQDN, isoliertes Netzwerksegment, kein aktiver SIP-Trunk
2. Ein aktuelles Backup auf dieser Testinstanz wiederherstellen
3. Prüfen: Sind alle Nutzer vorhanden? Stimmen Trunk-Konfiguration, IVR und Warteschlangen? Sind — falls eingeschlossen — Aufzeichnungen abspielbar und Voicemail zugänglich?
4. Ergebnis dokumentieren: erfolgreich, mit welchen Abweichungen, wie lange der Vorgang gedauert hat
5. Bei Problemen: Backup-Umfang oder Zeitplan entsprechend anpassen

Ein Restore-Test auf dem Produktivsystem selbst ist kein Test, sondern ein unnötiges Risiko — dafür ist die Testinstanz da. Empfehlenswerte Frequenz: mindestens einmal nach der Ersteinrichtung und danach quartalsweise oder nach jeder größeren Konfigurationsänderung.

Häufige Fehler und Lösungen

Backup schlägt wegen Speicherplatz fehl

Lokaler Speicher reicht nicht für das temporäre Backup-Archiv, besonders bei eingeschlossenen Aufzeichnungen. Entweder alte Aufzeichnungen archivieren/löschen oder Aufzeichnungen bewusst aus dem Backup-Umfang ausschließen.

FTP-Ziel nicht erreichbar

Häufigste Ursachen: falsches Scheme im Zielpfad gewählt (ftp:// statt ftps:///ftpes:// bei Providern, die nur verschlüsselte Verbindungen erlauben), falsche Zugangsdaten oder eine Firewall, die den Ziel-Port blockiert. FTP/FTPS läuft typischerweise über Port 21 plus eine Passive-Port-Range — beim Storage-Anbieter erfragen, welche Ports freigegeben sein müssen.

Wiederherstellung auf abweichender Version schlägt fehl

Backups sollten grundsätzlich auf gleicher oder neuerer 3CX-Version wiederhergestellt werden — Abwärtskompatibilität ist nicht garantiert. Vor jedem Versionsupdate deshalb zusätzlich ein manuelles Backup ziehen, das zur aktuell laufenden Version passt.

Vergessenes Verschlüsselungspasswort

Ohne das korrekte Verschlüsselungspasswort ist ein verschlüsseltes Backup nicht wiederherstellbar — es gibt keinen Wiederherstellungsmechanismus. Passwörter für Backups daher zwingend in einem Passwort-Manager hinterlegen, nicht nur im Kopf oder in derselben Datei wie das Backup.

Backup enthält keine Aufzeichnungen

Die Checkbox „Lokale/temporäre Aufzeichnungen einbeziehen“ war beim Erstellen nicht gesetzt. Ohne sie werden Konfiguration, Lizenz, Voicemail und Anrufverlauf gesichert — die Aufzeichnungen selbst fehlen ersatzlos, ohne dass das Backup als fehlerhaft markiert wird.

Disaster Recovery Planning

Ein umfassender Disaster Recovery Plan ist notwendig, um die Geschäftskontinuität im Falle eines schwerwiegenden Systems zu gewährleisten.

Wesentliche Komponenten eines DR-Plans:

• Recovery Time Objective (RTO): Definiere, wie schnell das System wiederhergestellt sein muss (z.B. 4 Stunden, 24 Stunden)
• Recovery Point Objective (RPO): Bestimme den akzeptablen Datenverlust (z.B. maximal 24 Stunden)
• Backup-Häufigkeit: Richte Backups häufiger ein, um RPO zu erfüllen
• Alternative Hardware: Halte redundante Hardware bereit oder nutze Cloud-Failover-Optionen
• Dokumentation: Dokumentiere alle Wiederherstellungsschritte und Kontaktdaten
• Testing-Regime: Führe regelmäßig Disaster Recovery Drills durch
• Kommunikationsplan: Etabliere einen Plan zur Benachrichtigung von Stakeholdern im Notfall

BitBlade bietet spezialisierte Disaster Recovery Services, um dein 3CX-System vor kritischen Ausfällen zu schützen.

Zugriffskontrolle und Sicherheit

Backups enthalten sensible Daten — Konfiguration, Zugangsdaten, ggf. Gesprächsdaten — und müssen entsprechend geschützt werden. Verschlüsselung ist dabei nur ein Baustein, siehe Verschlüsselung oben.

Zugriffskontrolle

Beschränke den Zugriff auf Backup-Dateien auf autorisiertes Personal:

• Dateisystemberechtigungen auf dem lokalen Backup-Verzeichnis und beim FTP(S)-Ziel restriktiv setzen
• Separate, nicht mit dem Tagesgeschäft geteilte Zugangsdaten für das Backup-Ziel verwenden
• Separate Administratorkonten für Backup-Verwaltung statt eines geteilten Admin-Logins

Netzwerk-Sicherheit

Nutze sichere Verbindungen für alle Backup-Übertragungen:

• ftps:// oder ftpes:// statt unverschlüsseltem ftp:// für Backup-Übertragungen
• Ziel-Port und Passive-Port-Range nur für die IP der 3CX-Anlage freigeben, nicht offen ins Internet
• TLS 1.2+ für alle HTTPS-Verbindungen zur Admin Console

Audit Logging

Aktiviere umfassendes Logging aller Backup- und Wiederherstellungsoperationen im Event Log. Dies hilft bei der Erkennung von unbefugten Zugriffen und der Compliance-Dokumentation.

BitBlade Empfohlene Backup-Strategie: Die 3-2-1 Regel

Die 3-2-1 Regel ist ein bewährtes Backup-Konzept, das wir unseren Partnern und Kunden empfehlen. Sie bietet optimalen Schutz gegen verschiedene Fehlerszenarien:

Praktische BitBlade Implementierung:

Diese Strategie stellt sicher, dass du vor lokalen Hardware-Ausfällen, Ransomware-Angriffen und Datencenter-Katastrophen geschützt bist. BitBlade kann dir bei der Implementierung dieser Strategie unterstützen.

Checkliste

• Remote-Speicher unter System → Speicher aktiviert (ftps:// oder ftpes://, nicht ftp://)
• Zeitplan unter Backup → Backup planen aktiv, Intervall passend zur Änderungsfrequenz
• Mehrere Backup-Generationen aufbewahrt statt einer einzigen überschriebenen Datei
• Verschlüsseltes Passwort für die Sicherung gesetzt und im Passwort-Manager hinterlegt — getrennt von den FTP-Zugangsdaten
• Aufzeichnungen bewusst ein- oder ausgeschlossen (Checkbox „Lokale/temporäre Aufzeichnungen einbeziehen“ geprüft)
• Mindestens ein Restore-Test auf einer separaten Testinstanz erfolgreich durchgeführt und dokumentiert
• Vor jedem Update und jeder größeren Konfigurationsänderung ein zusätzliches manuelles Backup erstellt
• Nach jedem Restore auf neuem Server oder neuer FQDN: SSL/TLS-Zertifikate geprüft bzw. neu ausgestellt