VPS वर Nextcloud कसे इंस्टॉल करायचे

तुम्ही प्रत्यक्षात काय तयार करत आहात

हा मार्गदर्शक (guide) Docker Compose वापरून VPS वर Nextcloud चालवतो, त्याच्या समोर Let's Encrypt TLS सेट करतो आणि खरोखर रिस्टोअर होऊ शकेल असा बॅकअप तयार करतो. यामध्ये चार कंटेनर्स आणि एक प्रॉक्सी आहेत: loopback वर ऐकणारी (listening) अधिकृत nextcloud इमेज, फाईल मेटाडेटा साठवणारा Postgres, फाईल लॉक्स (locks) साठवणारा Redis, फक्त cron loop चालवणारी Nextcloud इमेजची दुसरी प्रत, आणि सर्व प्रक्रियेच्या समोर TLS टर्मिनेट करणारा host वरील nginx. इन्स्टॉलेशनसाठी वीस मिनिटे लागतात, परंतु ते महत्त्वाचे नाही. पहिल्या तासात घेतलेले दोन निर्णय तुमचे फाईल्स एक वर्षानंतरही सुरक्षित आहेत की नाही हे ठरवतात: SQLite ऐवजी खरा डेटाबेस वापरणे, आणि data directory, database आणि config.php यांचा एक सुसंगत संच (consistent set) म्हणून बॅकअप घेणे.

यासाठी Ubuntu 24.04 LTS किंवा Debian 13, Docker च्या स्वतःच्या रिपॉझिटरीमधून इंस्टॉल केलेले Compose v2 प्लगइन असलेले Docker Engine, आणि VPS कडे cloud.example.com निर्देशित करणारा DNS A रेकॉर्ड (आणि जर तुमच्याकडे IPv6 असेल तर AAAA) आवश्यक आहे. या सर्वांसाठी तुमच्या नियंत्रणाखालील सर्व्हर असणे आवश्यक आहे — दुसऱ्याच्या SaaS वर TLS termination आणि डेटाबेस डम्प (database dump) करणे शक्य नाही.

Sizing: मेमरीचा प्रत्यक्ष वापर कशावर अवलंबून असतो

Nextcloud चा मेमरी वापर प्रामुख्याने तीन गोष्टींवर अवलंबून असतो आणि त्यापैकी कोणतीही गोष्ट प्रत्यक्ष "Nextcloud" नाही.

PHP workers. -apache इमेज प्रत्येक concurrent request साठी एक worker process वापरते, ज्यामध्ये PHP interpreter असतो. PHP द्वारे request थांबवण्यापूर्वी प्रत्येक worker PHP_MEMORY_LIMIT पर्यंत वाढू शकतो. तुमचा सर्वाधिक resident memory वापर अंदाजे concurrent requests × memory limit इतका असतो; डेस्कटॉप sync client प्रत्येक वापरकर्त्यासाठी अनेक parallel connections उघडतो. वापरकर्त्यांच्या संख्येपेक्षा concurrency मुळे मेमरीची मर्यादा ठरते.

The database. Postgres प्रत्येक connection साठी एक backend fork करते आणि shared buffers resident ठेवते. त्याचा working set bytes च्या संख्येपेक्षा files च्या संख्येवर अवलंबून असतो: oc_filecache मध्ये प्रत्येक वापरकर्त्यासाठी प्रत्येक file साठी एक row असते. एक लाख लहान files असणे, शंभर मोठ्या files असण्यापेक्षा डेटाबेसवर जास्त भार टाकते.

Preview generation. Thumbnail तयार करण्यासाठी मूळ image पूर्ण resolution मध्ये मेमरीमध्ये decode केली जाते. Video previews साठी ffmpeg वापरले जाते. occ preview:generate-all चालवल्यामुळे ही मेमरीची spike वारंवार आणि सलग येते, आणि लहान VPS मध्ये OOM killer सक्रिय होण्याचे हे सर्वात सामान्य कारण आहे.

Redis तुलनेने कमी मेमरी वापरते. तुम्ही नंतर जोडलेले कोणतेही घटक — जसे की Collabora, full-text search, किंवा antivirus scanner — हे स्वतंत्र resident service असतात आणि त्यांचे स्वतःचे footprint असते. ते सुरू करण्यापूर्वीच तुमच्या sizing plan मध्ये त्यांचा विचार करणे आवश्यक आहे.

जर तुमच्याकडे RAM कमी असेल, तर हे उपाय करा: PHP_MEMORY_LIMIT कमी करा, preview_max_x / preview_max_y / preview_max_filesize_image मर्यादित करा, enabledPreviewProviders फक्त तुम्ही पाहता त्या formats साठी मर्यादित करा, आणि trashbin_retention_obligation व versions_retention_obligation असे सेट करा की data directory चा आकार तुमच्या files च्या आकारापेक्षा कित्येक पटीने वाढणार नाही. एक swap file जोडा. Swap संथ असतो, परंतु upgrade दरम्यान OOM kill होणे अधिक घातक आहे.

SQLite का वापर केल्यास समस्या का येतात

Nextcloud मध्ये SQLite सपोर्ट येतो आणि अधिकृत image त्याचा वापर करू शकते. परंतु, तसे करू नका. SQLite डेटा लिहिताना संपूर्ण डेटाबेसवर lock लावते: संपूर्ण फाईलसाठी एका वेळी फक्त एकच writer काम करू शकतो. Nextcloud मध्ये सतत writes होतात — जसे की file locks, activity rows, cache entries आणि job state. तसेच, एखादा desktop client जेव्हा directory tree sync करतो, तेव्हा तो एकाच वेळी अनेक parallel requests पाठवतो. अशा परिस्थितीत SQLSTATE[HY000]: General error: 5 database is locked आणि HTTP 500 errors येतात. जेव्हा instance खऱ्या कामासाठी वापरण्यास सुरुवात होते, तेव्हाच ही समस्या प्रकर्षाने जाणवते.

नंतर occ db:convert-type वापरून रूपांतरण करणे शक्य आहे, परंतु live dataset वर ही एक मोठी आणि जोखमीची migration प्रक्रिया आहे. सुरुवातीपासूनच Postgres किंवा MariaDB वापरा.

The Compose file

हे /srv/nextcloud/compose.yaml मध्ये ठेवा. secrets साठी त्याच ठिकाणी 600 मोडमध्ये असलेली .env फाईल वापरा.

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 जशीच्या तशी कॉपी करण्यापूर्वी, major tag फिक्स करा आणि Docker Hub वर सध्याचे tag तपासा. भविष्यात docker compose pull च्या वेळी latest मुळे major version बदलू शकते, आणि Nextcloud त्यास सपोर्ट करत नाही.

data directory मुळे bind mount वापरण्याचे हेतुतूपूर्वक ठरलेले कारण म्हणजे: बॅकअप टूल थेट ज्या पाथवर वापरता येईल, ते अधिक महत्त्वाचे आहे. हे directory इमेजच्या 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 publish कडे लक्ष द्या: 127.0.0.1:8080:80. Docker ports publish करण्यासाठी DNAT rules वापरते, जे ufw च्या INPUT chain च्या आधी तपासले जातात — त्यामुळे ufw काय सांगते यापेक्षा, केवळ 8080:80 वापरल्यास Nextcloud सार्वजनिक इंटरनेटवर असुरक्षित राहू शकते. loopback ला bind केल्यामुळे ते public interface वरून सुरक्षित राहते. त्यानंतर, firewall ला फक्त proxy ला परवानगी द्यावी लागेल — आणि जर तुम्हाला SSH संपूर्ण इंटरनेटसाठी उघडा ठेवायचा नसेल, तर self-hosted WireGuard VPN द्वारे VPS ला ॲक्सेस केल्यास तुम्ही public rules मधून 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 तपासा. पहिल्या वेळी boot होताना संपूर्ण application tree volume मध्ये कॉपी केली जाते आणि installer रन होतो; जोपर्यंत ही प्रक्रिया पूर्ण होत नाही, तोपर्यंत कंटेनर कोणताही प्रतिसाद देत नाही.

TLS आणि reverse proxy

distro मधून nginx आणि certbot इंस्टॉल करा. योग्य server_name असलेला plain port-80 server block तयार करा आणि नंतर certbot ला तो rewrite करू द्या. HTTP-01 challenge ची कार्यपद्धती, renewal timer आणि failure modes ची पूर्ण माहिती issuing Let's Encrypt certificates with certbot and nginx on Ubuntu 24.04 मध्ये दिली आहे:

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

Certbot ssl_certificate lines आणि :80 → :443 redirect जोडते. तसेच, 90-दिवसांच्या certificate साठी renewal करणारे systemd timer इंस्टॉल करते. systemctl list-timers | grep certbot वापरून ते अस्तित्वात आहे का ते तपासा — जर renewal timer enable नसेल, तर 90-दिवसांची मुदत संपणे ही एक मोठी समस्या ठरू शकते.

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 आणि long read timeouts मुळे मोठ्या uploads मध्ये मध्येच येणारी अडचण थांबते. proxy_request_buffering off संपूर्ण file आधी proxy च्या disk वर spool करण्याऐवजी upload stream करते.

एका app साठी host वरील nginx वापरणे सर्वात सोपे आहे. जर Nextcloud ला इतर containers सोबत VPS शेअर करायचा असेल, तर running Traefik as a Docker Compose reverse proxy for multiple apps वापरा. यामध्ये routing आणि certificate issuance कंटेनर labels मध्ये हलवले जाते. तिथेही client_max_body_size आणि timeout च्या समस्या middleware आणि transport settings च्या स्वरूपात पुन्हा येतात.

trusted_proxies आणि overwriteprotocol

अनेक self-hosted Nextcloud instances मध्ये येथे चुका होतात, आणि त्यांची लक्षणे कारणाशी संबंधित वाटत नाहीत.

जेव्हा request trusted_proxies मध्ये सूचीबद्ध असलेल्या address कडून येते, तेव्हाच X-Forwarded-Proto: https लागू होते. जेव्हा ते लागू होत नाही, तेव्हा Nextcloud ला request plain HTTP असल्याचे वाटते आणि ते http:// URLs तयार करते; proxy त्या URLs ला HTTPS कडे redirect करते; browser त्याचे अनुसरण करतो; आणि Nextcloud पुन्हा http:// तयार करते. यामुळे redirect loop तयार होतो. OVERWRITEPROTOCOL: https मुळे scheme निश्चित राहते.

TRUSTED_PROXIES मधील अडचण अशी आहे की Nextcloud ला दिसणारे address 127.0.0.1 नसते. nginx host वर चालते आणि published port ला connect होते, त्यामुळे container ला Docker bridge gateway दिसते — जे 172.x मध्ये असते. खरा subnet शोधण्यासाठी खालील कमांड वापरा:

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

तो CIDR (किंवा covering 172.16.0.0/12) TRUSTED_PROXIES मध्ये टाका. जर तुम्ही ते खूप मोठे (wide) सेट केले, तर कोणताही client X-Forwarded-For spoof करू शकतो; जर ते चुकीचे सेट केले, तर प्रत्येक login gateway address कडून आल्यासारखे दिसेल, brute-force protection तुमच्या संपूर्ण instance ला ब्लॉक करेल, आणि admin overview मध्ये "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy." असा संदेश दिसेल.

cron container साठी OVERWRITECLIURL महत्त्वाचे आहे, कारण त्याकडे hostname infer करण्यासाठी कोणतीही incoming request नसते. याशिवाय, background jobs localhost कडे links तयार करतात आणि email notifications मध्ये वापरण्यायोग्य नसलेले URLs पाठवले जातात.

Background jobs: cron, not AJAX

Nextcloud चा default job runner AJAX आहे: जेव्हा कोणीतरी एखादे page load करते, तेव्हा jobs execute होतात. पहाटे 04:00 वाजता कोणीही browsing करत नाही, त्यामुळे trash expiry, versions cleanup, previews आणि federated retries थांबतात. याचे पहिले लक्षण म्हणजे data directory सतत वाढत राहणे. वरील cron service त्याच volumes वर official /cron.sh loop चालवते. Nextcloud ला याची माहिती देण्यासाठी खालीलप्रमाणे command वापरा:

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

प्रत्येक occ command याच स्वरूपात असते: docker compose exec -u www-data app php occ <command>. याचे alias तयार करणे फायदेशीर ठरेल.

Backups: तीन गोष्टी, किंवा काहीच नाही

फक्त filesystem चा backup घेतल्यास तो खराब झालेल्या instance वर रिस्टोर करता येत नाही. data directory मध्ये डेटा असतो; Postgres मध्ये file cache, shares, users आणि app state असते; config.php मध्ये database credentials, instance ID आणि password salt असते. जर तुम्ही database शिवाय फक्त files रिस्टोर केल्या, तर Nextcloud त्यांना ओळखू शकणार नाही. जर तुम्ही config.php शिवाय database रिस्टोर केला, तर तो database उघडता येणार नाही. जर तुम्ही नवीन data directory वर जुना database रिस्टोर केला, तर shares मध्ये अशा files दिसतील ज्यांची जागा बदलली आहे.

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 मुळे dump आणि file copy यांचा डेटा एकमेकांशी जुळतो. जर तुम्ही हे स्टेप वगळले, तर rsync ने अजून न पोहोचलेल्या file ला संदर्भ देणारा database dump तयार होण्याची शक्यता असते. लक्षात ठेवा की, script मध्ये timestamped database dumps राहतात, परंतु data directory ची फक्त एकच rolling mirror असते — rsync --delete प्रत्येक वेळी ती overwrite करते — त्यामुळे फक्त सर्वात नवीन dump आणि file copy एकमेकांशी जुळतात.

त्यानंतर तो डेटा त्या सर्व्हरवरून बाहेर काढा. ज्या VPS वर मूळ डेटा आहे, त्याच VPS वर backup ठेवणे म्हणजे केवळ 'copy' आहे, 'backup' नाही. Object storage किंवा दुसऱ्या host वर restic वापरणे हा योग्य उपाय आहे; याचे deduplication, nightly tarball पेक्षा data directory साठी अधिक चांगले काम करते. Repository init पासून nightly timer आणि restore drill पर्यंतची संपूर्ण माहिती off-box VPS backups with restic मध्ये आहे.

Restore करणे म्हणजे केवळ प्रक्रिया उलट करणे नव्हे. नवीन सुरू झालेला stack installer चालवतो आणि एक नवीन config.php — नवीन instance ID आणि password salt — तयार करतो. अशा नवीन identity वर dump import केल्यास sessions आणि share tokens खराब होतात. आधी जुनी identity या क्रमाने परत आणा:

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 file cache आणि disk वरील प्रत्यक्ष डेटा यांचा मेळ घालते. प्रत्यक्ष गरजेच्या वेळी अडचण येऊ नये म्हणून, आधी एका spare VPS वर याचा सराव करा.

Upgrades: एका वेळी एकच major version

Nextcloud एका वेळी फक्त एकच major version upgrade ला सपोर्ट करते. 29 कडून 31 कडे थेट जाणे शक्य नाही — यामुळे Exception: Updates between multiple major versions and downgrades are unsupported. त्रुटी येते आणि system maintenance mode मध्ये जाते.

Docker upgrade ची प्रक्रिया अशी आहे: backup घ्या, app आणि cron या दोन्ही services मध्ये tag 31 कडून 32 असा बदला, त्यानंतर docker compose pull && docker compose up -d करा, आणि मग docker compose logs -f app करा. Image entrypoint सध्याच्या data सोबत नवीन code तपासाते आणि स्वतःहून occ upgrade चालवते. ही प्रक्रिया मध्येच थांबवू नका. जेव्हा logs थांबतील, तेव्हा docker compose exec -u www-data app php occ status चालवा आणि versionstring तसेच apps पुन्हा enabled झाले आहेत की नाही ते तपासा.

दोन महत्त्वाचे नियम: एक major version upgrade करा, त्याची पडताळणी करा, आणि मग पुढचे upgrade करा. तसेच, cron मध्ये बदल न करता कधीही app service चा tag बदलू नका — एकाच database वर दोन वेगवेगळ्या Nextcloud versions वापरल्यास डेटा corrupt होऊ शकतो.

तुम्हाला प्रत्यक्षात येणाऱ्या त्रुटी (errors)

"Your data directory is readable by other users. Please change the permissions to 0770." bind-mounted डिरेक्टरीला 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 ने कधीही initialization केलेले नाही — पाथमध्ये (path) चूक आहे, किंवा कार्यरत instance च्या जागी नवीन रिकामी डिरेक्टरी वापरली आहे. host path आणि volume line तपासा.

"Access through untrusted domain." विनंतीमधील (request) hostname trusted_domains मध्ये नाही. NEXTCLOUD_TRUSTED_DOMAINS फक्त पहिल्या installation वेळी लागू होते; त्यानंतर ते live सेट करा: 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 अजूनही initialising आहे (docker compose logs app तपासा), ते exit झाले आहे (docker compose ps), किंवा publish line आणि proxy_pass port मॅच होत नाहीये. ss -ltnp | grep 8080 ने याची खात्री करा.

Redirect loop, किंवा admin overview मध्ये "insecure" चे warnings. OVERWRITEPROTOCOL: https गहाळ आहे, किंवा TRUSTED_PROXIES मध्ये Docker gateway subnet नाहीये. वरील proxy विभाग पहा.

LockedException: "files/..." is locked. जर REDIS_HOST सेट असेल, तर image Redis ला locking backend म्हणून कॉन्फिगर करते आणि stale locks येण्याची शक्यता कमी असते. त्याशिवाय, locks हे oc_file_locks या database table मध्ये साठवले जातात आणि write प्रक्रियेदरम्यान एखादी request बंद झाली तर rows मागे राहतात. lock rows मॅन्युअली डिलीट करण्यापूर्वी Redis खरोखर वापरले जात आहे याची खात्री करा — 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 वर काय परिणाम होतो याची नोंद ठेवा.

मोठ्या प्रमाणावर (at scale) येणाऱ्या अडचणी

पहिली अडचण म्हणजे डेटा डिरेक्टरीचा आकार व्हॉल्यूमपेक्षा मोठा होणे. VPS वर व्हॉल्यूम वाढवणे म्हणजे resize आणि filesystem grow करणे होय. डिस्क 100% भरल्यानंतर हे करणे कठीण जाते; त्यामुळे डिस्क वापराबाबत (disk usage) आधीच अलर्ट सेट करा.

दुसरी अडचण oc_filecache ही आहे. रो (row) संख्या वाढल्यामुळे फाईल लिस्टिंग आणि sync स्कॅनचा वेग मंदावतो. याचे निराकरण करण्यासाठी डेटाबेसवर लक्ष केंद्रित करा: Postgres जलद स्टोरेजवर ठेवा, त्याला पुरेसा shared memory वापरू द्या आणि डेटा साठून राहण्याऐवजी retention settings वापरून अनावश्यक डेटा काढून टाका.

तिसरी अडचण म्हणजे preview generation आणि इतर प्रक्रियांमधील स्पर्धा. लहान सर्व्हरवर, preview providers मर्यादित ठेवा आणि कामकाजाच्या वेळेत कधीही occ preview:generate-all चालवू नका.

त्यापलीकडे, खरे उत्तर असे आहे की अतिरिक्त सेवांसाठी स्वतंत्र मशीन आवश्यक आहे. Collabora आणि full-text search या स्वतंत्र सेवा आहेत ज्यांना स्वतःची मेमरी लागते. फाईल्सच्या एकमेव कॉपी असलेल्या त्याच मशीनवर या सेवा चालवल्यास, कोणताही फायदा न होता failure domain वाढतो. जेव्हा व्हॉल्यूम पुरेसा नसेल, तेव्हा फाईल स्टोरेज S3-compatible स्टोरेजवर हलवा — लक्षात ठेवा की यामुळे बॅकअप घेणे कठीण होते: मेटाडेटा अजूनही डेटाबेसमध्ये असतो आणि तो बकेटसोबतच डंप करणे आवश्यक आहे.

जेव्हा तुमची instance प्रत्यक्ष वापरकर्त्यांसाठी उपलब्ध असेल, तेव्हा तिच्या पुढे Uptime Kuma वापरा, जेणेकरून sync क्लायंट्सना समस्या येण्यापूर्वीच तुम्हाला डाउनटाइमची माहिती मिळेल. प्रायव्हेट क्लाउड तुमच्या स्वतःच्या मेल सर्व्हरसोबत चांगले काम करते. आणि जर तुम्हाला सर्व सेवा मॅन्युअली जोडायच्या नसतील, तर Cloudron, CasaOS and Coolify या प्लॅटफॉर्म्सची तुलना करा जे हे काम तुमच्यासाठी करतात.

FAQ

मी Postgres ऐवजी SQLite वर Nextcloud चालवू शकतो का?

हो, तुम्ही चालवू शकता आणि अधिकृत image तुम्हाला याची परवानगी देते, परंतु जेव्हा एकच desktop sync client समांतर (parallel) requests पाठवतो, तेव्हा SQLSTATE[HY000]: General error: 5 database is locked आणि HTTP 500 errors येतील. SQLite संपूर्ण database वर write lock घेते आणि Nextcloud मध्ये सतत writes होतात — जसे की file locks, activity rows आणि job state. Postgres किंवा MariaDB पासून सुरुवात करा; occ db:convert-type उपलब्ध आहे परंतु live data वर ही एक मोठी आणि जोखमीची migration प्रक्रिया आहे.

Nextcloud VPS साठी प्रत्यक्षात किती RAM आवश्यक आहे?

RAM ची गरज युजरच्या संख्येपेक्षा concurrency (एकाच वेळी होणाऱ्या विनंत्या) वर अवलंबून असते. जास्तीत जास्त वापरासाठी लागणारी resident memory साधारणपणे concurrent requests ची संख्या PHP_MEMORY_LIMIT ने गुणून, त्यात Postgres shared buffers, प्रत्येक connection साठी एक backend आणि preview generation मुळे होणारी वाढ (spikes) एवढी असते. जर तुम्ही previews मर्यादित केले आणि swap जोडला, तर 2 GB चा box एका लहान कुटुंबासाठी पुरेसा आहे; परंतु जर तुम्ही Collabora किंवा full-text search जोडले, तर तुम्हाला अतिरिक्त resident services साठी अधिक RAM लागेल.

nginx reverse proxy वापरताना मोठ्या uploads का फेल होतात?

याचे मुख्य कारण proxy मधील दोन settings असू शकतात: जर client_max_body_size डिफॉल्ट 1 MB वर ठेवले तर request मध्ये truncation होते, आणि कमी proxy_read_timeout / proxy_send_timeout मुळे लांब चालणारे transfers मध्येच थांबतात. या दोन्ही settings मोठ्या प्रमाणात सेट करा, proxy_request_buffering off ला spool ऐवजी stream वर सेट करा, आणि app container वरील PHP_UPLOAD_LIMIT देखील त्याचप्रमाणे वाढवा.

Nextcloud redirect loop मध्ये का जाते किंवा reverse proxy बद्दल warning का देते?

container ला 127.0.0.1 वर nginx दिसत नाही — त्याला 172.x मधील Docker bridge gateway दिसते. जेव्हा TRUSTED_PROXIES मधून तो address गहाळ असतो, तेव्हा X-Forwarded-Proto: https header दुर्लक्षित केला जातो, Nextcloud http:// URLs जनरेट करते आणि proxy त्या पुन्हा परत पाठवतो. TRUSTED_PROXIES हा खरा bridge subnet वर सेट करा आणि OVERWRITEPROTOCOL: https निश्चित (pin) करा.

मी Nextcloud 29 मधून थेट 31 वर upgrade करू शकतो का?

नाही. Nextcloud प्रत्येक upgrade मध्ये फक्त एकच major version ला सपोर्ट करते. जर तुम्ही version skip करण्याचा प्रयत्न केला तर Updates between multiple major versions and downgrades are unsupported. वर प्रक्रिया थांबते आणि instance maintenance mode मध्ये जाते. बॅकअप घ्या, app आणि cron या दोन्ही services वर tag एक major version ने वाढवा, docker compose pull && docker compose up -d करा, occ status ने पडताळणी करा आणि नंतर ही प्रक्रिया पुन्हा करा.