Self-hosted Dropbox متبادل: Nextcloud یا Syncthing؟

آپ کو کون سا self-hosted Dropbox متبادل چلانا چاہیے؟

چار self-hosted Dropbox متبادل آپ کے وقت کے قابل ہیں: Nextcloud، Seafile، Syncthing، اور اوپر client کے ساتھ object storage۔ یہ ایک دوسرے کے متبادل نہیں ہیں۔ Nextcloud ایسے گھر یا چھوٹی ٹیم کے لیے موزوں ہے جہاں دوسرے لوگوں کو فائلیں موصول کرنی ہوں۔ Seafile ایسے فرد یا ٹیم کے لیے موزوں ہے جو بہت بڑی تعداد میں چھوٹی فائلیں sync کرتی ہو، اور جہاں sync speed اس بات سے زیادہ اہم ہو کہ disk پر data کس شکل میں محفوظ ہے۔ Syncthing ایسے فرد کے لیے موزوں ہے جو اپنے devices کو sync کرتا ہو اور جسے کسی بیرونی شخص کے ساتھ link شیئر کرنے کی ضرورت نہ ہو۔ Object storage archive کے لیے موزوں ہے: سستا storage جسے آپ شاذونادر ہی کھولتے ہیں۔

Features کا موازنہ کرنے سے پہلے یہ طے کریں کہ sync کس طرح کام کرے گا۔ Feature lists سب ایک جیسی دکھائی دیتی ہیں۔ Topology، یعنی وہ machine جس پر وہ copy موجود ہوتی ہے جس سے دوسری تمام machines اتفاق کرتی ہیں، یہی طے کرتی ہے کہ چھ ماہ بعد بھی آپ اپنے انتخاب سے مطمئن رہیں گے یا نہیں۔

Sync topology: ایک مرکزی مستند سرور، یا بغیر سرور کے peers

دو ڈیزائن زیرِ غور ہیں، اور آگے آنے والی زیادہ تر باتیں اسی انتخاب پر منحصر ہیں۔

مرکزی مستند سرور۔ Nextcloud، Seafile اور object storage اسی طریقے سے کام کرتے ہیں۔ ایک مشین، عموماً VPS (virtual private server)، مستند copy رکھتی ہے۔ ہر device اسی مشین سے رابطہ کرتا ہے۔ آپ کا laptop ایک ماہ تک بند رہ سکتا ہے، پھر واپس آ کر خود ہی تازہ ترین تبدیلیاں حاصل کر سکتا ہے۔ 6 GB خالی جگہ والا phone صرف ایک subset رکھ سکتا ہے، جبکہ server سب کچھ محفوظ رکھتا ہے۔ Browser کے ذریعے files تک رسائی ممکن ہوتی ہے، اور اسی وجہ سے share links بن سکتے ہیں۔

بغیر سرور کے peers۔ Syncthing اسی طریقے سے کام کرتا ہے۔ Devices ایک دوسرے کو تلاش کرتے ہیں اور encrypted connection کے ذریعے براہِ راست file lists کا تبادلہ کرتے ہیں۔ کوئی copy مستند نہیں ہوتی: file صرف ان devices پر موجود ہوتی ہے جو اسے رکھتے ہیں، اور کہیں نہیں۔ کسی change کو devices کے درمیان منتقل ہونے کے لیے دونوں devices کا ایک ہی وقت میں online ہونا ضروری ہے۔ کسی کو دینے کے لیے کوئی URL موجود نہیں ہوتا، کیونکہ کوئی machine page serve نہیں کر رہی ہوتی۔

اس کے چار نتائج نکلتے ہیں، اور لوگ عموماً ان کا سامنا بعد میں کرتے ہیں۔

• کسی ایسے شخص کو file بھیجنے کے لیے جو software install نہیں کرے گا، مرکزی مستند server ضروری ہے۔ Link ایک URL ہوتا ہے، اور URL کے لیے کسی process کا port پر listening کرنا ضروری ہے۔
• کسی ایسی machine سے اپنی files تک رسائی کے لیے جسے آپ control نہیں کرتے، مثلاً work laptop، مرکزی مستند server ضروری ہے۔
• جو device کئی ہفتوں تک بند رہی ہو، وہ بیدار ہوتے ہی server سے تازہ ترین تبدیلیاں حاصل کر لیتی ہے۔ Peer setup میں وہ صرف اسی وقت تازہ ہوتی ہے جب اس data کو رکھنے والا کوئی دوسرا device بھی online ہو۔ اسی لیے Syncthing کے بہت سے صارفین VPS پر ایک instance کو ہمیشہ online peer کے طور پر چلاتے ہیں۔
• Storage کا حساب مختلف طریقے سے بڑھتا ہے۔ مرکزی مستند server ایک مکمل copy رکھتا ہے، اس کے علاوہ ہر device پر مقامی طور پر محفوظ data ہوتا ہے۔ ایک folder شیئر کرنے والے چار peers چار مکمل copies رکھتے ہیں، کیونکہ ہر peer پورا folder محفوظ رکھتا ہے۔

Nextcloud: صارفین، گروپس اور public links

Nextcloud ایک PHP web application ہے۔ یہ آپ کی فائلیں data directory کے اندر عام فائلوں کے طور پر محفوظ کرتا ہے اور ان کا ریکارڈ database میں رکھتا ہے۔ آپ کسی folder کو کسی user، group، یا password اور expiry date والے public link کے ذریعے share کر سکتے ہیں۔ Version history پہلے سے enabled ہوتی ہے اور deleted files پہلے trash bin میں جاتی ہیں۔ Desktop clients Linux، macOS اور Windows کے لیے دستیاب ہیں، جبکہ iOS اور Android apps official ہیں۔ اگر Dropbox چھوڑنے کی وجہ یہ ہے کہ دوسرے لوگوں کو آپ کی فائلیں وصول کرنی ہیں، تو اس کا واضح جواب یہی ہے۔

اصل لاگت اس کے متعدد components ہیں۔ ایک عام install میں web server، PHP-FPM (PHP process manager)، MariaDB یا PostgreSQL جیسا database، اور file locking کے لیے Redis چلتا ہے۔ ایک background job ہر پانچ منٹ بعد cron یا systemd timer کے ذریعے چلتی ہے۔ 1 GB VPS پر یہ شروع ہو جائے گا، لیکن پھر ایک بڑی upload یا طویل occ maintenance command کے دوران out-of-memory killer اسے بند کر سکتا ہے۔ چند users کے لیے 2 GB کو کم از کم حد سمجھیں، اور مزید apps enabled کرنے کے بعد 4 GB کی ضرورت متوقع رکھیں۔ دوسری لاگت upgrades ہیں: app-store apps کسی مخصوص core release کے لیے بنائی جاتی ہیں، اس لیے upgrade کرنے سے پہلے دیکھیں کہ آپ کی ضروری apps اگلے major version کو support کرتی ہیں۔

Nextcloud اس وقت سست ہو جاتا ہے جب ایک account میں سینکڑوں ہزاروں چھوٹی فائلیں ہوں، کیونکہ ہر فائل file cache table میں ایک row اور disk پر ایک حقیقی file ہوتی ہے، جبکہ desktop client انہیں ایک ایک کر کے process کرتا ہے۔ گھریلو سطح کے استعمال میں یہ مسئلہ سامنے نہیں آتا۔ Sizing، TLS (transport layer security) اور backups کی تفصیل TLS اور backups کے ساتھ Docker پر مبنی Nextcloud install میں ہے۔ فیصلہ کرنے کے بعد اسی طرف جائیں۔

دائرۂ کار کے بارے میں ایک انتباہ ہے۔ Nextcloud آپ کا calendar، contacts، notes اور photo library بھی چلا سکتا ہے، اور ہر enabled app background work میں اضافہ کرتی ہے اور upgrade روکنے والی ایک اضافی وجہ بن سکتی ہے۔ اگر اصل مسئلہ photos ہیں تو dedicated tool انہیں بہتر طور پر handle کرتا ہے: self-hosted Google Photos replacement کے طور پر Immich دیکھیں۔ اگر اصل مسئلہ documents اور wikis ہیں تو اپنی file server میں مزید apps شامل کرنے کے بجائے self-hosted Notion alternatives دیکھیں۔ ان documents کو browser میں edit کرنا Nextcloud app کے بجائے ایک الگ server کا کام ہے، اس لیے یہ فرض کرنے سے پہلے کہ 2 GB کی کم از کم حد اب بھی کافی ہے، OnlyOffice اور Collabora کا موازنہ کریں۔

Seafile: بہت بڑی تعداد میں چھوٹی فائلوں کے لیے تیار کیا گیا

Seafile ہر فائل کو blocks میں تقسیم کرتا ہے اور انہیں content hash کے ذریعے address کیے جانے والے داخلی object store میں محفوظ کرتا ہے۔ یہی بنیادی تصور git اپنے objects کے لیے استعمال کرتا ہے۔ Sync اور sharing کی unit folder tree کے بجائے library ہوتی ہے۔ Client ہر فائل کے لیے الگ request بھیجنے کے بجائے blocks اور ایک commit upload کرتا ہے، اس لیے 100,000 چھوٹی فائلوں والی directory کی syncing فی فائل protocol کے مقابلے میں کہیں زیادہ تیزی سے مکمل ہو جاتی ہے۔ یکساں blocks صرف ایک بار محفوظ کیے جاتے ہیں، اس لیے بڑی فائل کی دوسری copy تقریباً کوئی اضافی جگہ نہیں لیتی۔

اس کا نقصان یہ ہے کہ server پر آپ کی فائلیں عام files نہیں رہتیں۔ Storage directory کھولنے پر آپ کو hexadecimal ناموں والی object files ملتی ہیں۔ Data باہر نکالنے کے لیے Seafile client یا Seafile کے اپنے export اور fsck tools درکار ہوتے ہیں۔ Backups پھر بھی کام کرتے ہیں، کیونکہ یہ objects عام files ہوتی ہیں، لیکن آپ cp کے ذریعے ایک spreadsheet بحال نہیں کر سکتے۔ ابھی طے کریں کہ یہ قابل قبول ہے یا نہیں، کیونکہ لوگ بعد میں اسی خصوصیت پر افسوس کرتے ہیں۔

Seafile community edition اور paid professional edition جاری کرتا ہے، اور دونوں کے درمیان تقسیم releases کے ساتھ بدلتی رہتی ہے۔ اس لیے کسی مخصوص feature کے گرد team کی منصوبہ بندی کرنے سے پہلے ان کی site پر موجود موجودہ terms پڑھیں۔ Official desktop اور mobile clients دستیاب ہیں۔ Encrypted libraries کو client پر encrypt کیا جاتا ہے، اس لیے server ایسا ciphertext محفوظ کرتا ہے جسے وہ پڑھ نہیں سکتا۔ Passphrase کھو دیں تو library ناقابل مطالعہ ہو جاتی ہے، آپ کے لیے بھی۔ Browser میں encrypted library کھولنے کا مطلب ہے کہ یہ passphrase web session کو فراہم کی جائے۔ اس لیے اس ضمانت کی مضبوط شکل desktop اور mobile clients تک محدود ہے۔

Resource cost Nextcloud کے قریب رہتی ہے۔ آپ database، memory cache اور دو application processes چلا رہے ہوتے ہیں، اس لیے 2 GB دوبارہ ایک مناسب کم از کم حد ہے۔

Syncthing: لاگ اِن کرنے کے لیے کچھ نہیں

Syncthing ایک single Go binary ہے۔ یہ folders کی نگرانی کرتا ہے، discovery server یا relay کے ذریعے اپنے peers تلاش کرتا ہے، اور devices کے درمیان براہِ راست sync کرتا ہے۔ جن لوگوں کے ساتھ آپ sync کرتے ہیں ان کے لیے کوئی accounts یا login page نہیں ہوتا۔ آپ ID کے ذریعے دو devices pair کرتے ہیں اور دونوں طرف folder قبول کرتے ہیں۔ یہاں موجود تمام سافٹ ویئر میں اسے چلانے کے لیے سب سے کم محنت درکار ہوتی ہے، کیونکہ manage کرنے کے لیے بہت کم چیزیں ہوتی ہیں۔

اس کے بدلے آپ sharing کی پوری سہولت چھوڑ دیتے ہیں۔ اس کا اندراج Device pairing only, no links ہے۔ آپ کسی client، accountant یا رشتہ دار کو link نہیں دے سکتے۔ Mobile support بھی ایک کمی ہے: Android app, no official iOS۔ پروجیکٹ کے اپنے FAQ میں اس بارے میں واضح طور پر کہا گیا ہے: "موجودہ Syncthing ٹیم کا مستقبل قریب میں iOS کو باضابطہ طور پر support کرنے کا کوئی منصوبہ نہیں"، کیونکہ iOS background processing پر اتنی پابندیاں عائد کرتا ہے کہ قابلِ اعتماد syncing مشکل ہو جاتی ہے۔ iOS صارفین کے لیے third-party apps ہی باقی رہ جاتی ہیں۔

Resource use کم ہے، لیکن ایک بات جاننا ضروری ہے۔ Syncthing ہر sync ہونے والی file کے لیے ایک index entry رکھتا ہے، اس لیے memory اور پہلی scan total size کے بجائے file count کے ساتھ بڑھتے ہیں۔ پہلی بار بڑے folder کو hash کرنے کے دوران کچھ وقت CPU استعمال ہوگا، پھر استعمال معمول پر آ جائے گا۔ سب سے چھوٹے VPS plan پر بھی یہ آسانی سے چلتا ہے۔

Conflicts کو دونوں sides محفوظ رکھ کر handle کیا جاتا ہے۔ جب دو devices ایک ہی file میں اس وقت تبدیلی کرتے ہیں جب وہ ایک دوسرے کو نہیں دیکھ سکتے، تو Syncthing ایک copy کا نام بدل کر اسے دوسری copy کے ساتھ رکھ دیتا ہے۔ یوں آپ کو notes.sync-conflict-20260802-141530-K7MB3QT.md جیسی files ملتی ہیں۔ کوئی data ضائع نہیں ہوتا۔ تاہم کچھ بھی merge نہیں کیا جاتا، اور آپ کو conflict خود حل کرنا ہوتا ہے۔

کلائنٹ کے ساتھ object storage: سستے bytes، sync folder نہیں

Object storage سے مراد S3 (simple storage service) compatible bucket ہے، جسے آپ MinIO کے ذریعے self-hosted چلا سکتے ہیں یا کسی provider سے کرائے پر لے سکتے ہیں۔ اس تک رسائی کے لیے ایک tool استعمال ہوتا ہے: command line سے rclone، یا ایسا desktop client جو bucket کو drive کے طور پر دکھاتا ہے۔ Sharing کے لیے presigned URL استعمال ہوتا ہے؛ یہ ایسا link ہے جو خود اپنی expiry time رکھتا ہے۔ Versioning، bucket کی setting ہے: Bucket versioning, off by default، اس لیے bucket بناتے وقت اسے فعال کریں، کیونکہ یہ پہلے upload کیے گئے objects پر لاگو نہیں ہوتی۔

مسئلہ اس وقت پیدا ہوتا ہے جب bucket کو sync folder سمجھا جائے۔ Default طور پر کوئی چیز آپ کی Documents directory کو monitor نہیں کرتی۔ rclone bisync دو طرفہ sync کرتا ہے، اور rclone کی اپنی documentation بھی واضح کرتی ہے کہ اسے احتیاط سے configure کرنا ضروری ہے۔ Object storage کا بہترین استعمال بنیادی storage layer کے طور پر ہے: backup target، یا کسی application کے پیچھے storage layer۔ MinIO کے ساتھ self-hosted S3 compatible object storage میں server side کا طریقہ بیان کیا گیا ہے۔

یہاں resource cost عام صورتحال سے مختلف ہے۔ MinIO ایک binary ہے اور idle حالت میں بہت کم resources استعمال کرتا ہے۔ اصل خرچ disk کا ہوتا ہے، اور VPS پر اس کا مطلب ہے gigabyte کے حساب سے کرائے پر لیا گیا block volume، اس کے علاوہ objects کو اندر اور باہر منتقل کرنے میں استعمال ہونے والی bandwidth۔ ان دونوں اخراجات کی عکاسی free -h میں نہیں ہوتی، اس لیے archive کا سائز مقرر کرنے سے پہلے VPS کی ماہانہ اصل لاگت پڑھیں۔

اشتراک، موبائل کلائنٹس اور ورژننگ کا تقابلی جائزہ

[
  {
    "tool": "Nextcloud",
    "sharing": "Public links, users and groups",
    "mobile": "Official iOS and Android apps",
    "versioning": "On by default, plus trash"
  },
  {
    "tool": "Seafile",
    "sharing": "Public links with password and expiry",
    "mobile": "Official iOS and Android apps",
    "versioning": "Library history and snapshots"
  },
  {
    "tool": "Syncthing",
    "sharing": "Device pairing only, no links",
    "mobile": "Android app, no official iOS",
    "versioning": "Optional per folder, off by default"
  },
  {
    "tool": "Object storage",
    "sharing": "Presigned URLs you generate",
    "mobile": "Third party clients only",
    "versioning": "Bucket versioning, off by default"
  }
]

تمام 4 اختیارات ایک ہی بنیادی فرق کے ساتھ تقسیم ہوتے ہیں۔ ان میں سے تین ایسے ہیں جو صرف براؤزر رکھنے والے اجنبی کو بھی فائل فراہم کر سکتے ہیں۔ ان میں سے ایک صرف ان devices سے رابطہ کرتا ہے جو آپ پہلے ہی own کرتے ہیں۔ Seafile کی versioning entry، Library history and snapshots، پر ایک وضاحت ضروری ہے: history ہر library کے لیے الگ محفوظ کی جاتی ہے، اس لیے library حذف کرنے سے اس کی history بھی حذف ہو جاتی ہے۔

اپنا ڈیٹا دوبارہ حاصل کرنا

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

Nextcloud اصل فائلیں حقیقی directories میں محفوظ کرتا ہے، اس لیے data directory کے tar سے آپ اپنی دستاویزات حاصل کر سکتے ہیں، چاہے application دوبارہ کبھی start نہ ہو۔ Syncthing ہر peer پر یہی طریقہ اختیار کرتا ہے، اور یہاں منتقلی کا سب سے مضبوط راستہ فراہم کرتا ہے: فائلیں ہر device پر سادہ طور پر موجود رہتی ہیں۔ Seafile کے object store میں blocks کو دوبارہ files میں جوڑنے کے لیے Seafile یا اس کے export tools درکار ہوتے ہیں۔ Object storage کے لیے rclone یا اس کے مساوی tool درکار ہے، اور اسے ایک command سے چلایا جا سکتا ہے۔

Sync بیک اپ نہیں ہے، اور اسی فرق کی وجہ سے لوگ ڈیٹا کھو دیتے ہیں

یہاں موجود ہر ٹول مشینوں کے درمیان تبدیلیاں کاپی کرتا ہے۔ حذف کرنا بھی ایک تبدیلی ہے۔ اپنے لیپ ٹاپ سے کوئی فولڈر حذف کریں تو client سرور کو اطلاع دیتا ہے، سرور اسے لاگو کرتا ہے، اور ہر دوسرا device بھی اسے حذف کر دیتا ہے۔ Ransomware بھی یہی طریقہ استعمال کرتا ہے: یہ مقامی طور پر فائلوں کو encrypt کرتا ہے، client تبدیل شدہ فائلیں دیکھتا ہے، اور encrypted versions upload کر دیتا ہے۔ Sync درست طور پر کام کر رہا تھا۔ آپ کا ڈیٹا پھر بھی ختم ہو گیا۔

Trash bins اور version history اس نقصان کو کچھ حد تک کم کرتے ہیں۔ لیکن یہ بھی expire ہو جاتے ہیں، وہی account انہیں خالی کر سکتا ہے جس سے غلطی ہوئی ہو، اور یہ live copy والی ہی disk پر موجود ہوتے ہیں۔ کسی volume کے fail ہونے پر فائلیں اور ان کی history دونوں ایک ساتھ ضائع ہو جاتی ہیں۔

بیک اپ ایک الگ copy ہوتا ہے، جو الگ hardware پر مقررہ schedule کے مطابق لیا جاتا ہے، اور جسے آپ کم از کم ایک بار restore کر چکے ہوں۔ اسی run میں database اور فائلوں دونوں کا بیک اپ لیں۔ Database کے بغیر Nextcloud data directory restore کرنے سے ایسی instance ملتی ہے جسے معلوم نہیں ہوتا کہ وہ فائلیں موجود ہیں، اور اس کے بعد occ files:scan فائلیں تو recover کر دیتا ہے لیکن ان tables میں موجود shares اور version history ضائع ہو جاتی ہے۔ VPS سے مقررہ restic بیک اپ اس عمل کے encrypted اور deduplicated version کا احاطہ کرتا ہے، جس میں restore کو فرض کرنے کے بجائے test کرنے کا طریقہ بھی شامل ہے۔

میری ترجیح

یہاں موجود زیادہ تر قارئین کے لیے Nextcloud بہتر انتخاب ہے۔ Dropbox چھوڑنے کے بعد لوگ عموماً اس سہولت کو کم اہم سمجھتے ہیں کہ کسی ایسے شخص کو link دیا جا سکے جو کبھی کوئی چیز install نہیں کرے گا، اور فون پر file کھولی جا سکے۔ Nextcloud official clients کے ذریعے یہ دونوں کام کرتا ہے اور اس کی کوئی paid tier نہیں ہے۔ اس کے لیے 2 GB RAM ایک مناسب قیمت ہے۔

میں دو استثنا رکھتا ہوں۔ اگر folder صرف آپ کا ہو اور ہمیشہ آپ کے اپنے hardware پر رہے، تو Syncthing چلائیں۔ اس طرح آپ کو کسی server کو patch کرنے یا کسی web login کی حفاظت کرنے کی ضرورت نہیں رہتی۔ اگر آپ سیکڑوں ہزار files والی working directory sync کرتے ہیں، تو Seafile چلائیں اور speed کے بدلے opaque storage قبول کریں۔ Object storage کو آپ کے منتخب کردہ نظام کے نیچے backup target کے طور پر استعمال کریں، اس کے سامنے sync tool کے طور پر نہیں۔

FAQ

کیا Syncthing میرے laptop کا backup ہے؟

نہیں۔ Syncthing devices کے درمیان تبدیلیاں copy کرتا ہے، اور deletion بھی دوسری تبدیلیوں کی طرح ایک تبدیلی ہے، اس لیے جس file کو آپ غلطی سے delete کریں گے وہ چند seconds کے اندر ہر paired device سے غائب ہو جائے گی۔ Per-folder file versioning مدد دیتی ہے، لیکن ہر folder پر اسے enable کرنے تک یہ off رہتی ہے۔ الگ hardware پر باقاعدہ backup رکھیں، اسے مقررہ schedule کے مطابق بنائیں، اور ایک بار اس سے restore کریں تاکہ آپ کو معلوم ہو کہ restore کام کرتا ہے۔

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

ہاں، دونوں مختلف ports پر listen کرتے ہیں اور ایک دوسرے سے conflict نہیں کرتے۔ Syncthing folder کو Nextcloud کی data directory کی طرف point نہ کریں۔ Nextcloud ہر file کو database میں track کرتا ہے، اس لیے disk پر اس کے اندر ظاہر ہونے والی files اس وقت تک invisible رہتی ہیں جب تک آپ occ files:scan نہ چلائیں، اور اس کے اندر سے remove کی گئی files database میں ایسی rows چھوڑ دیتی ہیں جو کسی موجود file کی طرف point نہیں کرتیں۔ Syncthing کے لیے اپنی directory دیں، یا اس directory کو Nextcloud کے ساتھ external storage کے طور پر attach کریں تاکہ Nextcloud کو معلوم ہو کہ اسے وہاں دیکھنا ہے۔

کون سا software مجھے ایسے شخص کے ساتھ link share کرنے دیتا ہے جس کا کوئی account نہیں؟

Nextcloud اور Seafile دونوں public links بناتے ہیں، جن کے لیے optional password اور expiry date مقرر کی جا سکتی ہے۔ Object storage آپ کو presigned URL دیتا ہے جو مقررہ وقت گزرنے کے بعد خود کام کرنا بند کر دیتا ہے۔ Syncthing کے پاس اس کا کوئی حل نہیں۔ اس کا sharing model device pairing ہے، اس لیے دوسرے شخص کو Syncthing install کرنا، آپ کو device ID دینا، اور folder accept کرنا ہوگا۔

Server کو کتنی disk درکار ہے؟

Server of record کے لیے shared data کے مکمل size کے علاوہ version history اور trash کے لیے جگہ، نیز جاری uploads کے لیے working space رکھیں۔ Version history وہ حصہ ہے جسے لوگ کم سمجھتے ہیں: روزانہ تبدیل ہونے والی 2 GB file کی ہر version محفوظ رکھنے سے storage تیزی سے بڑھتی ہے، اس لیے شروع ہی میں retention policy مقرر کریں۔ Data کو الگ volume پر رکھنے سے یہ اضافہ root filesystem سے دور رہتا ہے؛ ورنہ full disk پورے server کو روک دیتی ہے، صرف ایک upload کو نہیں۔