Jak hostować Duplicati samodzielnie w 2026 roku: szyfrowane backupy, mounty i testy odtwarzania

Jeśli próbujesz już hostować Duplicati samodzielnie, prawdopodobnie znasz ten frustrujący scenariusz: UI się wyświetla, ale kontener widzi pustą ścieżkę, ponieważ źródła z hosta zostały zamontowane w innym miejscu. Ponowne utworzenie kontenera rzadko rozwiązuje niezgodność między URL-ami, stanem i zależnościami.

W tym przewodniku przyjmujemy jedno konkretne kryterium ukończenia — wykonanie backupu testowego katalogu do wybranego miejsca docelowego, usunięcie pliku źródłowego i odtworzenie go do czystej alternatywnej ścieżki. Każda decyzja konfiguracyjna jest oceniana względem tego kryterium, a nie na podstawie zielonej plakietki kontenera.

Porty, procesy i usługi prywatne

Przydatny diagram Duplicati pokazuje publiczną trasę, prywatny port 8200, granicę stanu oraz wszystkie wymagane elementy pomocnicze. Zaznacz, które strzałki przenoszą dane uwierzytelniające, a które zwykły ruch użytkowników. Kontrakt sieciowy dla Duplicati obejmuje mounty źródeł tylko do odczytu oraz osiągalny storage miejsca docelowego backupu. Prywatne endpointy utrzymuj w wewnętrznym DNS, zezwalaj wyłącznie na wymagane połączenia wychodzące i nadaj Duplicati ograniczone uprawnienia konta serwisowego.

Potwierdź diagram jednym rzeczywistym działaniem: wykonaj backup testowego katalogu do wybranego miejsca docelowego, usuń plik źródłowy i odtwórz go do czystej alternatywnej ścieżki. Największe obciążenie prawdopodobnie wynika z liczby plików źródłowych, kompresji, szyfrowania, opóźnienia miejsca docelowego oraz nakładania się zaplanowanych zadań; monitoruj tę ścieżkę zamiast traktować wszystkie żądania HTTP jednakowo.

Diagnozowanie Duplicati, który wygląda na sprawny

Zbuduj dashboardy wokół liczby plików źródłowych, kompresji, szyfrowania, opóźnienia miejsca docelowego oraz nakładania się zaplanowanych zadań. Wykres CPU bez kontekstu obciążenia nie wyjaśni, dlaczego Duplicati działa wolno. Dodaj synthetic check lub zaplanowane sprawdzenie, które próbuje wykonać backup testowego katalogu do wybranego miejsca docelowego, usunąć plik źródłowy i odtworzyć go do czystej alternatywnej ścieżki przy użyciu nieszkodliwych danych testowych.

Przed aktualizacją uwzględnij zagrożenie charakterystyczne dla tej aplikacji: zmiany w bazie konfiguracji Duplicati i formacie backupu należy testować bez nadpisywania jedynego zdalnego zestawu backupów. Odtwórz ostatni backup w odizolowanym wdrożeniu, uruchom tam migracje i porównaj działanie. Jeśli kontener widzi pustą ścieżkę, ponieważ źródła z hosta zostały zamontowane w innym miejscu, sprawdź odpowiednią granicę — publiczne origin, storage lub zależność — zanim zmienisz niezwiązane ustawienia.

Co musi przejść, zanim pojawią się rzeczywiste dane Duplicati

Rejestr wydania dla Duplicati powinien zawierać fakty, a nie informację „wygląda dobrze”. Zapisz digest wybranego obrazu, checksum konfiguracji, publiczny hostname oraz oznaczony timestampem wynik dla operacji: wykonanie backupu testowego katalogu do wybranego miejsca docelowego, usunięcie pliku źródłowego i odtworzenie go do czystej alternatywnej ścieżki. Używaj nieprodukcyjnych przykładowych danych, aby test można było uruchamiać po każdym wdrożeniu.

Zweryfikuj osobno dwa zdarzenia cyklu życia. Zastąpienie kontenera musi zachować normalne działanie; pełne odtworzenie musi wykazać, że nowa instancja Duplicati może zaimportować konfigurację i odtworzyć wybrane pliki ze zweryfikowanymi hashami. Podczas testów mierz liczbę plików źródłowych, kompresję, szyfrowanie, opóźnienie miejsca docelowego oraz nakładanie się zaplanowanych zadań, a wynik zachowaj jako oczekiwany zakres dla tej wersji.

Przetestuj również warunek odmowy lub nieprawidłowego działania: tymczasowo odbierz testowej tożsamości dostęp do mountów źródeł tylko do odczytu oraz osiągalnego storage miejsca docelowego backupu. Duplicati powinien zakończyć działanie w sposób możliwy do zdiagnozowania i nie powinien nadpisać poprawnego stanu. Przywróć prawidłowy warunek, ponownie uruchom test i dołącz odpowiednie zanonimizowane logi. Te artefakty dostarczą konkretnych dowodów potrzebnych przy podejmowaniu przyszłej decyzji o rollbacku.

Przekształcenie lokalnego polecenia w usługę, którą można kontrolować

Poniższe polecenie uwidacznia granicę kontenera bez udawania, że konfiguruje wszystkie zewnętrzne usługi.

docker run -d \
  --name duplicati \
  --restart unless-stopped \
  -p 127.0.0.1:8200:8200 \
  -v duplicati-data:/config \
  -v /srv/data:/source:ro \
  -e SETTINGS_ENCRYPTION_KEY=replace-with-a-long-random-value \
  lscr.io/linuxserver/duplicati:latest

Przed otwarciem ingress sprawdź rozstrzygnięte zmienne środowiskowe, mounty i listener. Dodaj zweryfikowane ustawienia połączeń dla mountów źródeł tylko do odczytu oraz osiągalnego storage miejsca docelowego backupu; używaj prywatnych nazw dla prywatnych usług. Pomyślne uruchomienie kończy się dopiero wtedy, gdy możesz wykonać backup testowego katalogu do wybranego miejsca docelowego, usunąć plik źródłowy i odtworzyć go do czystej alternatywnej ścieżki — nie wtedy, gdy docker ps wyświetla Up.

Mierzalne odtwarzanie Duplicati

Przed utworzeniem pierwszego rzeczywistego rekordu spisz stan: bazę konfiguracji Duplicati oraz osobno zweryfikowane zestawy backupów. Zamontuj /config przed bootstrapem, zapisz nieszkodliwe dane przykładowe i zastąp kontener, aby potwierdzić, że ta ścieżka rzeczywiście jest trwała. Potwierdź mount, zapisując nieszkodliwe dane, zastępując Duplicati i odczytując je ponownie.

Snapshoty są przydatne do szybkiego rollbacku, ale potrzebny jest niezależny backup na wypadek utraty hosta lub volume. Odtwórz dane w pustym środowisku przy użyciu przypiętego obrazu i sprawdź, czy nowa instancja Duplicati może zaimportować konfigurację oraz odtworzyć wybrane pliki ze zweryfikowanymi hashami. Skorzystaj z persistent volumes and snapshots, aby zachować rozdzielność tych dwóch mechanizmów odtwarzania.

TLS jest proste, ale generowane URL-e już nie

Udostępnij Duplicati pod jednym hostem HTTPS, a surowy port 8200 pozostaw prywatny. Prywatny interfejs zarządzania lub silne uwierzytelnianie udostępniaj za pośrednictwem HTTPS. Dzięki temu przeglądarki i klienci API nie poznają dwóch konkurencyjnych adresów.

Z czystego klienta uruchom sprawdzoną transakcję i przeanalizuj pierwsze żądanie, które kończy się błędem. Jeśli problem dotyczy DNS lub TLS, skorzystaj z custom-domain guide. Traktuj komunikat „kontener widzi pustą ścieżkę, ponieważ źródła z hosta zostały zamontowane w innym miejscu” jako osobną diagnozę aplikacji dopiero po potwierdzeniu poprawności trasy.

Zabezpieczenie Duplicati po bootstrapie

Dane uwierzytelniające używane podczas bootstrappingu są tymczasowe, ale model zaufania pozostaje na stałe. W przypadku Duplicati zwróć uwagę na montowanie źródeł backupu z prawem zapisu oraz na ryzyko utraty passphrase szyfrowania; montuj źródła tylko do odczytu, utrzymuj prywatny interfejs zarządzania i przechowuj passphrase backupu poza serwerem.

Wygeneruj SETTINGS_ENCRYPTION_KEY jeden raz, nie przechowuj go w Git i zachowaj go razem z manifestem odtwarzania, ponieważ jego zmiana może unieważnić zaszyfrowany lub podpisany stan aplikacji. Uruchamiaj obraz bez niepotrzebnych capabilities systemu Linux i udostępniaj wyłącznie publiczną trasę aplikacji. Zapewnij widoczność działań administratorów bez rejestrowania wartości sekretów.

Użycie Dockup w warstwie platformy

W przypadku Duplicati Dockup może utworzyć trasę i certyfikat TLS, zachować mounty, dostarczać sekrety oraz umieścić mounty źródeł tylko do odczytu i osiągalny storage miejsca docelowego backupu w prywatnej sieci, wdrażając usługę w Dockup lub na podłączonych serwerach.

Bramką wydania nadal jest konkretna transakcja Duplicati: wykonanie backupu testowego katalogu do wybranego miejsca docelowego, usunięcie pliku źródłowego i odtworzenie go do czystej alternatywnej ścieżki. Sprawdź również warunek odtwarzania — nowa instancja Duplicati może zaimportować konfigurację i odtworzyć wybrane pliki ze zweryfikowanymi hashami. Te dwa testy pokazują, czy wdrożenie działa i czy można je odtworzyć.

Najczęściej zadawane pytania

Czego Duplicati potrzebuje do wdrożenia produkcyjnego?

Skieruj kontener Duplicati na porcie 8200 przez jeden origin HTTPS. Wymaganie dotyczące sieci pomocniczej obejmuje mounty źródeł tylko do odczytu oraz osiągalny storage miejsca docelowego backupu. Nie uznawaj Duplicati za gotowe, dopóki nie możesz wykonać backupu testowego katalogu do wybranego miejsca docelowego, usunąć pliku źródłowego i odtworzyć go do czystej alternatywnej ścieżki.

Które dane Duplicati powinny należeć do backupu?

Utrwal /config i uwzględnij bazę konfiguracji Duplicati oraz osobno zweryfikowane zestawy backupów w tym samym manifeście odtwarzania. Odtworzenie Duplicati w czystym środowisku można uznać za udane tylko wtedy, gdy nowa instancja Duplicati może zaimportować konfigurację i odtworzyć wybrane pliki ze zweryfikowanymi hashami.

Czy Duplicati wymaga HTTPS za reverse proxy?

Używaj HTTPS dla publicznego origin Duplicati, a port 8200 pozostaw na wewnętrznej trasie. Zastosuj prawidłowo ustawienie Duplicati: utrzymuj prywatny interfejs zarządzania lub silne uwierzytelnianie za HTTPS. W przypadku Duplicati HTTPS chroni dane uwierzytelniające lub treści użytkowników podczas transmisji i zapewnia spójne działanie klienta zależne od origin.

Jak testować aktualizację Duplicati?

Odtwórz bieżący stan Duplicati w odizolowanym wdrożeniu, zastosuj wersję kandydującą i ponownie wykonaj transakcję akceptacyjną. Zwróć szczególną uwagę na to, że zmiany w bazie konfiguracji Duplicati i formacie backupu należy testować bez nadpisywania jedynego zdalnego zestawu backupów. Zachowaj poprzedni obraz Duplicati, dopóki granice migracji danych i rollbacku nie będą zrozumiałe.