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.
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):
| Komponente | Enthalten? | Hinweis |
|---|---|---|
| Systemkonfiguration (Nutzer, Trunks, Warteschlangen, IVR, Regeln) | Ja | Kern jedes Backups |
| Lizenzschlüssel (LIC) | Ja | Restore auf anderem Server möglich |
| FQDN | Ja | Relevant bei Restore auf abweichender Domain |
| Anrufverlauf / Call History (CH) | Ja | |
| Voicemails (VM) | Ja | |
| Sprachansagen / Prompts (PROMPTS) | Ja | Eigene und System-Ansagen |
| Telefon-Firmware-Cache (FW) | Ja | Für Endgeräte-Provisionierung |
| Anrufaufzeichnungen (REC) | Nur mit Checkbox | „Lokale/temporäre Aufzeichnungen einbeziehen" muss aktiv sein, sonst fehlen sie ersatzlos |
| SSL/TLS-Zertifikate | Nein | Nicht Teil der Backup-Komponenten — nach Restore auf neuem Server/neuer FQDN neu ausstellen |
| Chat-Verlauf | Nicht dokumentiert | In der offiziellen Komponentenliste nicht separat aufgeführt |
Manuelles Backup erstellen
- Admin Console öffnen → Tab Backup
- Jetzt sichern anklicken
- Backup-Namen vergeben
- Optional: Lokale/temporäre Aufzeichnungen einbeziehen aktivieren (erhöht die Dateigrösse spürbar)
- 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
- Admin Console → Backup → Backup planen
- Zeitplan-Typ wählen (z. B. Wöchentlich/Sonntag) und Intervall festlegen
- 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.
Remote-Speicher einrichten: System > Speicher
- Admin Console → System → Speicher
- Remote-Speicher aktivieren
- Zielpfad als URL mit einem der unterstützten Schemes eintragen: ftp://, ftps:// oder ftpes:// — der Platzhaltertext im Pfadfeld nennt genau diese drei
- 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.
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
- Admin Console → Backup → Wiederherstellen
- Gewünschte Backup-Datei auswählen (lokal vorhanden oder von extern hochladen)
- Bei verschlüsselten Backups: Passwort eingeben
- Restore bestätigen und Abschluss abwarten
- 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-Typ | Empfohlene Aufbewahrung |
|---|---|
| Tägliches automatisches Backup | Mindestens 30 Tage rollierend, mehrere Generationen |
| Manuelles Backup vor Updates | Bis zur Bestätigung, dass das Update stabil läuft (mind. 1–2 Wochen) |
| Jahres-/Meilenstein-Backup | Optional, 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
- Ausführliche Backup-Anleitung mit Praxisfall
- 3CX Update — Backup vorher nicht vergessen
- Sicherheit & Hardening
- Installation-Guide
- Troubleshooting & Logs
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