VPS లో Docker తో Nextcloud ని ఎలా సెటప్ చేయాలి?

మీరు వాస్తవానికి నిర్మిస్తున్నది

ఈ గైడ్‌లో, మీరు ఒక పటిష్టమైన మరియు స్కేలబుల్ వెబ్ సర్వర్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను ఏర్పాటు చేస్తున్నారు. దీని ప్రధాన ఉద్దేశ్యం ఒకే సర్వర్‌పై బహుళ అప్లికేషన్‌లను సురక్షితంగా మరియు సమర్థవంతంగా నిర్వహించడం. మీరు నిర్మించే ఈ సెటప్‌లో ఈ క్రింది అంశాలు ఉంటాయి:

• Reverse Proxy: Nginx లేదా Caddy వంటి సాఫ్ట్‌వేర్‌ను ఉపయోగించి, ఇన్‌కమింగ్ ట్రాఫిక్‌ను సరైన అప్లికేషన్‌కు మళ్లించడం.
• TLS Termination: SSL/TLS సర్టిఫికేట్‌లను ప్రాక్సీ స్థాయిలో నిర్వహించడం ద్వారా, ప్రతి అప్లికేషన్‌కు విడిగా సర్టిఫికేట్ అవసరం లేకుండా చేయడం.
• Containerization: ప్రతి అప్లికేషన్‌ను Docker కంటైనర్‌గా రన్ చేయడం, తద్వారా వాటి మధ్య డిపెండెన్సీ సమస్యలు లేకుండా చూడటం.
• Centralized Logging: అన్ని అప్లికేషన్ల లాగ్‌లను ఒకే చోట పర్యవేక్షించడం ద్వారా ట్రబుల్షూటింగ్‌ను సులభతరం చేయడం.

ఈ నిర్మాణం ద్వారా మీరు మీ సర్వర్ యొక్క attack surface ను తగ్గించడమే కాకుండా, భవిష్యత్తులో మరిన్ని సేవలను జోడించడానికి అవసరమైన సౌలభ్యాన్ని పొందుతారు.

Docker Compose తో Nextcloud నిర్వహణ

ఈ గైడ్ ఒక VPS పై Docker Compose ఉపయోగించి Nextcloud ను రన్ చేయడం, దానికి ముందు Let's Encrypt TLS ను అమర్చడం మరియు సమర్థవంతంగా పనిచేసే బ్యాకప్ విధానాన్ని సెటప్ చేయడం గురించి వివరిస్తుంది. ఇందులో నాలుగు కంటైనర్లు మరియు ఒక ప్రాక్సీ ఉంటాయి: లూప్‌బ్యాక్ (loopback) పై వినే అధికారిక nextcloud ఇమేజ్, ఫైల్ మెటాడేటాను నిల్వ చేసే Postgres, ఫైల్ లాక్‌లను నిర్వహించే Redis, కేవలం cron లూప్ కోసం మాత్రమే నడిచే రెండవ Nextcloud ఇమేజ్ కాపీ, మరియు వీటన్నింటికీ ముందు TLS ను టెర్మినేట్ చేసే హోస్ట్-స్థాయి nginx. ఇన్‌స్టాలేషన్ ప్రక్రియకు సుమారు ఇరవై నిమిషాలు పడుతుంది, కానీ ఇది అంత ముఖ్యమైనది కాదు. మొదటి గంటలో తీసుకునే రెండు నిర్ణయాలు ఒక సంవత్సరం తర్వాత మీ ఫైల్స్ సురక్షితంగా ఉంటాయా లేదా అని నిర్ణయిస్తాయి: SQLite కు బదులుగా ఒక నిజమైన డేటాబేస్ వాడటం, మరియు డేటా డైరెక్టరీ, డేటాబేస్ మరియు config.php లను ఒకే స్థిరమైన సెట్‌గా బ్యాకప్ చేయడం.

FAQ

SQLite కు బదులుగా Postgres ఎందుకు వాడాలి?

SQLite చిన్న అప్లికేషన్లకు సరిపోతుంది, కానీ Nextcloud వంటి ఫైల్-సింక్ సేవలకు ఇది సరిపోదు. ఎక్కువ ఫైల్స్ ఉన్నప్పుడు SQLite పనితీరు గణనీయంగా తగ్గుతుంది మరియు డేటాబేస్ లాక్ సమస్యలు తలెత్తుతాయి. Postgres వాడటం వల్ల డేటా సమగ్రత (integrity) మరియు వేగవంతమైన క్వెరీ ప్రాసెసింగ్ లభిస్తాయి.

బ్యాకప్ ఎందుకు ముఖ్యం?

కేవలం ఫైల్స్ కాపీ చేయడం వల్ల డేటాబేస్ స్థితి మరియు ఫైల్స్ మధ్య సమన్వయం దెబ్బతింటుంది. config.php లోని కాన్ఫిగరేషన్ ఫైల్స్, డేటాబేస్ డంప్ మరియు యూజర్ ఫైల్స్ అన్నీ ఒకే సమయానికి (consistent state) బ్యాకప్ తీసుకోకపోతే, రీస్టోర్ చేసేటప్పుడు డేటా కరప్ట్ అయ్యే అవకాశం ఉంది.

###
ముందస్తు అవసరాలు

ఈ గైడ్ Ubuntu 24.04 LTS లేదా Debian 13 ఆపరేటింగ్ సిస్టమ్‌లను ఉపయోగిస్తుందని భావిస్తుంది. Docker Engine మరియు Docker's repository నుండి ఇన్‌స్టాల్ చేయబడిన Compose v2 plugin ఉండాలి. అలాగే, మీ VPS IP అడ్రస్‌కు పాయింట్ చేసేలా ఒక DNS A రికార్డు (మీకు IPv6 ఉంటే AAAA రికార్డు కూడా) ఇప్పటికే సిద్ధంగా ఉండాలి. ఇవన్నీ మీరు నియంత్రించే సర్వర్‌పైనే జరగాలి; మరొకరి SaaS ప్లాట్‌ఫారమ్‌లో TLS termination చేయడం లేదా డేటాబేస్ డంప్ తీసుకోవడం సాధ్యం కాదు.

###
FAQ

TLS termination అంటే ఏమిటి?

TLS termination అనేది ఒక reverse proxy సర్వర్ ద్వారా HTTPS అభ్యర్థనలను స్వీకరించి, వాటిని డీక్రిప్ట్ చేసి, వెనుక ఉన్న అప్లికేషన్‌కు సాధారణ HTTP ద్వారా పంపే ప్రక్రియ. దీనివల్ల ప్రతి అప్లికేషన్‌కు విడిగా SSL certificates నిర్వహించాల్సిన అవసరం ఉండదు.

నా సర్వర్‌లో Docker Compose ఎందుకు అవసరం?

Docker Compose ద్వారా బహుళ కంటైనర్లను ఒకే YAML ఫైల్ ద్వారా సులభంగా నిర్వహించవచ్చు. ఇది నెట్‌వర్కింగ్, వాల్యూమ్ మౌంటింగ్ మరియు సర్వీస్ డిపెండెన్సీలను క్రమబద్ధీకరిస్తుంది.

DNS రికార్డులు ఎందుకు ముఖ్యం?

cloud.example.com వంటి డొమైన్ పేరు మీ సర్వర్ IPకి మ్యాప్ అయితేనే, బయటి ప్రపంచం నుండి వచ్చే ట్రాఫిక్ మీ సర్వర్‌కు చేరుతుంది. సరైన DNS కాన్ఫిగరేషన్ లేకపోతే, TLS సర్టిఫికెట్ జారీ చేయడం (Let's Encrypt వంటి వాటి ద్వారా) సాధ్యం కాదు.

మెమరీ వినియోగం: అసలు మెమరీని దేనికోసం ఉపయోగిస్తారు

Nextcloud మెమరీ వినియోగం ప్రధానంగా మూడు అంశాలపై ఆధారపడి ఉంటుంది, వీటిలో ఏదీ నేరుగా "Nextcloud" కు సంబంధించినది కాదు.

PHP workers. -apache ఇమేజ్ ప్రతి ఏకకాల అభ్యర్థనను (concurrent request) ఒక worker ప్రాసెస్ ద్వారా అందిస్తుంది, ఇది PHP ఇంటర్‌ప్రెటర్‌ను కలిగి ఉంటుంది. PHP అభ్యర్థనను నిలిపివేసేలోపు ప్రతి worker గరిష్టంగా PHP_MEMORY_LIMIT వరకు పెరగవచ్చు. మీ worst-case మెమరీ వినియోగం సుమారుగా ఏకకాల అభ్యర్థనలు × మెమరీ పరిమితి కి సమానం. డెస్క్‌టాప్ సింక్ క్లయింట్ ప్రతి వినియోగదారునికి అనేక సమాంతర కనెక్షన్‌లను తెరుస్తుంది. వినియోగదారుల సంఖ్య కాదు, ఏకకాల అభ్యర్థనల సంఖ్యే మెమరీ పరిమితిని నిర్ణయిస్తుంది.

డేటాబేస్. Postgres ప్రతి కనెక్షన్‌కు ఒక backend ను ఫోర్క్ చేస్తుంది మరియు shared buffers ను మెమరీలో ఉంచుతుంది. దీని పనితీరు ఫైళ్ల సంఖ్యపై ఆధారపడి ఉంటుంది, ఫైళ్ల పరిమాణంపై కాదు: oc_filecache ప్రతి వినియోగదారుని ప్రతి ఫైల్‌కు ఒక అడ్డు వరుసను (row) కలిగి ఉంటుంది. వంద పెద్ద ఫైళ్ల కంటే లక్ష చిన్న ఫైళ్లు ఉన్నప్పుడు డేటాబేస్ ఎక్కువ మెమరీని తీసుకుంటుంది.

ప్రివ్యూ జనరేషన్. థంబ్‌నెయిల్‌ను రూపొందించేటప్పుడు, అది సోర్స్ ఇమేజ్‌ను పూర్తి రిజల్యూషన్‌లో మెమరీలోకి డీకోడ్ చేస్తుంది. వీడియో ప్రివ్యూల కోసం ffmpeg ను ఉపయోగిస్తుంది. occ preview:generate-all ను రన్ చేయడం వల్ల ఈ ప్రక్రియ పదేపదే జరుగుతుంది, ఇది చిన్న VPS సర్వర్లను OOM killer బారిన పడేలా చేసే అత్యంత సాధారణ కారణం.

Redis వినియోగం తక్కువగానే ఉంటుంది. మీరు తర్వాత జోడించే Collabora, full-text search, antivirus scanner వంటివి విడివిడి సర్వీసులుగా మెమరీని తీసుకుంటాయి. వీటిని ఎనేబుల్ చేసే ముందే మీ ప్లానింగ్‌లో వీటిని పరిగణనలోకి తీసుకోవాలి.

మీకు RAM తక్కువగా ఉంటే, ఈ క్రింది మార్పులు చేయండి: PHP_MEMORY_LIMIT ను తగ్గించండి, preview_max_x / preview_max_y / preview_max_filesize_image లను పరిమితం చేయండి, enabledPreviewProviders లో మీరు వాడే ఫార్మాట్లను మాత్రమే ఉంచండి, మరియు trashbin_retention_obligation, versions_retention_obligation లను సెట్ చేయండి. తద్వారా డేటా డైరెక్టరీ మీ ఫైళ్ల పరిమాణం కంటే అనేక రెట్లు పెరగకుండా ఉంటుంది. ఒక swap file ను జోడించండి. Swap నెమ్మదిగా ఉన్నప్పటికీ, అప్‌గ్రేడ్ సమయంలో OOM kill జరగడం కంటే ఇది మేలు.

SQLite ఎందుకు విఫలమవుతుంది

Nextcloud లో SQLite సపోర్ట్ ఉంటుంది మరియు అధికారిక ఇమేజ్ దానిని సులభంగానే వాడుకుంటుంది. కానీ మీరు అలా చేయకండి. SQLite డేటాబేస్ మొత్తం మీద ఒకేసారి ఒకే రైటర్ (writer) మాత్రమే ఉండేలా లాక్ చేస్తుంది. Nextcloud నిరంతరం ఫైల్ లాక్స్, యాక్టివిటీ రోస్, కాష్ ఎంట్రీలు, జాబ్ స్టేట్ వంటి వాటిని రాస్తూనే ఉంటుంది. ఒక డెస్క్‌టాప్ క్లయింట్ డైరెక్టరీని సింక్ చేస్తున్నప్పుడు అనేక సమాంతర అభ్యర్థనలు (parallel requests) వస్తాయి. ఈ పద్ధతిలో మీకు SQLSTATE[HY000]: General error: 5 database is locked మరియు HTTP 500 ఎర్రర్స్ వస్తాయి. మీ ఇన్‌స్టాన్స్ ఉపయోగకరంగా మారినప్పుడే ఈ వైఫల్యం కనిపిస్తుంది.

తరువాత occ db:convert-type ఉపయోగించి మార్చుకోవడం సాధ్యమే, కానీ ఇది లైవ్ డేటాసెట్‌పై చేసే సుదీర్ఘమైన మరియు పూర్తిస్థాయి మైగ్రేషన్. కాబట్టి ప్రారంభం నుండే Postgres లేదా MariaDB వాడండి.

Compose ఫైల్

దీనిని /srv/nextcloud/compose.yaml లో ఉంచండి, రహస్యాలను (secrets) పక్కనే ఉన్న .env ఫైల్‌లో 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:

మేజర్ ట్యాగ్‌ను పిన్ చేయండి మరియు 31 ని యథాతథంగా కాపీ చేసే ముందు Docker Hub లో ప్రస్తుత వెర్షన్‌ను తనిఖీ చేయండి. latest భవిష్యత్తులో ఏదైనా docker compose pull అప్‌డేట్ సమయంలో మిమ్మల్ని మేజర్ వెర్షన్ దాటించేలా చేస్తుంది, దీనికి Nextcloud మద్దతు ఇవ్వదు.

డేటా డైరెక్టరీని నేమ్డ్ వాల్యూమ్‌గా కాకుండా బైండ్ మౌంట్‌గా ఉద్దేశపూర్వకంగానే ఉంచాము: బ్యాకప్ టూల్‌ను నేరుగా పాయింట్ చేయగల పాత్ ఉండటం, శుభ్రత కంటే ముఖ్యమైనది. దీనిని ఇమేజ్ యొక్క www-data UID తో మరియు Nextcloud కు అవసరమైన అనుమతులతో సృష్టించండి:

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

పోర్ట్ పబ్లిష్ గమనించండి: 127.0.0.1:8080:80. Docker పోర్ట్‌లను DNAT రూల్స్ రాయడం ద్వారా పబ్లిష్ చేస్తుంది, ఇవి ufw యొక్క INPUT చైన్ ప్యాకెట్‌ను చూడకముందే అమలు చేయబడతాయి. కేవలం 8080:80 అని ఇస్తే, ufw సెట్టింగ్‌లతో సంబంధం లేకుండా ఎన్‌క్రిప్షన్ లేని Nextcloud పబ్లిక్ ఇంటర్నెట్‌కు అందుబాటులోకి వస్తుంది. లూప్‌బ్యాక్ (loopback) కు బైండ్ చేయడం ద్వారా దీనిని పబ్లిక్ ఇంటర్‌ఫేస్ నుండి దూరంగా ఉంచవచ్చు. అప్పుడు ఫైర్‌వాల్ కేవలం ప్రాక్సీని మాత్రమే అనుమతించాల్సి ఉంటుంది. ఒకవేళ మీరు SSHను మొత్తం ఇంటర్నెట్‌కు అందుబాటులో ఉంచకూడదనుకుంటే, self-hosted WireGuard VPN ద్వారా VPS ని చేరుకోవడం ద్వారా పబ్లిక్ రూల్స్ నుండి పోర్ట్ 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 ని గమనించండి. మొదటిసారి బూట్ అయినప్పుడు మొత్తం అప్లికేషన్ ట్రీ వాల్యూమ్‌లోకి కాపీ అవుతుంది మరియు ఇన్‌స్టాలర్ రన్ అవుతుంది; అది పూర్తయ్యే వరకు కంటైనర్ ఏ సమాధానం ఇవ్వదు.

TLS మరియు రివర్స్ ప్రాక్సీ

మీ డిస్ట్రిబ్యూషన్ నుండి nginx మరియు certbot లను ఇన్‌స్టాల్ చేయండి, సరైన server_name తో ఒక సాధారణ port-80 సర్వర్ బ్లాక్‌ను సృష్టించండి, ఆపై certbot ద్వారా దానిని రీరైట్ చేయనివ్వండి. HTTP-01 ఛాలెంజ్ యొక్క మెకానిక్స్, రెన్యూవల్ టైమర్ మరియు ఫెయిల్యూర్ మోడ్‌ల గురించి Ubuntu 24.04లో certbot మరియు nginx తో Let's Encrypt సర్టిఫికేట్‌లను జారీ చేయడం లో పూర్తిగా వివరించబడింది:

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

Certbot, ssl_certificate లైన్లను మరియు :80 → :443 రీడైరెక్ట్‌ను జోడిస్తుంది, అలాగే 90 రోజుల సర్టిఫికేట్‌ను రెన్యూ చేసే systemd టైమర్‌ను ఇన్‌స్టాల్ చేస్తుంది. ఇది ఉందో లేదో systemctl list-timers | grep certbot తో నిర్ధారించుకోండి, ఎందుకంటే ఎనేబుల్ చేయని రెన్యూవల్ టైమర్ 90 రోజుల గడువు ముగిసే బాంబులాంటిది.

ప్రాక్సీ బ్లాక్ వివరాలు:

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 పాత బిల్డ్‌ను కలిగి ఉంటుంది, అందులో దీనికి సమానమైనది listen 443 ssl http2;. మీ బిల్డ్ దేనిని అంగీకరిస్తుందో nginx -t మీకు తెలియజేస్తుంది.

client_max_body_size మరియు ఎక్కువ సమయం ఉండే read timeouts, పెద్ద ఫైల్స్ అప్‌లోడ్ మధ్యలోనే ఆగిపోకుండా చూస్తాయి. proxy_request_buffering off, అప్‌లోడ్ చేసిన ఫైల్‌ను ముందుగా ప్రాక్సీ డిస్క్‌లో సేవ్ చేయకుండా, నేరుగా స్ట్రీమ్ చేస్తుంది.

ఒక అప్లికేషన్ కోసం హోస్ట్‌పై nginx ఉండటమే అత్యంత సరళమైన పద్ధతి. ఒకవేళ Nextcloud ఇతర కంటైనర్లతో కలిసి VPSని పంచుకోవాల్సి వస్తే, అనేక అప్లికేషన్ల కోసం Docker Compose రివర్స్ ప్రాక్సీగా Traefikని రన్ చేయడం ద్వారా రూటింగ్ మరియు సర్టిఫికేట్ జారీ ప్రక్రియను కంటైనర్ లేబుల్స్‌లోకి మార్చవచ్చు. అక్కడ కూడా అదే client_max_body_size మరియు టైమౌట్ అంశాలు మిడిల్‌వేర్ మరియు ట్రాన్స్‌పోర్ట్ సెట్టింగ్‌లుగా మళ్ళీ కనిపిస్తాయి.

trusted_proxies మరియు overwriteprotocol

చాలా వరకు self-hosted Nextcloud ఇన్‌స్టాన్స్‌లలో తప్పులు జరిగే చోటు ఇదే, దీని లక్షణాలు అసలు కారణానికి సంబంధం లేనట్లుగా కనిపిస్తాయి.

X-Forwarded-Proto: https అనేది కేవలం trusted_proxies లో పేర్కొన్న చిరునామా నుంచి అభ్యర్థన వచ్చినప్పుడు మాత్రమే పరిగణనలోకి తీసుకోబడుతుంది. ఇది పరిగణనలోకి తీసుకోనప్పుడు, Nextcloud ఆ అభ్యర్థనను సాధారణ HTTP అని భావించి http:// URLలను జారీ చేస్తుంది; proxy వాటిని HTTPSకి దారి మళ్లిస్తుంది (redirect); బ్రౌజర్ దానిని అనుసరిస్తుంది; Nextcloud మళ్ళీ http:// ని జారీ చేస్తుంది. ఇదే redirect loop. OVERWRITEPROTOCOL: https అనేది సంబంధం లేకుండా స్కీమ్‌ను స్థిరపరుస్తుంది.

TRUSTED_PROXIES లో ఉన్న చిక్కు ఏమిటంటే, Nextcloud చూసే చిరునామా 127.0.0.1 కాదు. nginx హోస్ట్‌పై నడుస్తూ ప్రచురించబడిన పోర్ట్‌కు కనెక్ట్ అవుతుంది, కాబట్టి కంటైనర్ Docker bridge గేట్‌వేని చూస్తుంది, ఇది 172.x లో ఏదో ఒకటి అయి ఉంటుంది. అసలైన సబ్‌నెట్‌ను ఇలా కనుగొనండి:

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

ఆ CIDR ను (లేదా దానిని కవర్ చేసే 172.16.0.0/12 ని) TRUSTED_PROXIES లో ఉంచండి. దీనిని మరీ ఎక్కువగా సెట్ చేస్తే ఏ క్లయింట్ అయినా X-Forwarded-For ని స్పూఫ్ (spoof) చేయగలదు; తప్పుగా సెట్ చేస్తే ప్రతి లాగిన్ గేట్‌వే చిరునామా నుంచే వస్తున్నట్లు కనిపిస్తుంది, brute-force రక్షణ మీ మొత్తం ఇన్‌స్టాన్స్‌ను ఒకేసారి బ్లాక్ చేస్తుంది, మరియు అడ్మిన్ ఓవర్‌వ్యూలో "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy." అని చూపిస్తుంది.

OVERWRITECLIURL అనేది cron కంటైనర్‌కు ముఖ్యం, ఎందుకంటే దీనికి హోస్ట్‌నేమ్‌ను ఊహించడానికి ఎటువంటి ఇన్‌కమింగ్ అభ్యర్థన ఉండదు. ఇది లేకపోతే, బ్యాక్‌గ్రౌండ్ జాబ్‌లు localhost కి లింక్‌లను సృష్టిస్తాయి మరియు ఇమెయిల్ నోటిఫికేషన్‌లు పనికిరాని URLలను పంపుతాయి.

నేపథ్య పనులు (Background jobs): cron, AJAX కాదు

Nextcloud యొక్క డిఫాల్ట్ జాబ్ రన్నర్ AJAX: ఎవరైనా పేజీని లోడ్ చేసినప్పుడు మాత్రమే పనులు జరుగుతాయి. 04:00 గంటలకు ఎవరూ బ్రౌజ్ చేయరు కాబట్టి, ట్రాష్ ఎక్స్‌పైరీ, వెర్షన్ల క్లీనప్, ప్రివ్యూలు మరియు ఫెడరేటెడ్ రిట్రైలు ఆగిపోతాయి. దీనివల్ల డేటా డైరెక్టరీ పరిమాణం నిరంతరం పెరుగుతూ ఉండటం మొదటి లక్షణం. పైన పేర్కొన్న cron సర్వీస్ అదే వాల్యూమ్‌లపై అధికారిక /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 సెట్ చేసుకోవడం మంచిది.

బ్యాకప్‌లు: మూడు అంశాలు, లేదా ఏవీ లేనట్టే

కేవలం ఫైల్‌సిస్టమ్‌ను మాత్రమే బ్యాకప్ చేయడం వల్ల పాడైపోయిన ఇన్‌స్టన్స్‌ను పునరుద్ధరించలేము. డేటా డైరెక్టరీలో కేవలం బైట్లు మాత్రమే ఉంటాయి; Postgres ఫైల్ కాష్, షేర్లు, యూజర్లు మరియు యాప్ స్థితిని కలిగి ఉంటుంది; config.php డేటాబేస్ క్రెడెన్షియల్స్, ఇన్‌స్టన్స్ ID మరియు పాస్‌వర్డ్ సాల్ట్‌ను కలిగి ఉంటుంది. డేటాబేస్ లేకుండా ఫైళ్లను పునరుద్ధరిస్తే Nextcloud వాటిని గుర్తించలేదు. config.php లేకుండా డేటాబేస్‌ను పునరుద్ధరిస్తే అది డేటాబేస్‌ను తెరవలేదు. పాత డేటాబేస్‌ను కొత్త డేటా డైరెక్టరీపై పునరుద్ధరిస్తే, షేర్లు మారిపోయిన ఫైళ్లను సూచిస్తాయి.

క్వియెస్డ్ (quiesced) స్థితిలో ఉన్న ఇన్‌స్టన్స్ నుండి ఈ మూడింటినీ బ్యాకప్ చేయండి:

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

మెయింటెనెన్స్ మోడ్ వల్లనే డంప్ మరియు ఫైల్ కాపీ ఒకదానితో ఒకటి సరిపోలుతాయి. దీన్ని దాటవేస్తే, rsync ఇంకా చేరుకోని ఫైల్‌ను సూచించే డేటాబేస్‌ను మీరు బ్యాకప్ చేసే ప్రమాదం ఉంది. ఈ స్క్రిప్ట్ టైమ్‌స్టాంప్ ఉన్న డేటాబేస్ డంప్‌లను ఉంచుతుంది, కానీ డేటా డైరెక్టరీకి సంబంధించి ఒకే ఒక రోలింగ్ మిర్రర్‌ను ఉంచుతుందని గమనించండి. rsync --delete ప్రతి రన్ సమయంలో దానిని ఓవర్‌రైట్ చేస్తుంది, కాబట్టి కేవలం సరికొత్త డంప్ మాత్రమే ఫైల్ కాపీతో సరిపోలుతుంది.

ఆ తర్వాత వాటిని సర్వర్ నుండి బయటకు తరలించండి. బ్యాకప్ చేసిన సర్వర్‌లోనే ఆ బ్యాకప్ ఉంటే అది కేవలం కాపీ మాత్రమే, బ్యాకప్ కాదు. restic ద్వారా ఆబ్జెక్ట్ స్టోరేజ్ లేదా రెండవ హోస్ట్‌కు పంపడం సాధారణ పద్ధతి. దీనిలోని డీడూప్లికేషన్ (deduplication) ఫీచర్, రాత్రిపూట తీసే tarball కంటే డేటా డైరెక్టరీని మెరుగ్గా నిర్వహిస్తుంది. రిపోజిటరీ ఇనిషియలైజేషన్ నుండి నైట్లీ టైమర్ మరియు రీస్టోర్ డ్రిల్ వరకు పూర్తి సెటప్ ఇక్కడ ఉంది: off-box VPS backups with restic.

పునరుద్ధరణ (restore) అనేది కేవలం రివర్స్ ప్రక్రియ కాదు. కొత్తగా ప్రారంభించిన స్టాక్ ఇన్‌స్టాలర్‌ను రన్ చేసి, సరికొత్త config.php, కొత్త ఇన్‌స్టన్స్ ID మరియు పాస్‌వర్డ్ సాల్ట్‌ను రాస్తుంది. ఆ కొత్త గుర్తింపుపై పాత డంప్‌ను ఇంపోర్ట్ చేస్తే సెషన్లు మరియు షేర్ టోకెన్లు పాడవుతాయి. పాత గుర్తింపును ముందుగా ఈ క్రమంలో తిరిగి ఉంచండి:

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 ఫైల్ కాష్‌ను డిస్క్‌లో ఉన్న వాస్తవ డేటాతో సరిపోల్చుతుంది. మీకు అవసరమయ్యే ముందు, ఒకసారి విడి VPSలో దీనిని ప్రాక్టీస్ చేయండి. డిస్క్‌లోని బైట్లు మరియు Postgres లోని మెటాడేటా మధ్య ఉండే ఈ విభజన ఇలాంటి అన్ని అప్లికేషన్లకు వర్తిస్తుంది. అందుకే an Immich backup that captures the library but not the database restores to an empty timeline.

అప్‌గ్రేడ్‌లు: ఒకసారికి ఒక మేజర్ వెర్షన్ మాత్రమే

Nextcloud ఒకసారికి సరిగ్గా ఒక మేజర్ వెర్షన్‌ను మాత్రమే అప్‌గ్రేడ్ చేయడానికి మద్దతు ఇస్తుంది. 29 నుంచి 31కి నేరుగా మారడం సరిగ్గా జరగదు, అది Exception: Updates between multiple major versions and downgrades are unsupported. తో విఫలమై మిమ్మల్ని maintenance mode లో ఉంచుతుంది.

Docker అప్‌గ్రేడ్ విధానం ఇది: బ్యాకప్ తీసుకోండి, app మరియు cron సర్వీసులలోని ట్యాగ్‌ను 31 నుండి 32 కి మార్చండి, ఆపై docker compose pull && docker compose up -d చేయండి, చివరగా docker compose logs -f app రన్ చేయండి. ఇమేజ్ ఎంట్రీపాయింట్ పాత డేటాకు వ్యతిరేకంగా కొత్త కోడ్‌ను గుర్తించి, అదే స్వయంగా occ upgrade ని రన్ చేస్తుంది. దీనిని మధ్యలో ఆపవద్దు. లాగ్స్ నిశ్శబ్దంగా మారినప్పుడు, docker compose exec -u www-data app php occ status రన్ చేసి, versionstring ని తనిఖీ చేయండి మరియు యాప్స్ అన్నీ తిరిగి ఎనేబుల్ అయ్యాయో లేదో చూడండి.

మిమ్మల్ని కాపాడే రెండు నియమాలు: ఒక మేజర్ వెర్షన్ పెంచండి, ధృవీకరించండి, ఆపై తదుపరి వెర్షన్‌కు వెళ్లండి. మరియు cron ని కూడా మార్చకుండా app సర్వీస్‌లోని ట్యాగ్‌ను ఎప్పుడూ మార్చవద్దు; ఒకే డేటాబేస్‌పై రెండు వేర్వేరు Nextcloud వెర్షన్లను వాడటం డేటా పాడవ్వడానికి దారితీస్తుంది.

మీకు కనిపించే వాస్తవ లోపాలు

"Your data directory is readable by other users. Please change the permissions to 0770." bind-mount చేసిన డైరెక్టరీకి group లేదా world read bits ఉన్నాయి. 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 ఎప్పుడూ initialize చేయని చోటికి చూపిస్తోంది, path లో టైపింగ్ తప్పు ఉంది, లేదా పనిచేస్తున్న instance కింద కొత్త ఖాళీ డైరెక్టరీని మార్చారు. host path, 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 వద్ద దేనినీ చేరుకోలేకపోయింది. కంటైనర్ ఇంకా initialize అవుతుండవచ్చు (docker compose logs app తనిఖీ చేయండి), అది ఆగిపోయి ఉండవచ్చు (docker compose ps), లేదా publish లైన్ proxy_pass పోర్ట్‌తో సరిపోలడం లేదు. ss -ltnp | grep 8080 తో నిర్ధారించుకోండి.

ఒక redirect loop, లేదా admin overview లో "insecure" హెచ్చరికలు. OVERWRITEPROTOCOL: https లేదు, లేదా TRUSTED_PROXIES లో Docker gateway subnet లేదు. పైన ఉన్న proxy విభాగాన్ని చూడండి.

LockedException: "files/..." is locked. REDIS_HOST సెట్ చేసినప్పుడు, image Redis ను locking backend గా కాన్ఫిగర్ చేస్తుంది మరియు stale locks అరుదుగా ఉంటాయి. అది లేకపోతే, locks డేటాబేస్ టేబుల్ oc_file_locks లో ఉంటాయి మరియు మధ్యలో ఆగిపోయిన request వల్ల rows అలాగే ఉండిపోతాయి. మీరు స్వయంగా lock rows ను తొలగించే ముందు, Redis నిజంగా వాడుకలో ఉందో లేదో నిర్ధారించుకోండి, occ config:system:get memcache.locking Redis క్లాస్‌ను తిరిగి ఇవ్వాలి.

"The PHP memory limit is below the recommended value of 512MB." PHP_MEMORY_LIMIT ను పెంచి, కంటైనర్‌ను మళ్ళీ సృష్టించండి. ఇది మీ worst-case మెమరీ వినియోగంపై ఎలాంటి ప్రభావం చూపుతుందో గుర్తుంచుకోండి.

స్కేల్ పెరిగినప్పుడు వచ్చే సమస్యలు

మొదటి అడ్డంకి డేటా డైరెక్టరీ వాల్యూమ్ సామర్థ్యాన్ని మించిపోవడం. VPSలో వాల్యూమ్‌ను పెంచడం అంటే రీసైజ్ చేయడం మరియు ఫైల్‌సిస్టమ్‌ను విస్తరించడం; ఇది డిస్క్ 100% నిండిన తర్వాత చేసేదానికంటే ముందే ప్లాన్ చేసుకుంటే చాలా సులభం. కాబట్టి డిస్క్ వినియోగంపై ఇప్పుడే అలర్ట్స్ సెట్ చేసుకోండి.

రెండవ అడ్డంకి oc_filecache. ఫైల్ లిస్టింగ్ మరియు సింక్ స్కాన్‌లు రో కౌంట్ పెరిగేకొద్దీ నెమ్మదిస్తాయి. దీనికి పరిష్కారం డేటాబేస్ ఆప్టిమైజేషన్: Postgres ను వేగవంతమైన స్టోరేజ్‌లో ఉంచండి, దానికి తగినంత shared memory కేటాయించండి, మరియు పాత ఫైల్స్, వెర్షన్లను అలాగే ఉంచకుండా retention సెట్టింగ్స్ ద్వారా ఎప్పటికప్పుడు తొలగించండి.

మూడవది, ప్రివ్యూ జనరేషన్ ఇతర పనులతో పోటీ పడటం. చిన్న సర్వర్‌లో ప్రివ్యూ ప్రొవైడర్లను పరిమితం చేయండి మరియు పని వేళల్లో occ preview:generate-all రన్ చేయకండి. మీరు స్టోర్ చేసే వాటిలో ఫోన్ కెమెరా రోల్ ఎక్కువగా ఉంటే, ఆ థంబ్‌నెయిల్ పనులను ప్రత్యేకమైన ఫోటో సర్వర్‌కు తరలించండి. RAM, ఫోన్ యాప్స్ మరియు బ్యాకప్ కమాండ్ల పరంగా PhotoPrism మరియు Immich ల పోలిక Nextcloud బాక్స్‌తో పోలిస్తే వీటి ఖర్చు ఎంత ఉంటుందో వివరిస్తుంది.

ఆ తర్వాత, నిజాయితీగా చెప్పాలంటే, అదనపు ఫీచర్లకు ప్రత్యేక మెషిన్ అవసరం. Collabora మరియు full-text search అనేవి వేర్వేరు మెమరీ ప్రొఫైల్స్ కలిగిన ప్రత్యేక సర్వీసులు. వీటిని మీ ఫైల్స్ ఉన్న సర్వర్‌లోనే ఉంచడం వల్ల, ఎటువంటి ప్రయోజనం లేకుండానే ఫెయిల్యూర్ డొమైన్ పరిధి పెరుగుతుంది. బ్రౌజర్‌లో డాక్యుమెంట్ ఎడిటింగ్ కావాలనుకుంటే, OnlyOffice మరియు Collabora ల మధ్య RAM మరియు కనెక్షన్ పరిమితుల ఆధారంగా ఎంపిక 2 నుండి 4 GB VPS ఏది తట్టుకోగలదో నిర్ణయిస్తుంది. వాల్యూమ్ సరిపోనప్పుడు ఫైల్ స్టోరేజ్‌ను S3-compatible స్టోరేజ్‌కు మార్చండి. అయితే ఇది బ్యాకప్‌లను సులభతరం చేయదు, మరింత క్లిష్టతరం చేస్తుంది: డేటాబేస్ మెటాడేటాను కలిగి ఉంటుంది కాబట్టి, బకెట్‌తో పాటు డేటాబేస్‌ను కూడా డంప్ చేయాలి.

ఇన్‌స్టాన్స్ వినియోగదారులకు అందుబాటులోకి వచ్చిన తర్వాత, Uptime Kuma ను ముందు ఉంచండి, తద్వారా సింక్ క్లయింట్లు గుర్తించకముందే డౌన్‌టైమ్ గురించి మీకు తెలుస్తుంది. ప్రైవేట్ క్లౌడ్ మీ స్వంత మెయిల్ సర్వర్ తో బాగా పనిచేస్తుంది. ఒకవేళ మీరు సర్వీసులను మాన్యువల్‌గా కనెక్ట్ చేయకూడదనుకుంటే, Cloudron, CasaOS మరియు Coolify వంటి ప్లాట్‌ఫారమ్‌లను పరిశీలించండి. ఒకవేళ మీరు self-hosted సెర్చ్ ఇంజిన్‌ను ఏర్పాటు చేయాలనుకుంటే, పైన పేర్కొన్న వాటికంటే భిన్నమైన సమస్యలు ఎదురవుతాయి: SearXNG యొక్క 429 ఎర్రర్స్ దాని సొంత రేట్ లిమిటర్ వల్ల లేదా అప్‌స్ట్రీమ్ ఇంజిన్లు మీ VPS IPని బ్లాక్ చేయడం వల్ల రావచ్చు; ఏది కారణమో కేవలం లాగ్స్ మాత్రమే చెబుతాయి.

FAQ

నేను Nextcloud ను Postgres కు బదులుగా SQLite పై నడపవచ్చా?

మీరు నడపవచ్చు, అధికారిక image కూడా దీనిని అనుమతిస్తుంది, కానీ ఒకే డెస్క్‌టాప్ సింక్ క్లయింట్ సమాంతర అభ్యర్థనలను పంపినప్పుడు SQLSTATE[HY000]: General error: 5 database is locked మరియు HTTP 500 లోపాలు వస్తాయి. SQLite డేటాబేస్ మొత్తం మీద రైట్ లాక్ (write lock) తీసుకుంటుంది, కానీ Nextcloud నిరంతరం ఫైల్ లాక్‌లు, యాక్టివిటీ రోస్, జాబ్ స్టేట్ వంటి వాటిని రాస్తూనే ఉంటుంది. కాబట్టి Postgres లేదా MariaDB తో ప్రారంభించండి; occ db:convert-type అందుబాటులో ఉన్నప్పటికీ, ఇది లైవ్ డేటాపై చేసే సుదీర్ఘమైన మరియు సంక్లిష్టమైన మైగ్రేషన్ ప్రక్రియ.

Nextcloud VPS కి వాస్తవానికి ఎంత RAM అవసరం?

యూజర్ల సంఖ్యను బట్టి కాకుండా, ఒకే సమయంలో జరిగే పనుల (concurrency) ఆధారంగా పరిమాణాన్ని నిర్ణయించుకోండి. గరిష్ట మెమరీ వినియోగం అనేది సుమారుగా ఒకే సమయంలో జరిగే అభ్యర్థనల సంఖ్యను PHP_MEMORY_LIMIT తో గుణించగా వచ్చే విలువ, దానికి Postgres షేర్డ్ బఫర్లు, ప్రతి కనెక్షన్‌కు ఒక బ్యాకెండ్, మరియు ప్రివ్యూ జనరేషన్ సమయంలో పెరిగే అదనపు మెమరీని కలిపితే వస్తుంది. మీరు ప్రివ్యూలను పరిమితం చేసి, swap ఉపయోగిస్తే 2 GB సర్వర్ చిన్న కుటుంబ అవసరాలకు సరిపోతుంది; ఒకవేళ మీరు Collabora లేదా full-text search వంటివి జోడిస్తే, అదనపు సర్వీసుల కోసం మరిన్ని వనరులు అవసరమవుతాయి.

nginx రివర్స్ ప్రాక్సీ వెనుక పెద్ద ఫైల్ అప్‌లోడ్‌లు ఎందుకు విఫలమవుతాయి?

సాధారణంగా ప్రాక్సీలోని రెండు సెట్టింగ్‌లు దీనికి కారణం: client_max_body_size డిఫాల్ట్‌గా 1 MB వద్ద ఉంటే అభ్యర్థనను కత్తిరిస్తుంది, మరియు తక్కువ proxy_read_timeout / proxy_send_timeout విలువలు సుదీర్ఘమైన బదిలీలను మధ్యలోనే ఆపివేస్తాయి. ఈ రెండింటినీ తగినంత ఎక్కువగా సెట్ చేయండి, proxy_request_buffering off ను spool కు బదులుగా stream కు మార్చండి, మరియు యాప్ కంటైనర్‌లోని PHP_UPLOAD_LIMIT విలువను కూడా దానికి అనుగుణంగా పెంచండి.

Nextcloud ఎందుకు లూప్‌లో రీడైరెక్ట్ అవుతుంది లేదా రివర్స్ ప్రాక్సీ గురించి హెచ్చరిస్తుంది?

కంటైనర్ 127.0.0.1 వద్ద ఉన్న nginx ను చూడలేదు, అది 172.x లోని Docker బ్రిడ్జ్ గేట్‌వేని మాత్రమే చూస్తుంది. ఆ అడ్రస్ TRUSTED_PROXIES లో లేనప్పుడు, X-Forwarded-Proto: https హెడర్ విస్మరించబడుతుంది, Nextcloud http:// URLలను పంపుతుంది, మరియు ప్రాక్సీ వాటిని తిరిగి పంపుతుంది. TRUSTED_PROXIES ను సరైన బ్రిడ్జ్ సబ్‌నెట్‌కు సెట్ చేసి, OVERWRITEPROTOCOL: https ను పిన్ చేయండి.

నేను Nextcloud ను 29 వెర్షన్ నుండి నేరుగా 31 కి అప్‌గ్రేడ్ చేయవచ్చా?

లేదు. Nextcloud ఒకసారి అప్‌గ్రేడ్ చేసినప్పుడు ఒక మేజర్ వెర్షన్‌ను మాత్రమే సపోర్ట్ చేస్తుంది, వెర్షన్లను దాటవేస్తే Updates between multiple major versions and downgrades are unsupported. తో ఆగిపోయి, ఇన్‌స్టాన్స్ మెయింటెనెన్స్ మోడ్‌లో ఉండిపోతుంది. బ్యాకప్ తీసుకోండి, app మరియు cron సర్వీసుల ట్యాగ్‌ను ఒక మేజర్ వెర్షన్ పెంచండి, docker compose pull && docker compose up -d చేయండి, occ status తో ధృవీకరించండి, ఆపై మళ్ళీ ఇదే ప్రక్రియను పునరావృతం చేయండి.