Nextcloud کے قابل self-hosted متبادل: کون سا بہتر ہے؟

کون سے Nextcloud متبادل self-hosting کے قابل ہیں؟

وہ Nextcloud متبادل self-hosting کے قابل ہیں جو ان حصوں کو ہٹا دیتے ہیں جنہیں آپ نے کبھی استعمال نہیں کیا۔ Nextcloud ایک ہی PHP application میں file server، calendar، contact book، office suite اور app platform فراہم کرتا ہے، اور ہر page load پر آپ ان سب کی لاگت ادا کرتے ہیں۔ اس لیے replacement کا انتخاب اس بنیاد پر کریں کہ آپ کو اب بھی کون سا ایک کام درکار ہے، پھر یہ جانچیں کہ آپ کی موجودہ files منتقل کرنے پر کیا لاگت آئے گی۔

یہ guide options کو اسی کام کے مطابق ترتیب دیتی ہے: صرف sync، زیادہ تیز server کے ساتھ sync، اوپر client کے ساتھ object storage، یا سادہ remote file access۔ ہر section بتاتا ہے کہ small VPS (virtual private server) پر server کو کیا درکار ہے اور آپ کی موجودہ folder tree کے ساتھ کیا ہوگا۔ اگر آپ پہلے سے چلنے والے Nextcloud box کے بجائے Dropbox یا Google Drive سے آ رہے ہیں تو self-hosted Dropbox متبادلات کا وسیع جائزہ اسی سمت سے آغاز کرتا ہے۔

ایک چھوٹے VPS پر Nextcloud سست کیوں ہو جاتا ہے

سستی کی قابلِ شناخت وجوہات ہوتی ہیں۔ انہیں سمجھنے سے معلوم ہوتا ہے کہ سرور تبدیل کرنے سے واقعی بہتری آئے گی یا نہیں۔

ہر صفحہ لوڈ ایک PHP worker استعمال کرتا ہے۔ اگست 2026 تک Nextcloud کے اپنے system requirements ہر process کے لیے memory بتاتے ہیں: کم از کم 128 MB اور تجویز کردہ 512 MB۔ یہ پورے server کی مجموعی memory نہیں ہے۔ 2 GB plan پر دس workers کا pool ایک حقیقی memory budget بن جاتا ہے۔ اسی لیے administrators PHP-FPM pool config میں pm.max_children کم کر دیتے ہیں۔ پھر requests موجود workers کے پیچھے queue میں چلی جاتی ہیں۔ disk idle ہونے کے باوجود interface سست محسوس ہوتا ہے۔

Database bytes کے بجائے files کی تعداد کے ساتھ بڑھتا ہے۔ default table prefix کے تحت file cache table، oc_filecache، server کو معلوم ہر storage کی ہر file اور folder کے لیے ایک row رکھتی ہے۔ 300,000 چھوٹی files پر مشتمل photo library ایک بڑی table ہوتی ہے؛ 400 files میں موجود 300 GB video files ایک چھوٹی table بناتی ہیں۔ Sharing، search اور file scanner سب اسی table کو پڑھتے ہیں۔

sudo mysql nextcloud -e 'SELECT COUNT(*) FROM oc_filecache;'

Millions میں count ہونا کسی بھی disk benchmark کے مقابلے میں سست file list کی بہتر وضاحت کرتا ہے۔ اگر آپ کی instance مختلف table prefix یا PostgreSQL استعمال کرتی ہے تو query میں تبدیلی کریں۔

Background jobs web interface کے ساتھ وسائل کے لیے مقابلہ کرتے ہیں۔ Nextcloud کا manual ہر پانچ منٹ بعد cron.php چلانے والی system cron entry تجویز کرتا ہے۔ Preview generation اور file scanning اسی CPU پر چلتے ہیں جو آپ کے browser کو service فراہم کرتا ہے۔

Major upgrades database migration ہوتے ہیں۔ Instance maintenance mode میں چلی جاتی ہے اور migration مکمل ہونے تک ہر request کا جواب Nextcloud is in maintenance mode, please try again later سے دیتی ہے۔ بڑے oc_filecache والے چھوٹے VPS پر یہ مدت اتنی طویل ہو سکتی ہے کہ فرق محسوس ہو۔

پہلے طے کریں کہ آپ کیا برقرار رکھنا چاہتے ہیں

• اپنی ملکیت کی مشینوں کے درمیان ایک فولڈر sync کریں اور web interface نہ ہو: Syncthing۔
• کئی لوگوں کے لیے sync درکار ہو، web interface، mobile clients اور share links بھی چاہییں: Seafile۔
• بڑی مقدار میں data کم لاگت پر محفوظ کریں اور اسے scripts اور backup tools سے access کریں: object storage کے ساتھ ایک client۔
• نیا server software نصب کیے بغیر اپنی files کو remotely پڑھیں اور لکھیں: SFTP یا WebDAV۔
• browser میں documents پر مل کر کام کریں یا لوگوں کے درمیان calendar share کریں: Nextcloud برقرار رکھیں، یا دو services چلانے کو قبول کریں۔

Syncthing: فائلوں کی ہم وقت کاری، بغیر server application کے

Syncthing آپ کی فائلوں کو عام فائلوں کے طور پر رکھتا ہے۔ اس میں content database نہیں ہوتا اور نہ ہی ایسا web interface ہوتا ہے جو آپ کی دستاویزات پیش کرے۔ کسی folder میں شامل ہونے والا ہر device اس کی مکمل copy رکھتا ہے، اور Syncthing تمام copies کو یکساں رکھتا ہے۔

sudo mkdir -p /etc/apt/keyrings
sudo curl -L -o /etc/apt/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg
echo "deb [signed-by=/etc/apt/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing stable-v2" | sudo tee /etc/apt/sources.list.d/syncthing.list
sudo apt-get update
sudo apt-get install syncthing

sudo systemctl enable --now syncthing@$USER
sudo ss -lntp | grep 8384

127.0.0.1:8384 دکھانے والی سطر کا مطلب ہے کہ web interface چل رہا ہے اور صرف localhost سے bind ہے، جو public VPS پر مطلوبہ صورت ہے۔ SSH tunnel کے ذریعے اس تک پہنچیں: ssh -L 8384:127.0.0.1:8384 you@your-vps، پھر اپنے laptop پر http://127.0.0.1:8384 کھولیں۔ اگر 8384 پر کوئی listener موجود نہ ہو تو service start نہیں ہوئی، اور journalctl -u syncthing@$USER -n 50 اس کی وجہ بتاتا ہے۔

وسائل۔ Syncthing کم از کم memory کی کوئی مقدار مقرر نہیں کرتا۔ اس کا استعمال فائلوں کے مجموعی حجم کے بجائے index کی جانے والی فائلوں کی تعداد کے مطابق بڑھتا ہے، کیونکہ ہر shared folder میں ہر فائل کے لیے ایک index entry رکھی جاتی ہے۔ بڑے folder کی پہلی scan CPU استعمال کرتی ہے: کسی بھی چیز کا موازنہ کرنے سے پہلے Syncthing ہر فائل کا hash بناتا ہے۔ مشترکہ vCPU پر اس پہلے مرحلے کو مکمل ہونے میں کچھ وقت لگ سکتا ہے، اور memory فائلوں کی تعداد کے ساتھ بڑھے گی، gigabytes کے ساتھ نہیں۔

اصل لاگت disk ہے۔ Server-side saving نہیں ہوتی، کیونکہ Syncthing server نہیں ہے۔ VPS اور laptop کے درمیان share کیے گئے 200 GB کے folder کے لیے دونوں devices پر 200 GB درکار ہے۔ یہ Nextcloud کے بالکل برعکس ہے، جہاں server ہر چیز محفوظ رکھتا ہے اور clients منتخب کرتے ہیں کہ کیا sync کرنا ہے۔ اگر VPS کو peer کے بجائے backup target بنانا ہو تو selective folders استعمال کریں اور VPS پر receive only folder بنائیں۔

اسے منتخب کرنے کی وجہ migration ہے۔ Syncthing کو اس directory tree کی طرف point کریں جو پہلے سے موجود ہے۔ نہ import درکار ہے، نہ upload اور نہ conversion۔ VPS پر folder شامل کریں، پھر اسی folder ID کے ساتھ laptop پر بھی شامل کریں، اور دونوں sides کو converge ہونے دیں۔ اگر پہلے رابطے کے وقت دونوں sides پر ایک ہی فائل مختلف صورت میں موجود ہو تو Syncthing دونوں فائلیں رکھتا ہے اور ایک کا نام filename.sync-conflict-20260809-142530-ABCD123.txt کر دیتا ہے۔ پہلی sync کے دوران ایسی فائلیں نظر آنا معمول ہے، failure نہیں۔

آپ کو کن سہولتوں سے دست بردار ہونا پڑتا ہے۔ اس میں accounts نہیں ہوتے، دوسرے لوگوں کو بھیجنے کے لیے share links نہیں ہوتے، اور phone browser سے اپنی فائلیں browse کرنے کا طریقہ نہیں ہوتا۔ اصل Android app اب خود project کی جانب سے maintained نہیں ہے، اور ایک community fork اسے آگے برقرار رکھتا ہے۔ اگر مقصد mobile access ہو تو یہ بات اہم ہے۔ Syncthing اور Nextcloud کا براہ راست موازنہ feature gaps کا ایک ایک کر کے جائزہ لیتا ہے۔

Seafile: ہلکے سرور کے ساتھ تیز sync

Seafile کام کو دو حصوں میں تقسیم کرتا ہے۔ Seahub نامی Python web application interface دکھاتی ہے، جبکہ ایک الگ C process sync traffic سنبھالتا ہے۔ آپ کی file transfers web application سے نہیں گزرتیں، اسی لیے کوئی دوسرا شخص interface استعمال کر رہا ہو تب بھی بڑی upload تیز رہتی ہے۔ Version 13.0 کو 5 January 2026 کو release کیا گیا تھا۔

sudo mkdir -p /opt/seafile
cd /opt/seafile
sudo wget -O .env https://manual.seafile.com/13.0/repo/docker/ce/env
sudo wget https://manual.seafile.com/13.0/repo/docker/ce/seafile-server.yml
sudo wget https://manual.seafile.com/13.0/repo/docker/seadoc.yml
sudo wget https://manual.seafile.com/13.0/repo/docker/caddy.yml

کچھ بھی شروع کرنے سے پہلے .env میں ترمیم کریں۔ یہ SEAFILE_SERVER_HOSTNAME، INIT_SEAFILE_ADMIN_EMAIL، INIT_SEAFILE_ADMIN_PASSWORD، SEAFILE_MYSQL_DB_PASSWORD اور JWT_PRIVATE_KEY مقرر کرتی ہے، اور JWT_PRIVATE_KEY کم از کم 32 characters پر مشتمل random string ہونی چاہیے۔ یہ file compose کو یہ بھی بتاتی ہے کہ download کی گئی YAML files میں سے کون سی پڑھنی ہیں، اس لیے چاروں downloads مل کر ایک stack بناتے ہیں۔

cd /opt/seafile
sudo docker compose up -d
sudo docker compose ps

ہر container کو running state رپورٹ کرنی چاہیے۔ اگر کوئی container بار بار restart ہو رہا ہو تو تقریباً ہمیشہ .env میں کوئی value missing ہوتی ہے، اور sudo docker compose logs seafile بتاتا ہے کہ کون سی value غائب ہے۔

Resources۔ August 2026 تک Seafile کی documentation کم از کم 2 GB RAM اور 2 GHz سے زیادہ رفتار والا 2 core CPU تجویز کرتی ہے۔ اسے پورے stack کے لیے کم از کم ضرورت سمجھیں، کیونکہ Docker deployment MariaDB، Caddy reverse proxy اور SeaDoc editor بھی شروع کرتی ہے۔ اگر اسے ایک یا دو سے زیادہ افراد استعمال کریں تو 4 GB RAM دیں، یا optional containers شامل نہ کریں۔

Migration کا اہم مسئلہ storage format ہے۔ Seafile آپ کی files کو عام files کی صورت میں محفوظ نہیں کرتا۔ یہ ہر file کو /opt/seafile-data کے تحت blocks میں تقسیم کرتا ہے اور اس کی tree کو database میں درج کرتا ہے۔ آپ Seafile کو کسی موجودہ directory کی طرف point کر کے اسے library کے طور پر ظاہر نہیں کر سکتے، اس لیے migration کے لیے آپ کی تمام files کو ایک مرتبہ مکمل طور پر upload کرنا ہوگا۔ اسی design کی وجہ سے cp کے ذریعے data واپس بھی نہیں نکالا جا سکتا: recovery server کے ذریعے ہوتی ہے، consistency checks کے لیے seaf-fsck استعمال ہوتا ہے، یا read-only seaf-fuse mount کے ذریعے۔

rclone میں Seafile کا native backend موجود ہے، جو اس upload کو طویل drag-and-drop session کے بجائے ایک resumable command میں تبدیل کر دیتا ہے۔

rclone config
rclone copy /srv/files seafile:MyLibrary --progress

rclone کی documentation Seafile 6.x سے 9.x تک کے versions کو tested بتاتی ہے، اس لیے پہلے اسے ایک چھوٹے folder پر چلائیں اور نتیجہ چیک کریں، پھر 1 terabyte data منتقل کریں۔

Encrypted libraries وہ feature ہے جس کی خاطر لوگ migration کرتے ہیں۔ Password client میں set کیا جاتا ہے، اور server ایسے blocks محفوظ کرتا ہے جنہیں وہ پڑھ نہیں سکتا۔ ایک اہم وضاحت یہ ہے کہ encrypted library کی file کو browser میں preview کرنے پر اس session کے لیے password server کو بھیجا جاتا ہے، اس لیے browser preview اور zero-knowledge storage بیک وقت دستیاب نہیں ہوتے۔ Seafile اور Nextcloud کا براہ راست موازنہ میں باقی feature trade-offs کا جائزہ دیا گیا ہے۔

اوپر sync client کے ساتھ object storage

اگر مقصد کم لاگت میں بہت زیادہ bytes محفوظ کرنا اور انہیں scripts سے قابلِ رسائی رکھنا ہے تو S3 compatible object store چلائیں اور sync کو الگ tool سمجھیں۔ آپ کو durability، versioning اور ایسا protocol ملتا ہے جسے ہر backup tool پہلے ہی support کرتا ہے۔ لیکن file-server کے مفہوم میں user accounts یا ایسا file manager نہیں ملتا جسے استعمال کرنا آسان ہو۔ MinIO کے ساتھ self-hosted object storage میں server side کا طریقہ بیان کیا گیا ہے۔

rclone copy /srv/files s3remote:mybucket --progress
rclone check /srv/files s3remote:mybucket

rclone check دونوں sides کا size اور hash کے ذریعے موازنہ کرتا ہے اور بتاتا ہے کہ کتنی files مختلف ہیں۔ zero کے علاوہ کوئی بھی error اس بات کی علامت ہے کہ copy مکمل نہیں ہوئی، اس لیے source delete کرنے سے پہلے copy دوبارہ چلائیں۔ دو باتوں کی توقع رکھیں: object storage میں directories نہیں ہوتیں، صرف key prefixes ہوتے ہیں، اس لیے empty folder copy کے بعد برقرار نہیں رہتا؛ اور S3 chunk size کے ساتھ --transfers بڑھانے سے rclone کی memory use بڑھتی ہے، اس لیے 1 GB VPS پر دونوں کو default values پر رہنے دیں۔

صرف remote files درکار ہوں تو Plain WebDAV یا SFTP

اکثر سستا متبادل یہ ہوتا ہے کہ کچھ نیا نصب ہی نہ کیا جائے۔ اگر آپ کے VPS پر OpenSSH چل رہا ہے تو آپ کے پاس پہلے ہی file server موجود ہے۔ SFTP کے لیے اضافی daemon، database یا PHP درکار نہیں ہوتا، اور نہ ہی ایسا upgrade کرنا پڑتا ہے جو اتوار کے دن خرابی پیدا کر دے۔

sftp you@your-vps
rclone mount sftpremote: ~/vps --vfs-cache-mode writes

WebDAV استعمال کرنے والے clients کے لیے، جن میں زیادہ تر phone file managers شامل ہیں، rclone اسی tree کو serve کر سکتا ہے۔

sudo apt install apache2-utils
sudo htpasswd -c /etc/rclone/htpasswd you
rclone serve webdav --addr 127.0.0.1:8080 --htpasswd /etc/rclone/htpasswd /srv/files

اسے 127.0.0.1 سے bind کریں اور اس کے سامنے TLS (transport layer security) کے ساتھ reverse proxy رکھیں۔ WebDAV basic authentication ہر request میں password بھیجتی ہے، اس لیے یہاں plain HTTP استعمال کرنے کا مطلب ہے کہ password ایک منٹ میں کئی مرتبہ بھیجا جائے گا۔ Migration کی لاگت صفر ہے، کیونکہ files کہیں منتقل نہیں ہوتیں۔ اس کا نقصان یہ ہے کہ sync اور offline copy موجود نہیں ہوتی: link منقطع ہونے پر client سے files اس وقت تک غائب رہتی ہیں جب تک connection بحال نہ ہو جائے۔

کیلنڈر، contacts اور دستاویزات کی editing کے متبادل

Nextcloud چھوڑنے سے یہاں کچھ سہولتیں ختم ہوتی ہیں، اور یہ واضح کرنا ضروری ہے کہ کون سی۔ کیلنڈر اور contacts، CalDAV اور CardDAV ہیں (HTTP کے ذریعے کیلنڈر اور contacts کی synchronization)، جبکہ Radicale ان کا ہلکا متبادل ہے۔ یہ ہر collection کو disk پر files کی صورت میں محفوظ کرتا ہے اور عموماً دسیوں megabytes استعمال کرتا ہے۔

sudo apt install radicale
sudo systemctl enable --now radicale
sudo ss -lntp | grep 5232

package میں /usr/lib/systemd/system/radicale.service اور اس کی default config /etc/radicale/config شامل ہے، اور یہ localhost:5232 پر listening کرتا ہے۔ Radicale میں events edit کرنے کے لیے interface نہیں ہے، اس لیے phone یا desktop client کو اس سے connect کریں اور editing وہیں کریں۔

Browser میں documents edit کرنے کا متبادل تلاش کرنا زیادہ مشکل ہے۔ OnlyOffice Docs اور Collabora Online دونوں editing engines ہیں، storage systems نہیں۔ ہر ایک کو ایسی host application درکار ہوتی ہے جو files محفوظ کرے اور documents اس کے حوالے کرے۔ Nextcloud ہٹانے کے بعد آپ کو کوئی دوسری host درکار ہوگی، مثلاً Seafile، جس کا اپنا SeaDoc editor ہے۔ OnlyOffice اور Collabora کا موازنہ اس بات کا جائزہ پیش کرتا ہے کہ host کا فیصلہ کرنے کے بعد کون سا engine چلایا جائے۔

اگر درج ذیل میں سے کوئی بات درست ہے تو Nextcloud برقرار رکھیں

• کئی افراد ایک calendar اور ایک address book استعمال کرتے ہیں، اور یہی accounts فائلوں کے لیے بھی استعمال ہوتے ہیں۔
• آپ browser میں office documents میں ترمیم کرتے ہیں، اور اسی file میں کسی دوسرے شخص کے ساتھ بیک وقت کام کرتے ہیں۔
• آپ کو ہر file کے لیے expiry dates اور passwords والے share links، نیز group permissions درکار ہیں۔
• آپ کے users تکنیکی ماہر نہیں ہیں، اور وہ عملاً mobile apps ہی استعمال کرتے ہیں۔

ان کاموں کے لیے ایسا ہلکا متبادل موجود نہیں جو یہ سب کچھ انجام دے سکے۔ اس لیے درست فیصلہ یہ ہے کہ installation چھوڑنے کے بجائے اسے درست کیا جائے۔ زیادہ تر سست instances میں default PHP-FPM pool چل رہا ہوتا ہے اور memory cache configure نہیں ہوتی۔ Nextcloud کا admin overview page missing cache کے بارے میں warning دیتا ہے۔ tracked files کی تعداد کم کرنے سے کسی بھی ایک دوسری تبدیلی کے مقابلے میں زیادہ فائدہ ہوتا ہے، کیونکہ file cache table ہی بڑھتی ہے۔ Docker، TLS اور backups کے ساتھ VPS پر Nextcloud installation اسے اس طریقے سے configure کرتی ہے جس سے ان میں سے زیادہ تر مسائل سے بچا جا سکتا ہے۔

منتقلی کی اصل لاگت، ہر اختیار کے لحاظ سے

• Syncthing: کوئی import نہیں۔ اسے دونوں جانب موجودہ tree پر point کریں اور اسے ہم آہنگ ہونے دیں۔
• اسی tree پر SFTP یا WebDAV: بالکل کوئی import نہیں، کیونکہ کچھ بھی منتقل نہیں ہوتا۔
• Object storage: نیٹ ورک کے ذریعے ایک مکمل copy، جسے resume کیا جا سکتا ہے اور script کے ذریعے چلایا جا سکتا ہے؛ خالی folders اس عمل میں برقرار نہیں رہتے۔
• Seafile: libraries میں ایک مکمل upload، کیونکہ server files کے بجائے blocks محفوظ کرتا ہے۔

آپ جو بھی اختیار منتخب کریں، پہلے Nextcloud سے ایک صاف copy حاصل کریں۔ User files data directory کے اندر plain form میں، ہر user کے لیے ایک folder میں موجود ہوتی ہیں، اس لیے rsync اس tree کا source ہے۔ copy کرنے سے پہلے instance کو maintenance mode میں رکھیں، ورنہ copy کے دوران لکھا جا رہا data بھی شامل ہو جائے گا۔

sudo -u www-data php occ maintenance:mode --on
sudo rsync -a --info=progress2 /path/to/nextcloud/data/ /srv/files/
find /srv/files -type f | wc -l

اس count کا source پر موجود اسی find سے موازنہ کریں۔ کمی عموماً اس لیے ہوتی ہے کہ permissions نے rsync کو کچھ پڑھنے سے روک دیا، اور یہ عمل کے دوران وہ errors دکھاتا ہے۔

اس copy میں دو اہم مسائل پیش آ سکتے ہیں۔ Nextcloud کے external storage feature کے ذریعے حاصل کی جانے والی files data directory میں بالکل موجود نہیں ہوتیں، کیونکہ وہ اس remote system پر محفوظ ہوتی ہیں جس کے بارے میں Nextcloud کو بتایا گیا ہے۔ اگر server-side encryption کبھی enabled کی گئی ہو تو disk پر موجود files ciphertext ہوتی ہیں، اس لیے copy سے پہلے occ encryption:decrypt-all چلانا ضروری ہے؛ ورنہ آپ ناقابلِ مطالعہ data کا folder منتقل کریں گے۔ کسی بھی عمل کو cancel کرنے سے پہلے دونوں امور کی جانچ کریں۔

FAQ

کیا کوئی ایسا Nextcloud متبادل ہے جو میری موجودہ folder structure برقرار رکھے؟

Syncthing، اور کوئی بھی سادہ SFTP یا WebDAV setup۔ Syncthing اس directory کو index کرتا ہے جس کی آپ نشاندہی کرتے ہیں، اور ہر device پر وہی names اور layout برقرار رکھتا ہے؛ اس لیے import step یا upload کی ضرورت نہیں ہوتی۔ Seafile اور object storage دونوں کے لیے ایک مکمل upload pass درکار ہوتا ہے، کیونکہ ان میں سے کوئی بھی آپ کے data کو عام files کی صورت میں عام tree کے اندر محفوظ نہیں کرتا۔ Seafile اپنی data directory کے اندر files کو blocks میں تقسیم کرتا ہے، جبکہ object storage میں directories کے بجائے keys ہوتی ہیں۔

کیا Seafile 2 GB VPS پر چل جائے گا؟

August 2026 تک Seafile کی documentation میں کم از کم 2 GB RAM اور 2 GHz سے زیادہ رفتار والا 2 core CPU درکار بتایا گیا ہے۔ اسے بغیر کسی اضافی گنجائش کی کم از کم حد سمجھیں، کیونکہ Docker deployment اپنے الگ containers میں MariaDB، Caddy اور SeaDoc editor بھی چلاتی ہے۔ ایک user کے لیے یہ قابلِ استعمال ہے۔ گھرانے یا چھوٹی team کے لیے 4 GB پر منتقل ہوں، یا SeaDoc container کو stack سے نکال دیں اور in-browser document editing ترک کر دیں۔

downloads اب بھی تیز ہوں تو میرا Nextcloud web interface سست کیوں ہے؟

کیونکہ دونوں paths میں مختلف کام ہوتا ہے۔ Download disk سے bytes stream کرتا ہے، جبکہ page load PHP چلاتا ہے، file cache table سے queries کرتا ہے، اور اکثر کسی free PHP-FPM worker کا انتظار کرتا ہے۔ Storage کو موردِ الزام ٹھہرانے سے پہلے oc_filecache میں rows شمار کریں اور اپنے PHP-FPM pool میں pm.max_children چیک کریں۔ لاکھوں rows والی table اور پانچ workers کا pool عین یہی pattern پیدا کرتے ہیں۔

کیا میں calendars کے لیے Nextcloud برقرار رکھ کر صرف files منتقل کر سکتا ہوں؟

ہاں، اور اکثر یہ سب سے کم خرچ حل ہوتا ہے۔ اپنے بڑے folders کو Syncthing یا Seafile کے ساتھ sync کریں، اور Nextcloud کو CalDAV، CardDAV اور browser document editing کے لیے چلتا رہنے دیں۔ چونکہ Nextcloud کا database اس کے track کردہ files کی تعداد کے ساتھ بڑھتا ہے، اس لیے بڑے trees کو اس سے ہٹانا ہی interface کو دوبارہ تیز بناتا ہے۔ انہیں web interface یا occ کے ذریعے delete کریں، disk پر موجود data directory سے نہیں؛ ورنہ database میں ان files کی طرف اشارہ کرنے والی rows برقرار رہیں گی جو اب موجود نہیں ہیں۔