فائل sync کے لیے Seafile یا Nextcloud؟

Seafile بمقابلہ Nextcloud: مختصر جواب

Seafile بمقابلہ Nextcloud کا فیصلہ ایک بنیادی فرق پر ہوتا ہے: سرور تک پہنچنے کے بعد فائل کی نوعیت کیا رہتی ہے۔ Seafile ہر فائل کو blocks میں تقسیم کرتا ہے اور انہیں ایسے object store میں محفوظ کرتا ہے جسے صرف Seafile پڑھ سکتا ہے۔ اس لیے sync تیز ہوتی ہے، لیکن backup دو حصوں پر مشتمل کام بن جاتا ہے۔ Nextcloud آپ کی فائل کو disk پر فائل کے طور پر لکھتا ہے، اور sync کو ایسے platform کی ایک feature سمجھتا ہے جو calendars، contacts، documents اور share links بھی چلاتا ہے۔ اسی فرق کی بنیاد پر فیصلہ کریں، کیونکہ باقی تمام امور اسی سے متعین ہوتے ہیں۔

August 2026 تک Seafile کی 13.0 series اور Nextcloud کی 34 series ہے۔ دونوں mature ہیں، اور ان میں سے کوئی بھی اپنے storage model کو جلد تبدیل نہیں کرے گا۔

Seafile آپ کی فائلیں کیسے محفوظ کرتا ہے

Seafile library کو اسی طرح ماڈل کرتا ہے جیسے git repository کو ماڈل کرتا ہے۔ انتظامی manual میں داخلی ماڈل Repo، Commit، FS اور Block کے طور پر دیا گیا ہے، اور یہ بھی بتایا گیا ہے کہ repo کو library بھی کہا جاتا ہے۔ ہر فائل کو content-defined chunking (CDC، ایک ایسا algorithm جو خود data کی بنیاد پر block boundaries منتخب کرتا ہے) کے ذریعے مختلف لمبائی کے blocks میں تقسیم کیا جاتا ہے، اور manual میں block کا اوسط سائز تقریباً 8 MB بتایا گیا ہے۔ Blocks کے نام ان کے contents کی بنیاد پر رکھے جاتے ہیں، اس لیے ایک بڑی فائل کے دو versions ہر وہ block مشترک طور پر استعمال کرتے ہیں جو تبدیل نہیں ہوا، اور دو libraries بھی یکساں blocks مشترک طور پر استعمال کرتی ہیں۔

Relational database میں libraries کے بارے میں صرف تھوڑی مقدار میں metadata محفوظ ہوتا ہے۔ باقی سب کچھ، یعنی commits، directory objects اور blocks، data directory کے تحت موجود ہوتا ہے۔ 12 اور 13 series میں استعمال ہونے والے Docker layout میں یہ /opt/seafile-data/seafile/seafile-data ہے۔ وہاں ls چلانے سے آپ کو کوئی مفید معلومات نہیں ملتیں، کیونکہ آپ کو hash names سے بھری directories دکھائی دیتی ہیں، نہ کہ Invoices/2026/march.pdf۔

Sync بھی اسی model کی پیروی کرتا ہے۔ Client server سے پوچھتا ہے کہ کیا تبدیل ہوا، block hashes کی فہرست وصول کرتا ہے، اور صرف وہ blocks حاصل کرتا ہے جو اس کے پاس پہلے سے موجود نہیں ہوتے۔ اسی وجہ سے Seafile بڑی library کے ساتھ مؤثر رہتا ہے: منتقل ہونے والے bytes ان blocks کے متناسب ہوتے ہیں جو تبدیل ہوئے ہیں، نہ کہ اس file کے سائز کے جو انہیں شامل کرتی ہے۔

Nextcloud آپ کی فائلیں کیسے محفوظ کرتا ہے

Nextcloud فائل کو disk پر اسی جگہ محفوظ کرتا ہے جہاں آپ اس کی توقع کرتے ہیں۔ path data/<username>/files/ میں وہی ساخت ہوتی ہے جو صارف web interface میں دیکھتا ہے۔ database table oc_filecache بھی اسی درختی ساخت کو file sizes، modification times اور etags کے ساتھ محفوظ کرتی ہے، اور Nextcloud disk کے بجائے اسی table پر اعتماد کرتا ہے۔

desktop client HTTPS کے ذریعے WebDAV (web distributed authoring and versioning) سے رابطہ کرتا ہے۔ ہر فائل کے لیے کم از کم ایک request درکار ہوتی ہے۔ اسی لیے Nextcloud نے bulk upload API شامل کی۔ developer manual کے مطابق بہت سی چھوٹی فائلیں upload کرنا اس لیے سست ہوتا ہے کہ network bandwidth پوری طرح استعمال نہیں ہوتی، لہٰذا چھوٹی فائلوں کو ایک ساتھ pack کیا جاتا ہے۔ بڑی فائلیں اس کے بجائے chunking API کے ذریعے منتقل ہوتی ہیں، اور desktop client کا default chunk size 5 MiB ہوتا ہے (OWNCLOUD_CHUNK_SIZE کی default قدر 5242880 bytes ہے)۔

disk پر فائلیں رکھنے کا فائدہ یہ ہے کہ آپ کے پاس موجود ہر tool آپ کا data پڑھ سکتا ہے۔ اس کا نقصان یہ ہے کہ Nextcloud اپنی نگرانی کے بغیر کی گئی تبدیلیوں کا پتہ نہیں چلاتا۔ فائلیں براہِ راست data directory میں copy کریں تو scan کرنے تک وہ web interface میں نظر نہیں آئیں گی:

sudo -E -u www-data php occ files:scan --all -vv

admin manual rescan کے لیے بالکل یہی صورتیں بیان کرتا ہے: فائلیں براہِ راست data directory میں copy کرنے کے بعد، migration کے بعد، اور file cache inconsistencies کی تفتیش کے دوران۔

کون سا بڑے library کو زیادہ تیزی سے sync کرتا ہے؟

Seafile، خاص طور پر ان دو صورتوں میں جہاں فرق نمایاں ہوتا ہے: دسیوں ہزار چھوٹی files، اور بڑی files میں بار بار کی جانے والی edits۔ اس کا طریقۂ کار block-level deduplication ہے، اس لیے 4 GB کی disk image کے درمیان میں تبدیلی ہو تو صرف چند blocks upload ہوتے ہیں۔ Nextcloud bulk upload کے ذریعے چھوٹی files کے فرق کو کم کرتا ہے، لیکن بڑی file کے فرق کو ختم نہیں کر سکتا، کیونکہ اس میں transfer unit پوری file ہوتی ہے۔

فرق کی مقدار کے بارے میں نہ صرف میری بات پر بھروسا کریں، بلکہ vendor benchmark پر بھی انحصار نہ کریں۔ ایسی library بنائیں جو آپ کی library جیسی ہو، پھر اس کا وقت ناپیں:

mkdir -p ~/synctest && cd ~/synctest
for i in $(seq 1 20000); do head -c 4096 /dev/urandom > "file_$i.bin"; done
du -sh ~/synctest

اس directory کو ہر server کے synced folder میں رکھیں اور دیکھیں کہ client کب مکمل ہوتا ہے۔ Reliability کی اہمیت speed جتنی ہی ہے۔ Seafile client پہلے blocks upload کرتا ہے اور آخر میں ان کا حوالہ دینے والا commit لکھتا ہے، اس لیے upload کے دوران رکاوٹ آنے پر library آدھی لکھی ہوئی tree کے بجائے اپنے پچھلے commit پر رہتی ہے۔

چھوٹے VPS پر ہر ایک کی ضروریات

Seafile کی دستاویزات میں "کم از کم 2G RAM اور 2-core CPU (> 2GHz)" درکار بتایا گیا ہے۔ Nextcloud اس کے بجائے memory کو ہر PHP process کے حساب سے بیان کرتا ہے: کم از کم 128 MB اور تجویز کردہ 512 MB فی process۔ اس مقدار کو worker count سے ضرب دے کر database، cache اور preview generation کی memory شامل کریں۔ ذیل میں چھوٹی ٹیم کے لیے وہ ابتدائی وسائل دیے گئے ہیں جنہیں میں استعمال کروں گا۔ یہ ابتدائی اندازے ہیں، پیمائش شدہ نتائج نہیں۔

[
  {
    "label": "Seafile CE 13",
    "start_ram_gb": 4,
    "start_cpu_cores": 2,
    "sql_databases": 3
  },
  {
    "label": "Nextcloud 34",
    "start_ram_gb": 4,
    "start_cpu_cores": 2,
    "sql_databases": 1
  },
  {
    "label": "Syncthing 2",
    "start_ram_gb": 1,
    "start_cpu_cores": 1,
    "sql_databases": 0
  }
]

دونوں ایک ہی زمرے میں آتے ہیں: 4 GB RAM اور 2 cores۔ اس لیے footprint کی بنیاد پر ان میں فیصلہ نہیں ہوتا۔ Syncthing 1 GB RAM اور 1 core میں چلتا ہے، اور اسے زیرِ غور لانے کی یہی معقول وجہ ہے۔ Memory کے مقابلے میں دونوں کے operational components میں زیادہ فرق ہے۔ Seafile میں 3 SQL databases ہوتی ہیں، جبکہ Nextcloud میں 1 ہوتی ہیں۔ Seafile کی default Docker deployment ان files سے server، MariaDB، Memcached، SeaDoc اور Caddy شروع کرتی ہے جو آپ پہلے download کرتے ہیں:

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

.env میں SEAFILE_SERVER_HOSTNAME، MySQL root اور database passwords، ابتدائی admin account، اور JWT_PRIVATE_KEY مقرر کریں۔ Manual میں اس key کے لیے کم از کم 32 characters پر مشتمل random string درکار ہے۔ یہ value پہلی start کے وقت پڑھی جاتی ہے، اس لیے stack شروع کرنے سے پہلے اسے generate کریں:

openssl rand -base64 40
docker compose up -d

پہلی start تینوں databases اور admin user بناتی ہے۔ Nextcloud کے متعلقہ فیصلے، جن میں TLS اور reverse proxy بھی شامل ہیں، Docker، TLS اور backups کے ساتھ VPS پر Nextcloud کی guide میں بیان کیے گئے ہیں۔

بیک اپس میں کیا فرق ہے؟

یہ وہ پہلو ہے جسے لوگ کم اہم سمجھتے ہیں، اور دونوں مصنوعات میں سب سے بڑا فرق بھی یہی ہے۔

Seafile میں ترتیب اختیاری نہیں ہے۔ manual کی ہدایت ہے کہ پہلے SQL کا بیک اپ لیں اور اس کے بعد data directory کا، کیونکہ اس طرح database کے ہر record کے لیے reference کرنے والا درست object موجود رہتا ہے اور libraries خراب نہیں ہوتیں۔ اگر ترتیب الٹ دی جائے تو database کی کوئی row ایسے block کی طرف اشارہ کر سکتی ہے جسے آپ کے snapshot نے محفوظ ہی نہیں کیا۔

docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt ccnet_db > ccnet_db.sql
docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt seafile_db > seafile_db.sql
docker exec -i seafile-mysql mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --opt seahub_db > seahub_db.sql
rsync -az /opt/seafile-data/seafile /backup/data/

ان سطور میں دو باتیں اہم ہیں۔ mariadb-dump استعمال کریں، کیونکہ mysql commands کی series، Seafile کے ساتھ فراہم کردہ MariaDB image میں deprecated ہے۔ جب output کو file میں redirect کریں تو docker exec سے -t flag نکال دیں، کیونکہ TTY line endings کو دوبارہ لکھ کر dump کو خراب کر دیتا ہے۔

دونوں حصے الگ الگ محفوظ کیے جاتے ہیں، اس لیے ان میں وقت کے ساتھ فرق آ سکتا ہے۔ کسی بھی restore کے بعد store کو قابلِ اعتماد سمجھنے سے پہلے اسے check کریں:

docker exec -it seafile bash
cd /opt/seafile/seafile-server-latest
./seaf-fsck.sh

جب کوئی چیز غائب ہو تو tool object کا نام بتاتا ہے:

Block 650fb22495b0b199cff0f1e1ebf036e548fcb95a is missing.
Repo ca1a860d HEAD commit is corrupted, need to restore to an old version.

garbage collection کے لیے بھی منصوبہ بنائیں۔ Deduplication کی وجہ سے deleted files اور deleted libraries کے blocks اس وقت تک برقرار رہتے ہیں جب تک آپ اسی directory سے ./seaf-gc.sh نہ چلائیں، اور run اپنی دریافت کی تفصیل دیتا ہے، مثلاً GC finished. 507 blocks total, about 507 reachable blocks, 0 blocks can be removed.۔ اگر اسے ایک سال تک نہ چلایا جائے تو آپ کے backups ایسے data کی لاگت بھی اٹھاتے رہیں گے جسے صارفین delete کر چکے ہیں۔

Nextcloud میں بھی یہی دو حصوں کا مسئلہ مختلف شکل میں موجود ہے، کیونکہ data directory اور database کو ایک ہی tree کی وضاحت کرنی چاہیے:

sudo -E -u www-data php occ maintenance:mode --on
rsync -Aavx /srv/nextcloud/ /backup/nextcloud-dirbkp/
mariadb-dump --single-transaction --default-character-set=utf8mb4 -u nextcloud -p"$DB_PASS" nextcloud > /backup/nextcloud-sqlbkp.bak
sudo -E -u www-data php occ maintenance:mode --off

config folder، data folder، تمام custom apps اور اپنا theme، نیز اس dump کو محفوظ رکھیں۔ دونوں حصوں کو ایک ہی وقت کے backup سے restore کریں۔ اگر data directory database سے نئی ہو تو صارفین کو ایسی files نظر آتی ہیں جن سے file cache واقف نہیں ہوتا، اور occ files:scan --all اسے درست کرتا ہے۔ اگر database نیا ہو تو cache rows ان files کی طرف اشارہ کرتی ہیں جو موجود نہیں، اور occ files:cleanup storage table میں matching entry نہ رکھنے والی cache entries کو حذف کرتا ہے۔

دونوں صورتوں میں آپ کو ایسا backup program چاہیے جو بہت سی چھوٹی files کو سنبھال سکے اور history محفوظ رکھے، اور یہی وہ کام ہے جو restic اور BorgBackup مختلف طریقے سے کرتے ہیں۔

ڈیسک ٹاپ اور موبائل پر کلائنٹس

Seafile دو ڈیسک ٹاپ پروگرام فراہم کرتا ہے۔ Syncing client آپ کی منتخب کردہ libraries کی مقامی نقل برقرار رکھتا ہے۔ Drive client (SeaDrive) آپ کی libraries کو virtual drive کے طور پر mount کرتا ہے اور رسائی کے وقت فائلیں download کرتا ہے: Windows پر یہ Microsoft کی cloud files API استعمال کرتا ہے، macOS پر version 3.0 سے یہ Finder extension ہے، اور Linux پر version 3.0.12 سے یہ AppImage کے طور پر فراہم کیا جاتا ہے اور ~/SeaDrive پر mount ہوتا ہے۔ Encrypted libraries تینوں ڈیسک ٹاپ platforms پر کام کرتی ہیں۔ Mobile apps فائلوں تک رسائی کے لیے موجود ہیں، اور ان کا مقصد صرف یہی ہے۔

Nextcloud کا desktop client بھی virtual files فراہم کرتا ہے، جبکہ اس کی mobile apps platform کے باقی حصے بھی ساتھ لاتی ہیں؛ اس لیے file access کے ساتھ calendar، contacts، Talk اور notes بھی دستیاب ہوتے ہیں۔ اگر آپ کے users زیادہ تر phones استعمال کرتے ہیں اور انہیں صرف فائلوں سے زیادہ سہولیات درکار ہیں، تو روزمرہ استعمال میں یہ ایک حقیقی فرق ہے۔

Seafile کی ایک تفصیل کی منصوبہ بندی ضروری ہے: library sharing، sync، permissions اور encryption کی بنیادی اکائی ہے۔ 500 GB کو ایک ہی library میں load کرنے سے پہلے اپنی library layout طے کریں، کیونکہ libraries کے درمیان منتقلی rename نہیں بلکہ copy اور delete کا عمل ہے؛ اس لیے file history بھی اس کے ساتھ منتقل نہیں ہوتی۔

Encryption: ہر طریقہ حقیقت میں کیا محفوظ کرتا ہے

Seafile کی encrypted libraries کلائنٹ سائیڈ پر کام کرتی ہیں۔ password کبھی server پر محفوظ نہیں ہوتا۔ password اور library id سے اخذ کیا گیا ایک magic token library کے ساتھ محفوظ ہوتا ہے، تاکہ client sync شروع کرنے سے پہلے password کی تصدیق کر سکے۔ password سے AES 256/CBC استعمال کرتے ہوئے ایک key اور IV (initialisation vector) اخذ کی جاتی ہے۔ file key اسی key سے encrypt ہوتی ہے، اور file data کو اس file key سے encrypt کیا جاتا ہے۔

دستاویزی حدود ضرور پڑھیں، کیونکہ لوگ انہیں نظر انداز کر دیتے ہیں۔ encrypted library صرف file contents کو encrypt کرتی ہے۔ folder اور file names encrypt نہیں ہوتے، اور file sizes یا edit history بھی encrypt نہیں ہوتے۔ web browser میں encrypted library دیکھنا end to end نہیں ہے: آپ password درج کرتے ہیں، server اسے file key decrypt کرنے کے لیے استعمال کرتا ہے، اور password کو ایک گھنٹے کے لیے memory میں cache کر لیتا ہے۔ manual میں یہ بھی واضح ہے کہ encrypted library integrity یقینی نہیں بناتی، کیونکہ server admin file کے کسی حصے کا content تبدیل کر سکتا ہے اور client اس تبدیلی کا پتا نہیں چلا سکتا۔

Nextcloud میں دو features ہیں جن کے نام ایک دوسرے سے گمراہ کن حد تک ملتے جلتے ہیں۔ Server side encryption files کو at rest حالت میں encrypt کرتی ہے، لیکن keys اسی server پر رکھتی ہے۔ اس لیے یہ external storage پر محفوظ data کو بہتر طور پر محفوظ کرتی ہے، مگر اس مشین پر root رکھنے والے شخص سے تحفظ فراہم نہیں کرتی۔ end to end encryption app کلائنٹ پر منتخب folders کو encrypt کرتی ہے۔ ڈیزائن کے مطابق server انہیں پڑھ نہیں سکتا، اس لیے web interface، server side search اور previews بھی ان folders کے اندر موجود data نہیں دیکھ سکتے۔

کسی بھی product کی encryption encrypted backup کا متبادل نہیں ہے۔ Backup کو الگ سے encrypt کریں۔

کیلنڈر، contacts، office اور app platform

یہ محور قریب نہیں ہے۔ Nextcloud میں core کے اندر CalDAV (WebDAV کے ذریعے calendar) اور CardDAV (WebDAV کے ذریعے contacts) شامل ہیں۔ یہ documents کے لیے Collabora یا OnlyOffice کے ساتھ integration فراہم کرتا ہے اور باقی ضروریات کے لیے app store بھی موجود ہے۔ Seafile 13 میں collaborative documents اور wiki pages کے لیے SeaDoc شامل ہے، اور یہیں تک محدود ہے۔ اس میں calendar یا address book موجود نہیں ہے۔

اس platform کی ایک قیمت ہے، اور وہ قیمت upgrades ہیں۔ آپ جو بھی app install کرتے ہیں، وہ Nextcloud upgrade کو روک سکتی ہے یا upgrade کے بعد درست طور پر کام نہ کرے۔ اس لیے آپ کے users جتنی زیادہ apps پر depend کریں گے، upgrade window کو اتنی ہی زیادہ احتیاط سے manage کرنا ہوگا۔ Seafile میں خراب ہونے کے لیے کم اجزا ہیں، کیونکہ اس کی functionality بھی کم ہے۔ یہ بھی یاد رکھیں کہ documents کے اندر full text search اور folder level permissions paid licence کے تحت Seafile Professional میں شامل ہیں، Community Edition میں نہیں۔ اس لیے تصدیق کریں کہ جس feature پر آپ انحصار کر رہے ہیں، وہ اس edition میں شامل ہے جسے آپ چلانے کا ارادہ رکھتے ہیں۔

ہر ایک کی معروف خرابی

Seafile اس وقت ناکام ہوتا ہے جب database اور object store میں مطابقت ختم ہو جائے۔ آپ کو ایسی library نظر آتی ہے جو کھل نہیں رہی، یا ایسی files نظر آتی ہیں جو غائب ہو گئی ہیں، اور seaf-fsck.sh غائب block کی نشاندہی کرتا ہے۔ یہاں ہاتھ سے درست کرنے کے لیے file tree موجود نہیں ہوتا، اس لیے recovery کے لیے آپ کا database dump اور object store درکار ہوتے ہیں، اور انہیں درست ترتیب سے restore کرنا ہوتا ہے۔ اس restore کو ایک بار اضافی VPS پر ضرور آزمائیں، کیونکہ ایسا backup جسے آپ نے کبھی restore نہ کیا ہو، صرف ایک اندازہ ہے۔

Nextcloud اس وقت ناکام ہوتا ہے جب file cache اور disk کی معلومات میں اختلاف ہو جائے۔ عموماً اس کی وجہ یہ ہوتی ہے کہ کسی چیز نے Nextcloud کو بتائے بغیر data directory میں لکھ دیا ہو۔ آپ کو disk پر ایسی file نظر آتی ہے جسے web interface فہرست میں شامل نہیں کرتا، یا ایسا folder نظر آتا ہے جس کا size درست نہیں، اور occ files:scan اس کا حل ہے۔ اس کی دو دیگر بڑی مشکلات بہت سی چھوٹی files کے ساتھ protocol speed اور PHP memory ہیں۔ CPU کی مقدار بڑھانے سے پہلی مشکل حل نہیں ہوتی۔ بڑی images اور videos کے previews عموماً memory میں اچانک اضافہ کرتے ہیں، اس لیے ہر process کے لیے 512 MB رکھیں اور previews requests کے دوران بنانے کے بجائے scheduled job میں generate کریں۔

دونوں میں سے کوئی نہیں: اگر آپ کو صرف فائلوں کی ہم وقت سازی چاہیے تو Syncthing

اگر آپ کی اصل ضرورت مشینوں کے درمیان ایک فولڈر کی mirror بنانا ہے، تو دونوں مصنوعات آپ کی ضرورت سے زیادہ سافٹ ویئر فراہم کرتی ہیں۔ Syncthing میں server یا accounts نہیں ہوتے۔ ہر device ایک peer ہوتی ہے، اور VPS وہ peer بن جاتا ہے جو آپ کے laptop کے sleep ہونے پر بھی بیدار رہتا ہے۔ Syncthing 2 موجودہ release line ہے، اور packages project کی اپنی repository سے حاصل ہوتے ہیں:

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

اسے عام user کے طور پر چلائیں، کبھی بھی root کے طور پر نہیں، تاکہ اس کی لکھی ہوئی files کی ownership درست رہے:

sudo systemctl enable --now syncthing@youruser
systemctl status syncthing@youruser

web interface بطور default 127.0.0.1:8384 پر bind ہوتی ہے، اس لیے یہ internet سے قابل رسائی نہیں ہوتی، جو درست default ہے۔ اپنے laptop سے SSH tunnel کے ذریعے اس تک رسائی حاصل کریں:

ssh -L 8384:127.0.0.1:8384 youruser@your-server

اس کے بعد laptop پر http://127.0.0.1:8384 کھولیں۔ Sync خود TCP اور QUIC پر port 22000 استعمال کرتی ہے، جبکہ local discovery UDP 21027 استعمال کرتی ہے، جو internet کے پار کوئی کام نہیں کرتی۔ VPS پر 22000 کھولیں اور interface کو بند رہنے دیں:

sudo ufw allow 22000/tcp
sudo ufw allow 22000/udp

اس کے بدلے آپ server کی تمام features سے محروم ہو جاتے ہیں: ایسے لوگوں کے لیے share links نہیں ہوتے جو Syncthing نہیں چلاتے، web file browser نہیں ہوتا، user accounts نہیں ہوتے، اور server-side trash بھی نہیں ہوتا، الا یہ کہ آپ ہر folder کے لیے file versioning فعال کریں۔ عام طور پر پیش آنے والی حیرت conflict file ہوتی ہے۔ اگر دو devices پر ایک ہی file کو اس وقت edit کریں جب وہ ایک دوسرے کو نہیں دیکھ سکتیں، تو notes.sync-conflict-20260806-142233-ABCD1EF.md جیسی نام والی ایک sibling file بن جاتی ہے۔ کوئی warning ظاہر نہیں ہوتی، اس لیے وقتاً فوقتاً sync-conflict تلاش کریں۔

اگر آپ کو synced folder نہیں بلکہ ایسا bucket چاہیے جس میں applications data لکھیں، تو اس کے لیے ایک مختلف tool درکار ہے: self-hosted S3 compatible object storage دیکھیں۔ وسیع تر جائزے کے لیے self-hosted Dropbox متبادلات کا جائزہ میں ان options کا احاطہ کیا گیا ہے جو اس comparison میں شامل نہیں ہو سکے۔

فیصلہ کرنے کا اصول

1. اگر کام بڑے پیمانے پر sync ہے، یعنی بہت سی files، بڑی files، متعدد devices، اور ایسا data store قابل قبول ہے جسے صرف Seafile پڑھ سکتا ہے، تو Seafile منتخب کریں۔
2. اگر کام ایک platform درکار کرتا ہے، یعنی calendars، contacts، documents اور share links، جبکہ disk پر plain files موجود ہوں جنہیں کوئی بھی backup tool پڑھ سکتا ہو، تو Nextcloud منتخب کریں۔
3. اگر کام صرف mirrored folder کا ہے اور کسی اضافی feature کی ضرورت نہیں، تو Syncthing منتخب کریں۔

اب احتیاط سے انتخاب کریں، کیونکہ Seafile اور Nextcloud کے درمیان migration ہی اصل lock-in ہے۔ اس کے لیے کوئی converter موجود نہیں۔ آپ تمام data کسی client پر sync کرتے ہیں، اسے دوسرے server پر upload کرتے ہیں، اور bandwidth اور وقت کی قیمت ادا کرتے ہیں، جبکہ version history اور share links پچھلے server پر رہ جاتے ہیں۔ آج کے انتخاب کی sizing اگلے تین سال کے لیے کرنا، دوسرے سال میں switching کرنے سے کم مہنگا ہے۔

FAQ

کیا بڑی libraries کی syncing کے لیے Seafile، Nextcloud سے تیز ہے؟

ہاں، ان دونوں صورتوں میں عموماً کارکردگی متاثر ہوتی ہے، اور اس کی وجہ verify کی جا سکتی ہے۔ Seafile فائلوں کو اوسطاً تقریباً 8 MB کے blocks میں تقسیم کرتا ہے اور صرف تبدیل شدہ blocks منتقل کرتا ہے، اس لیے بڑی فائل کے اندر کی گئی ترمیم میں چند blocks منتقل ہوتے ہیں۔ Nextcloud میں transfer unit پوری فائل ہوتی ہے، اس لیے وہی ترمیم پوری فائل دوبارہ upload کرتی ہے۔ بہت سی چھوٹی فائلوں کے لیے کم از کم ایک WebDAV request درکار ہوتی ہے، اسی لیے اس کی bulk upload API چھوٹی فائلوں کو ایک ساتھ pack کرتی ہے۔ فیصلہ کرنے سے پہلے اپنے VPS پر دونوں کا وقت ناپیں، کیونکہ آپ کا CPU، disk اور network link بھی protocol جتنے ہی اہم ہیں۔

کیا data directory پر rsync چلا کر Seafile کا backup لیا جا سکتا ہے؟

صرف databases کے ساتھ، اور دستاویزی ترتیب کے مطابق۔ Seafile کے manual میں پہلے SQL اور اس کے بعد data directory کا backup لینے کی ہدایت ہے، کیونکہ اس طرح backup میں ہر database record ایسے object کی طرف اشارہ کرتا ہے جو موجود ہوتا ہے۔ command rsync -az /opt/seafile-data/seafile /backup/data/، conf، seafile-data اور seahub-data کو copy کرتی ہے، لیکن یہ اکیلی قابلِ بحالی نہیں ہے، کیونکہ object store میں پڑھنے کے قابل file tree موجود نہیں ہوتا اور database اس کا index ہوتا ہے۔ دونوں حصے restore کرنے کے بعد seaf-fsck.sh چلائیں اور نتیجے پر اعتماد کرنے سے پہلے اس کا output پڑھیں۔

اگر مجھے صرف file sync چاہیے تو کیا Nextcloud ضروری ہے؟

نہیں۔ Nextcloud ایک platform ہے، اور calendar، contacts اور app store آپ کی memory اور upgrade management کی ضرورت بڑھاتے ہیں، چاہے آپ انہیں استعمال کریں یا نہ کریں۔ سادہ file sync کے لیے Seafile کم وسائل استعمال کرنے والا اور تیز protocol رکھنے والا product ہے، جبکہ Syncthing اس سے بھی ہلکا ہے کیونکہ اس کے لیے server side چلانے کی ضرورت نہیں ہوتی۔ Nextcloud اس وقت منتخب کریں جب آپ کو اضافی applications درکار ہوں، اسے default انتخاب نہ بنائیں۔

کیا encrypted Seafile library میری file names چھپاتی ہے؟

نہیں۔ encrypted library client پر file contents کو encrypt کرتی ہے اور password کبھی server تک نہیں پہنچتا، لیکن folder names، file names، file sizes اور edit history سب server پر visible رہتے ہیں۔ Web interface میں encrypted library کھولنے سے password server کو بھی بھیجا جاتا ہے۔ Server اس password سے file key decrypt کرتا ہے اور password کو ایک گھنٹے تک memory میں رکھتا ہے۔ اگر names خود حساس ہوں تو اس library کو web interface سے دور رکھیں اور کسی دوسری layer پر encryption استعمال کریں۔

VPS پر Seafile یا Nextcloud کے لیے کتنی RAM مختص کرنی چاہیے؟

چند users کے ساتھ دونوں میں سے کسی ایک کے لیے 4 GB اور 2 cores سے آغاز کریں، پھر preview generation اور search کے دوران memory monitor کریں۔ Seafile کی اپنی docs میں کم از کم 2 GB RAM اور 2 GHz سے زیادہ رفتار والا 2 core CPU مقرر کیا گیا ہے۔ Nextcloud فی PHP process 512 MB کی سفارش کرتا ہے۔ Database اور cache شامل کرنے سے پہلے اس مقدار کو worker count سے ضرب دیں۔ Syncthing 1 GB میں آسانی سے چلتا ہے۔