3CX.BitBlade

3CX Backup & Restore

Ein funktionierendes Backup ist der Unterschied zwischen einem kurzen Zwischenfall und einem tagelangen Totalausfall der Telefonanlage. Diese Seite ist die kompakte Referenz: Was 3CX sichert, wie Remote-Speicher per FTP/FTPS/FTPES eingerichtet wird, und worauf es bei Zeitplan, Verschlüsselung und Restore-Test ankommt. Die ausführliche Schritt-für-Schritt-Fassung mit einem realen Praxisfall steht in der Backup-Anleitung.

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 (Festplattendefekt, Diebstahl, Brand, fehlgeschlagenes Update), ist die Konfiguration ebenso weg wie das Backup, das sie hätte retten sollen. 3CX weist selbst im Systemübersicht-Dashboard darauf hin, wenn kein Remote-Speicher konfiguriert ist.

3CX-Systemübersicht-Dashboard mit Warnhinweis, dass der Remote-Speicher nicht konfiguriert ist
Abb. 1: Systemübersicht-Dashboard — Warnhinweis „Der Remote-Speicher ist nicht konfiguriert" bei rein lokalem Backup.

Konsequenz: Externe Speicherung (System → Speicher, siehe unten) ist keine Kür, sondern die Voraussetzung dafür, dass ein Backup im Ernstfall überhaupt etwas rettet.

Was im 3CX-Backup enthalten ist — und was nicht

Die vollständige Komponentenliste ergibt sich aus den offiziellen Backup-Kommandozeilenoptionen von 3CX (--options=ALL bzw. einzeln CH, LIC, FQDN, PROMPTS, FW, REC, VM):

KomponenteEnthalten?Hinweis
Systemkonfiguration (Nutzer, Trunks, Warteschlangen, IVR, Regeln)JaKern jedes Backups
Lizenzschlüssel (LIC)JaRestore auf anderem Server möglich
FQDNJaRelevant bei Restore auf abweichender Domain
Anrufverlauf / Call History (CH)Ja
Voicemails (VM)Ja
Sprachansagen / Prompts (PROMPTS)JaEigene und System-Ansagen
Telefon-Firmware-Cache (FW)JaFür Endgeräte-Provisionierung
Anrufaufzeichnungen (REC)Nur mit Checkbox„Lokale/temporäre Aufzeichnungen einbeziehen" muss aktiv sein, sonst fehlen sie ersatzlos
SSL/TLS-ZertifikateNeinNicht Teil der Backup-Komponenten — nach Restore auf neuem Server/neuer FQDN neu ausstellen
Chat-VerlaufNicht dokumentiertIn der offiziellen Komponentenliste nicht separat aufgeführt

Manuelles Backup erstellen

  1. Admin Console öffnen → Tab Backup
  2. Jetzt sichern anklicken
  3. Backup-Namen vergeben
  4. Optional: Lokale/temporäre Aufzeichnungen einbeziehen aktivieren (erhöht die Dateigrösse spürbar)
  5. Empfohlen: Verschlüsseltes Passwort für die Sicherung setzen

Weitere Aktionen im selben Tab: Wiederherstellen, Herunterladen und Löschen für bereits vorhandene Backups.

Zeitplan setzen: Backup > Backup planen

  1. Admin Console → Backup → Backup planen
  2. Zeitplan-Typ wählen (z. B. Wöchentlich/Sonntag) und Intervall festlegen
  3. Checkboxen setzen: Lokale/temporäre Aufzeichnungen einbeziehen, Deaktivieren der Backup-Komprimierung (in der Regel aus lassen), Verschlüsseltes Passwort für die Sicherung

Wöchentlich ist für viele Installationen zu selten — wie oft sinnvoll ist, hängt von der Änderungsfrequenz ab (siehe „Zeitplan sinnvoll setzen" unten). Zusätzlich wird eine Rotation konfiguriert, also wie viele Backup-Generationen aufbewahrt werden, bevor die älteste überschrieben wird.

Dialogfenster für den 3CX-Backup-Zeitplan mit Zeitplan-Typ, Intervall und Optionen für lokale Aufzeichnungen sowie Backup-Verschlüsselung
Abb. 2: Backup → Backup planen — Zeitplan-Typ, Intervall, „Lokale/temporäre Aufzeichnungen einbeziehen", „Deaktivieren der Backup-Komprimierung" und verschlüsseltes Backup-Passwort.

Remote-Speicher einrichten: System > Speicher

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

ftp:// überträgt Zugangsdaten und später das komplette Backup — inklusive Konfiguration, Anrufverlauf und ggf. Voicemail/Aufzeichnungen — unverschlüsselt. ftps:// (FTP über implizites TLS) und ftpes:// (FTP über explizites TLS) verschlüsseln die Verbindung. Für eine Telefonanlage, deren Backup Zugangsdaten und potenziell Gesprächsdaten enthält, ist unverschlüsseltes FTP die falsche Wahl — ftps:// oder ftpes:// verwenden.

Versionshinweis: Auf der geprüften Live-Anlage (V20 Update 9) akzeptiert das Pfadfeld ausschliesslich diese drei FTP-Schemes — kein S3, kein Azure, kein GCS, kein SMB. Die offizielle 3CX-Dokumentation beschreibt für neuere Versionen zusätzlich einen separaten Auswahl-Dialog „Location Type" mit weiteren Zielen (u. a. Google Cloud Storage, SMB, SFTP, Amazon S3, Microsoft SharePoint) — ob diese Optionen erscheinen, hängt vom Versionsstand ab und sollte am eigenen System geprüft werden.

3CX-Systemeinstellungen für Speicher und Archivierung mit dem Feld für die Remote-Speicher-URL
Abb. 3: System → Speicher — Remote-Speicher mit ftp://-, ftps:// oder ftpes://-Zielpfad.

Zeitplan sinnvoll setzen

Die richtige Häufigkeit hängt vom Recovery Point Objective ab: Wie viel Datenverlust — Nutzeränderungen, Anrufverlauf — ist im schlimmsten Fall akzeptabel? Für aktiv genutzte Systeme mit häufigen Änderungen an Nutzern, Regeln oder Warteschlangen ist wöchentlich zu selten; täglich ausserhalb der Geschäftszeiten ist der gängige Kompromiss. Mindestens so wichtig wie die Frequenz: mehrere Backup-Generationen aufbewahren statt eine einzige Datei zu überschreiben. Eine wöchentlich überschriebene Einzeldatei schützt nicht vor einem Fehler, der erst nach Tagen auffällt — dann ist die letzte fehlerfreie Version bereits weg.

Verschlüsselung

Das Feld „Verschlüsseltes Passwort für die Sicherung" gehört bei jedem Backup gesetzt, das extern liegt — es ist die letzte Schutzschicht, falls das FTP(S)-Ziel selbst kompromittiert wird. Ohne dieses Passwort ist ein Restore aus einem verschlüsselten Backup nicht möglich; es gibt keinen Wiederherstellungsmechanismus. Das Passwort gehört in einen Passwort-Manager, getrennt vom Backup-Ziel selbst aufbewahrt — nie in derselben Notiz wie die FTP-Zugangsdaten.

Restore durchführen

Achtung: Während des Restores werden die 3CX-Dienste gestoppt — planen Sie den Vorgang zwingend ausserhalb der Geschäftszeiten.
  1. Admin Console → Backup → Wiederherstellen
  2. Gewünschte Backup-Datei auswählen (lokal vorhanden oder von extern hochladen)
  3. Bei verschlüsselten Backups: Passwort eingeben
  4. Restore bestätigen und Abschluss abwarten
  5. System danach neu starten und Kernfunktionen (eingehende Anrufe, SIP-Trunk-Status, Nutzer) testen

Wiederherstellung testen

Ein ungetestetes Backup ist eine Vermutung, keine Absicherung. Testen, ohne die Produktivanlage zu gefährden: Restore auf einer separaten Testinstanz (eigene FQDN, isoliertes Netz, SIP-Trunk nicht scharf geschaltet) durchführen und prüfen, ob Nutzer, Trunk-Konfiguration, Warteschlangen und — falls eingeschlossen — Aufzeichnungen und Voicemail korrekt vorhanden sind. Ein Restore-Test auf dem Produktivsystem selbst ist kein Test, sondern ein Risiko.

Häufige Fehler und Lösungen

Backup schlägt mit „Insufficient disk space" fehl

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

Remote-Storage-Test schlägt fehl / 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.

Restore bricht mit Passwortfehler ab

Das Backup wurde verschlüsselt erstellt, aber beim Restore ein falsches oder kein Passwort eingegeben. Ohne das korrekte Verschlüsselungspasswort ist ein verschlüsseltes Backup nicht wiederherstellbar — Passwörter für Backups daher zwingend in einem Passwort-Manager hinterlegen, nicht nur im Kopf.

Wiederherstellung auf abweichender Version schlägt fehl

Backups sollten auf gleicher oder neuerer 3CX-Version wiederhergestellt werden — Abwärtskompatibilität ist nicht garantiert. Vor jedem Versionsupdate zusätzlich ein manuelles Backup ziehen.

Backup enthält keine Aufzeichnungen

Die Checkbox „Lokale/temporäre Aufzeichnungen einbeziehen" war beim Erstellen nicht gesetzt. Ohne sie werden nur Konfiguration, Lizenz, Voicemail und Anrufverlauf gesichert — die Aufzeichnungen selbst fehlen ersatzlos.

Best Practices

  • Tägliches automatisiertes Backup, mindestens 30 Tage bzw. mehrere Generationen Aufbewahrung
  • Immer extern speichern (ftps:// oder ftpes://-Ziel) — niemals ausschliesslich lokal auf demselben Server
  • Backups verschlüsseln, Passwort sicher und getrennt vom Ziel verwahren
  • Restore-Vorgang mindestens einmal testweise auf einer Testinstanz durchspielen, bevor er im Ernstfall gebraucht wird
  • Vor jedem Update und jeder grösseren Konfigurationsänderung ein zusätzliches manuelles Backup ziehen

Was ein Backup nicht ersetzt

Ein Backup schützt vor Datenverlust, aber nicht vor Ausfallzeit während der Wiederherstellung. Für Organisationen mit sehr geringer Ausfalltoleranz (z. B. Callcenter im 24/7-Betrieb) lohnt sich zusätzlich zur Backup-Strategie eine Überlegung zu Redundanz — etwa ein zweiter, passiv bereitstehender 3CX-Server oder ein SLA-basiertes Hosting-Modell mit garantierten Wiederherstellungszeiten.

Typische Aufbewahrungsfristen

Backup-TypEmpfohlene Aufbewahrung
Tägliches automatisches BackupMindestens 30 Tage rollierend, mehrere Generationen
Manuelles Backup vor UpdatesBis zur Bestätigung, dass das Update stabil läuft (mind. 1–2 Wochen)
Jahres-/Meilenstein-BackupOptional, für Audit-/Compliance-Zwecke separat archivieren

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 gesetzt und im Passwort-Manager hinterlegt
  • Aufzeichnungen bewusst ein- oder ausgeschlossen (Checkbox geprüft)
  • Mindestens ein Restore-Test auf einer Testinstanz erfolgreich durchgeführt
  • Vor jedem Update ein zusätzliches manuelles Backup erstellt

Weiterführend

Backups nicht mehr selbst verwalten wollen?

Bei BitBlade-Hosting sind tägliche, verschlüsselte Backups mit externer Speicherung und regelmässigen Restore-Tests bereits Teil des Betriebs — Sie müssen sich um nichts mehr kümmern.

Hosting ansehen Beratung anfragen