ద్వారా Matt Connor 2026-07-14 · అప్‌డేట్ చేయబడింది 2026-07-25

VPSలో Nextcloud Dockerతో సెటప్ చేయడం TLS బ్యాకప్

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

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

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

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

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

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

Docker Compose, Postgres, Redis, nginx TLS ప్రాక్సీతో VPSపై Nextcloud నడపడం ఇక్కడ ఉంది. డేటా కోల్పోకుండా బ్యాకప్ మరియు అప్‌గ్రేడ్ దశలు కూడా ఉన్నాయి.

మీరు వాస్తవానికి నిర్మించేది ఏమిటి

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

ఇది Ubuntu 24.04 LTS లేదా Debian 13 అని ఊహిస్తుంది. Docker స్వంత రిపోజిటరీ నుండి ఇన్‌స్టాల్ చేసిన Compose v2 ప్లగిన్‌తో Docker Engine అవసరం. VPS వైపు cloud.example.com‌ను సూచిస్తూ ఇప్పటికే DNS A రికార్డ్ (మీకు IPv6 ఉంటే AAAA కూడా) ఉండాలి. ఇవన్నీ మీ నియంత్రణలో ఉన్న సర్వర్‌ను కావాలి. ఇతరుల SaaSపై TLS టెర్మినేషన్ మరియు డేటాబేస్ డంప్ చేయడం సాధ్యం కాదు.

పరిమాణ నిర్ధారణ: వాస్తవానికి మెమరీని ఏమి వాడుకుంటుంది

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

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

డేటాబేస్. ప్రతి కనెక్షన్‌కు Postgres ఒక బ్యాకెండ్‌ను ఫోర్క్ చేస్తుంది. షేర్డ్ బఫర్‌లను రెసిడెంట్‌గా ఉంచుతుంది. దాని వర్కింగ్ సెట్ బైట్ల సంఖ్యపై కాదు, ఫైళ్ల సంఖ్యతో పెరుగుతుంది: oc_filecache ప్రతి వినియోగదారుడి ప్రతి ఫైలుకు ఒక వరుసను కలిగి ఉంటుంది. లక్ష చిన్న ఫైళ్లు, వంద పెద్ద ఫైళ్ల కంటే డేటాబేస్‌పై ఎక్కువ భారం మోపుతాయి.

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

Redis పోలిస్తే సరసిగా చౌక. మీరు తరువాత జోడించే ప్రతిదీ — Collabora, ఫుల్-టెక్స్ట్ సెర్చ్, యాంటీవైరస్ స్కానర్ — వాటికి వాటికే ప్రత్యేక రెసిడెంట్ సర్వీస్‌లు ఉంటాయి. వాటిని ప్రారంభించడానికి ముందే మీ పరిమాణ ప్రణాళికలో చేర్చుకోండి.

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

SQLite ఎందుకు విరుగుతుంది

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

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

Compose ఫైలు

దీన్ని /srv/nextcloud/compose.yaml లో ఉంచండి, రహస్యాలను అదే స్థాయిలో ఉన్న .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 లో ప్రస్తుత ట్యాగ్‌ను తనిఖీ చేయండి. భవిష్యత్తులో ఏదైనా docker compose pull లో latest మిమ్మల్ని ఒక పెద్ద వెర్షన్ హద్దు దాటిస్తుంది. 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 ను ఉంచుతుంది. దాన్ని లూప్‌బ్యాక్‌కు బైండ్ చేయడం వల్ల అది పబ్లిక్ ఇంటర్‌ఫేస్ నుండి దూరంగా ఉంటుంది. అప్పుడు ఫైర్‌వాల్ ప్రాక్సీని మాత్రమే అనుమతించాలి — మరియు మీకు SSH ను మొత్తం ఇంటర్నెట్‌కు ఓపెన్‌గా ఉంచాలని ఇష్టం లేకపోతే, సెల్ఫ్-హోస్టెడ్ 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 మరియు సుదీర్ఘ రీడ్ టైమౌట్‌లు అనేవి పెద్ద అప్‌లోడ్‌లు మధ్యలో ఆగిపోకుండా ఆపడానికి ఉపయోగపడతాయి. proxy_request_buffering off అనేది మొత్తం ఫైల్‌ను ముందుగా ప్రాక్సీ డిస్క్‌కు స్పూల్ చేయకుండా అప్‌లోడ్‌ను స్ట్రీమ్ చేస్తుంది.

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

trusted_proxies మరియు overwriteprotocol

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

X-Forwarded-Proto: https అభ్యర్థన trusted_proxiesలో జాబితా చేయబడిన చిరునామా నుండి వచ్చినప్పుడు మాత్రమే పరిగణించబడుతుంది. అది పరిగణించబడనప్పుడు, Nextcloud అభ్యర్థన సాధారణ HTTP అని భావిస్తుంది మరియు http:// URLలను ఉత్పత్తి చేస్తుంది. ప్రాక్సీ వాటిని HTTPSకి దారిమళిపు చేస్తుంది. బ్రౌజర్ అనుసరిస్తుంది. Nextcloud మళ్లీ http:// ఉత్పత్తి చేస్తుంది. అదే దారిమళిపు లూప్. OVERWRITEPROTOCOL: https పథకాన్ని ఏదైనా ఉన్నా నిర్ధారిస్తుంది.

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

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

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

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

బ్యాక్‌గ్రౌండ్ ఉద్యోగాలు: 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>. దీనికి అలయాస్ ఇవ్వడం విలువైనది.

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

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

మూడింటినీ బ్యాకప్ చేయండి, నిశ్చల ఇన్‌స్టెన్స్ నుండి:

#!/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 ప్రతి రన్‌లో దాన్ని ఓవర్‌రైట్ చేస్తుంది — కాబట్టి కొత్త డంప్ మాత్రమే ఫైల్ కాపీతో జతకట్టుతుంది.

తర్వాత దాన్ని బాక్స్ నుండి బయటకు పంపండి. తాను బ్యాకప్ చేసే వస్తువు వలె అదే VPSలో ఉండే బ్యాకప్ ఒక కాపీ, బ్యాకప్ కాదు. ఆబ్జెక్ట్ స్టోరేజ్ లేదా రెండవ హోస్ట్‌కు వ్యతిరేకంగా restic సాధారణ సమాధానం, మరియు దాని డిడప్లికేషన్ డేటా డైరెక్టరీని రాత్రి టార్‌బాల్ కంటే చాలా మెరుగ్గా నిర్వహిస్తుంది. పూర్తి సెటప్, రిపోజిటరీ init నుండి రాత్రి టైమర్ మరియు పునరుద్ధరణ డ్రిల్ వరకు, resticతో ఆఫ్-బాక్స్ VPS బ్యాకప్‌లులో ఉంది.

పునరుద్ధరణ కేవలం వ్యతిరేక క్రమం కాదు. కొత్తగా ప్రారంభించిన స్టాక్ ఇన్‌స్టాలర్‌ను నడుపుతుంది మరియు కొత్త 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లో దీన్ని ఒకసారి సాధన చేయండి.

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

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

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 తనిఖీ చేయండి, అలాగే యాప్‌లు మళ్లీ ఎనేబుల్ అయ్యాయో కూడా చూడండి.

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

మీరు వాస్తవానికి చూసే దోషాలు

"Your data directory is readable by other users. Please change the permissions to 0770." బైండ్-మౌంట్ చేసిన డైరెక్టరీకి గ్రూప్ లేదా వరల్డ్ రీడ్ బిట్‌లు ఉన్నాయి. 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." బైండ్ మౌంట్ అనేది Nextcloud ఎన్నడూ ప్రారంభించని చోటికి సూచిస్తోంది — పాత్‌లో టైపో, లేదా పని చేసే ఇన్‌స్టాన్స్ కింద ఖాళీ డైరెక్టరీ మార్పిడి చేయబడింది. హోస్ట్ పాత్ వాల్యూమ్ లైన్‌తో సరిపోలుతుందో కాదో తనిఖీ చేయండి.

"Access through untrusted domain." అభ్యర్థనలోని హోస్ట్‌పేరు 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 పై ఏమీ చేరుకోలేదు. కంటైనర్ ఇంకా ప్రారంభమవుతోంది (docker compose logs app తనిఖీ చేయండి), అది నిష్క్రమించింది (docker compose ps), లేదా పబ్లిష్ లైన్ proxy_pass పోర్ట్‌తో సరిపోలడం లేదు. ss -ltnp | grep 8080 తో నిర్ధారించండి.

రీడైరెక్ట్ లూప్, లేదా నిర్వాహక అవలోకనంలో "insecure" హెచ్చరికలు. OVERWRITEPROTOCOL: https లేదు, లేదా TRUSTED_PROXIES లో Docker గేట్‌వే సబ్‌నెట్ లేదు. పైన ఉన్న ప్రాక్సీ విభాగాన్ని చూడండి.

LockedException: "files/..." is locked. REDIS_HOST సెట్ చేయబడితే, ఇమేజ్ Redis ని లాకింగ్ బ్యాకెండ్‌గా ఆకృతీకరిస్తుంది మరియు పాత లాక్‌లు అరుదు. అది లేకపోతే, లాక్‌లు డేటాబేస్ పట్టిక oc_file_locks లో ఉంటాయి మరియు మధ్యలో రద్దు చేయబడిన అభ్యర్థన వరుసలను వదిలివేస్తుంది. Redis వాస్తవానికి వాడుకలో ఉందో కాదో నిర్ధారించండి — occ config:system:get memcache.locking అనేది Redis క్లాస్‌ను అందించాలి — మీరు మాన్యువల్‌గా లాక్ వరుసలను క్లియర్ చేయడానికి వెళ్లే ముందు.

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

పెద్ద ఎత్తున ఏమి పనికిరాదు

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

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

మూడవది ప్రివ్యూ జనరేషన్ మిగతా అన్నింటితో పోటీపడటం. చిన్న సర్వర్‌పై, ప్రివ్యూ ప్రొవైడర్‌లను పరిమితంగా ఉంచండి. పని సమయాల్లో occ preview:generate-all ఎప్పుడూ రన్ చేయవద్దు.

ఇందులో మించి, నిజాయితీ సమాధానం ఏమిటంటే అదనపు సేవలకు వాటి స్వంత మెషీన్ కావాలి. Collabora మరియు ఫుల్-టెక్స్ట్ సెర్చ్ వేర్వేరు రెసిడెంట్ సర్వీసులు. అవి తమ స్వంత మెమరీ ప్రొఫైల్‌లను కలిగి ఉంటాయి. మీ ఫైళ్ల ఏకైక కాపీ ఉన్న మెషీన్‌పైనే వీటిని కూడా ఉంచడం వల్ల ఎలాంటి లాభం లేకుండా ఫెయిల్యూర్ డొమైన్ పెరుగుతుంది. వాల్యూమ్ సరిగ్గా సరిపోనప్పుడు ఫైల్ స్టోరేజీని S3-కంపాటిబుల్ ప్రైమరీ స్టోరేజీకి తరలించండి. దీనివల్ల బ్యాకప్‌లు సులభం కాదు, కష్టమవుతాయని గమనించండి: డేటాబేస్ ఇప్పటికీ మెటాడేటాను కలిగి ఉంటుంది, మరియు దాన్ని బకెట్‌తో పాటు డంప్ చేయాలి.

ఇన్‌స్టెన్స్ నిజమైన యూజర్‌లకు సర్వీస్ ఇచ్చే దశకు వచ్చాక, దాని ముందు Uptime Kuma ఉంచండి. అప్పుడు సింక్ క్లయింట్‌ల కంటే ముందే మీకు డౌన్‌టైమ్ తెలుస్తుంది. ప్రైవేట్ క్లౌడ్ మీ స్వంత మెయిల్ సర్వర్‌తో మంచి జతగా సర్దుబాటవుతుంది. సర్వీసులను మీరే చేతులతో కనెక్ట్ చేయాలనుకోకపోతే, Cloudron, CasaOS మరియు Coolify మీ కోసం అది చేసే ప్లాట్‌ఫారమ్‌లను పోల్చి చూపిస్తుంది.

FAQ

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

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

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

వినియోగదారుల సంఖ్య కాదు, ఏకకాల వినియోగం కోసం ప్రణాళిక చేయండి. అత్యంత పనితీరు స్థితిలో రెసిడెంట్ మెమరీ సుమారుగా ఏకకాల అభ్యర్థనల సంఖ్యను PHP_MEMORY_LIMIT తో గుణించినంత. దానికి Postgres షేర్డ్ బఫర్‌లు, ప్రతి కనెక్షన్‌కు ఒక బ్యాకెండ్, మరియు ప్రివ్యూ జనరేషన్ స్పైక్ అయ్యే మొత్తం కూడా కలుపుతారు. ఒక 2 GB సర్వర్ చిన్న హౌస్‌హోల్డ్ ఇన్‌స్టాన్స్‌ను నడుపుతుంది. ప్రివ్యూలను పరిమితం చేసి, స్వాప్ జోడిస్తే ఇది సాధ్యం. Collabora లేదా ఫుల్-టెక్స్ట్ సెర్చ్ జోడిస్తే, రెండవ సెట్ రెసిడెంట్ సర్వీసుల కోసం ప్రణాళిక చేయాలి.

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

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

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

కంటైనర్ nginx ను 127.0.0.1 వద్ద చూడదు. అది Docker బ్రిడ్జ్ గేట్‌వేను, 172.x లో ఎక్కడో చూస్తుంది. ఆ చిరునామా 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 తో ధృవీకరించండి. తర్వాత మళ్లీ చేయండి.

#nextcloud#docker #self-hosting #backups #reverse-proxy#postgres