Jak bezpiecznie tworzyć kopie zapasowe i przywracać pliki konfiguracyjne Collabora CODE

Wersja Collabora Online Development Edition (CODE) 26.04.4.2 została wydana 24 września 2026 roku. Ma to znaczenie dla planowania tworzenia kopii zapasowych, ponieważ wersja 26.04 zmieniła również niektóre elementy zalecanej obsługi ścieżek proxy odwrotnego dla nowszych adresów URL WebSocket. Jeśli przygotowujesz się do aktualizacji, migracji lub odzyskiwania po awarii, utworzenie kopii zapasowej tylko jednego pliku XML może nie wystarczyć do odtworzenia działającego wdrożenia.

Zweryfikowany rdzeń jest prosty: główny plik konfiguracyjny serwera Collabora znajduje się /etc/coolwsd/coolwsd.xmlw oficjalnym kontenerze CODE. Oficjalna dokumentacja Dockera obsługuje również kopiowanie tego pliku z kontenera, kopiowanie go z powrotem lub montowanie go z hosta za pomocą bindowania. Różnice dotyczą wszystkiego, co go otacza: zmiennych środowiskowych Dockera, montowania bindowania, kluczy WOPI, zakończenia TLS i konfiguracji odwrotnego proxy.

Ten przewodnik przedstawia konserwatywny proces tworzenia kopii zapasowych i przywracania danych zarówno dla instalacji pakietów natywnych, jak i wdrożeń Dockera. Celowo oddziela on to, co potwierdza dokumentacja Collabora, od tego, co zależy od Twojego własnego wdrożenia.

Co powinna zawierać kopia zapasowa kodu Collabora?

Zweryfikowany: /etc/coolwsd/coolwsd.xml to główny plik konfiguracyjny Collabora Online. Collabora dokumentuje tę ścieżkę bezpośrednio i opisuje plik jako samodokumentujący dostępne opcje serwera. Zobacz oficjalny podręcznik zestawu SDK Collabora Online .

Zależne od wdrożenia: pełne odzyskiwanie może również wymagać konfiguracji użytej do uruchomienia usługi. W przypadku Dockera może to obejmować Compose YAML, zmienne środowiskowe, montowania powiązań, sekrety i pliki montowane z hosta. W przypadku instalacji natywnej może to obejmować wirtualnego hosta z odwrotnym serwerem proxy i certyfikaty, jeśli są one zarządzane na tym samym serwerze.

Działanie: przed utworzeniem archiwum zanotuj, czy Twoja instancja to instalacja natywna pakietu, czy wdrożenie Docker/Compose. Nie zakładaj, że ta sama procedura przywracania dotyczy obu.

Typowe nieporozumienia przed rozpoczęciem

Tworzenie kopii zapasowej pliku coolwsd.xml nie powoduje utworzenia kopii zapasowej dokumentów użytkownika

CODE jest zazwyczaj połączony z platformą pamięci masowej za pośrednictwem WOPI. Dokumenty pozostają pod kontrolą tej platformy pamięci masowej, takiej jak NextCloud lub inny host WOPI. Przywrócenie konfiguracji CODE nie powoduje przywrócenia samych dokumentów.

Działanie: utwórz kopię zapasową hosta WOPI i jego magazynu danych, korzystając z procedury tworzenia kopii zapasowych danego produktu. Traktuj tę kopię zapasową KODU jako kopię zapasową konfiguracji usługi.

Kontener Docker nie jest kopią zapasową

Kontener można odtworzyć z obrazu. Konfiguracja przekazana za pomocą zmiennych środowiskowych lub montowań powiązań może znajdować się poza kontenerem, a zmiany wprowadzone tylko wewnątrz kontenera mogą zniknąć po jego wymianie.

Działanie: zapisz definicję wdrożenia i pliki zamontowane na hoście, a nie tylko system plików kontenera.

Kopiowanie starego pliku coolwsd.xml na nowszą wersję nie zawsze jest najbezpieczniejszym sposobem przywrócenia

Opcje konfiguracji mogą się zmieniać między wersjami CODE. Aktualne informacje o wydaniu Collabora pokazują ciągłe zmiany w serwerze i serwerze proxy w serii 26.04, w tym zaktualizowane zalecenia dotyczące serwera proxy dla kompaktowego adresu URL WebSocket. Zobacz oficjalne informacje o wydaniu CODE 26.04 .

Działanie: zapisuj wersję KODU przy każdej kopii zapasowej. Podczas przywracania do innej wersji, porównaj zapisany plik z domyślną wersją nowego pakietu przed jego całkowitą zamianą.

Krok 1: Zapisz zainstalowaną wersję i typ wdrożenia

Zacznij od zarejestrowania wystarczającej ilości informacji, aby odtworzyć środowisko. W przypadku wdrożenia kontenera sprawdź działający kontener i jego obraz:

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

Jeśli kontener używa innej nazwy, należy ją collaboraodpowiednio zmienić. Oficjalny obraz jest opublikowany jako collabora/code; Docker Hub obecnie identyfikuje obraz 26.04.4.2 w najnowszej wersji. Zobacz oficjalny obraz Collabora CODE w Docker Hub .

W przypadku instalacji pakietu natywnego zapisz wersję pakietu w menedżerze pakietów, którego faktycznie używasz. Na przykład w systemie Debian lub Ubuntu:

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

Działanie: zapisz wynikową wersję w tym samym chronionym katalogu kopii zapasowej, w którym znajduje się archiwum konfiguracji.

Krok 2: Utwórz kopię zapasową konfiguracji głównej i metadanych wdrożenia

Instalacja pakietu natywnego

Utwórz katalog kopii zapasowej tylko dla użytkownika root i zarchiwizuj cały /etc/coolwsdkatalog, zamiast wybierać tylko główny plik XML. Dzięki temu zachowasz wszystkie dodatkowe pliki, które umieściłeś w tym katalogu zainstalowanym pakietem lub dostosowaną lokalnie wersją.

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

To polecenie celowo zmienia się na /etcbefore archiwization, dzięki czemu archiwum zawiera coolwsd/ścieżkę względną zamiast bezwzględnej ścieżki do systemu plików.

Docker lub Docker Compose

W dokumentacji Collabora podano, że oficjalny obraz zawiera plik /etc/coolwsd/coolwsd.xmli administratorzy mogą go skopiować, zmodyfikować, skopiować z powrotem lub zamontować spoza kontenera.

Jeśli plik nie jest jeszcze zamontowany na hoście, skopiuj go:

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

Następnie przechwyć, jak został skonfigurowany kontener:

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

Ważne: dane wyjściowe środowiska mogą zawierać hasła, dane uwierzytelniające do konsoli administratora, nazwy hostów lub inne poufne informacje. Pliki te należy przechowywać wyłącznie w trybie do odczytu przez użytkownika root i szyfrować lub w inny sposób chronić kopie poza hostem.

Jeśli korzystasz z Docker Compose, skopiuj plik Compose oraz wszelkie pliki środowiskowe i tajne, do których się odwołujesz, z hosta. Ich lokalizacje są specyficzne dla danego wdrożenia, więc nie ma uniwersalnej ścieżki, którą można bezpiecznie założyć.

Działanie: sprawdź, czy kopia zapasowa zawiera źródło danych. Jeśli coolwsd.xmljest zamontowana metodą bind-mount, utwórz kopię zapasową pliku hosta. Jeśli konfiguracja jest dostarczana za pomocą zmiennych środowiskowych, zachowaj konfigurację Compose/Run, która definiuje te zmienne.

Krok 3: Dołącz klucze testowe, konfigurację serwera proxy i protokół TLS tylko wtedy, gdy mają zastosowanie

Elementy te są istotne właśnie dlatego, że nie są identyczne w każdej instalacji.

Klucz dowodu WOPI: Collabora dokumentuje, że instalacje RPM i DEB automatycznie generują parę kluczy dowodu WOPI. W przypadku Dockera para kluczy nie jest dostarczana w obrazie publicznym; w przypadku użycia musi zostać wygenerowana i dostarczona do kontenera, zazwyczaj za pośrednictwem woluminu. Instrukcja zawiera dokumentację coolconfig generate-proof-keydotyczącą generowania klucza. Ponieważ klucz Dockera znajduje się poza niezmiennym obrazem, utrata zamontowanego klucza po stronie hosta może zmienić tożsamość używaną do podpisywania dowodu WOPI.

Działanie: użyj listy montowań kontenera, aby zidentyfikować lokalizację hosta dowolnego montowania z kluczem dowodowym i bezpiecznie utworzyć kopię zapasową tego pliku lub katalogu po stronie hosta. Nie wymyślaj ścieżki, jeśli Twoje wdrożenie jej nie używa.

Odwrotny serwer proxy: Apache, Nginx, HAProxy, Traefik lub inny serwer proxy może przechowywać publiczną nazwę hosta, zakończenie TLS, routing WebSocket i reguły przekazywania żądań. W CODE 26.04 firma Collabora zaktualizowała wytyczne dotyczące serwera proxy dla nowszego, kompaktowego adresu URL WebSocket, zachowując jednocześnie w niektórych przypadkach starszą wersję zapasową.

Działanie: utwórz kopię zapasową dokładnej konfiguracji serwera proxy obsługującej nazwę hosta Collabora. Ścieżka do systemu plików zależy od systemu operacyjnego i serwera proxy, dlatego zidentyfikuj ją na podstawie aktywnej konfiguracji serwera proxy, zamiast kopiować ogólną ścieżkę z samouczka.

Certyfikaty TLS: twórz ich kopie zapasowe tylko wtedy, gdy dany host faktycznie jest ich właścicielem. Jeśli TLS zostanie zakończony na module równoważenia obciążenia, kontrolerze wejściowym, CDN lub oddzielnym odwrotnym serwerze proxy, kopia zapasowa certyfikatu powinna tam zostać umieszczona.

Krok 4: Zweryfikuj kopię zapasową przed jej potrzebą

Samo udane tarpolecenie nie wystarczy. Sprawdź, czy archiwum można wyświetlić i czy oczekiwany główny plik konfiguracyjny jest obecny.

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

Utwórz sumę kontrolną do weryfikacji poza hostem:

cd /var/backups/collabora
sha256sum * > SHA256SUMS

Następnie skopiuj kopię zapasową do drugiej chronionej lokalizacji, używając swojego standardowego systemu kopii zapasowych. Nie pozostawiaj jedynej kopii na tym samym hoście, który chronisz.

Działanie: przetestuj ekstrakcję do katalogu tymczasowego przynajmniej raz. Kopia zapasowa, której nigdy nie otwierałeś, to tylko założenie.

Krok 5: Przywróć konserwatywnie, a następnie sprawdź poprawność uruchomionej usługi

Przywróć natywną instalację

Lepiej najpierw zainstalować tę samą wersję CODE. Zatrzymaj usługę, rozpakuj archiwum do katalogu przejściowego i porównaj zapisaną konfigurację z nowo zainstalowaną konfiguracją domyślną:

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

Jeżeli wersje są takie same i zamierzasz dokonać całkowitej wymiany, najpierw zachowaj nowy katalog jako kopię zapasową:

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

Jeśli wersje się różnią, scal faktycznie zmienione ustawienia, zamiast bezmyślnie zastępować nowy plik. Pozwoli to uniknąć odrzucania nowych ustawień domyślnych lub wymaganych elementów wprowadzonych w nowszej wersji.

Przywracanie wdrożenia Dockera

Utwórz ponownie kontener z zarejestrowanej wersji obrazu i oryginalnego Docker Compose lub docker rundefinicji. Przywróć konfigurację zamontowaną na hoście, klucze testowe i inne pliki zewnętrzne do ich oryginalnych ścieżek hosta przed uruchomieniem kontenera.

Jeśli celowo zachowałeś coolwsd.xmlplik w kontenerze, a nie jako montowanie powiązania, udokumentowane podejście Collabora pozwala na skopiowanie pliku z powrotem. W praktyce, montowanie powiązania hosta jest łatwiejsze do odtworzenia, ponieważ konfiguracja przetrwa wymianę kontenera.

Działanie: najpierw przywróć definicję wdrożenia, a następnie przywróć pliki, do których się ona odwołuje. Dzięki temu zmienne środowiskowe, woluminy i konfiguracja XML będą spójne.

Jak sprawdzić, czy przywrócenie faktycznie zadziałało

Nie oceniaj sukcesu tylko na podstawie tego, czy proces się uruchomił. Sprawdź usługę z tej samej ścieżki sieciowej, z której korzystają klienci.

W przypadku instalacji natywnej:

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

Dla Dockera:

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

Collabora dokumentuje /hosting/capabilitiespunkt końcowy, aby między innymi pobrać nazwę i wersję uruchomionego produktu. Przetestuj go za pomocą publicznego adresu URL Collabora:

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

Zastąp nazwę hosta własną. Otwórz również prawdziwy dokument z hosta WOPI i sprawdź, czy edycja, zapisywanie i ponowne łączenie działają przez standardową ścieżkę odwrotnego proxy.

Działanie: uznaj przywracanie za zakończone dopiero po otrzymaniu odpowiedzi z punktu końcowego możliwości oraz możliwości otwarcia i zapisania dokumentu.

Praktyczna lista kontrolna kopii zapasowych

Ostateczna rekomendacja

Najbardziej niezawodny plan odzyskiwania kodu Collabora CODE to nie pojedynczy skopiowany plik. Zachowaj coolwsd.xmldokładną wersję kodu CODE i definicję wdrożenia jako jeden odzyskiwalny zestaw. Dodawaj klucze testowe, reguły proxy i materiały TLS tylko tam, gdzie Twoja architektura faktycznie ich używa. W przypadku aktualizacji, w miarę możliwości przywróć do tej samej wersji; jeśli migrujesz do nowszej wersji, porównaj i scal konfigurację, zamiast nadpisywać nowe ustawienia domyślne bez przeglądu.

Na dzień 6 października 2026 r., CODE 26.04.4.2 to aktualna wersja, o której mowa w oficjalnych informacjach o wydaniu 26.04 firmy Collabora oraz metadanych obrazu Docker. Przed przyszłą migracją należy ponownie sprawdzić te oficjalne źródła, ponieważ wersje obrazów, rekomendacje dotyczące serwerów proxy i opcje konfiguracji stale ewoluują.