VPS-ல் Docker மூலம் Nextcloud நிறுவுவது எப்படி?

What you are actually building

This guide runs Nextcloud on a VPS with Docker Compose, puts Let's Encrypt TLS in front of it, and sets up a backup that actually restores. Four containers and a proxy: the official nextcloud image listening on loopback, Postgres holding every piece of file metadata, Redis holding the file locks, a second copy of the Nextcloud image running nothing but the cron loop, and nginx on the host terminating TLS in front of all of it. The install itself takes twenty minutes, and it is not the part that matters. Two decisions made in the first hour decide whether you still have your files in a year: a real database instead of SQLite, and a backup that captures the data directory, the database and config.php as one consistent set.

This assumes Ubuntu 24.04 LTS or Debian 13, Docker Engine with the Compose v2 plugin installed from Docker's own repository, and a DNS A record (plus AAAA if you have IPv6) already pointing cloud.example.com at the VPS. All of it needs a server you control, there is no way to do TLS termination and a database dump on someone else's SaaS.

அளவு நிர்ணயம்: நினைவகத்தை உண்மையில் பயன்படுத்துவது எது

Nextcloud-ன் நினைவகப் பயன்பாடு மூன்று முக்கிய காரணிகளால் தீர்மானிக்கப்படுகிறது, இதில் எதுவுமே "Nextcloud" என்ற மென்பொருள் சார்ந்தது அல்ல.

PHP workers. -apache image, ஒரே நேரத்தில் வரும் ஒவ்வொரு கோரிக்கையையும் PHP interpreter-ஐக் கொண்ட ஒரு worker process மூலம் கையாளுகிறது. PHP அந்த கோரிக்கையை முடிக்கும் வரை, ஒவ்வொரு worker-ம் PHP_MEMORY_LIMIT அளவு வரை நினைவகத்தை எடுத்துக்கொள்ளலாம். உங்கள் worst-case நினைவகப் பயன்பாடு என்பது தோராயமாக ஒரே நேரத்தில் வரும் கோரிக்கைகள் × நினைவக வரம்பு ஆகும். ஒரு desktop sync client, ஒரு பயனருக்குப் பல இணைப்புகளை ஒரே நேரத்தில் திறக்கும். பயனர்களின் எண்ணிக்கையை விட, ஒரே நேரத்தில் வரும் கோரிக்கைகளின் (concurrency) எண்ணிக்கையே நினைவகத் தேவையைத் தீர்மானிக்கிறது.

Database. Postgres ஒவ்வொரு இணைப்புக்கும் ஒரு backend-ஐ உருவாக்கி, shared buffers-ஐ நினைவகத்தில் வைத்திருக்கும். இதன் பயன்பாடு கோப்புகளின் எண்ணிக்கையைப் பொறுத்தே அமையும், கோப்புகளின் அளவைப் பொறுத்தல்ல: oc_filecache ஒவ்வொரு பயனரின் ஒவ்வொரு கோப்புக்கும் ஒரு row-ஐ வைத்திருக்கும். நூறு பெரிய கோப்புகளை விட, ஒரு லட்சம் சிறிய கோப்புகள் database-க்கு அதிக சுமையைத் தரும்.

Preview generation. ஒரு thumbnail-ஐ உருவாக்கும்போது, மூலப் படத்தை முழுத் தெளிவுத்திறனுடன் (full resolution) நினைவகத்தில் decode செய்யும். Video previews-ஐ உருவாக்க ffmpeg பயன்படுத்தப்படுகிறது. occ preview:generate-all-ஐ இயக்கும்போது, இந்தச் செயல்முறை மீண்டும் மீண்டும் நடக்கும். இதுவே சிறிய VPS-களில் OOM killer தூண்டப்படுவதற்கு மிக முக்கியமான காரணமாகும்.

Redis-ன் பயன்பாடு ஒப்பீட்டளவில் குறைவு. நீங்கள் பின்னர் சேர்க்கும் Collabora, full-text search, antivirus scanner போன்ற ஒவ்வொன்றும் தனித்தனி service-கள். அவற்றுக்கெனத் தனி நினைவகத் தேவை உண்டு. எனவே, அவற்றைச் செயல்படுத்தும் முன்பே உங்கள் அளவு நிர்ணயத் திட்டத்தில் சேர்த்துக்கொள்ள வேண்டும்.

உங்களிடம் RAM குறைவாக இருந்தால், இந்த மாற்றங்களைச் செய்யலாம்: PHP_MEMORY_LIMIT-ஐக் குறைக்கவும், preview_max_x / preview_max_y / preview_max_filesize_image ஆகியவற்றிற்கு வரம்பு விதிக்கவும், enabledPreviewProviders-ல் உங்களுக்குத் தேவையான வடிவங்களை மட்டும் வைத்துக்கொள்ளவும், மேலும் trashbin_retention_obligation மற்றும் versions_retention_obligation ஆகியவற்றைச் சரியாக அமைக்கவும். இதன் மூலம் data directory உங்கள் கோப்புகளின் அளவை விடப் பல மடங்கு அதிகரிக்காது. ஒரு swap file-ஐச் சேர்க்கவும். Swap மெதுவானதுதான், ஆனால் upgrade செய்யும்போது OOM kill ஏற்படுவது அதைவிட மோசமானது.

SQLite ஏன் செயலிழக்கிறது

Nextcloud-ல் SQLite ஆதரவு உள்ளது, அதன் அதிகாரப்பூர்வ image-ம் அதை இயல்பாகவே பயன்படுத்தும். ஆனால், அதைத் தவிர்க்கவும். SQLite தரவுத்தளம் முழுமைக்கும் ஒரு பூட்டை (lock) இடுவதன் மூலம் எழுதும் பணிகளை வரிசைப்படுத்துகிறது: ஒரே நேரத்தில் ஒரு கோப்பில் ஒரு செயல்முறை மட்டுமே எழுத முடியும். Nextcloud தொடர்ந்து கோப்புகளை எழுதுதல், கோப்பு பூட்டுகள், செயல்பாட்டு வரிசைகள், cache பதிவுகள், மற்றும் job நிலைகளை மாற்றிக்கொண்டே இருக்கும். ஒரு desktop client கோப்புத் தொகுப்பை ஒத்திசைக்கும்போது (sync), அது பல இணையான கோரிக்கைகளை (parallel requests) அனுப்பும். இந்தச் செயல்பாட்டு முறையில் உங்களுக்கு SQLSTATE[HY000]: General error: 5 database is locked பிழையும் HTTP 500 பிழைகளும் ஏற்படும். உங்கள் instance பயனுள்ளதாக மாறத் தொடங்கும்போதே இந்தச் செயலிழப்பு நிகழும்.

பிற்காலத்தில் occ db:convert-type மூலம் தரவுத்தளத்தை மாற்றுவது சாத்தியம் என்றாலும், அது நேரடி தரவுத் தொகுப்பில் (live dataset) செய்யப்படும் நீண்ட மற்றும் முழுமையான இடம்பெயர்வு ஆகும். எனவே, தொடக்கத்திலிருந்தே Postgres அல்லது MariaDB-ஐப் பயன்படுத்தவும்.

Compose கோப்பு

இதை /srv/nextcloud/compose.yaml-ல் சேமிக்கவும். ரகசியங்களை (secrets) அதன் அருகிலுள்ள .env கோப்பில் 600 பயன்முறையில் (mode) வைக்கவும்.

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:

Docker Hub-ல் தற்போதைய பதிப்பைச் சரிபார்த்து, major tag-ஐ மட்டும் பயன்படுத்தவும். 31-ஐ அப்படியே நகலெடுக்கும் முன் கவனமாக இருக்கவும். latest எதிர்காலத்தில் ஏதேனும் ஒரு docker compose pull-ல் உங்களை major பதிப்பு மாற்றத்திற்கு உட்படுத்தும்; Nextcloud இதற்கு ஆதரவளிக்காது.

தரவு அடைவு (data directory) ஒரு bind mount ஆகும், இது named volume அல்ல. இது வேண்டுமென்றே செய்யப்படுகிறது: ஒரு backup கருவியை நேரடியாகச் சுட்டிக்காட்டக்கூடிய பாதை, நேர்த்தியை விட முக்கியமானது. இதை image-ன் www-data UID மற்றும் Nextcloud கோரும் அனுமதிகளுடன் (permissions) உருவாக்கவும்:

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

Port வெளியீட்டைக் கவனிக்கவும்: 127.0.0.1:8080:80. Docker, DNAT விதிகளை எழுதுவதன் மூலம் ports-ஐ வெளியிடுகிறது. இவை ufw-ன் INPUT சங்கிலி பாக்கெட்டுகளைப் பார்ப்பதற்கு முன்பே மதிப்பீடு செய்யப்படுகின்றன. ஒரு சாதாரண 8080:80, ufw என்ன சொன்னாலும், குறியாக்கம் செய்யப்படாத Nextcloud-ஐ பொது இணையத்தில் (public internet) விட்டுவிடும். Loopback-ல் பிணைப்பது (binding) அதை பொது இடைமுகத்திலிருந்து (public interface) விலக்கி வைக்கும். பிறகு, firewall proxy-ஐ மட்டும் அனுமதித்தால் போதும். SSH-ஐ முழு இணையத்திற்கும் திறந்து வைக்க விரும்பவில்லை என்றால், self-hosted WireGuard VPN மூலம் VPS-ஐ அணுகுவது port 22-ஐ பொது விதிகளிலிருந்து முழுமையாக நீக்க உதவும்:

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

docker compose up -d மூலம் இதைத் தொடங்கவும், பிறகு docker compose logs -f app-ஐக் கவனிக்கவும். முதல் முறை தொடங்கும் போது, முழு application கட்டமைப்பும் volume-க்குள் நகலெடுக்கப்பட்டு installer இயங்கும்; அது முடியும் வரை container எந்தப் பதிலையும் தராது.

TLS மற்றும் reverse proxy

Distro-விலிருந்து nginx மற்றும் certbot ஆகியவற்றை நிறுவி, சரியான server_name உடன் ஒரு plain port-80 server block-ஐ உருவாக்கவும். பின்னர் certbot-ஐப் பயன்படுத்தி அதை rewrite செய்யவும். HTTP-01 challenge-ன் செயல்பாடுகள், renewal timer மற்றும் தோல்விக்கான காரணங்கள் அனைத்தும் Ubuntu 24.04-ல் certbot மற்றும் nginx மூலம் Let's Encrypt certificates பெறுதல் என்ற பகுதியில் விரிவாக விளக்கப்பட்டுள்ளன:

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

Certbot, ssl_certificate வரிகளையும் :80 → :443 redirect-ஐயும் சேர்க்கிறது. மேலும், 90 நாட்கள் செல்லுபடியாகும் certificate-ஐப் புதுப்பிக்கும் systemd timer-ஐயும் நிறுவுகிறது. systemctl list-timers | grep certbot மூலம் அது இருப்பதை உறுதிப்படுத்தவும்; ஒரு renewal timer-ஐ enable செய்யத் தவறினால், அது 90 நாட்களுக்குப் பிறகு certificate காலாவதியாகும் அபாயத்தை ஏற்படுத்தும்.

Proxy block-ன் அமைப்பு:

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

Nginx 1.25 மற்றும் அதற்குப் பிந்தைய பதிப்புகளில், http2 on;-ஐச் சேர்க்கவும். Ubuntu 24.04-ல் உள்ள பழைய build-ல் இதற்கு இணையான கட்டளை listen 443 ssl http2; ஆகும். உங்கள் build எதை ஏற்கும் என்பதை nginx -t மூலம் கண்டறியலாம்.

client_max_body_size மற்றும் நீண்ட read timeouts ஆகியவை பெரிய கோப்புகளைப் பதிவேற்றும்போது அவை பாதியிலேயே துண்டிக்கப்படுவதைத் தடுக்கின்றன. proxy_request_buffering off, கோப்பு முழுவதையும் முதலில் proxy-ன் disk-ல் சேமிக்காமல், பதிவேற்றத்தை நேரடியாக stream செய்கிறது.

ஒரே ஒரு application-க்கு host-ல் உள்ள nginx-ஐப் பயன்படுத்துவதே எளிமையான வழி. Nextcloud-ஐ மற்ற containers-உடன் சேர்த்து ஒரு VPS-ல் இயக்கப்போகிறீர்கள் என்றால், பல applications-க்கு Docker Compose reverse proxy-ஆக Traefik-ஐ இயக்குதல் என்ற முறை routing மற்றும் certificate வழங்குதலை container labels-க்கு மாற்றும். அதே client_max_body_size மற்றும் timeout தொடர்பான சிக்கல்கள் அங்கும் middleware மற்றும் transport settings-ஆக மீண்டும் தோன்றும்.

trusted_proxies மற்றும் overwriteprotocol

பெரும்பாலான self-hosted Nextcloud instances-களில் தவறுகள் நடக்கும் இடம் இதுதான். இதன் அறிகுறிகள், உண்மையான காரணத்துடன் தொடர்பில்லாதது போலத் தோன்றும்.

X-Forwarded-Proto: https, trusted_proxies-ல் பட்டியலிடப்பட்டுள்ள முகவரியிலிருந்து கோரிக்கை (request) வரும்போது மட்டுமே ஏற்றுக்கொள்ளப்படும். இது ஏற்றுக்கொள்ளப்படாதபோது, Nextcloud அந்த கோரிக்கையை சாதாரண HTTP என்று கருதி http:// URL-களை வெளியிடுகிறது; proxy அவற்றை HTTPS-க்கு மாற்றுகிறது; browser அதைப் பின்தொடர்கிறது; Nextcloud மீண்டும் http://-ஐ வெளியிடுகிறது. இதுவே redirect loop ஆகும். OVERWRITEPROTOCOL: https, கோரிக்கையின் scheme-ஐ மாற்றமின்றி அப்படியே வைத்திருக்கும்.

TRUSTED_PROXIES-ல் உள்ள சிக்கல் என்னவென்றால், Nextcloud பார்க்கும் முகவரி 127.0.0.1 அல்ல. nginx host-ல் இயங்கி, வெளியிடப்பட்ட port-உடன் இணைகிறது, எனவே container-ஆனது Docker bridge gateway-ஐப் பார்க்கிறது, இது 172.x-ல் உள்ள ஒன்றாக இருக்கும். உண்மையான subnet-ஐக் கண்டறியவும்:

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

அந்த CIDR-ஐ (அல்லது அதை உள்ளடக்கிய 172.16.0.0/12-ஐ) TRUSTED_PROXIES-ல் உள்ளிடவும். இதை மிக விரிவாக அமைத்தால், எந்தவொரு client-ம் X-Forwarded-For-ஐ போலியாகக் காட்ட முடியும்; தவறாக அமைத்தால், அனைத்து login-களும் gateway முகவரியிலிருந்து வருவது போலத் தோன்றும், brute-force protection உங்கள் முழு instance-ஐயும் ஒரே நேரத்தில் முடக்கிவிடும், மேலும் admin overview-ல் "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy." என்ற பிழை தோன்றும்.

OVERWRITECLIURL, cron container-க்கு முக்கியமானது, ஏனெனில் அதற்கு hostname-ஐக் கண்டறிய உள்வரும் கோரிக்கைகள் எதுவும் இல்லை. இது இல்லையென்றால், background jobs localhost-க்கான இணைப்புகளை உருவாக்கும் மற்றும் மின்னஞ்சல் அறிவிப்புகள் பயன்படுத்த முடியாத URL-களை அனுப்பும்.

பின்னணிப் பணிகள்: cron, AJAX அல்ல

Nextcloud-ன் இயல்புநிலை பணி இயக்கி (job runner) AJAX ஆகும்: யாராவது ஒரு பக்கத்தை ஏற்றும்போது மட்டுமே பணிகள் பின்னணியில் இயங்கும். அதிகாலை 04:00 மணிக்கு யாரும் இணையதளத்தைப் பயன்படுத்த மாட்டார்கள் என்பதால், குப்பை நீக்கம் (trash expiry), பதிப்புச் சுத்திகரிப்பு (versions cleanup), முன்னோட்டங்கள் (previews) மற்றும் கூட்டமைப்பு மறுமுயற்சிகள் (federated retries) போன்றவை தேங்கிவிடும். இதன் முதல் அறிகுறி, தரவு அடைவு (data directory) தொடர்ந்து வளர்ந்து கொண்டே இருப்பதுதான். மேலே உள்ள cron சேவை, அதே volumes-ல் அதிகாரப்பூர்வ /cron.sh சுழற்சியை இயக்குகிறது. இதை Nextcloud-க்குத் தெரிவிக்கவும்:

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

ஒவ்வொரு occ கட்டளையும் இந்த அமைப்பைப் பின்பற்றுகிறது: docker compose exec -u www-data app php occ <command>. இதற்கு alias அமைப்பது பயனுள்ளது.

Backups: மூன்று விஷயங்கள், அல்லது எதுவுமில்லை

Filesystem-ஐ மட்டும் backup எடுத்தால், அது பழுதடைந்த instance-ஐ மட்டுமே மீட்டெடுக்கும். Data directory-ல் bytes இருக்கும்; Postgres-ல் file cache, shares, users மற்றும் app state இருக்கும்; config.php-ல் database credentials, instance ID மற்றும் password salt இருக்கும். Database இல்லாமல் கோப்புகளை மட்டும் மீட்டெடுத்தால் Nextcloud-ஆல் அவற்றைப் பார்க்க முடியாது. config.php இல்லாமல் database-ஐ மீட்டெடுத்தால், அதனால் database-ஐத் திறக்க முடியாது. புதிய data directory-ல் பழைய database-ஐ மீட்டெடுத்தால், நகர்த்தப்பட்ட கோப்புகளைச் சுட்டிக்காட்டும் shares குழப்பமடையும்.

Quiesced நிலையில் உள்ள instance-லிருந்து இந்த மூன்றையும் backup எடுக்கவும்:

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

Maintenance mode-தான் database dump மற்றும் file copy ஆகியவற்றை ஒன்றுடன் ஒன்று ஒத்துப்போகச் செய்கிறது. இதைத் தவிர்த்தால், rsync இன்னும் சென்றடையாத ஒரு கோப்பைக் குறிப்பிடும் database-ஐ நீங்கள் backup எடுக்க நேரிடும். இந்த script timestamp செய்யப்பட்ட database dump-களை வைத்திருக்கும், ஆனால் data directory-க்கு ஒரே ஒரு rolling mirror மட்டுமே இருக்கும் என்பதை கவனிக்கவும். rsync --delete ஒவ்வொரு முறையும் அதை overwrite செய்யும், எனவே மிகப்புதிய dump மட்டுமே file copy-உடன் இணையும்.

பிறகு அதை server-லிருந்து வெளியேற்றவும். எதை backup எடுக்கிறீர்களோ, அதே VPS-ல் இருக்கும் backup என்பது ஒரு நகல் மட்டுமே, அது உண்மையான backup அல்ல. restic-ஐ object storage அல்லது இரண்டாவது host-க்கு அனுப்புவதே வழக்கமான தீர்வாகும். அதன் deduplication வசதி, nightly tarball-ஐ விட data directory-ஐ மிகச்சிறப்பாகக் கையாளும். Repository init முதல் nightly timer மற்றும் restore drill வரையிலான முழுமையான அமைப்பு off-box VPS backups with restic-ல் உள்ளது.

Restore செய்வது என்பது வெறும் reverse செயல்முறை அல்ல. புதிதாகத் தொடங்கப்பட்ட stack, installer-ஐ இயக்கி ஒரு புதிய config.php, புதிய instance ID மற்றும் password salt-ஐ உருவாக்கும். அந்தப் புதிய அடையாளத்தின் மீது dump-ஐ import செய்தால், sessions மற்றும் share tokens பழுதடைந்துவிடும். பழைய அடையாளத்தை முதலில் பின்வரும் வரிசையில் மீட்டமைக்கவும்:

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, disk-ல் உள்ள கோப்புகளுடன் file cache-ஐ ஒத்திசைக்கும். உங்களுக்குத் தேவைப்படுவதற்கு முன்பே, ஒரு spare VPS-ல் இதை ஒருமுறை பயிற்சி செய்து பார்க்கவும். Disk-ல் உள்ள bytes மற்றும் Postgres-ல் உள்ள metadata ஆகியவற்றுக்கு இடையேயான இந்த வேறுபாடே இது போன்ற அனைத்து application-களுக்கும் பொருந்தும். இதனால்தான் an Immich backup that captures the library but not the database restores to an empty timeline என்று கூறப்படுகிறது.

மேம்படுத்தல்கள்: ஒரு நேரத்தில் ஒரு முக்கிய பதிப்பு மட்டும்

Nextcloud ஒரு நேரத்தில் சரியாக ஒரு முக்கிய பதிப்பை (major version) மட்டுமே மேம்படுத்த அனுமதிக்கிறது. பதிப்பு 29-லிருந்து 31-க்கு நேரடியாக மாறுவது சரியாகச் செயல்படாது; அது Exception: Updates between multiple major versions and downgrades are unsupported. பிழையை ஏற்படுத்தி, உங்களை maintenance mode-ல் நிறுத்திவிடும்.

Docker மேம்படுத்தல் முறை: முதலில் backup எடுக்கவும், பிறகு app மற்றும் cron ஆகிய இரண்டு services-லும் உள்ள tag-ஐ 31-லிருந்து 32-க்கு மாற்றவும், அதன் பிறகு docker compose pull && docker compose up -d கட்டளையை இயக்கவும், இறுதியாக docker compose logs -f app கட்டளையை இயக்கவும். Image entrypoint, ஏற்கனவே உள்ள தரவுகளுடன் புதிய code-ஐ ஒப்பிட்டு, தானாகவே occ upgrade-ஐ இயக்கும். இந்தச் செயல்பாட்டை இடையில் நிறுத்த வேண்டாம். logs அமைதியான பிறகு, docker compose exec -u www-data app php occ status-ஐ இயக்கி, versionstring-ஐச் சரிபார்க்கவும்; மேலும், அனைத்து apps-களும் மீண்டும் enabled நிலையில் உள்ளதா என்பதை உறுதிப்படுத்தவும்.

உங்களைக் காக்கும் இரண்டு விதிகள்: ஒரு முக்கிய பதிப்பை மட்டும் உயர்த்தி, சரிபார்த்து, அதன் பிறகு அடுத்த பதிப்பிற்குச் செல்லவும். மேலும், cron-ஐ மாற்றாமல் app service-ல் உள்ள tag-ஐ ஒருபோதும் மாற்ற வேண்டாம்; ஒரே database-ஐ இரண்டு வெவ்வேறு Nextcloud பதிப்புகள் அணுகுவது தரவுச் சிதைவிற்கு (corruption) வழிவகுக்கும்.

நீங்கள் உண்மையில் காணக்கூடிய பிழைகள்

"Your data directory is readable by other users. Please change the permissions to 0770." bind-mount செய்யப்பட்ட கோப்பகத்தில் (directory) group அல்லது world read அனுமதிகள் உள்ளன. sudo chmod 0770 /srv/nextcloud/data மற்றும் sudo chown -R 33:33 /srv/nextcloud/data-ஐப் பார்க்கவும்.

"Your data directory is invalid. Ensure there is a file called .ocdata in the root." bind mount என்பது Nextcloud ஒருபோதும் உருவாக்கப்படாத இடத்தைச் சுட்டிக்காட்டுகிறது, பாதையில் எழுத்துப் பிழை உள்ளது, அல்லது இயங்கிக்கொண்டிருக்கும் instance-க்கு அடியில் புதிய காலி கோப்பகம் மாற்றப்பட்டுள்ளது. host பாதை volume வரியுடன் ஒத்துப்போகிறதா என்பதைச் சரிபார்க்கவும்.

"Access through untrusted domain." கோரிக்கையில் உள்ள hostname trusted_domains-ல் இல்லை. NEXTCLOUD_TRUSTED_DOMAINS முதல்முறை நிறுவும் போது மட்டுமே பொருந்தும்; அதன் பிறகு அதை நேரலையில் அமைக்கவும்: occ config:system:set trusted_domains 1 --value=cloud.example.com.

502 Bad Gateway, /var/log/nginx/error.log-ல் connect() failed (111: Connection refused) while connecting to upstream பிழையுடன். nginx 127.0.0.1:8080-ல் எதையும் சென்றடையவில்லை. container இன்னும் தொடங்கிக்கொண்டிருக்கலாம் (docker compose logs app-ஐச் சரிபார்க்கவும்), அது வெளியேறியிருக்கலாம் (docker compose ps), அல்லது publish வரி proxy_pass port-உடன் பொருந்தவில்லை. ss -ltnp | grep 8080 மூலம் உறுதிப்படுத்தவும்.

ஒரு redirect loop, அல்லது நிர்வாக மேலோட்டத்தில் "insecure" எச்சரிக்கைகள். OVERWRITEPROTOCOL: https விடுபட்டுள்ளது, அல்லது TRUSTED_PROXIES-ல் Docker gateway subnet இல்லை. மேலே உள்ள proxy பகுதியைப் பார்க்கவும்.

LockedException: "files/..." is locked. REDIS_HOST அமைக்கப்பட்டிருக்கும்போது, image ஆனது Redis-ஐ locking backend-ஆக உள்ளமைக்கிறது மற்றும் பழைய locks அரிதாகவே இருக்கும். அது இல்லையென்றால், locks தரவுத்தள அட்டவணையான oc_file_locks-ல் இருக்கும், மேலும் எழுதும் பணியின் நடுவில் ஒரு கோரிக்கை நிறுத்தப்பட்டால், அது வரிசைகளை (rows) அப்படியே விட்டுவிடும். Redis உண்மையில் பயன்பாட்டில் உள்ளதா என்பதை உறுதிப்படுத்தவும், நீங்கள் கைமுறையாக lock வரிசைகளை நீக்கும் முன் occ config:system:get memcache.locking கட்டளை Redis class-ஐத் திருப்பியளிக்க வேண்டும்.

"The PHP memory limit is below the recommended value of 512MB." PHP_MEMORY_LIMIT-ஐ அதிகரிக்கவும் மற்றும் container-ஐ மீண்டும் உருவாக்கவும். அது உங்கள் worst-case ceiling-ல் என்ன மாற்றத்தை ஏற்படுத்தும் என்பதை நினைவில் கொள்ளவும்.

அளவீடு அதிகரிக்கும்போது ஏற்படும் சிக்கல்கள்

முதல் தடையாக இருப்பது, தரவு அடைவு (data directory) அதன் volume அளவைத் தாண்டி வளர்வதுதான். ஒரு VPS-ல் volume-ஐ அதிகரிப்பது என்பது, அதன் அளவை மாற்றி, filesystem-ஐ விரிவுபடுத்துவதாகும். இது 100% நிறைந்த பிறகு செய்வதை விட, முன்கூட்டியே திட்டமிட்டுச் செய்வது எளிது. எனவே, disk பயன்பாடு குறித்த எச்சரிக்கைகளை இப்போதே அமைக்கவும்.

இரண்டாவது தடை oc_filecache ஆகும். கோப்புகளின் எண்ணிக்கை அதிகரிக்கும்போது, கோப்புப் பட்டியல் (file listings) மற்றும் sync scans வேகம் குறையும். இதற்குத் தீர்வாக database-ஐ மேம்படுத்த வேண்டும்: Postgres-ஐ வேகமான storage-ல் வைத்திருக்கவும், அதற்குத் தேவையான shared memory-ஐ வழங்கவும், மேலும் retention settings மூலம் தேவையற்ற கோப்புகள் மற்றும் பழைய பதிப்புகளை நீக்கிவிடவும்; அவற்றை நிரந்தரமாகச் சேமிக்க வேண்டாம்.

மூன்றாவது சிக்கல், preview generation மற்ற செயல்பாடுகளுடன் போட்டியிடுவது. சிறிய server-ல், preview providers-ஐக் குறைவாக வைத்திருக்கவும், வேலை நேரத்தில் ஒருபோதும் occ preview:generate-all-ஐ இயக்க வேண்டாம். உங்கள் சேமிப்பில் பெரும்பாலானவை தொலைபேசி கேமரா புகைப்படங்களாக இருந்தால், அந்த thumbnail உருவாக்கத்தை அதற்கென பிரத்யேகமாக உருவாக்கப்பட்ட photo server-க்கு மாற்றவும். RAM, phone apps மற்றும் backup commands அடிப்படையில் PhotoPrism மற்றும் Immich ஒப்பீடு கட்டுரை, Nextcloud-ஐ விட இவை ஒவ்வொன்றும் எவ்வளவு செலவாகும் என்பதை விளக்குகிறது.

இதைத் தாண்டி, கூடுதல் வசதிகள் ஒவ்வொன்றிற்கும் தனித்தனி machine-ஐப் பயன்படுத்துவதே சிறந்தது. Collabora மற்றும் full-text search ஆகியவை தனித்தனி memory தேவைகளைக் கொண்ட resident services ஆகும். உங்கள் கோப்புகளின் ஒரே நகலை வைத்திருக்கும் அதே server-ல் இவற்றை இயக்குவது, தேவையற்ற ஆபத்தை மட்டுமே அதிகரிக்கும். browser-ல் ஆவணங்களைத் திருத்தும் வசதி உங்களுக்குத் தேவைப்பட்டால், OnlyOffice மற்றும் Collabora-வை வேறுபடுத்தும் vendor RAM அளவுகள் மற்றும் connection வரம்புகள் கட்டுரையைப் படித்து, 2 முதல் 4 GB RAM கொண்ட VPS-ல் எதை இயக்க முடியும் என்பதை முடிவு செய்யவும். volume-ன் அளவு போதுமானதாக இல்லாதபோது, கோப்புச் சேமிப்பை S3-compatible primary storage-க்கு மாற்றவும். இது backup எடுப்பதை எளிதாக்காது, மாறாகக் கடினமாக்கும் என்பதை நினைவில் கொள்க: database-ல் தான் metadata இருக்கும், எனவே bucket-உடன் சேர்த்து அதையும் backup எடுக்க வேண்டும்.

instance உண்மையான பயனர்களுக்குச் சேவை செய்யத் தொடங்கியதும், Uptime Kuma-வை முன்னால் நிறுவவும். இதன் மூலம் sync clients-க்குத் தெரிவதற்கு முன்பே downtime குறித்து நீங்கள் அறிந்துகொள்ளலாம். ஒரு private cloud-ஐ உங்கள் சொந்த mail server-உடன் இணைப்பது சிறப்பாக இருக்கும். சேவைகளை நீங்களே கைகளால் இணைக்க விரும்பவில்லை என்றால், Cloudron, CasaOS மற்றும் Coolify போன்ற தளங்களை ஒப்பிட்டுப் பார்த்து, உங்களுக்கானதைத் தேர்வு செய்யவும். self-hosted search engine-ஐ அடுத்து நிறுவத் திட்டமிட்டால், மேலே குறிப்பிட்டவற்றிலிருந்து மாறுபட்ட சிக்கல்களைச் சந்திக்க நேரிடும்: SearXNG-ன் 429 errors என்பது அதன் சொந்த rate limiter-ஆல் அல்லது upstream engines உங்கள் VPS IP-ஐத் தடுப்பதாலோ ஏற்படலாம். log கோப்புகளைப் பார்த்தால் மட்டுமே இதற்கான காரணத்தை அறிய முடியும்.

FAQ

Postgres-க்கு பதிலாக SQLite-ல் Nextcloud-ஐ இயக்க முடியுமா?

இயக்கலாம், அதிகாரப்பூர்வ image-ம் அதற்கு அனுமதிக்கும். ஆனால், ஒரு desktop sync client ஒரே நேரத்தில் பல கோரிக்கைகளை அனுப்பும்போது SQLSTATE[HY000]: General error: 5 database is locked பிழையும் HTTP 500 பிழைகளும் ஏற்படும். SQLite முழு தரவுத்தளத்திற்கும் write lock-ஐப் பயன்படுத்துகிறது. Nextcloud தொடர்ந்து கோப்புகளை எழுதுதல், file locks, activity rows மற்றும் job state போன்றவற்றைச் செய்வதால் இது சிக்கலை உண்டாக்கும். தொடக்கத்திலிருந்தே Postgres அல்லது MariaDB-ஐப் பயன்படுத்துங்கள்; occ db:convert-type வசதி இருந்தாலும், நேரலையில் உள்ள தரவுகளை முழுமையாக இடமாற்றம் செய்வது கடினமான செயல்.

Nextcloud VPS-க்கு உண்மையில் எவ்வளவு RAM தேவை?

பயனர்களின் எண்ணிக்கையை விட, ஒரே நேரத்தில் செயல்படும் கோரிக்கைகளின் (concurrency) அடிப்படையில் அளவிடவும். அதிகபட்ச memory பயன்பாடு என்பது, ஒரே நேரத்தில் வரும் கோரிக்கைகளின் எண்ணிக்கையை PHP_MEMORY_LIMIT-ஆல் பெருக்கி, அதனுடன் Postgres shared buffers, ஒவ்வொரு இணைப்பிற்கும் ஒரு backend மற்றும் preview generation-க்கான கூடுதல் தேவை ஆகியவற்றைக் கூட்டி கணக்கிடப்படுகிறது. நீங்கள் preview-களைக் கட்டுப்படுத்தி swap சேர்த்தால், 2 GB RAM கொண்ட server ஒரு சிறிய குடும்பத்தின் பயன்பாட்டிற்குப் போதுமானது. Collabora அல்லது full-text search போன்றவற்றைச் சேர்த்தால், கூடுதல் சேவைகளுக்கான RAM-ஐத் தனியாக ஒதுக்க வேண்டும்.

nginx reverse proxy-க்கு பின்னால் பெரிய கோப்புகளைப் பதிவேற்றும்போது ஏன் தோல்வியடைகிறது?

proxy-ல் உள்ள இரண்டு அமைப்புகள் இதற்கு முக்கியக் காரணம்: client_max_body_size இயல்பாக 1 MB என இருப்பதால் கோரிக்கை பாதியிலேயே துண்டிக்கப்படுகிறது. மேலும், proxy_read_timeout / proxy_send_timeout ஆகியவற்றின் மதிப்பு குறைவாக இருந்தால், நீண்ட நேரப் பதிவேற்றங்கள் பாதியிலேயே நின்றுவிடும். இரண்டையும் போதுமான அளவு அதிகரிக்கவும், proxy_request_buffering off-ஐ spool செய்வதற்குப் பதிலாக stream செய்ய மாற்றவும், மேலும் app container-ல் PHP_UPLOAD_LIMIT-ஐ அதற்கு இணையாக அதிகரிக்கவும்.

Nextcloud ஏன் redirect loop-ல் சிக்கிக்கொள்கிறது அல்லது reverse proxy குறித்து எச்சரிக்கிறது?

Container-ஆனது 127.0.0.1-ல் உள்ள nginx-ஐப் பார்க்காது; அது Docker bridge gateway-ஐ மட்டுமே பார்க்கும், இது 172.x வரம்பிற்குள் இருக்கும். இந்த முகவரி TRUSTED_PROXIES-ல் விடுபட்டிருந்தால், X-Forwarded-Proto: https header புறக்கணிக்கப்படும். இதனால் Nextcloud http:// URL-களை உருவாக்கும், proxy அவற்றை மீண்டும் திருப்பி அனுப்பும். TRUSTED_PROXIES-ஐ உண்மையான bridge subnet-க்கு அமைத்து, OVERWRITEPROTOCOL: https-ஐ உறுதிப்படுத்தவும்.

Nextcloud-ஐ 29-லிருந்து நேரடியாக 31-க்கு upgrade செய்ய முடியுமா?

முடியாது. Nextcloud ஒரு முறைக்கு ஒரு major version-ஐ மட்டுமே ஆதரிக்கிறது. பதிப்புகளைத் தவிர்த்தால் Updates between multiple major versions and downgrades are unsupported. பிழை ஏற்பட்டு, instance maintenance mode-ல் நின்றுவிடும். முதலில் backup எடுக்கவும், பின் app மற்றும் cron ஆகிய இரண்டு சேவைகளிலும் tag-ஐ ஒரு major version உயர்த்தவும். docker compose pull && docker compose up -d செய்யவும், occ status மூலம் சரிபார்க்கவும், பிறகு அடுத்த கட்டத்திற்குச் செல்லவும்.