Nextcloud na VPS z Docker Compose: konfiguracja i backup

Co faktycznie budujesz

Ten przewodnik uruchamia Nextcloud na VPS przy użyciu Docker Compose, umieszcza przed nim szyfrowanie TLS od Let's Encrypt oraz konfiguruje kopię zapasową, która faktycznie umożliwia przywrócenie danych. Całość składa się z czterech kontenerów i proxy: oficjalnego obrazu nextcloud nasłuchującego na interfejsie loopback, bazy Postgres przechowującej wszystkie metadane plików, Redis obsługującego blokady plików, drugiej kopii obrazu Nextcloud uruchomionej wyłącznie w celu obsługi pętli cron oraz serwera nginx na hoście, który kończy połączenia TLS przed całą resztą. Sama instalacja zajmuje dwadzieścia minut i nie ona jest najważniejsza. Dwie decyzje podjęte w pierwszej godzinie decydują o tym, czy za rok nadal będziesz mieć swoje pliki: wybór prawdziwej bazy danych zamiast SQLite oraz kopia zapasowa, która obejmuje katalog danych, bazę danych i config.php jako jeden spójny zestaw.

Zakłada się, że używasz Ubuntu 24.04 LTS lub Debian 13, Docker Engine z wtyczką Compose v2 zainstalowaną z oficjalnego repozytorium Docker oraz że rekord DNS A (oraz AAAA, jeśli posiadasz IPv6) już wskazuje cloud.example.com na Twój serwer VPS. Wszystko to wymaga serwera, nad którym masz pełną kontrolę; nie ma możliwości przeprowadzenia terminacji TLS i zrzutu bazy danych w ramach cudzej usługi SaaS.

Dobór rozmiaru: co faktycznie zużywa pamięć

Zużycie pamięci przez Nextcloud zależy głównie od trzech czynników, z których żaden nie jest bezpośrednio samym oprogramowaniem Nextcloud.

Procesy robocze PHP. Obraz -apache obsługuje każde równoległe żądanie za pomocą procesu roboczego, który utrzymuje interpreter PHP. Każdy proces może urosnąć do PHP_MEMORY_LIMIT, zanim PHP przerwie żądanie. W najgorszym przypadku rezydentne zużycie pamięci to w przybliżeniu liczba równoległych żądań × limit pamięci, a klient synchronizacji na komputerze otwiera kilka połączeń jednocześnie na użytkownika. To współbieżność, a nie liczba użytkowników, wyznacza górny limit.

Baza danych. Postgres tworzy proces potomny dla każdego połączenia i utrzymuje współdzielone bufory w pamięci. Zestaw roboczy skaluje się wraz z liczbą plików, a nie liczbą bajtów: oc_filecache przechowuje wiersz dla każdego pliku każdego użytkownika. Sto tysięcy małych plików obciąża bazę danych bardziej niż sto dużych.

Generowanie podglądów. Generowanie miniatury wymaga zdekodowania obrazu źródłowego do pamięci w pełnej rozdzielczości. Podglądy wideo wywołują ffmpeg. Uruchomienie occ preview:generate-all powoduje powtarzanie tego procesu w krótkich odstępach czasu i jest najczęstszą przyczyną wywołania mechanizmu OOM killer na małych serwerach VPS.

Redis jest stosunkowo tani w utrzymaniu. Każdy dodatkowy komponent, taki jak Collabora, wyszukiwanie pełnotekstowe czy skaner antywirusowy, jest osobną usługą rezydentną z własnym zapotrzebowaniem na zasoby i powinien zostać uwzględniony w planie doboru rozmiaru przed jego włączeniem.

Dźwignie, z których można skorzystać przy ograniczonej pamięci RAM: obniżenie PHP_MEMORY_LIMIT, ograniczenie preview_max_x / preview_max_y / preview_max_filesize_image, ograniczenie enabledPreviewProviders do formatów faktycznie przeglądanych oraz ustawienie trashbin_retention_obligation i versions_retention_obligation, aby katalog danych nie rozrastał się w sposób niekontrolowany do rozmiarów kilkukrotnie przekraczających sumę plików. Należy dodać plik wymiany (swap). Swap jest wolny, ale przerwanie procesu przez OOM killer w trakcie aktualizacji jest gorsze.

Dlaczego SQLite powoduje awarie

Nextcloud jest dostarczany z obsługą SQLite, a oficjalny obraz kontenera domyślnie z niej korzysta. Nie należy tego robić. SQLite szereguje operacje zapisu za pomocą blokady obejmującej całą bazę danych: w danej chwili tylko jeden proces może zapisywać do pliku. Nextcloud zapisuje dane w sposób ciągły: blokady plików, wiersze aktywności, wpisy w pamięci podręcznej, stan zadań, a pojedynczy klient desktopowy synchronizujący drzewo katalogów generuje wiele równoległych żądań. W takim modelu pracy pojawiają się błędy SQLSTATE[HY000]: General error: 5 database is locked oraz kody HTTP 500, a awaria występuje dokładnie w momencie, gdy instancja zaczyna być użyteczna.

Późniejsza konwersja jest możliwa za pomocą occ db:convert-type, jednak jest to długotrwała migracja typu „wszystko albo nic” na działającym zbiorze danych. Należy rozpocząć od Postgres lub MariaDB.

Plik Compose

Umieść go w /srv/nextcloud/compose.yaml, a sekrety w pliku .env znajdującym się w tym samym katalogu, z uprawnieniami 600.

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: redis-server --requirepass ${REDIS_PASSWORD}

  app:
    image: nextcloud:31-apache
    restart: unless-stopped
    depends_on: [db, redis]
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - html:/var/www/html
      - /srv/nextcloud/data:/var/www/html/data
    environment:
      POSTGRES_HOST: db
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      REDIS_HOST: redis
      REDIS_HOST_PASSWORD: ${REDIS_PASSWORD}
      NEXTCLOUD_ADMIN_USER: admin
      NEXTCLOUD_ADMIN_PASSWORD: ${ADMIN_PASSWORD}
      NEXTCLOUD_TRUSTED_DOMAINS: cloud.example.com
      TRUSTED_PROXIES: 172.16.0.0/12
      OVERWRITEPROTOCOL: https
      OVERWRITECLIURL: https://cloud.example.com
      APACHE_DISABLE_REWRITE_IP: "1"
      PHP_MEMORY_LIMIT: 512M
      PHP_UPLOAD_LIMIT: 10G

  cron:
    image: nextcloud:31-apache
    restart: unless-stopped
    entrypoint: /cron.sh
    depends_on: [db, redis]
    volumes:
      - html:/var/www/html
      - /srv/nextcloud/data:/var/www/html/data

volumes:
  db:
  html:

Przypnij główną wersję tagu i sprawdź aktualną na Docker Hub przed skopiowaniem 31 w niezmienionej formie. latest spowoduje przejście na nową główną wersję przy przyszłym docker compose pull, czego Nextcloud nie obsługuje.

Katalog danych jest celowo zamontowany jako bind mount, a nie nazwany wolumen: ścieżka, do której można bezpośrednio skierować narzędzie do kopii zapasowych, jest cenniejsza niż porządek. Utwórz go z UID www-data używanym przez obraz i uprawnieniami wymaganymi przez Nextcloud:

sudo mkdir -p /srv/nextcloud/data
sudo chown -R 33:33 /srv/nextcloud/data
sudo chmod 0770 /srv/nextcloud/data

Zwróć uwagę na publikację portu: 127.0.0.1:8080:80. Docker publikuje porty poprzez zapisywanie reguł DNAT, które są przetwarzane, zanim łańcuch INPUT w ufw otrzyma pakiet. Zwykłe 8080:80 wystawia niezaszyfrowany Nextcloud na publiczny dostęp do Internetu, niezależnie od ustawień ufw. Powiązanie z interfejsem loopback izoluje usługę od publicznego interfejsu. Wtedy firewall musi jedynie zezwolić na ruch z proxy. Jeśli wolisz nie pozostawiać portu 22 otwartego na cały Internet, uzyskanie dostępu do VPS przez własny serwer WireGuard VPN pozwala na całkowite usunięcie portu 22 z publicznych reguł:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Uruchom usługę za pomocą docker compose up -d, a następnie monitoruj docker compose logs -f app. Pierwsze uruchomienie kopiuje całe drzewo aplikacji do wolumenu i wykonuje instalator; kontener nie odpowiada na żadne żądania, dopóki proces ten się nie zakończy.

TLS i reverse proxy

Zainstaluj nginx oraz certbot z repozytoriów dystrybucji, utwórz standardowy blok serwera na porcie 80 z odpowiednim server_name, a następnie pozwól certbot na jego nadpisanie. Mechanika wyzwania HTTP-01, timer odnawiania oraz tryby awarii zostały szczegółowo opisane w wydawanie certyfikatów Let's Encrypt za pomocą certbot i nginx na Ubuntu 24.04:

sudo apt install nginx certbot python3-certbot-nginx
sudo certbot --nginx -d cloud.example.com

Certbot dodaje linie ssl_certificate oraz przekierowanie :80 → :443, a także instaluje timer systemd, który odnawia 90-dniowy certyfikat. Potwierdź jego istnienie za pomocą systemctl list-timers | grep certbot; timer odnawiania, który nie został włączony, stanowi 90-dniowy bezpiecznik.

Sam blok proxy:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name cloud.example.com;

    # certbot manages ssl_certificate / ssl_certificate_key here

    add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;

    client_max_body_size 10G;
    client_body_timeout 300s;

    location = /.well-known/carddav { return 301 /remote.php/dav; }
    location = /.well-known/caldav  { return 301 /remote.php/dav; }

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host  $host;
        proxy_request_buffering off;
        proxy_buffering off;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

W nginx 1.25 i nowszych dodaj http2 on;. Ubuntu 24.04 dostarcza starszą wersję, w której odpowiednikiem jest listen 443 ssl http2;. Polecenie nginx -t wskaże, którą opcję akceptuje Twoja kompilacja.

client_max_body_size oraz długie limity czasu odczytu zapobiegają przerywaniu dużych wysyłek plików w trakcie ich trwania. proxy_request_buffering off przesyła dane strumieniowo, zamiast najpierw zapisywać cały plik na dysku proxy.

nginx na hoście to najprostsze rozwiązanie dla jednej aplikacji. Jeśli Nextcloud ma współdzielić VPS z innymi kontenerami, uruchomienie Traefik jako reverse proxy w Docker Compose dla wielu aplikacji przenosi routing i wydawanie certyfikatów do etykiet kontenerów, a te same kwestie dotyczące client_max_body_size oraz limitów czasu pojawiają się tam jako ustawienia middleware i transportu.

trusted_proxies oraz overwriteprotocol

W tym miejscu popełniana jest większość błędów przy samodzielnym hostowaniu instancji Nextcloud, a objawy wydają się niezwiązane z przyczyną.

Parametr X-Forwarded-Proto: https jest uwzględniany tylko wtedy, gdy żądanie pochodzi z adresu wymienionego w trusted_proxies. Gdy nie jest uwzględniany, Nextcloud uznaje żądanie za zwykłe HTTP i generuje adresy URL typu http://; proxy przekierowuje je na HTTPS; przeglądarka podąża za przekierowaniem; Nextcloud ponownie generuje http://. Tak powstaje pętla przekierowań. Parametr OVERWRITEPROTOCOL: https wymusza schemat niezależnie od okoliczności.

Pułapka w TRUSTED_PROXIES polega na tym, że adres, który widzi Nextcloud, to nie 127.0.0.1. Serwer nginx działa na hoście i łączy się z opublikowanym portem, więc kontener widzi bramę mostu Docker, czyli adres z zakresu 172.x. Należy ustalić właściwą podsieć:

docker network inspect nextcloud_default \
  -f '{{range .IPAM.Config}}{{.Subnet}}{{end}}'

Należy umieścić ten CIDR (lub obejmujący go 172.16.0.0/12) w TRUSTED_PROXIES. Zbyt szerokie ustawienie pozwoli każdemu klientowi na podszycie się pod X-Forwarded-For; błędne ustawienie sprawi, że każde logowanie będzie wyglądać na pochodzące z adresu bramy, mechanizm ochrony przed atakami brute-force zablokuje całą instancję naraz, a panel administracyjny wyświetli komunikat: "Konfiguracja nagłówka reverse proxy jest nieprawidłowa lub uzyskujesz dostęp do Nextcloud przez zaufane proxy."

Parametr OVERWRITECLIURL ma znaczenie dla kontenera cron, który nie otrzymuje żądań przychodzących, na podstawie których mógłby wywnioskować nazwę hosta. Bez niego zadania w tle generują linki do localhost, a powiadomienia e-mail zawierają nieużywalne adresy URL.

Zadania w tle: cron zamiast AJAX

Domyślnym mechanizmem uruchamiania zadań w Nextcloud jest AJAX: zadania wykonują się jako efekt uboczny ładowania strony przez użytkownika. Nikt nie przegląda plików o godzinie 04:00, więc usuwanie niepotrzebnych danych, czyszczenie wersji, generowanie podglądów oraz ponawianie prób federacyjnych zostaje wstrzymane. Pierwszym objawem jest nieustanny wzrost rozmiaru katalogu z danymi. Usługa cron opisana powyżej uruchamia oficjalną pętlę /cron.sh w tych samych wolumenach. Należy poinformować Nextcloud, aby korzystał z tego rozwiązania:

docker compose exec -u www-data app php occ background:cron

Każde polecenie occ ma następującą strukturę: docker compose exec -u www-data app php occ <command>. Warto utworzyć dla niego alias.

Kopie zapasowe: trzy elementy albo żadnego

Kopia zapasowa ograniczona wyłącznie do systemu plików przywraca uszkodzoną instancję. Katalog danych przechowuje bajty; Postgres przechowuje pamięć podręczną plików, udziały, użytkowników i stan aplikacji; config.php przechowuje poświadczenia bazy danych, identyfikator instancji oraz sól hasła. Przywrócenie plików bez bazy danych sprawia, że Nextcloud ich nie widzi. Przywrócenie bazy danych bez config.php uniemożliwia jej otwarcie. Przywrócenie starej bazy danych na nowszy katalog danych powoduje, że udziały wskazują na pliki, które zostały przeniesione.

Wykonaj kopię zapasową wszystkich trzech elementów z wyciszonej instancji:

#!/usr/bin/env bash
set -euo pipefail
cd /srv/nextcloud
DEST="/var/backups/nextcloud/$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$DEST"

occ() { docker compose exec -T -u www-data app php occ "$@"; }

occ maintenance:mode --on
trap 'occ maintenance:mode --off' EXIT

docker compose exec -T db \
  pg_dump -U nextcloud --clean --if-exists nextcloud | gzip > "$DEST/db.sql.gz"

docker compose exec -T app \
  tar -C /var/www/html -cf - config custom_apps themes > "$DEST/app.tar"

rsync -a --delete /srv/nextcloud/data/ /var/backups/nextcloud/data/

Tryb konserwacji (maintenance mode) zapewnia spójność między zrzutem bazy a kopią plików. Pominięcie tego kroku doprowadzi do sytuacji, w której baza danych odwołuje się do pliku, do którego rsync jeszcze nie dotarł. Skrypt przechowuje zrzuty bazy danych z sygnaturami czasowymi, ale tylko jedno bieżące lustro katalogu danych; rsync --delete nadpisuje je przy każdym uruchomieniu, więc tylko najnowszy zrzut jest zgodny z kopią plików.

Następnie przenieś dane poza serwer. Kopia zapasowa znajdująca się na tym samym VPS co źródło danych jest tylko kopią, a nie backupem. restic z wykorzystaniem pamięci obiektowej lub drugiego hosta jest standardowym rozwiązaniem, a deduplikacja radzi sobie z katalogiem danych znacznie lepiej niż nocne archiwum tar. Pełna konfiguracja, od inicjalizacji repozytorium po nocny timer i procedurę przywracania, znajduje się w kopie zapasowe VPS poza serwerem z użyciem restic.

Przywracanie nie jest prostym procesem odwrotnym. Świeżo uruchomiony stos wykonuje instalator i zapisuje zupełnie nowy config.php, nowy identyfikator instancji oraz sól hasła, a zaimportowanie zrzutu na taką nową tożsamość pozostawia uszkodzone sesje i tokeny udziałów. Najpierw przywróć starą tożsamość, zachowując następującą kolejność:

docker compose up -d && docker compose stop app cron    # create the volumes, then halt the app
sudo rsync -a --delete /var/backups/nextcloud/data/ /srv/nextcloud/data/
docker compose run --rm -T --entrypoint "" app \
  tar -C /var/www/html -xf - < app.tar                  # the original config.php returns
gunzip -c db.sql.gz | docker compose exec -T db psql -U nextcloud -d nextcloud
docker compose start app cron
docker compose exec -T -u www-data app php occ maintenance:mode --off
docker compose exec -T -u www-data app php occ files:scan --all

files:scan synchronizuje pamięć podręczną plików z tym, co faktycznie znajduje się na dysku. Przećwicz tę procedurę raz, na zapasowym VPS, zanim zajdzie taka potrzeba. Ten sam podział między bajtami na dysku a metadanymi w Postgres dotyczy każdej innej aplikacji o tej strukturze, dlatego kopia zapasowa Immich, która obejmuje bibliotekę, ale nie bazę danych, przywraca pustą oś czasu.

Aktualizacje: jedna główna wersja na raz

Nextcloud wspiera aktualizację dokładnie o jedną główną wersję w jednym kroku. Przeskok z 29 na 31 nie kończy się poprawnym działaniem, lecz błędem Exception: Updates between multiple major versions and downgrades are unsupported. i pozostawieniem instancji w trybie konserwacji (maintenance mode).

Aktualizacja w środowisku Docker przebiega następująco: wykonaj kopię zapasową, zmień tag z 31 na 32 w usługach app oraz cron, a następnie wykonaj docker compose pull && docker compose up -d i docker compose logs -f app. Punkt wejścia obrazu (entrypoint) wykrywa nowszy kod w odniesieniu do istniejących danych i samodzielnie uruchamia occ upgrade. Nie przerywaj tego procesu. Gdy logi przestaną generować wpisy, uruchom docker compose exec -u www-data app php occ status i sprawdź versionstring oraz to, czy aplikacje zostały ponownie włączone.

Dwie zasady, które chronią system: zwiększaj wersję o jeden stopień, weryfikuj poprawność, a następnie przejdź do kolejnej aktualizacji. Nigdy nie zmieniaj tagu w usłudze app bez jednoczesnej aktualizacji cron do tej samej wersji; używanie dwóch różnych wersji Nextcloud z jedną bazą danych prowadzi do uszkodzenia danych.

Błędy, które faktycznie wystąpią

"Your data directory is readable by other users. Please change the permissions to 0770." Katalog zamontowany przez bind mount posiada uprawnienia do odczytu dla grupy lub wszystkich użytkowników. Sprawdź sudo chmod 0770 /srv/nextcloud/data oraz sudo chown -R 33:33 /srv/nextcloud/data.

"Your data directory is invalid. Ensure there is a file called .ocdata in the root." Punkt montowania wskazuje na lokalizację, w której Nextcloud nigdy nie został zainicjowany, w ścieżce wystąpiła literówka lub pod działającą instancję podłożono nowy, pusty katalog. Sprawdź, czy ścieżka na hoście zgadza się z definicją wolumenu.

"Access through untrusted domain." Nazwa hosta w żądaniu nie znajduje się w trusted_domains. NEXTCLOUD_TRUSTED_DOMAINS ma zastosowanie tylko przy pierwszej instalacji; później należy edytować ustawienia na żywo: occ config:system:set trusted_domains 1 --value=cloud.example.com.

502 Bad Gateway, z błędem connect() failed (111: Connection refused) while connecting to upstream w /var/log/nginx/error.log. nginx nie uzyskał odpowiedzi na 127.0.0.1:8080. Kontener jest w trakcie inicjalizacji (sprawdź docker compose logs app), został zatrzymany (docker compose ps) lub port w sekcji publish nie zgadza się z portem proxy_pass. Potwierdź stan za pomocą ss -ltnp | grep 8080.

Pętla przekierowań lub ostrzeżenia o braku bezpieczeństwa w panelu administratora. Brakuje OVERWRITEPROTOCOL: https lub TRUSTED_PROXIES nie zawiera podsieci bramy Docker. Zobacz sekcję dotyczącą proxy powyżej.

LockedException: "files/..." is locked. Przy ustawionym REDIS_HOST obraz konfiguruje Redis jako backend blokad, co sprawia, że przestarzałe blokady występują rzadko. Bez tego blokady są przechowywane w tabeli bazy danych oc_file_locks, a żądanie przerwane w trakcie zapisu pozostawia w niej wiersze. Przed ręcznym usuwaniem wierszy blokad upewnij się, że Redis faktycznie działa; occ config:system:get memcache.locking powinno zwrócić klasę Redis.

"The PHP memory limit is below the recommended value of 512MB." Zwiększ PHP_MEMORY_LIMIT i utwórz kontener ponownie. Pamiętaj o wpływie tej zmiany na maksymalne zużycie zasobów w najgorszym scenariuszu.

Co ulega awarii przy dużej skali

Pierwszą barierą jest katalog danych, który przerasta wolumen. Zwiększenie wolumenu na VPS wymaga zmiany rozmiaru partycji oraz systemu plików; jest to znacznie mniej kłopotliwe, gdy zaplanuje się to wcześniej, niż przy 100% zapełnieniu. Należy monitorować użycie dysku teraz, a nie później.

Drugą barierą jest oc_filecache. Listowanie plików i skanowanie synchronizacji zwalnia wraz ze wzrostem liczby wierszy. Rozwiązaniem jest optymalizacja bazy danych: przechowuj Postgres na szybkim nośniku, zapewnij mu wystarczającą ilość pamięci współdzielonej oraz usuwaj zbędne dane i wersje za pomocą ustawień retencji, zamiast pozwalać im gromadzić się w nieskończoność.

Trzecią barierą jest generowanie podglądów, które konkuruje z innymi procesami. Na małym serwerze ogranicz liczbę dostawców podglądów i nigdy nie uruchamiaj occ preview:generate-all w godzinach pracy. Jeśli większość przechowywanych danych stanowią zdjęcia z telefonu, przetwarzanie miniatur powinno odbywać się na dedykowanym serwerze zdjęć. Artykuł porównanie PhotoPrism i Immich pod kątem RAM, aplikacji mobilnych i poleceń kopii zapasowych omawia koszty tych rozwiązań w porównaniu z instancją Nextcloud.

Poza tym, uczciwa odpowiedź brzmi: dodatkowe usługi wymagają własnej maszyny. Collabora i wyszukiwanie pełnotekstowe to osobne usługi rezydujące w pamięci, mające własne profile zużycia zasobów. Umieszczanie ich na serwerze, który przechowuje jedyną kopię plików, zwiększa domenę awarii bez żadnych korzyści. Jeśli edycja dokumentów w przeglądarce jest niezbędna, minimalne wymagania RAM i limity połączeń dla OnlyOffice oraz Collabora określają, co może obsłużyć VPS z 2 do 4 GB RAM. Przenieś przechowywanie plików do pamięci zgodnej z S3, gdy wolumen przestanie być odpowiedni. Pamiętaj, że utrudnia to tworzenie kopii zapasowych: baza danych nadal przechowuje metadane i musi być zrzucana w synchronizacji z zawartością bucketu.

Gdy instancja obsługuje rzeczywistych użytkowników, umieść przed nią Uptime Kuma, aby otrzymywać powiadomienia o przestojach, zanim dowiedzą się o nich klienci synchronizacji. Chmura prywatna dobrze współpracuje z własnym serwerem pocztowym. Jeśli wolisz nie łączyć usług ręcznie, Cloudron, CasaOS i Coolify porównują platformy, które zrobią to za Ciebie. Jeśli kolejnym krokiem ma być własna wyszukiwarka, przygotuj się na inny rodzaj problemów niż powyżej: błędy 429 w SearXNG wynikają z własnego limitera zapytań lub blokowania adresu IP Twojego VPS przez silniki zewnętrzne; tylko dziennik zdarzeń wskaże przyczynę.

FAQ

Czy można uruchomić Nextcloud na SQLite zamiast Postgres?

Jest to możliwe i oficjalny obraz na to pozwala, jednak pojedynczy klient synchronizacji pulpitu wysyłający równoległe żądania spowoduje SQLSTATE[HY000]: General error: 5 database is locked oraz błędy HTTP 500. SQLite nakłada blokadę zapisu na całą bazę danych, a Nextcloud wykonuje stałe operacje zapisu, blokady plików, wpisy aktywności oraz stany zadań. Należy rozpocząć od Postgres lub MariaDB; occ db:convert-type istnieje, ale jest to czasochłonna migracja typu „wszystko albo nic” na działających danych.

Ile pamięci RAM faktycznie potrzebuje VPS z Nextcloud?

Wielkość zasobów należy dobierać pod kątem współbieżności, a nie liczby użytkowników. Pamięć rezydentna w najgorszym przypadku to w przybliżeniu liczba jednoczesnych żądań pomnożona przez PHP_MEMORY_LIMIT, powiększona o współdzielone bufory Postgres i jeden backend na połączenie, oraz skoki zapotrzebowania podczas generowania podglądów. Serwer 2 GB obsłuży małą instancję domową, jeśli ograniczy się podglądy i doda swap; dodanie Collabora lub pełnotekstowego wyszukiwania wymaga zarezerwowania zasobów dla kolejnego zestawu usług rezydentnych.

Dlaczego duże przesyłanie plików kończy się niepowodzeniem za reverse proxy Nginx?

Zazwyczaj przyczyną są dwa ustawienia proxy: client_max_body_size pozostawione na domyślnej wartości 1 MB powoduje ucięcie żądania, a krótkie wartości proxy_read_timeout / proxy_send_timeout przerywają długie transfery w trakcie ich trwania. Należy ustawić obie wartości na wyższe, zmienić proxy_request_buffering off na strumieniowanie zamiast buforowania na dysku oraz zwiększyć PHP_UPLOAD_LIMIT w kontenerze aplikacji, aby dopasować parametry.

Dlaczego Nextcloud wpada w pętlę przekierowań lub ostrzega o reverse proxy?

Kontener nie widzi Nginx pod adresem 127.0.0.1, lecz bramę mostu Docker, znajdującą się w 172.x. Gdy tego adresu brakuje w TRUSTED_PROXIES, nagłówek X-Forwarded-Proto: https jest ignorowany, Nextcloud generuje adresy URL http://, a proxy odsyła je z powrotem. Należy ustawić TRUSTED_PROXIES na właściwą podsieć mostu i przypiąć OVERWRITEPROTOCOL: https.

Czy można zaktualizować Nextcloud bezpośrednio z wersji 29 do 31?

Nie. Nextcloud wspiera aktualizację o jedną główną wersję naraz, a pominięcie tego kroku kończy się błędem Updates between multiple major versions and downgrades are unsupported., pozostawiając instancję w trybie konserwacji. Należy wykonać kopię zapasową, zwiększyć tag o jedną wersję główną w usługach app oraz cron, wykonać docker compose pull && docker compose up -d, zweryfikować za pomocą occ status, a następnie powtórzyć proces.