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

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

ప్రివ్యూ జనరేషన్. థంబ్‌నెయిల్‌ను రూపొందించేటప్పుడు, సోర్స్ ఇమేజ్‌ను పూర్తి రిజల్యూషన్‌లో మెమరీలోకి డీకోడ్ చేస్తుంది. వీడియో ప్రివ్యూల కోసం 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 లను సెట్ చేయండి, తద్వారా డేటా డైరెక్టరీ మీ ఫైళ్ల పరిమాణం కంటే అనేక రెట్లు పెరగకుండా ఉంటుంది. ఒక swap ఫైల్‌ను జోడించండి. Swap నెమ్మదిగా ఉండవచ్చు, కానీ అప్‌గ్రేడ్ మధ్యలో OOM కిల్లర్ వల్ల సర్వీస్ ఆగిపోవడం అంతకంటే ప్రమాదకరం.

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

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

తర్వాతి దశలో 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 మరియు ఎక్కువ సమయం ఉండే రీడ్ టైమౌట్‌లు, పెద్ద ఫైల్ అప్‌లోడ్‌లు మధ్యలోనే ఆగిపోకుండా చూస్తాయి. 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 హోస్ట్‌పై నడుస్తూ ప్రచురించబడిన port కి కనెక్ట్ అవుతుంది, కాబట్టి కంటైనర్ Docker bridge గేట్‌వేని చూస్తుంది, ఇది 172.x లో ఏదో ఒకటి అయి ఉంటుంది. అసలైన సబ్‌నెట్‌ను ఇలా కనుగొనండి:

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

ఆ CIDR ను (లేదా దానిని కవర్ చేసే 172.16.0.0/12 ని) TRUSTED_PROXIES లో ఉంచండి. దీనిని మరీ ఎక్కువగా (wide) సెట్ చేస్తే, ఏ క్లయింట్ అయినా 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): AJAX కాదు, cron వాడండి

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 డిస్క్‌లో ఉన్న ఫైళ్లతో ఫైల్ కాష్‌ను సరిపోల్చుతుంది (reconcile). మీకు అవసరమయ్యే ముందు, ఒకసారి విడి 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 ని తనిఖీ చేయండి మరియు అప్లికేషన్లు తిరిగి ఎనేబుల్ అయ్యాయో లేదో చూడండి.

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

మీకు కనిపించే వాస్తవ దోషాలు (errors)

"Your data directory is readable by other users. Please change the permissions to 0770." bind-mounted డైరెక్టరీకి 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 ఎన్నడూ 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 సబ్‌నెట్ లేదు. పైన ఉన్న proxy విభాగాన్ని చూడండి.

LockedException: "files/..." is locked. REDIS_HOST సెట్ చేయబడినప్పుడు, ఇమేజ్ Redis ను locking backend గా కాన్ఫిగర్ చేస్తుంది మరియు పాత లాక్‌లు అరుదుగా ఉంటాయి. అది లేకపోతే, లాక్‌లు oc_file_locks డేటాబేస్ టేబుల్‌లో ఉంటాయి మరియు రైటింగ్ మధ్యలో అభ్యర్థన ఆగిపోతే అదనపు అడ్డు వరుసలు (rows) మిగిలిపోతాయి. మీరు మాన్యువల్‌గా లాక్ రోలను తొలగించే ముందు, 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 ను వేగవంతమైన స్టోరేజ్‌లో ఉంచండి, దానికి తగినంత shared memory కేటాయించండి, మరియు రిటెన్షన్ సెట్టింగ్‌ల ద్వారా పాత వెర్షన్లను, చెత్తను ఎప్పటికప్పుడు తొలగించండి.

మూడవది, ప్రివ్యూ జనరేషన్ ఇతర పనులతో పోటీ పడటం. చిన్న సర్వర్లలో, ప్రివ్యూ ప్రొవైడర్లను పరిమితం చేయండి మరియు పని వేళల్లో 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 వంటి ప్లాట్‌ఫారమ్‌లను పరిశీలించండి. ఒకవేళ మీరు సెల్ఫ్-హోస్టెడ్ సెర్చ్ ఇంజిన్‌ను ఏర్పాటు చేయాలనుకుంటే, పైన పేర్కొన్న వాటి కంటే భిన్నమైన సమస్యలు ఎదురవుతాయి: SearXNG యొక్క 429 ఎర్రర్స్ దాని సొంత రేట్ లిమిటర్ వల్ల లేదా అప్‌స్ట్రీమ్ ఇంజిన్లు మీ VPS IPని బ్లాక్ చేయడం వల్ల రావచ్చు; ఏది కారణమో కేవలం లాగ్స్ మాత్రమే చెబుతాయి.

FAQ

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

మీరు చేయవచ్చు, అధికారిక ఇమేజ్ కూడా దీనిని అనుమతిస్తుంది, కానీ ఒకే డెస్క్‌టాప్ సింక్ క్లయింట్ సమాంతర అభ్యర్థనలను పంపినప్పుడు అది 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 లేదా ఫుల్-టెక్స్ట్ సెర్చ్‌ను జోడిస్తే, అదనపు సర్వీసుల కోసం మరింత మెమరీ అవసరమవుతుంది.

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 తో ధృవీకరించండి, ఆపై మళ్ళీ ఇదే ప్రక్రియను పునరావృతం చేయండి.