Nextcloud sa VPS: Docker, TLS at backup

Ang aktuwal na binubuo mo

Pinapatakbo ng gabay na ito ang Nextcloud sa isang VPS gamit ang Docker Compose, inilalagay ang Let's Encrypt TLS sa harap nito, at nagse-set up ng backup na aktuwal na nare-restore. May apat na container at isang proxy: ang opisyal na nextcloud image na nakikinig sa loopback, ang Postgres na naglalaman ng lahat ng file metadata, ang Redis na naglalaman ng file locks, ang ikalawang kopya ng Nextcloud image na cron loop lamang ang pinapatakbo, at ang nginx sa host na nagte-terminate ng TLS sa harap ng lahat ng ito. Dalawampung minuto lamang ang pag-install, at hindi ito ang bahaging pinakamahalaga. Dalawang desisyong ginawa sa unang oras ang magpapasya kung nasa iyo pa rin ang mga file mo makalipas ang isang taon: gumamit ng totoong database sa halip na SQLite, at gumamit ng backup na kumukuha sa data directory, database, at config.php bilang isang consistent na set.

Ipinapalagay nito ang Ubuntu 24.04 LTS o Debian 13, Docker Engine na may naka-install na Compose v2 plugin mula sa sariling repository ng Docker, at isang DNS A record (dagdag ang AAAA kung mayroon kang IPv6) na nakaturo na sa cloud.example.com ng VPS. Kailangan ng lahat ng ito ang server na kontrolado mo. Walang paraan upang magawa ang TLS termination at database dump sa SaaS ng ibang tao.

Sizing: ano talaga ang kumokonsumo ng memory

Tatlong bagay ang pangunahing kumokonsumo ng memory ng Nextcloud, at wala sa mga ito ang mismong “Nextcloud.”

PHP workers. Hinahandle ng -apache image ang bawat sabay-sabay na request gamit ang worker process na may PHP interpreter. Maaaring lumaki ang bawat worker hanggang PHP_MEMORY_LIMIT bago ihinto ng PHP ang request. Tinatayang sabay-sabay na requests × memory limit ang worst-case resident memory, at nagbubukas ang desktop sync client ng ilang parallel connection bawat user. Concurrency, hindi user count, ang nagtatakda ng ceiling.

Ang database. Nagfo-fork ang Postgres ng backend para sa bawat connection at nananatiling resident ang shared buffers nito. Nakasalalay ang working set nito sa bilang ng files, hindi sa bilang ng bytes: may isang row ang oc_filecache para sa bawat file ng bawat user. Mas mabigat sa database ang isang daang libong maliliit na file kaysa isang daang malalaking file.

Preview generation. Kapag gumagawa ng thumbnail, dini-decode ang source image sa memory sa full resolution. Gumagamit ang video previews ng shell command papunta sa ffmpeg. Kapag pinatakbo ang occ preview:generate-all, paulit-ulit at magkakasunod nitong ginagawa ang memory spike na iyon. Ito ang pinakakaraniwang paraan para maitulak ang maliit na VPS sa OOM killer.

Mas kaunti ang memory na ginagamit ng Redis kumpara rito. Anumang idagdag mo sa susunod, gaya ng Collabora, full-text search, o antivirus scanner, ay hiwalay na resident service na may sariling footprint. Isama ito sa sizing plan bago mo ito i-enable.

Kung kapos ang RAM, gamitin ang mga sumusunod na adjustment: ibaba ang PHP_MEMORY_LIMIT, lagyan ng cap ang preview_max_x / preview_max_y / preview_max_filesize_image, limitahan ang enabledPreviewProviders sa mga format na aktuwal mong bina-browse, at itakda ang trashbin_retention_obligation at versions_retention_obligation para hindi tahimik na lumaki ang data directory nang ilang ulit kumpara sa laki ng mga file. Magdagdag ng swap file. Mabagal ang swap, at mas malala ang OOM kill habang nag-u-upgrade.

Bakit nagkakaproblema ang SQLite

May suporta ang Nextcloud para sa SQLite, at awtomatikong gagamitin ito ng official image. Huwag itong gamitin. Sina-serialize ng SQLite ang mga write gamit ang lock na sumasaklaw sa buong database: isang writer lang sa bawat pagkakataon para sa buong file. Patuloy na nagsusulat ang Nextcloud para sa file locks, activity rows, cache entries, at job state. Bukod dito, maraming parallel request ang ipinapadala ng isang desktop client kapag nagsi-sync ng directory tree. Sa ganitong pattern, nagkakaroon ka ng SQLSTATE[HY000]: General error: 5 database is locked at HTTP 500 errors. Karaniwang lumilitaw ang problema kapag nagsisimula nang maging kapaki-pakinabang ang instance.

Posibleng mag-convert sa ibang database sa kalaunan gamit ang occ db:convert-type, pero mahaba itong all-or-nothing migration sa isang live dataset. Magsimula sa Postgres o MariaDB.

Ang Compose file

Ilagay ito sa /srv/nextcloud/compose.yaml, at ilagay ang mga secret sa katabing .env file na may mode na 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:

I-lock ang major tag at tingnan muna ang kasalukuyang tag sa Docker Hub bago mong kopyahin nang eksakto ang 31. Ililipat ka ng latest lampas sa major boundary sa isang hinaharap na docker compose pull, at hindi ito sinusuportahan ng Nextcloud.

Bind mount ang data directory, hindi named volume, at sinadya ito: mas mahalaga ang path na direktang magagamit ng backup tool kaysa sa pagiging maayos ng layout. Gawin ito gamit ang www-data UID ng image at ang mga permission na hinihingi ng Nextcloud:

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

Pansinin ang port publish: 127.0.0.1:8080:80. Nagsusulat ang Docker ng DNAT rules para sa pag-publish ng ports. Sinusuri ang mga ito bago pa makita ng INPUT chain ng ufw ang packet. Kapag bare 8080:80 ang ginamit, ilalantad nito sa public internet ang hindi naka-encrypt na Nextcloud, anuman ang configuration ng ufw. Kapag naka-bind sa loopback, hindi ito maa-access sa public interface. Dahil dito, proxy lang ang kailangang payagan ng firewall. Kung ayaw mong iwanang bukas ang SSH sa buong internet, maaari mong ma-access ang VPS gamit ang self-hosted WireGuard VPN at tuluyang alisin ang port 22 sa public rules:

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

Paandarin ito gamit ang docker compose up -d, pagkatapos ay i-monitor ang docker compose logs -f app. Sa unang boot, kinokopya nito ang buong application tree sa volume at pinapatakbo ang installer. Hindi sasagot ang container hangga't hindi ito natatapos.

TLS at ang reverse proxy

I-install ang nginx at certbot mula sa distro, gumawa ng plain port-80 server block na may tamang server_name, at hayaang i-rewrite ito ng certbot. Detalyadong saklaw ng pag-isyu ng Let's Encrypt certificates gamit ang certbot at nginx sa Ubuntu 24.04 ang mekanismo ng HTTP-01 challenge, renewal timer, at mga posibleng failure mode:

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

Idinadagdag ng Certbot ang mga linyang ssl_certificate at ang redirect na :80 → :443. Nag-i-install din ito ng systemd timer na nagre-renew ng 90-day certificate. Tiyaking umiiral ito gamit ang systemctl list-timers | grep certbot. Ang renewal timer na hindi kailanman na-enable ay parang 90-day fuse.

Ang proxy block mismo:

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;
    }
}

Sa nginx 1.25 at mas bago, idagdag ang http2 on;. Ang Ubuntu 24.04 ay may mas lumang build kung saan ang katumbas nito ay listen 443 ssl http2;. Sasabihin sa iyo ng nginx -t kung alin ang tinatanggap ng iyong build.

Ang client_max_body_size at mahahabang read timeout ang pumipigil na maputol sa kalagitnaan ang malalaking upload. I-stream ng proxy_request_buffering off ang upload sa proxy sa halip na i-spool muna ang buong file sa disk ng proxy.

Ang nginx sa host ang pinakasimpleng gumaganang setup para sa isang app. Kung makikigamit ang Nextcloud ng VPS kasama ng iba pang container, inililipat ng pagpapatakbo ng Traefik bilang Docker Compose reverse proxy para sa maraming app ang routing at certificate issuance sa container labels. Doon, muling lilitaw ang parehong mga concern sa client_max_body_size at timeout bilang middleware at transport settings.

trusted_proxies at overwriteprotocol

Dito kadalasang nagkakamali ang mga self-hosted Nextcloud instance, at mukhang walang kaugnayan sa sanhi ang mga sintomas.

Iginagalang lamang ang X-Forwarded-Proto: https kapag nagmumula ang request sa address na nakalista sa trusted_proxies. Kapag hindi ito iginalang, inaakala ng Nextcloud na plain HTTP ang request at gumagawa ito ng mga URL na http://; nire-redirect ng proxy ang mga iyon sa HTTPS; sinusundan ito ng browser; pagkatapos ay muli na namang gumagawa ang Nextcloud ng http://. Iyan ang redirect loop. Pilit na itinatakda ng OVERWRITEPROTOCOL: https ang scheme sa lahat ng pagkakataon.

Ang problema sa TRUSTED_PROXIES ay hindi 127.0.0.1 ang address na nakikita ng Nextcloud. Tumatakbo ang nginx sa host at kumokonekta ito sa isang published port, kaya ang nakikita ng container ay ang Docker bridge gateway, na nasa 172.x. Hanapin ang aktuwal na subnet:

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

Ilagay ang CIDR na iyon, o ang sumasaklaw na 172.16.0.0/12, sa TRUSTED_PROXIES. Kapag masyadong malawak ang itinakda mo, maaaring mag-spoof ang sinumang client ng X-Forwarded-For. Kapag mali naman ang itinakda mo, magmumukhang mula sa gateway address ang bawat login, haharangin ng brute-force protection ang buong instance mo, at ipapakita ng admin overview ang "Mali ang reverse proxy header configuration, o ina-access mo ang Nextcloud mula sa isang trusted proxy."

Mahalaga ang OVERWRITECLIURL para sa cron container dahil wala itong incoming request na mapagkukunan ng hostname. Kung wala ito, gagawa ang background jobs ng mga link na localhost at magpapadala ang email notifications ng mga URL na hindi magagamit.

Mga background job: cron, hindi AJAX

Ang default job runner ng Nextcloud ay AJAX: tumatakbo ang mga job bilang side effect ng pag-load ng page ng isang user. Walang nagba-browse nang 04:00, kaya natitigil ang pag-expire ng trash, paglilinis ng versions, pagbuo ng previews, at mga federated retry. Ang unang palatandaan ay data directory na patuloy na lumalaki. Tumatakbo ang cron service sa itaas gamit ang opisyal na /cron.sh loop laban sa parehong volumes. Sabihin sa Nextcloud na ito ang dapat nitong asahan:

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

Pare-pareho ang anyo ng bawat occ command: docker compose exec -u www-data app php occ <command>. Mainam na gumawa ng alias para rito.

Mga backup: tatlong bahagi, o wala

Ang filesystem-only backup ay nagre-restore sa sirang instance. Nasa data directory ang mga byte; nasa Postgres ang file cache, shares, users, at app state; nasa config.php ang database credentials, instance ID, at password salt. Kapag ni-restore ang mga file nang walang database, hindi makikita ng Nextcloud ang mga ito. Kapag ni-restore ang database nang walang config.php, hindi nito mabubuksan ang database. Kapag ni-restore ang lumang database laban sa mas bagong data directory, magkakaroon ka ng mga share na tumuturo sa mga file na nailipat na.

I-back up ang tatlong ito mula sa quiesced instance:

#!/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/

Ang maintenance mode ang nagsisiguro na nagtutugma ang dump at file copy. Kapag nilaktawan mo ito, kalaunan ay makakakuha ka ng database na tumutukoy sa file na hindi pa naaabot ng rsync. Tandaan na nagtatago ang script ng mga database dump na may timestamp, pero isang rolling mirror lang ng data directory ang pinananatili nito. Ino-overwrite ito ng rsync --delete sa bawat run, kaya ang pinakabagong dump lang ang katugma ng file copy.

Pagkatapos, ilipat ito palabas ng server. Ang backup na nasa parehong VPS ng bina-back up nito ay kopya lang, hindi backup. Karaniwang solusyon ang restic laban sa object storage o pangalawang host. Mas mahusay nitong pinangangasiwaan ang data directory dahil sa deduplication nito kumpara sa nightly tarball. Nasa mga off-box VPS backup gamit ang restic ang buong setup, mula sa repository init hanggang sa nightly timer at restore drill.

Hindi simpleng kabaligtaran nito ang restore. Ang bagong-start na stack ay nagpapatakbo ng installer at nagsusulat ng bagong config.php, bagong instance ID, at password salt. Kapag ini-import ang dump sa ibabaw ng bagong identity na ito, masisira ang sessions at share tokens. Ibalik muna ang lumang identity, sa ganitong pagkakasunod-sunod:

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

Inaayos ng files:scan ang file cache upang tumugma sa aktuwal na nasa disk. Sanayin ito nang isang beses sa spare VPS bago mo ito kailanganin. Ang parehong paghihiwalay ng mga byte sa disk at metadata sa Postgres ang umiiral sa lahat ng iba pang app na ganito ang disenyo. Kaya ang Immich backup na kumukuha ng library pero hindi ng database ay nagre-restore sa walang laman na timeline.

Mga Upgrade: tig-iisang major version lang

Sinusuportahan ng Nextcloud ang pag-upgrade ng eksaktong isang major version sa bawat pagkakataon. Kapag lumaktaw mula 29 papuntang 31, hindi ito maayos na magfa-fail. Magfa-fail ito gamit ang Exception: Updates between multiple major versions and downgrades are unsupported. at maiiwan ka sa maintenance mode.

Ganito ang Docker upgrade: gumawa muna ng backup, palitan ang tag mula 31 tungo sa 32 sa parehong app at cron services, pagkatapos ay docker compose pull && docker compose up -d, at saka docker compose logs -f app. Tinutukoy ng image entrypoint na mas bago ang code kumpara sa kasalukuyang data at awtomatiko nitong pinapatakbo ang occ upgrade. Huwag itong abalahin. Kapag tumahimik na ang logs, patakbuhin ang docker compose exec -u www-data app php occ status at tingnan ang versionstring, pati kung naka-enable muli ang mga app.

Dalawang panuntunang makakatulong: mag-upgrade ng isang major version, mag-verify, at saka mag-upgrade sa susunod. Huwag kailanman palitan ang tag sa app service nang hindi pinapantayan ang cron. Ang paggamit ng dalawang magkaibang Nextcloud version sa iisang database ay maaaring magdulot ng corruption.

Mga error na aktuwal mong makikita

"Nababasa ng ibang user ang iyong data directory. Palitan ang permissions nito sa 0770." May group o world read bits ang bind-mounted directory. sudo chmod 0770 /srv/nextcloud/data at sudo chown -R 33:33 /srv/nextcloud/data.

"Invalid ang iyong data directory. Tiyaking may file na .ocdata sa root." Nakaturo ang bind mount sa lokasyong hindi kailanman na-initialize ng Nextcloud, may typo sa path, o napalitan ang gumaganang instance ng bagong empty directory. Tiyaking tumutugma ang host path sa volume line.

"Access through untrusted domain." Wala sa trusted_domains ang hostname sa request. Nalalapat lamang ang NEXTCLOUD_TRUSTED_DOMAINS sa unang installation; pagkatapos nito, itakda ito habang tumatakbo ang system: occ config:system:set trusted_domains 1 --value=cloud.example.com.

502 Bad Gateway, na may connect() failed (111: Connection refused) while connecting to upstream sa /var/log/nginx/error.log. Walang naabot ang nginx sa 127.0.0.1:8080. Maaaring nag-i-initialize pa ang container (suriin ang docker compose logs app), nag-exit ito (docker compose ps), o hindi tumutugma ang publish line sa port ng proxy_pass. Kumpirmahin gamit ang ss -ltnp | grep 8080.

May redirect loop, o may mga babalang "insecure" sa admin overview. Nawawala ang OVERWRITEPROTOCOL: https, o hindi naglalaman ang TRUSTED_PROXIES ng Docker gateway subnet. Tingnan ang proxy section sa itaas.

LockedException: "files/..." is locked. Kapag nakatakda ang REDIS_HOST, kino-configure ng image ang Redis bilang locking backend kaya bihira ang stale locks. Kung wala ito, nasa database table na oc_file_locks ang locks, at ang request na naputol habang nagsusulat ay nag-iiwan ng mga row. Tiyaking aktuwal na ginagamit ang Redis; dapat ibalik ng occ config:system:get memcache.locking ang Redis class bago ka mag-delete ng mga lock row nang mano-mano.

"Mas mababa sa inirerekomendang value na 512MB ang PHP memory limit." Itaas ang PHP_MEMORY_LIMIT at i-recreate ang container. Tandaan kung paano nito naaapektuhan ang worst-case ceiling mo.

Ano ang nasisira kapag lumaki ang scale

Ang unang limitasyon ay kapag lumampas ang data directory sa kapasidad ng volume. Ang pagpapalaki ng volume sa isang VPS ay nangangailangan ng resize at pagpapalaki ng filesystem. Mas kaunti ang abala kapag nakaiskedyul ito kaysa kapag umabot na sa 100% full ang volume. Mag-set up ng alert para sa disk usage ngayon, hindi kapag huli na.

Ang ikalawang limitasyon ay oc_filecache. Bumababagal ang file listings at sync scans habang dumarami ang mga row. Database work ang solusyon: ilagay ang Postgres sa mabilis na storage, bigyan ito ng sapat na shared memory, at regular na alisin ang trash at mga version gamit ang retention settings sa halip na hayaang maipon ang mga ito nang walang katapusan.

Ang ikatlong limitasyon ay ang pakikipag-agawan ng preview generation sa iba pang workload. Sa maliit na server, limitahan ang preview providers at huwag patakbuhin ang occ preview:generate-all habang oras ng trabaho. Kung phone camera roll ang bumubuo sa karamihan ng iniimbak mo, mas angkop na sa purpose-built photo server gawin ang thumbnail work na iyon. Tinalakay sa paghahambing ng PhotoPrism at Immich ayon sa RAM, phone apps at backup commands kung magkano ang resource cost ng bawat isa kapag isinama sa isang Nextcloud box.

Paglampas dito, ang tapat na sagot ay kailangan ng sariling machine ng mga dagdag na serbisyo. Ang Collabora at full-text search ay magkahiwalay na resident service na may sarili nilang memory profile. Kapag inilagay ang mga ito sa server na naglalaman din ng nag-iisa mong kopya ng mga file, lumalaki ang failure domain nang walang pakinabang. Kung in-browser document editing ang gusto mong idagdag, ang vendor RAM floors at connection limits na nagtatangi sa OnlyOffice at Collabora ang magpapasya kung kaya ng isang 2 hanggang 4 GB VPS ang alinman sa mga ito. Ilipat ang file storage sa S3-compatible primary storage kapag hindi na angkop ang kasalukuyang hugis ng volume. Tandaan na mas mahirap nito ang backups, hindi mas madali: nasa database pa rin ang metadata, at kailangan itong i-dump kasabay ng bucket.

Kapag nagsisilbi na ang instance sa mga totoong user, ilagay sa harap nito ang Uptime Kuma upang malaman mo ang downtime bago pa ito mapansin ng sync clients. Ang private cloud ay mahusay ipares sa sarili mong mail server. Kung ayaw mong manu-manong pagdugtungin ang mga serbisyo, ihambing sa Cloudron, CasaOS at Coolify ang mga platform na gumagawa nito para sa iyo. Kung self-hosted search engine naman ang susunod sa listahan, asahan ang ibang uri ng problema kaysa sa mga nabanggit: nagmumula ang 429 errors ng SearXNG sa sarili nitong rate limiter o sa upstream engines na nagba-block sa VPS IP mo. Log lamang ang makapagsasabi kung alin dito ang dahilan.

FAQ

Maaari ko bang patakbuhin ang Nextcloud sa SQLite sa halip na Postgres?

Maaari, at papayagan ka ng official image, pero tatama ang isang desktop sync client na sabay-sabay na nagpapadala ng mga request sa SQLSTATE[HY000]: General error: 5 database is locked at HTTP 500 errors. Nagla-lock ang SQLite sa buong database para sa pagsusulat, at palaging nagsusulat ang Nextcloud sa database—file locks, activity rows, at job state. Magsimula sa Postgres o MariaDB; umiiral ang occ db:convert-type, pero mahaba itong migration na all-or-nothing sa live data.

Gaano karaming RAM ang talagang kailangan ng Nextcloud VPS?

Maglaan batay sa concurrency, hindi sa bilang ng user. Ang worst-case resident memory ay humigit-kumulang bilang ng sabay-sabay na request na minultiply sa PHP_MEMORY_LIMIT, dagdag ang Postgres shared buffers at isang backend para sa bawat connection, pati ang memory na maaaring gamitin ng preview generation kapag tumindi ito. Kayang patakbuhin ng 2 GB na server ang maliit na household instance kung lilimitahan mo ang previews at magdadagdag ng swap; kapag nagdagdag ka ng Collabora o full-text search, kailangan mong maglaan para sa isa pang set ng resident services.

Bakit nabibigo ang malalaking upload sa likod ng nginx reverse proxy?

Karaniwang dalawang setting sa proxy ang sanhi nito: pinuputol ng client_max_body_size, na nananatili sa default na 1 MB, ang request, at pinatitigil ng maiikling value ng proxy_read_timeout / proxy_send_timeout ang mahahabang transfer bago matapos. Magtakda ng sapat na malalaking value para sa dalawa, itakda ang proxy_request_buffering off upang mag-stream sa halip na mag-spool, at itaas ang PHP_UPLOAD_LIMIT sa app container para tumugma.

Bakit nagre-redirect nang paikot ang Nextcloud o nagbibigay ng babala tungkol sa reverse proxy?

Hindi nakikita ng container ang nginx sa 127.0.0.1. Ang nakikita nito ay ang Docker bridge gateway, na nasa isang address sa 172.x. Kapag wala ang address na iyon sa TRUSTED_PROXIES, binabalewala ang X-Forwarded-Proto: https header, gumagawa ang Nextcloud ng http:// URLs, at ibinabalik ang mga ito ng proxy sa pinanggalingan. Itakda ang TRUSTED_PROXIES sa totoong bridge subnet at i-pin ang OVERWRITEPROTOCOL: https.

Maaari ko bang i-upgrade ang Nextcloud mula 29 diretso sa 31?

Hindi. Sinusuportahan ng Nextcloud ang isang major version lamang bawat upgrade. Kapag nag-skip, hihinto ito sa Updates between multiple major versions and downgrades are unsupported. at maiiwan ang instance sa maintenance mode. Mag-back up, itaas nang isang major ang tag sa parehong app at cron services, docker compose pull && docker compose up -d, i-verify gamit ang occ status, at saka ulitin.