Comment sauvegarder et restaurer en toute sécurité les fichiers de configuration de Collabora CODE

Collabora Online Development Edition (CODE) 26.04.4.2 a été publié le 24 septembre 2026. Cette date est importante pour la planification des sauvegardes, car la version 26.04 a également modifié la gestion des chemins de proxy inverse recommandés pour les URL WebSocket plus récentes. Si vous préparez une mise à niveau, une migration ou une reprise après sinistre, la sauvegarde d'un seul fichier XML peut s'avérer insuffisante pour reproduire un déploiement fonctionnel.

Le cœur du système est simple : le fichier de configuration principal du serveur Collabora se /etc/coolwsd/coolwsd.xmltrouve dans le conteneur CODE officiel. La documentation Docker officielle permet également de copier ce fichier hors du conteneur, de le recopier ou de le monter depuis l'hôte. Les éléments qui varient concernent tout ce qui l'entoure : variables d'environnement Docker, montages de répertoires, clés de preuve WOPI, terminaison TLS et configuration du proxy inverse.

Ce guide présente une procédure de sauvegarde et de restauration prudente, applicable aussi bien aux installations de paquets natifs qu'aux déploiements Docker. Il distingue volontairement les éléments validés par la documentation Collabora de ceux qui dépendent de votre propre déploiement.

Que doit contenir une sauvegarde Collabora CODE ?

Vérifié : /etc/coolwsd/coolwsd.xml il s’agit du fichier de configuration principal de Collabora Online. Collabora documente directement ce chemin et décrit le fichier comme étant auto-documenté pour les options serveur disponibles. Consultez le manuel officiel du SDK Collabora Online .

Selon le déploiement : une restauration complète peut également nécessiter la configuration utilisée pour lancer le service. Pour Docker, cela peut inclure le fichier YAML Compose, les variables d'environnement, les points de montage de liaison, les secrets et les fichiers montés depuis l'hôte. Pour une installation native, cela peut inclure un hôte virtuel proxy inverse et les certificats s'ils sont gérés sur le même serveur.

Action : avant de créer une archive, notez si votre instance est une installation native ou un déploiement Docker/Compose. Ne supposez pas que la même procédure de restauration s’applique aux deux.

Idées reçues courantes avant de commencer

La sauvegarde de coolwsd.xml ne sauvegarde pas les documents utilisateur.

CODE est généralement connecté à une plateforme de stockage via WOPI. Les documents restent sous le contrôle de cette plateforme, telle que Nextcloud ou un autre hébergeur WOPI. La restauration de la configuration de CODE ne restaure donc pas les documents eux-mêmes.

Action : sauvegardez l’hôte WOPI et son espace de stockage de données à l’aide de la procédure de sauvegarde propre à ce produit. Considérez cette sauvegarde de code comme une sauvegarde de configuration de service.

Un conteneur Docker n'est pas une sauvegarde

Un conteneur peut être recréé à partir d'une image. La configuration transmise via des variables d'environnement ou des montages de liaison peut résider en dehors du conteneur, tandis que les modifications effectuées uniquement à l'intérieur de celui-ci peuvent disparaître lors de son remplacement.

Action : enregistrez la définition de déploiement et les fichiers montés sur l’hôte, et pas seulement le système de fichiers du conteneur.

Copier un ancien fichier coolwsd.xml par-dessus une version plus récente n'est pas toujours la méthode de restauration la plus sûre.

Les options de configuration peuvent varier d'une version de CODE à l'autre. Les notes de version actuelles de Collabora indiquent des modifications continues apportées au serveur et au proxy dans la série 26.04, notamment des recommandations de proxy mises à jour pour l'URL WebSocket compacte. Consultez les notes de version officielles de CODE 26.04 .

Action : notez la version du code à chaque sauvegarde. Lors d’une restauration vers une version différente, comparez le fichier enregistré avec le fichier par défaut du nouveau package avant de le remplacer intégralement.

Étape 1 : Notez la version installée et le type de déploiement

Commencez par enregistrer suffisamment d'informations pour reproduire l'environnement. Dans le cas d'un déploiement de conteneur, examinez le conteneur en cours d'exécution et son image :

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

Si votre conteneur utilise un nom différent, remplacez-le collaboraen conséquence. L'image officielle est publiée sous le nomcollabora/code ; Docker Hub identifie actuellement l'image 26.04.4.2 dans la dernière version publiée. Consultez l' image officielle Collabora CODE sur Docker Hub .

Pour une installation de paquet natif, notez la version du paquet avec le gestionnaire de paquets que vous utilisez. Sur Debian ou Ubuntu, par exemple :

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

Action : enregistrer la version générée dans le même répertoire de sauvegarde protégé que l’archive de configuration.

Étape 2 : Sauvegarder la configuration principale et les métadonnées de déploiement

installation de paquets natifs

Créez un répertoire de sauvegarde contenant uniquement la racine et archivez-le intégralement /etc/coolwsdplutôt que de sélectionner uniquement le fichier XML principal. Cela préservera tous les fichiers supplémentaires que votre package installé ou vos personnalisations locales y ont placés.

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

Cette commande modifie délibérément le chemin /etcavant l'archivage, de sorte que l'archive contienne un coolwsd/chemin relatif au lieu d'un chemin absolu du système de fichiers.

Docker ou Docker Compose

La documentation de Collabora indique que l'image officielle contient les fichiers nécessaires /etc/coolwsd/coolwsd.xmlet que les administrateurs peuvent la copier, la modifier, la recopier ou la monter depuis l'extérieur du conteneur.

Si le fichier n'est pas déjà monté depuis l'hôte, copiez-le :

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

Ensuite, notez comment le conteneur a été configuré :

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

Important : les variables d’environnement peuvent contenir des mots de passe, des identifiants d’administration, des noms d’hôtes ou d’autres informations confidentielles. Veillez à ce que ces fichiers soient accessibles uniquement à l’utilisateur root et chiffrez ou protégez d’une autre manière les copies hors de l’hôte.

Si vous utilisez Docker Compose, copiez le fichier Compose et tous les fichiers d'environnement ou secrets référencés depuis l'hôte. Leur emplacement étant spécifique à votre déploiement, il n'existe pas de chemin universel fiable.

Action : vérifiez que votre sauvegarde inclut bien la source de référence. Si coolwsd.xmlle volume est monté, sauvegardez le fichier host. Si la configuration est fournie via des variables d’environnement, conservez la configuration Compose/run qui définit ces variables.

Étape 3 : Inclure les clés de preuve, la configuration du proxy et TLS uniquement lorsqu’ils sont applicables.

Ces composants sont importants précisément parce qu'ils ne sont pas identiques sur chaque installation.

Clé de preuve WOPI : Collabora indique que les installations RPM et DEB génèrent automatiquement la paire de clés de preuve WOPI. Pour Docker, cette paire de clés n'est pas incluse dans l'image publique ; elle doit être générée et fournie au conteneur, généralement via un volume. La documentation explique coolconfig generate-proof-keycomment générer la clé. La clé Docker étant stockée en dehors de l'image immuable, la perte de la clé montée côté hôte peut modifier l'identité utilisée pour la signature de preuve WOPI.

Action : utilisez la liste des points de montage du conteneur pour identifier l’emplacement hôte de tout point de montage nécessitant une clé de preuve et sauvegardez ce fichier ou répertoire côté hôte de manière sécurisée. N’inventez pas de chemin si votre déploiement n’en utilise pas.

Proxy inverse : Apache, Nginx, HAProxy, Traefik ou tout autre proxy peut gérer le nom d’hôte public, la terminaison TLS, le routage WebSocket et les règles de transfert des requêtes. Dans CODE 26.04, Collabora a mis à jour les recommandations relatives aux proxys pour la nouvelle URL WebSocket compacte, tout en conservant une solution de repli pour les anciennes versions dans certains cas.

Action : sauvegardez la configuration exacte du proxy qui gère votre nom d’hôte Collabora. Son chemin d’accès dépend de votre système d’exploitation et du proxy utilisé ; identifiez-le donc dans la configuration du proxy actif plutôt que de copier un chemin générique depuis un tutoriel.

Certificats TLS : sauvegardez-les uniquement si cet hôte en est le propriétaire. Si la connexion TLS est terminée par un équilibreur de charge, un contrôleur d’entrée, un CDN ou un proxy inverse distinct, la sauvegarde du certificat doit être effectuée à cet endroit.

Étape 4 : Vérifiez la sauvegarde avant d’en avoir besoin

Une commande réussie tarne suffit pas. Vérifiez que l'archive peut être listée et que le fichier de configuration principal attendu est présent.

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

Créer une somme de contrôle pour la vérification hors hôte :

cd /var/backups/collabora
sha256sum * > SHA256SUMS

Copiez ensuite la sauvegarde vers un second emplacement protégé à l'aide de votre système de sauvegarde habituel. Ne laissez pas l'unique copie sur l'hôte que vous protégez.

Action : tester l’extraction dans un répertoire temporaire au moins une fois. Une sauvegarde que vous n’avez jamais ouverte n’est qu’une supposition.

Étape 5 : Restaurez le service avec précaution, puis validez son bon fonctionnement.

Restaurez une installation native

Il est préférable d'installer d'abord la même version de CODE. Arrêtez le service, extrayez l'archive dans un répertoire temporaire et comparez la configuration enregistrée avec la configuration par défaut nouvellement installée :

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

Si les versions correspondent et que vous prévoyez un remplacement complet, conservez d'abord le répertoire mis à jour comme copie de restauration :

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

Si les versions diffèrent, fusionnez les paramètres que vous avez modifiés au lieu de remplacer aveuglément le nouveau fichier. Cela vous évitera de perdre les nouveaux paramètres par défaut ou les éléments obligatoires introduits par la version la plus récente.

Restaurer un déploiement Docker

Recréez le conteneur à partir de l'image enregistrée et du fichier Docker Compose ou docker runde la définition d'origine. Avant de démarrer le conteneur, restaurez la configuration montée sur l'hôte, les clés de preuve et les autres fichiers externes à leurs emplacements d'origine sur l'hôte.

Si vous avez délibérément conservé coolwsd.xmlle fichier à l'intérieur du conteneur plutôt que de le monter via un volume de liaison, la méthode documentée de Collabora permet de le recopier. En pratique, un volume de liaison sur l'hôte est plus facile à reproduire car la configuration est conservée même après le remplacement du conteneur.

Action : commencez par restaurer la définition de déploiement, puis les fichiers auxquels elle fait référence. Cela permet de garantir la cohérence des variables d’environnement, des volumes et de la configuration XML.

Comment vérifier que la restauration a bien fonctionné ?

Ne jugez pas le succès uniquement par le fait que le processus démarre. Vérifiez le service depuis le même chemin réseau que celui utilisé par les clients.

Pour une installation native :

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

Pour Docker :

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

Collabora documente ce /hosting/capabilitiespoint de terminaison comme permettant de récupérer, entre autres informations, le nom et la version du produit en cours d'exécution. Testez-le via votre URL Collabora publique avec :

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

Remplacez le nom d'hôte par le vôtre. Ouvrez également un document réel depuis l'hôte WOPI et vérifiez que la modification, l'enregistrement et la reconnexion fonctionnent correctement via le chemin du proxy inverse habituel.

Action : la restauration ne sera considérée comme terminée qu’après la réponse du point de terminaison des capacités et la possibilité d’ouvrir et d’enregistrer un document.

Liste de vérification pratique pour les sauvegardes

Recommandation finale

Le plan de récupération le plus fiable pour Collabora CODE ne consiste pas à copier un seul fichier. Conservez coolwsd.xmlla version exacte de CODE et la définition de déploiement ensemble, afin de pouvoir les récupérer. N'ajoutez les clés de preuve, les règles de proxy et les éléments TLS que là où votre architecture les utilise réellement. Lors des mises à niveau, restaurez la configuration dans la même version si possible ; si vous passez à une version plus récente, comparez et fusionnez les configurations au lieu de remplacer les nouvelles valeurs par défaut sans les avoir vérifiées.

Au 6 octobre 2026, la version CODE 26.04.4.2 est la version actuelle, comme indiqué dans les notes de version officielles de Collabora (version 26.04) et les métadonnées de l'image Docker. Consultez à nouveau ces sources officielles avant toute migration, car les versions d'images, les recommandations de proxy et les options de configuration sont susceptibles d'évoluer.