So sichern und stellen Sie Collabora CODE-Konfigurationsdateien sicher wieder her

Collabora Online Development Edition (CODE) 26.04.4.2 wurde am 24. September 2026 veröffentlicht. Dies ist für die Backup-Planung relevant, da die Versionsreihe 26.04 auch Änderungen an der empfohlenen Behandlung des Reverse-Proxy-Pfads für neuere WebSocket-URLs vorgenommen hat. Wenn Sie ein Upgrade, eine Migration oder eine Notfallwiederherstellung vorbereiten, reicht die Sicherung nur einer XML-Datei möglicherweise nicht aus, um eine funktionierende Bereitstellung wiederherzustellen.

Der verifizierte Kern ist unkompliziert: Die Hauptserverkonfigurationsdatei von Collabora befindet sich /etc/coolwsd/coolwsd.xmlim offiziellen CODE-Container. Die offizielle Docker-Dokumentation beschreibt außerdem, wie diese Datei aus dem Container kopiert, zurückkopiert oder vom Host aus eingebunden werden kann. Die Unterschiede liegen in der Umgebung: Docker-Umgebungsvariablen, Einbindungen, WOPI-Prüfschlüssel, TLS-Terminierung und Reverse-Proxy-Konfiguration.

Diese Anleitung beschreibt einen konservativen Backup- und Wiederherstellungsprozess sowohl für native Paketinstallationen als auch für Docker-Bereitstellungen. Sie trennt bewusst die in der Collabora-Dokumentation bestätigten Informationen von den Aspekten, die von Ihrer individuellen Bereitstellung abhängen.

Was sollte ein Collabora CODE-Backup enthalten?

Bestätigt: /etc/coolwsd/coolwsd.xml Dies ist die primäre Konfigurationsdatei von Collabora Online. Collabora dokumentiert diesen Pfad direkt und beschreibt die Datei als selbsterklärend für die verfügbaren Serveroptionen. Siehe das offizielle Collabora Online SDK-Handbuch .

Je nach Bereitstellung: Für eine vollständige Wiederherstellung kann auch die Konfiguration erforderlich sein, die zum Starten des Dienstes verwendet wurde. Bei Docker können dies Compose-YAML-Dateien, Umgebungsvariablen, Bind-Mounts, Secrets und vom Host eingebundene Dateien sein. Bei einer nativen Installation können dies ein Reverse-Proxy-Virtual-Host und Zertifikate sein, sofern diese auf demselben Server verwaltet werden.

Vor dem Erstellen eines Archivs notieren Sie sich , ob es sich bei Ihrer Instanz um eine native Paketinstallation oder eine Docker/Compose-Bereitstellung handelt. Gehen Sie nicht davon aus, dass für beide die gleiche Wiederherstellungsprozedur gilt.

Häufige Missverständnisse vor dem Start

Das Sichern der Datei coolwsd.xml sichert keine Benutzerdokumente.

CODE ist normalerweise über WOPI mit einer Speicherplattform verbunden. Die Dokumente bleiben unter der Kontrolle dieser Speicherplattform, beispielsweise Nextcloud oder eines anderen WOPI-Hosts. Die Wiederherstellung der CODE-Konfiguration stellt daher nicht die Dokumente selbst wieder her.

Maßnahme: Sichern Sie den WOPI-Host und seinen Datenspeicher mithilfe der produktspezifischen Sicherungsprozedur. Behandeln Sie diese CODE-Sicherung als Sicherung der Dienstkonfiguration.

Ein Docker-Container ist kein Backup.

Ein Container kann aus einem Image neu erstellt werden. Konfigurationen, die über Umgebungsvariablen oder Bind-Mounts übergeben werden, können außerhalb des Containers gespeichert werden, während Änderungen, die nur innerhalb des Containers vorgenommen werden, beim Ersetzen des Containers verloren gehen können.

Aktion: Speichern Sie die Bereitstellungsdefinition und die auf dem Host eingebundenen Dateien, nicht nur das Container-Dateisystem.

Das Kopieren einer alten coolwsd.xml-Datei über eine neuere Version ist nicht immer die sicherste Wiederherstellungsmethode.

Die Konfigurationsoptionen können sich zwischen den CODE-Versionen ändern. Die aktuellen Versionshinweise von Collabora zeigen fortlaufende Server- und Proxy-Änderungen in der 26.04-Serie, einschließlich aktualisierter Proxy-Empfehlungen für die kompakte WebSocket-URL. Siehe die offiziellen Versionshinweise zu CODE 26.04 .

Maßnahme: Notieren Sie die CODE-Version bei jeder Sicherung. Vergleichen Sie beim Wiederherstellen einer anderen Version die gespeicherte Datei mit der Standarddatei des neuen Pakets, bevor Sie sie vollständig ersetzen.

Schritt 1: Installierte Version und Bereitstellungstyp notieren

Beginnen Sie damit, genügend Informationen zu erfassen, um die Umgebung nachzubilden. Untersuchen Sie bei einer Containerbereitstellung den laufenden Container und sein Image:

docker ps --filter name=collabora
docker inspect collabora --format '{{.Config.Image}}'
docker inspect collabora --format '{{json .Mounts}}'

Falls Ihr Container einen anderen Namen verwendet, ersetzen Sie ihn collaboraentsprechend. Das offizielle Image ist unter folgendem Namen veröffentlicht collabora/code: ; Docker Hub führt derzeit das Image 26.04.4.2 in der neuesten Release-Reihe. Siehe das offizielle Collabora CODE-Image auf Docker Hub .

Bei einer nativen Paketinstallation notieren Sie sich die Paketversion mit dem von Ihnen verwendeten Paketmanager. Unter Debian oder Ubuntu beispielsweise:

dpkg-query -W 'coolwsd*' 'collaboraoffice*' 2>/dev/null

Aktion: Speichern Sie die Versionsausgabe im selben geschützten Sicherungsverzeichnis wie das Konfigurationsarchiv.

Schritt 2: Sichern der Kernkonfiguration und der Bereitstellungsmetadaten

Installation des nativen Pakets

Erstellen Sie ein Backup-Verzeichnis nur im Stammverzeichnis und archivieren Sie das gesamte /etc/coolwsdVerzeichnis, anstatt nur die Haupt-XML-Datei auszuwählen. Dadurch bleiben alle zusätzlichen Dateien erhalten, die Ihr installiertes Paket oder Ihre lokalen Anpassungen dort abgelegt haben.

sudo install -d -m 700 /var/backups/collabora
sudo tar -C /etc -czpf \
  /var/backups/collabora/coolwsd-etc-$(date +%F).tar.gz \
  coolwsd

Dieser Befehl ändert sich absichtlich /etcvor der Archivierung, sodass das Archiv einen relativen coolwsd/Pfad anstelle eines absoluten Dateisystempfads enthält.

Docker oder Docker Compose

In der Dokumentation von Collabora heißt es, dass das offizielle Image /etc/coolwsd/coolwsd.xmldie Datei enthält und dass Administratoren sie kopieren, modifizieren, zurückkopieren oder von außerhalb des Containers einbinden können.

Falls die Datei noch nicht vom Host eingebunden ist, kopieren Sie sie heraus:

sudo install -d -m 700 /var/backups/collabora
docker cp collabora:/etc/coolwsd/coolwsd.xml \
  /var/backups/collabora/coolwsd.xml

Als Nächstes sollte erfasst werden, wie der Container konfiguriert wurde:

docker inspect collabora --format '{{json .Config.Env}}' \
  > /var/backups/collabora/container-env.json

docker inspect collabora --format '{{json .Mounts}}' \
  > /var/backups/collabora/container-mounts.json

Wichtig: Die Ausgabedateien der Umgebung können Passwörter, Anmeldeinformationen für die Administratorkonsole, Hostnamen oder andere vertrauliche Informationen enthalten. Diese Dateien dürfen nur vom Stammverzeichnis gelesen werden und Kopien außerhalb des Hosts müssen verschlüsselt oder anderweitig geschützt werden.

Wenn Sie Docker Compose verwenden, kopieren Sie die eigentliche Compose-Datei sowie alle referenzierten Umgebungs- oder Geheimnisdateien vom Hostsystem. Deren Speicherorte sind spezifisch für Ihre Bereitstellung, daher gibt es keinen allgemeingültigen Pfad, der als solcher angenommen werden kann.

Maßnahme: Stellen Sie sicher, dass Ihre Sicherung die maßgebliche Quelle enthält. Wenn das coolwsd.xmlSystem eingebunden ist, sichern Sie die Host-Datei. Wenn die Konfiguration über Umgebungsvariablen bereitgestellt wird, sichern Sie die Compose/Run-Konfiguration, die diese Variablen definiert.

Schritt 3: Fügen Sie Nachweisschlüssel, Proxy-Konfiguration und TLS nur dann hinzu, wenn sie zutreffen.

Diese Komponenten sind gerade deshalb wichtig, weil sie nicht bei jeder Installation identisch sind.

WOPI-Prüfschlüssel: Collabora dokumentiert, dass RPM- und DEB-Installationen das WOPI-Prüfschlüsselpaar automatisch generieren. Bei Docker ist das Schlüsselpaar nicht im öffentlichen Image enthalten; es muss generiert und dem Container bereitgestellt werden, üblicherweise über ein Volume. Die Dokumentation coolconfig generate-proof-keybeschreibt die Generierung des Schlüssels. Da sich der Docker-Schlüssel außerhalb des unveränderlichen Images befindet, kann der Verlust des hostseitig eingebundenen Schlüssels die für die WOPI-Signatur verwendete Identität verändern.

Maßnahme: Verwenden Sie die Mount-Liste des Containers, um den Host-Speicherort aller Proof-Key-Mounts zu ermitteln und sichern Sie die entsprechende Datei oder das entsprechende Verzeichnis auf dem Host sicher. Erstellen Sie keinen Pfad, falls Ihre Bereitstellung keinen verwendet.

Reverse-Proxy: Apache, Nginx, HAProxy, Traefik oder ein anderer Proxy kann den öffentlichen Hostnamen, die TLS-Terminierung, das WebSocket-Routing und die Weiterleitungsregeln für Anfragen verwalten. In CODE 26.04 hat Collabora die Proxy-Richtlinien für die neuere, kompakte WebSocket-URL aktualisiert und gleichzeitig in einigen Fällen eine ältere Fallback-Lösung beibehalten.

Maßnahme: Sichern Sie die exakte Proxy-Konfiguration, die Ihren Collabora-Hostnamen bedient. Der Dateisystempfad hängt von Ihrem Betriebssystem und Proxy ab. Ermitteln Sie ihn daher anhand der aktiven Proxy-Konfiguration, anstatt einen generischen Pfad aus einer Anleitung zu kopieren.

TLS-Zertifikate: Sichern Sie diese nur, wenn der Host tatsächlich der Inhaber ist. Wird TLS an einem Load Balancer, Ingress Controller, CDN oder einem separaten Reverse-Proxy terminiert, ist die Zertifikatssicherung dort vorzunehmen.

Schritt 4: Überprüfen Sie die Sicherung, bevor Sie sie benötigen.

Ein erfolgreicher tarBefehl allein genügt nicht. Prüfen Sie, ob das Archiv aufgelistet werden kann und ob die erwartete Hauptkonfigurationsdatei vorhanden ist.

sudo tar -tzf /var/backups/collabora/coolwsd-etc-$(date +%F).tar.gz \
  | grep 'coolwsd/coolwsd.xml'

Erstellen einer Prüfsumme für die Off-Host-Verifizierung:

cd /var/backups/collabora
sha256sum * > SHA256SUMS

Kopieren Sie anschließend die Sicherung mithilfe Ihres üblichen Sicherungssystems an einen zweiten geschützten Ort. Achten Sie darauf, dass sich die einzige Kopie nicht auf demselben Host befindet, den Sie sichern.

Maßnahme: Testen Sie die Extraktion in ein temporäres Verzeichnis mindestens einmal. Ein Backup, das Sie noch nie geöffnet haben, ist nur eine Annahme.

Schritt 5: Konservative Wiederherstellung durchführen und anschließend den laufenden Dienst überprüfen

Eine native Installation wiederherstellen

Installieren Sie vorzugsweise zuerst dieselbe CODE-Version. Stoppen Sie den Dienst, extrahieren Sie das Archiv in ein temporäres Verzeichnis und vergleichen Sie die gespeicherte Konfiguration mit der neu installierten Standardkonfiguration.

sudo systemctl stop coolwsd
sudo mkdir -p /root/collabora-restore
sudo tar -xzf /var/backups/collabora/coolwsd-etc-YYYY-MM-DD.tar.gz \
  -C /root/collabora-restore

sudo diff -u \
  /etc/coolwsd/coolwsd.xml \
  /root/collabora-restore/coolwsd/coolwsd.xml

Wenn die Versionen übereinstimmen und Sie einen vollständigen Austausch beabsichtigen, behalten Sie zunächst das neue Verzeichnis als Rollback-Kopie:

sudo cp -a /etc/coolwsd /etc/coolwsd.pre-restore
sudo cp -a /root/collabora-restore/coolwsd/. /etc/coolwsd/
sudo systemctl start coolwsd

Falls die Versionen voneinander abweichen, sollten Sie die tatsächlich geänderten Einstellungen zusammenführen, anstatt die neue Datei einfach zu ersetzen. Dadurch vermeiden Sie, dass neue Standardwerte oder erforderliche Elemente der neueren Version verloren gehen.

Wiederherstellen einer Docker-Bereitstellung

Erstellen Sie den Container anhand der aufgezeichneten Image-Version und der ursprünglichen Docker Compose-Datei bzw. docker run-Definition neu. Stellen Sie die vom Host eingebundenen Konfigurationsdateien, die Proof-Keys und andere externe Dateien vor dem Start des Containers in ihren ursprünglichen Host-Pfaden wieder her.

Wenn Sie die Datei absichtlich coolwsd.xmlinnerhalb des Containers und nicht als Bind-Mount gespeichert haben, ermöglicht die dokumentierte Vorgehensweise von Collabora das Zurückkopieren der Datei. In der Praxis lässt sich ein Host-Bind-Mount leichter reproduzieren, da die Konfiguration auch nach einem Containerwechsel erhalten bleibt.

Vorgehensweise: Stellen Sie zuerst die Bereitstellungsdefinition und anschließend die darin referenzierten Dateien wieder her. Dadurch bleiben Umgebungsvariablen, Volumes und die XML-Konfiguration konsistent.

So überprüfen Sie, ob die Wiederherstellung tatsächlich funktioniert hat

Beurteilen Sie den Erfolg nicht allein daran, ob der Prozess startet. Überprüfen Sie den Dienst über denselben Netzwerkpfad, den auch die Clients verwenden.

Für eine native Installation:

sudo systemctl status coolwsd --no-pager
sudo journalctl -u coolwsd -n 100 --no-pager

Für Docker:

docker ps --filter name=collabora
docker logs --tail 100 collabora

Collabora dokumentiert den /hosting/capabilitiesEndpunkt als Möglichkeit, unter anderem den Namen und die Version des laufenden Produkts abzurufen. Testen Sie ihn über Ihre öffentliche Collabora-URL mit folgendem Befehl:

curl -fsS https://office.example.com/hosting/capabilities

Ersetzen Sie den Hostnamen durch Ihren eigenen. Öffnen Sie außerdem ein echtes Dokument vom WOPI-Host und überprüfen Sie, ob das Bearbeiten, Speichern und erneute Verbinden über den normalen Reverse-Proxy-Pfad funktionieren.

Vorgehen: Die Wiederherstellung gilt erst dann als abgeschlossen, wenn der Capabilities-Endpunkt antwortet und ein tatsächliches Dokument geöffnet und gespeichert werden kann.

Praktische Backup-Checkliste

Abschließende Empfehlung

Der zuverlässigste Collabora CODE-Wiederherstellungsplan besteht nicht aus einer einzelnen kopierten Datei. Bewahren Sie coolwsd.xmldie exakte CODE-Version und die Bereitstellungsdefinition als ein wiederherstellbares Set auf. Fügen Sie Proof-Keys, Proxy-Regeln und TLS-Materialien nur dort hinzu, wo Ihre Architektur sie tatsächlich benötigt. Stellen Sie bei Upgrades nach Möglichkeit die gleiche Version wieder her. Wenn Sie auf eine neuere Version wechseln, vergleichen und führen Sie die Konfigurationen zusammen, anstatt die neuen Standardeinstellungen ohne Überprüfung zu überschreiben.

Stand 6. Oktober 2026 ist CODE 26.04.4.2 die aktuelle Version, wie aus den offiziellen Versionshinweisen zu Collabora 26.04 und den Metadaten des Docker-Images hervorgeht. Bitte prüfen Sie diese offiziellen Quellen vor einer zukünftigen Migration erneut, da sich Image-Versionen, Proxy-Empfehlungen und Konfigurationsoptionen fortlaufend ändern.