VPS پر file sync کے لیے Syncthing یا Nextcloud؟

Syncthing بمقابلہ Nextcloud: فیصلہ کن فرق

Syncthing بمقابلہ Nextcloud کا بنیادی فرق ایک ساختی امتیاز ہے، اور باقی سب اسی سے نکلتا ہے۔ Syncthing peer to peer نظام ہے۔ ہر device میں پورا folder موجود ہوتا ہے، اور کوئی ایک copy authoritative نہیں ہوتی۔ Nextcloud ایک server ہے۔ ایک machine files محفوظ کرتی ہے، user accounts ان files تک رسائی کو منظم کرتے ہیں، اور clients ان کی copies download کرتے ہیں۔

اسی لیے Syncthing میں share link یا documents کا web view نہیں ہوتا۔ پیش کرنے کے لیے کوئی مرکزی copy موجود نہیں ہوتی، اس لیے browser کے لیے مانگنے کو کچھ نہیں ہوتا۔ Nextcloud دونوں سہولتیں فراہم کرتا ہے، لیکن اس کے لیے PHP runtime، database server، web server اور TLS (transport layer security) کے لیے reverse proxy درکار ہوتا ہے۔

Syncthing اس وقت منتخب کریں جب شامل ہر device آپ کی ملکیت ہو۔ Nextcloud اس وقت منتخب کریں جب کسی browser یا دوسرے شخص کو files تک رسائی درکار ہو۔

ہر ڈیزائن میں VPS اصل میں کیا کام کر رہا ہے

Nextcloud چلانے والا VPS آپ کے ڈیٹا کا گھر ہوتا ہے۔ اپنے laptop پر موجود مقامی copy حذف کر دیں، تب بھی file server پر موجود رہتی ہے، کیونکہ اصل copy ہمیشہ server پر تھی۔

Syncthing چلانے والا VPS مختلف کام کرتا ہے: یہ ہمیشہ آن رہنے والا peer ہوتا ہے۔ Syncthing ڈیٹا براہ راست ان دو devices کے درمیان منتقل کرتا ہے جو ایک ہی وقت میں online ہوں۔ اس لیے اگر دو laptops کبھی ایک ساتھ آن نہیں ہوتے تو وہ آپس میں sync نہیں ہو سکتے، چاہے آپ کتنا ہی انتظار کریں۔ ایک ایسے VPS پر تیسرا peer شامل کریں جو کبھی sleep نہ ہو، تو مسئلہ ختم ہو جاتا ہے۔ Laptop A، 09:00 پر data بھیجتا ہے، Laptop B، 22:00 پر data حاصل کرتا ہے، اور VPS اس دوران folder محفوظ رکھتا ہے۔

یہ واقعی ایک مفید کردار ہے، اور یہ "Dropbox replacement" کے دعوے سے محدود ہے۔ Syncthing آپ کو کبھی ایسی link نہیں دے گا جو آپ کسی client کو بھیج سکیں۔ اگر آپ کی ضرورت یہ ہے تو یہیں رکیں اور self-hosted Dropbox متبادل کا خلاصہ پڑھیں۔

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

Syncthing ایک واحد Go binary ہے۔ یہ ایک socket پر listening کرتا ہے، آپ کی فائلوں کا index مقامی database میں محفوظ رکھتا ہے، اور یہی مکمل stack ہے۔ version 2.0 سے یہ index LevelDB کے بجائے SQLite استعمال کرتا ہے، اس لیے 1.x install سے upgrade کرنے پر پہلی بار launch کے دوران one-time migration چلتی ہے۔ بڑے folder set پر یہ migration کافی وقت لے سکتی ہے۔ اسے مکمل ہونے دیں۔ مزید کچھ install کرنے کی ضرورت نہیں، اور نہ ہی کسی دوسری چیز کو patch کرنے کی ضرورت ہے۔

Nextcloud کو زیادہ اجزا درکار ہوتے ہیں۔ August 2026 تک Nextcloud 35، PHP 8.3 سے 8.5 تک کو MariaDB یا PostgreSQL کے ساتھ support کرتا ہے، اور اسے Apache 2.4 یا nginx کے ذریعے php-fpm کے ساتھ serve کیا جاتا ہے۔ admin manual میں "a minimum of 512MB RAM per process" کی سفارش کی گئی ہے، جبکہ php-fpm بیک وقت کئی worker processes چلاتا ہے۔

1 GB VPS پر Syncthing آسانی سے چلتا ہے، جبکہ Nextcloud کے لیے وسائل محدود رہتے ہیں۔ اس کا مطلب یہ نہیں کہ Nextcloud غلط انتخاب ہے۔ اس کا مطلب یہ ہے کہ یہ ایک بڑا انتظامی عہد ہے، کیونکہ ایک کے بجائے چار components کو تازہ رکھنا پڑتا ہے۔ Docker، TLS اور backups کا احاطہ کرنے والی VPS پر Nextcloud guide میں بیان کردہ container route اس اضافی بوجھ کو سنبھالنے کا کم سے کم تکلیف دہ طریقہ ہے۔ اس کے علاوہ browser based document editing شامل کرنے سے مطلوبہ وسائل مزید بڑھ جاتے ہیں۔ OnlyOffice اور Collabora کا موازنہ 2 سے 4 GB کی مشین کے لیے اسی فرق کی وضاحت کرتا ہے۔

VPS پر Syncthing انسٹال کریں

Ubuntu میں syncthing package شامل ہوتا ہے، لیکن یہ upstream کے مقابلے میں کافی پرانا ہوتا ہے۔ پروجیکٹ کی اپنی 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
syncthing --version

syncthing --version کو syncthing v2 سے شروع ہونے والی سطر دکھانی چاہیے۔ وہاں v1 کا مطلب ہے کہ apt نے اب بھی distribution package کو ترجیح دی ہے۔ upstream repository کو اس سے اوپر priority دیں اور دوبارہ انسٹال کریں۔

printf "Package: *\nPin: origin apt.syncthing.net\nPin-Priority: 990\n" | sudo tee /etc/apt/preferences.d/syncthing.pref

اسے عام user account کے تحت system service کے طور پر چلائیں، تاکہ کوئی user لاگ اِن نہ ہونے کے باوجود یہ boot کے وقت شروع ہو جائے۔

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

systemctl status کو active (running) دکھانا چاہیے۔ Configuration اور index files /home/youruser/.local/state/syncthing میں محفوظ ہوتی ہیں، جبکہ config file config.xml ہے۔ Syncthing 1.27 سے پہلے بنائی گئی installations انہیں ~/.config/syncthing میں رکھتی ہیں، اس لیے machines کے درمیان کچھ copy کرنے سے پہلے دونوں paths چیک کریں۔

اب ports کھولیں۔ Syncthing sync protocol کے لیے 22000/TCP، اپنے QUIC transport کے لیے 22000/UDP، اور local discovery کے لیے 21027/UDP استعمال کرتا ہے۔ Discovery کے لیے broadcast اور multicast استعمال ہوتے ہیں، جو internet کے پار نہیں جاتے، اس لیے VPS پر صرف پہلے دو ports درکار ہیں۔

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

ufw status کو دونوں rules دکھانے چاہییں۔ اگر یہ Status: inactive دکھائے تو ufw کسی traffic کو filter نہیں کر رہا، اور صرف آپ کے provider کا network firewall فعال ہے۔ اس panel کو بھی چیک کریں، کیونکہ زیادہ تر hosts پر یہ الگ control ہوتا ہے۔ Service چل رہی ہو لیکن remote device Disconnected پر رکی رہے تو عموماً اس کا مطلب ہے کہ ان دونوں firewalls میں سے ایک اب بھی بند ہے۔

Syncthing GUI کو public کیے بغیر اس تک رسائی حاصل کریں

Web GUI (graphical user interface) بطور default 127.0.0.1:8384 پر listening کرتی ہے، اس لیے یہ صرف خود server سے آنے والی درخواستوں کا جواب دیتی ہے۔ یہ default حفاظتی ہے، کیونکہ GUI میں API (application programming interface) key شامل ہوتی ہے جو server پر موجود ہر folder path کو دوبارہ لکھ سکتی ہے۔

پہلے مرحلے میں اسے تمام network کے لیے نہ کھولیں۔ Documentation واضح کرتی ہے کہ network address پر bind کرنے سے کیا حاصل نہیں ہوتا: "اپنے computer کا LAN address مقرر کرنے سے رسائی صرف اپنے local network کے devices تک محدود نہیں ہوگی!" اس کے بجائے اپنے laptop سے SSH کے ذریعے port forward کریں۔

ssh -L 8384:127.0.0.1:8384 youruser@your.vps.example

جب تک SSH session فعال ہو، اپنے local browser میں http://127.0.0.1:8384 کھولیں۔ SSH session ختم ہونے پر tunnel بھی بند ہو جاتی ہے، اس لیے بعد میں کوئی چیز listening نہیں رہتی۔

اگر GUI تک براہ راست رسائی درکار ہو تو پہلے credentials مقرر کریں۔ Server پر browser موجود نہیں، اس لیے یہ کام command line سے کریں۔

sudo systemctl stop syncthing@youruser.service
sudo -H -u youruser syncthing generate --gui-user=admin --gui-password=-
sudo systemctl start syncthing@youruser.service

-H اہم ہے، کیونکہ اس کے بغیر sudo root کی home directory برقرار رکھتا ہے اور آپ غلط config.xml میں ترمیم کرتے ہیں۔ Password value کے طور پر single dash دینے سے syncthing generate password کو standard input سے پڑھتا ہے۔ اس طرح password shell history میں محفوظ نہیں ہوتا، اور file میں لکھنے سے پہلے value کو hash کر دیا جاتا ہے۔ Login کرنے کے بعد GUI settings میں HTTPS فعال کریں۔

Syncthing آپ کی غلطیوں کو کیوں پھیلاتا ہے

Syncthing FAQ خود backup کے سوال کا جواب دیتی ہے: "Syncthing ایک بہترین backup application نہیں ہے، کیونکہ آپ کی فائلوں میں ہونے والی تمام تبدیلیاں (ترمیم، حذف وغیرہ) آپ کے تمام devices تک پہنچا دی جاتی ہیں۔"

اپنے laptop پر غلطی سے کوئی folder حذف کر دیں تو Syncthing بالکل اسی طرح کام کرتا ہے جیسے اسے کرنا چاہیے۔ وہ folder چند seconds میں ہر جگہ سے حذف ہو جاتا ہے۔ Sync کا مطلب اتفاقِ رائے ہے، اور اس میں یہ اتفاق بھی شامل ہے کہ کوئی file موجود نہیں رہی۔

File versioning اس مسئلے کا حل ہے، لیکن اسے فعال کیے بغیر یہ بند رہتی ہے۔ Documentation کے مطابق versioning کی default حالت "no file versioning" ہے، یعنی files کی پرانی copies محفوظ نہیں کی جاتیں۔ ہر folder کے لیے چار strategies دستیاب ہیں۔ Trash Can کسی remote change سے حذف یا replace ہونے والی ہر file کی ایک copy محفوظ رکھتا ہے۔ Simple ہر file کی پرانی versions کی مقررہ تعداد رکھتا ہے۔ Staggered وقت گزرنے کے ساتھ history کو کم کرتا ہے: ایک دن تک hourly copies، ایک ماہ تک daily copies، اور اسی طرح آگے۔ External ہر فیصلہ آپ کے لکھے ہوئے command کے سپرد کرتا ہے۔ پرانی copies shared folder کے اندر موجود .stversions directory میں رکھی جاتی ہیں۔

VPS peer پر Staggered فعال کریں اور laptops پر versioning بند رہنے دیں۔ اس طرح ہمیشہ فعال peer history محفوظ رکھتا ہے، جبکہ laptops پر اضافی data جمع نہیں ہوتا۔

Nextcloud یہ کام بہتر طریقے سے کرتا ہے، لیکن پھر بھی backup نہیں ہے۔ Deleted files trash bin میں چلی جاتی ہیں اور Versions app edits محفوظ کرتی ہے، لیکن disk بھرنے کے ساتھ دونوں خودکار طور پر کم کی جاتی ہیں۔ آپ کے laptop پر چلنے والا کوئی process files کو encrypt کرے تو ان encrypted versions کو sync کر دیا جائے گا، اور اچھی copies بھی اپنے مقررہ schedule کے مطابق خود بخود حذف ہو جائیں گی۔

دونوں tools کے نیچے حقیقی backup ضروری ہے: snapshots کسی الگ program سے بنائے جائیں، ایسی جگہ لکھے جائیں جہاں sync client رسائی نہ کر سکے، اور کم از کم ایک بار restore کیے جائیں تاکہ یقین ہو کہ restore درست کام کرتا ہے۔ restic اور BorgBackup کا موازنہ میں بتایا گیا ہے کہ data directory کے لیے کس tool کو استعمال کیا جائے۔

دونوں کے درمیان conflicts کیسے مختلف ہیں

دونوں tools اس وقت conflict file بناتے ہیں جب sync کے درمیان دونوں sides ایک ہی file میں تبدیلی کریں۔ فرق یہ ہے کہ اسے کون دیکھتا ہے۔

Syncthing ہارنے والی copy کا نام بدل کر <filename>.sync-conflict-<date>-<time>-<modifiedBy>.<ext> رکھتا ہے۔ جس copy کا modification time زیادہ پرانا ہو، وہ ہار جاتی ہے۔ اگر دونوں times یکساں ہوں تو device ID کے پہلے 63 bits میں بڑی value رکھنے والا device ہار جاتا ہے۔ یہ انتخاب بظاہر من مانا ہے، لیکن ہر peer پر نتیجہ یکساں رہتا ہے۔ اس کے بعد اہم بات یہ ہے: یہ files "بننے کے بعد normal files سمجھی جاتی ہیں، اس لیے devices کے درمیان propagate ہوتی ہیں"۔ ہر peer کو conflict copy موصول ہوتی ہے۔ اسے صاف کرنے کے لیے صرف ایک deletion درکار ہے جو sync ہو جاتی ہے، لیکن اس سے پہلے یہ file آپ کی تمام machines پر نظر آئے گی۔

Nextcloud desktop client <name> (conflicted copy YYYY-MM-DD HHMMSS).<ext> لکھتا ہے، مثلاً mydata (conflicted copy 2018-04-10 093612).txt، اور default طور پر یہ file upload نہیں کرتا۔ Client manual میں اس کی وجہ بیان کی گئی ہے: تبدیلی کرنے والا شخص conflict حل کرنے کے لیے سب سے موزوں ہوتا ہے، جبکہ دوسرے users کو conflict دکھانے سے صرف الجھن پیدا ہوتی ہے۔ اگر آپ اس کے برعکس behavior چاہتے ہیں تو client کے environment میں OWNCLOUD_UPLOAD_CONFLICT_FILES=1 set کریں۔

اس لیے Syncthing conflict پورے cluster کا event ہوتا ہے، جبکہ Nextcloud conflict صرف ایک desktop تک محدود رہتا ہے۔

فولڈر کی اقسام Syncthing کو سرور پر زیادہ محفوظ بناتی ہیں

Syncthing میں فولڈر کی تین اقسام ہیں۔ VPS پر درست قسم منتخب کرنے سے حادثاتی تبدیلیوں کا ایک پورا سلسلہ روکا جا سکتا ہے۔

• Send & Receive طے شدہ قسم ہے۔ تبدیلیاں دونوں سمتوں میں منتقل ہوتی ہیں۔
• Send Only کلسٹر سے بھیجی جانے والی تمام تبدیلیوں کو نظرانداز کرتا ہے۔ اسے وہاں استعمال کریں جہاں کوئی ڈیوائس صرف ڈیٹا شائع کرے۔ جب یہ فولڈر sync سے باہر ہو جائے تو GUI میں سرخ "Override Changes" بٹن دکھائی دیتا ہے۔ یہ مقامی حالت سبھی ڈیوائسز پر نافذ کر دیتا ہے۔
• Receive Only کلسٹر سے آنے والی تبدیلیاں لاگو کرتا ہے اور مقامی edits واپس نہیں بھیجتا۔ اسے archive کے طور پر کام کرنے والے VPS پر استعمال کریں۔ وہاں کی گئی مقامی edits کے لیے اس کے بجائے سرخ "Revert Local Changes" بٹن دکھائی دیتا ہے۔

VPS پر Receive Only فولڈر میں Staggered versioning فعال کرنے سے versioned mirror بن جاتا ہے۔ لیپ ٹاپ پر deletion پھر بھی لاگو ہوتی ہے، کیونکہ deletion کلسٹر کی جائز تبدیلی ہے، لیکن پرانی copy غائب ہونے کے بجائے .stversions میں چلی جاتی ہے۔

کس کا انتخاب کرنا چاہیے

ذیل کی 7 قطاریں ان وجوہات کا احاطہ کرتی ہیں جن کی بنا پر لوگ حقیقت میں یہ سوال پوچھتے ہیں۔

[
  {
    "label": "Keep two of my own laptops in sync",
    "pick": "Syncthing",
    "notes": "No accounts to manage. The VPS is the peer that is always awake."
  },
  {
    "label": "Send a download link to a client",
    "pick": "Nextcloud",
    "notes": "Syncthing has no public link sharing at all."
  },
  {
    "label": "Open a file from a borrowed browser",
    "pick": "Nextcloud",
    "notes": "The Syncthing GUI shows sync state, never file contents."
  },
  {
    "label": "Sync 200 GB between machines I own",
    "pick": "Syncthing",
    "notes": "Peers transfer directly. The VPS copy is optional."
  },
  {
    "label": "Phone photo upload with a store app",
    "pick": "Nextcloud",
    "notes": "The official Syncthing Android app ended in December 2024."
  },
  {
    "label": "Calendar and contacts alongside files",
    "pick": "Nextcloud",
    "notes": "Syncthing syncs files. That is the entire feature set."
  },
  {
    "label": "1 GB VPS with nothing else to spare",
    "pick": "Syncthing",
    "notes": "One Go binary against PHP plus a database plus a web server."
  }
]

پہلی قطار دیکھیں۔ اپنے دو laptops کو باہم sync رکھنے کا مطلب Syncthing کی طرف اشارہ کرتا ہے، اور یہی وہ صورت ہے جس میں VPS ایسے peer کے طور پر مفید ثابت ہوتا ہے جو کبھی سوتا نہیں۔ browser، link یا کسی دوسرے شخص سے متعلق ہر قطار دوسرے انتخاب کی طرف اشارہ کرتی ہے۔

اگر Nextcloud بار بار بہتر انتخاب ثابت ہو رہا ہے لیکن اس کا footprint آپ کو پریشان کرتا ہے تو Seafile اور Nextcloud کا موازنہ اگلا مضمون ہے جسے پڑھنا چاہیے، کیونکہ Seafile مختلف sync engine کے ساتھ server model برقرار رکھتا ہے۔

ایک ہی VPS پر دونوں چلانا

یہ دونوں ایک دوسرے کے متبادل نہیں ہیں۔ اپنی مشینوں کے درمیان فائلیں منتقل کرنے کے لیے Syncthing اور فائل sharing اور calendars کے لیے Nextcloud استعمال کرنا ایک عام انتظام ہے۔

اگر آپ ایسا کرتے ہیں تو ایک اصول پر عمل کریں: Syncthing کو کبھی بھی Nextcloud کی data directory کی طرف point نہ کریں۔ Nextcloud ہر فائل کا ریکارڈ اپنے database میں رکھتا ہے، اس لیے باہر سے disk پر ظاہر ہونے والی فائلیں web interface میں اس وقت تک نظر نہیں آتیں جب تک database اپ ڈیٹ نہ ہو جائے۔ Nextcloud کی installation directory سے:

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

یہ command اسکین کی گئی files اور folders کی تعداد دکھاتی ہے۔ اسے timer پر چلانا ایک عارضی workaround ہے، مناسب design نہیں۔ ہر tool کے لیے الگ directory رکھیں۔ اگر آپ ابھی یہ طے کر رہے ہیں کہ اس box پر سرے سے کیا self-host کرنا چاہیے، تو پہلے sync tool منتخب کرنے کے بجائے 2026 میں self-host کرنے والی چیزوں کی guide سے آغاز کرنا بہتر ہے۔

FAQ

کیا Syncthing، Dropbox کی جگہ لے سکتا ہے؟

صرف اس حد تک کہ آپ کے اپنے devices آپس میں sync رہیں۔ Syncthing میں public share links اور user accounts نہیں ہوتے، اور اس کا web interface کبھی file contents نہیں دکھاتا، کیونکہ browser کے لیے درخواست کرنے کو کوئی مرکزی copy موجود نہیں ہوتی۔ سرکاری Android app دسمبر 2024 کی release کے بعد بند کر دی گئی اور Play Store سے ہٹا دی گئی، اس لیے اب phone support کا انحصار community fork پر ہے۔ اگر آپ کو کسی کو link بھیجنا ہو تو server درکار ہوگا، یعنی Nextcloud یا اس جیسی کوئی سروس۔

کیا Syncthing backup ہے؟

نہیں، اور project بھی یہ بات براہ راست کہتا ہے۔ Deletions اور modifications ہر device تک پہنچ جاتی ہیں، اس لیے accidental deletion چند seconds میں ہر جگہ ختم ہو جاتی ہے۔ ہر folder کے لیے file versioning فعال کرنے سے، خاص طور پر ہمیشہ چلنے والے peer پر Staggered استعمال کرنے سے، .stversions directory کے ذریعے recovery window ملتی ہے۔ یہ الگ tool کے ذریعے الگ storage پر لیے گئے snapshots کا متبادل نہیں ہے۔

میں Syncthing کے web GUI میں اپنی files کیوں نہیں دیکھ سکتا؟

کیونکہ GUI sync state کے لیے control panel ہے، file browser نہیں۔ یہ folders، devices، transfer progress اور conflict counts دکھاتا ہے، لیکن file contents کی فہرست کبھی نہیں دکھاتا اور نہ انہیں کھولتا ہے۔ یہ peer to peer design کا لازمی نتیجہ ہے: آپ کی files آپ کے devices پر موجود ہوتی ہیں، جبکہ VPS پر موجود GUI انہیں منتقل کرنے کے process کا انتظام کرتا ہے۔

VPS پر Syncthing کے لیے کون سے ports کھلے ہونے چاہییں؟

Sync protocol کے لیے 22000/TCP اور QUIC transport کے لیے 22000/UDP درکار ہیں۔ Port 21027/UDP broadcast اور multicast کے ذریعے local discovery کے لیے استعمال ہوتا ہے، جو internet کے پار نہیں پہنچتا؛ اس لیے public server پر اسے بند رکھیں۔ GUI کو 8384 پر 127.0.0.1 کے ساتھ bind رکھیں اور SSH tunnel کے ذریعے اس تک رسائی حاصل کریں۔ اپنے provider کا network firewall بھی ufw کے ساتھ check کریں، کیونکہ یہ الگ controls ہیں۔

کیا میں ایک ہی VPS پر Syncthing اور Nextcloud چلا سکتا ہوں؟

ہاں، اور 2 GB RAM یا اس سے زیادہ والے server پر یہ مناسب ہے۔ ان کی directories الگ رکھیں۔ Nextcloud files کو اپنے database میں index کرتا ہے، اس لیے Syncthing کی جانب سے Nextcloud کے storage میں لکھی گئی کوئی بھی چیز web interface میں اس وقت تک نظر نہیں آئے گی جب تک occ files:scan نہیں چلتا۔ ایک ہی directory میں دو tools کے ذریعے writing کرنے سے conflict files بھی بنتی ہیں، جن کی کسی بھی tool کو توقع نہیں ہوتی۔