Large migrations · Verification · پیشرفت بار کے پیچھے ثبوت

بادلوں کے درمیان سیکڑوں جی بی منتقل کرنا: آپ کو کیسے معلوم ہوگا کہ ہر فائل پہنچی ہے؟

500 GB پر، "اپ لوڈ ختم ہو گیا" ثبوت نہیں ہے۔ قابل بھروسہ ہجرت کے لیے ایک پائیدار انوینٹری، ہر چیز کے لیے ایک ریاستی منتقلی، رکاوٹوں کے بعد دوبارہ قابل بحالی، اور منزل سے ہی ثبوت کی ضرورت ہوتی ہے۔

تازہ کاری ; 16 منٹ کا مطالعہ.

مختصر جواب

فائل آرک لائبریری کو فی فائل ریکارڈ اور پائیدار قطار پیغامات میں توڑ دیتا ہے۔ ایک کارکن ایک ڈیلیوری کو کاپی کرتا ہے، لوٹی ہوئی منزل کی شناخت کو اسٹور کرتا ہے، سائز کی توثیق کرتا ہے، اس عین آبجیکٹ کو واپس پڑھتا ہے، اور سورس پے لوڈ کے ساتھ SHA-256 کا موازنہ کرتا ہے۔ ریکارڈ کی تصدیق ہو جاتی ہے — اور پیغام کو تسلیم کیا جاتا ہے — صرف ان چیکوں اور ڈیٹا بیس کی تازہ کاری کے کامیاب ہونے کے بعد۔

پیمانہ "کام کیا" کے معنی کیوں بدلتا ہے

دس فائلوں کا معائنہ کرنا آسان ہے۔ دس ہزار فائلیں نہیں ہیں۔ ایک بڑی ذاتی لائبریری چھوٹے دستاویزات، ملٹی گیگا بائٹ ویڈیوز، خالی فائلیں، نیسٹڈ فولڈرز، یونیکوڈ نام، محفوظ شدہ پروجیکٹس، اور کلاؤڈ مقامی فارمیٹس کو یکجا کر سکتی ہے۔ ایک ناکامی متاثر کن نظر آنے والے فیصد کے اندر چھپ سکتی ہے۔

ٹوٹل مفید لیکن نامکمل ہیں۔ دو لائبریریاں ایک ہی ظاہری سائز کو ظاہر کر سکتی ہیں جب کہ کسی میں کوئی چیز غائب ہو یا کسی غیر متعلقہ فائل سے متوازن ایک کٹی ہوئی چیز پر مشتمل ہو۔ فائل کا شمار مقامی دستاویز کی برآمد یا فراہم کنندہ اشیاء کو خارج کرنے کے بعد بھی مختلف ہو سکتا ہے۔

سچائی کی کارآمد اکائی فائل جاب ہے: کون سا سورس آبجیکٹ پڑھا گیا، کون سی منزل آبجیکٹ بنائی گئی، کن بائٹس کا موازنہ کیا گیا، جب تصدیق مکمل ہوئی، اور کیا کوئی کوشش حل طلب نہیں ہے۔

مکمل فائل آرک لائف سائیکل، تشریح شدہ

تشریح شدہ لائف سائیکل فائل آرک براؤزر سیٹ اپ سکینر ڈیٹا بیس پائیدار قطار کارکن اور SHA-256 کی توثیق دکھا رہا ہے
براؤزر کنٹرول کا بہاؤ شروع کرتا ہے۔ سکینر، مسلسل قطار، ڈیٹا بیس، اور کارکن طویل عرصے سے چلنے والی منتقلی کو لے جاتے ہیں۔

جب Start کو قبول کر لیا جاتا ہے، تو API سب سے پہلے MongoDB کو اسکین جاب لکھتا ہے اور پھر پبلشر کی تصدیق کے ساتھ ایک پائیدار RabbitMQ قطار میں ایک مستقل اسکین پیغام شائع کرتا ہے۔ اگر اشاعت ناکام ہو جاتی ہے، تو کام کو ناکام کے طور پر نشان زد کیا جاتا ہے اور API رپورٹ کرتا ہے کہ یہ سکین کو محفوظ طریقے سے قطار میں نہیں لگا سکتا۔

سکینر دونوں فراہم کنندگان کی توثیق کرتا ہے، منتخب کردہ ذریعہ کی فہرست تیار کرتا ہے، دریافت شدہ بائٹس کے خلاف محدود منزل کے کوٹہ کو چیک کرتا ہے، اور ہر سورس فائل کے لیے ڈیٹا بیس ریکارڈ کو اوپر کرتا ہے۔ یہ مسلسل منتقلی کے پیغامات شائع کرتا ہے اور ان کی اشاعت کے کامیاب ہونے کے بعد ہی اسکین مکمل ہونے کا نشان لگاتا ہے۔

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

ڈیٹا بیس کی قطار ایک چیک لسٹ آئٹم ہے، ڈسپوزایبل بک کیپنگ نہیں۔

ہر فائل کا ریکارڈ زیر التواء شروع ہوتا ہے، ایک کوشش کے دوران InProgress پر چلا جاتا ہے، اور تصدیق کے بعد ہی اپ لوڈ شدہ تک پہنچ جاتا ہے۔ کوشش کی گنتی، آخری کوشش کا وقت، خرابی کی تفصیل، منزل آبجیکٹ ID، دونوں SHA-256 ڈائجسٹ، تصدیق کا طریقہ، اور VerifiedAt ریکارڈ کے ساتھ منسلک رہتے ہیں۔

مکمل شدہ ریکارڈ ڈیٹا بیس میں پیش رفت اور آڈٹ ٹریل کے طور پر رہتا ہے۔ "فائل کو کراس کرنا" کا مطلب ہے ایک کنٹرول شدہ ریاست کی تبدیلی، ثبوت کو حذف نہ کرنا۔ ڈپلیکیٹ قطار کی ترسیل اس ریاست کا معائنہ کرتی ہے اور فوری طور پر تصدیق کرتی ہے کہ پہلے سے ہی نشان زدہ ریکارڈ کو VerifiedAt کے ساتھ اپ لوڈ کیا گیا ہے۔

تین ناکام کوششوں کے بعد، کوشش کے چکر کے مکمل ہونے کے ٹائم سٹیمپ کے ساتھ ایک مستقل مسئلہ ناکام ہو جاتا ہے۔ یہ مستثنیات کو مرئی بناتا ہے اور ایک زہریلے پیغام کو ہمیشہ کے لیے گھومنے سے روکتا ہے جب کہ ڈیش بورڈ پھنس جاتا ہے۔

ایک فائل کے لیے تکمیلی گیٹ
Pending
  → InProgress (attempt recorded)
  → destination ID stored
  → destination size matches
  → exact destination object re-downloaded
  → source SHA-256 == destination SHA-256
  → Uploaded + VerifiedAt persisted
  → queue message acknowledged

کیوں ایک فائل ایک سے زیادہ بار ڈیلیور کی جا سکتی ہے۔

قابل اعتماد قطاریں عام طور پر کم از کم ایک بار ڈیلیوری فراہم کرتی ہیں، نہ کہ کلاؤڈ API، ایک میسج بروکر، اور ڈیٹا بیس میں بالکل ایک بار کا جادوئی وعدہ۔ حادثہ OneDrive یا Google Drive کے اپ لوڈ کو قبول کرنے کے بعد ہو سکتا ہے لیکن کارکن مکمل ہونے سے پہلے لکھتا ہے۔

FileArk اس غیر یقینی صورتحال کو idempotent ریکارڈز اور منزل کی بحالی کے ساتھ ہینڈل کرتا ہے۔ کارکن پہلے چیک کرتا ہے کہ آیا ریکارڈ پہلے سے تصدیق شدہ ہے۔ اگر نہیں، تو یہ ذخیرہ شدہ منزل کی ID استعمال کر سکتا ہے یا دوبارہ اپ لوڈ کرنے کا فیصلہ کرنے سے پہلے متوقع منزل کے راستے اور رکاوٹ والے نتیجے کے لیے درست سائز تلاش کر سکتا ہے۔

بازیابی کے امیدواروں کو پھر اسی عین مطابق آبجیکٹ ہیش کی تصدیق کا نشانہ بنایا جاتا ہے۔ ایک مانوس فائل کا نام تلاش کرنا کافی نہیں ہے۔ نقطہ یہ ہے کہ رکاوٹ کی گئی کوشش کو دوبارہ ثبوت میں تبدیل کیا جائے، نہ کہ پرامید کامیابی میں۔

منزل پر اور کارکن پر صلاحیت کی جانچ کی جاتی ہے۔

فی فائل جابز شائع ہونے سے پہلے، سکینر غیر منفی سورس میٹا ڈیٹا کے سائز کا مجموعہ کرتا ہے اور جب بھی فراہم کنندہ ایک محدود کوٹہ فراہم کرتا ہے تو مطلوبہ مطلوبہ کا تقابل منزل کے رپورٹ کردہ باقی اسٹوریج سے کرتا ہے۔ ایک کم سائز کی منزل کام کو ایک معروف ڈیڈ اینڈ میں کھلانے کے بجائے اسکین کو ناکام بناتی ہے۔

اعداد و شمار ایک پری فلائٹ ہے، کوئی گارنٹی نہیں: اکاؤنٹ کی سرگرمی رن کے دوران جگہ استعمال کر سکتی ہے، فراہم کنندہ کوٹہ کی رپورٹیں پیچھے رہ سکتی ہیں، اور برآمد شدہ کلاؤڈ-آبائی فائلوں کا روایتی سورس سائز نہیں ہو سکتا۔ فراہم کنندہ کا نفاذ اور فی فائل ایرر ہینڈلنگ فعال رہتی ہے۔

آپ کی کمپیوٹر ڈسک اسٹیجنگ کے لیے استعمال نہیں ہوتی ہے۔ مائیگریشن ورکر پر، فائلوں کو میموری کی حد سے اوپر ایک الگ تھلگ عارضی ڈائرکٹری میں صرف اس وقت رکھا جاتا ہے جب حجم میں متوقع آبجیکٹ کے علاوہ دو گیگا بائٹ ریزرو کی گنجائش ہوتی ہے۔ عارضی مواد کو صفائی میں ہٹا دیا جاتا ہے چاہے کوشش کامیاب ہو یا پھینک دی جائے۔

منزل ID پلس SHA-256 کیوں اہم ہے۔

فائل کا نام کوئی منفرد شناخت نہیں ہے۔ منزل میں پہلے سے ہی ایک ہی نظر آنے والے نام کے ساتھ دو فائلیں ہوسکتی ہیں، یا میٹا ڈیٹا کی فہرست سازی میں وقت لگ سکتا ہے۔ اپ لوڈ کا جواب فراہم کنندہ آبجیکٹ ID فراہم کرتا ہے، اور FileArk حتمی تصدیق کے مرحلے سے پہلے اس ID کو اسٹور کرتا ہے۔

کارکن SHA-256 کو سورس پے لوڈ سٹریم میں شمار کرتا ہے، اسے اپ لوڈ کرتا ہے، پھر اس ID کے ذریعے عین منزل آبجیکٹ کو کھولتا ہے اور SHA-256 کی دوبارہ گنتی کرتا ہے۔ مساوی سائز واضح تراش کو پکڑتا ہے۔ مساوی کرپٹوگرافک ڈائجسٹ زیادہ مضبوط بائٹ لیول چیک ہے۔

صرف منتقل شدہ فائل کی نمائندگی کا احاطہ کیا گیا ہے۔ ڈائجسٹ شیئرنگ کے قوانین، تبصروں، ورژنز، لیبلز، شارٹ کٹس، برقرار رکھنے کی ترتیبات، یا کسی صارف کے لیے برآمد کردہ Google دستاویز کیسے پیش کرتا ہے اس کی توثیق نہیں کر سکتا۔ وہ قبولیت کے کام رہ جاتے ہیں۔

ماخذ کو حذف کرنا جان بوجھ کر عام کامیابی کے راستے سے باہر ہے۔

سب سے محفوظ ڈیفالٹ صرف کاپی ہے، اور FileArk کا ڈیلیٹ کرنے کا آپشن بند ہے جب تک کہ آپ اسے فعال نہ کریں۔ حذف کرنے کے غیر فعال ہونے کے ساتھ، توثیق کی ناکامی اصل کو نہیں ہٹا سکتی کیونکہ حذف کرنے کی کبھی درخواست نہیں کی جاتی ہے۔

اگر آپ جان بوجھ کر ڈیلیٹ آفٹر موو کو فعال کرتے ہیں، تو کارکن ماخذ فراہم کنندہ کے ڈیلیٹ آپریشن کو کال کرنے سے پہلے منزل کی ID، سائز، اور SHA-256 کی توثیق کا انتظار کرتا ہے۔ ناقابل تبدیل یا بہت بڑی لائبریریوں کے لیے مضبوط آپریشنل انتخاب اب بھی آپشن کو بند رکھنے اور انسانی منظور شدہ اوورلیپ مدت کا استعمال کرنا ہے۔

ہجرت کا جواب ہے "کیا تصدیق شدہ کاپی پہنچی ہے؟" برقرار رکھنے کے جوابات "پرانی کاپی کو کب ہٹایا جا سکتا ہے؟" ان کو الگ الگ ثبوت کے ساتھ الگ الگ فیصلے سمجھیں۔

ایک ہی کنٹرول ماڈل دونوں سمتوں میں کام کرتا ہے۔

OneDrive سے Google Drive کے لیے، سورس پے لوڈ کو مائیکروسافٹ گراف سے پڑھا جاتا ہے اور منزل آبجیکٹ کی Google Drive کے ذریعے اس کی واپس کی گئی ID کے ذریعے تصدیق کی جاتی ہے۔ Google Drive سے OneDrive کے لیے، ماخذ کو گوگل ڈرائیو کے ذریعے ڈاؤن لوڈ یا ایکسپورٹ کیا جاتا ہے اور نئی OneDrive آئٹم کو مائیکروسافٹ گراف کے ذریعے دوبارہ پڑھا جاتا ہے۔

قطار، ڈیٹا بیس کی حالتیں، باؤنڈڈ کوششیں، صلاحیت سے پہلے پرواز، سورس ڈائجسٹ، ڈیسٹینیشن آئی ڈی، ڈیسٹینیشن ڈائجسٹ، اور ایکنولجمنٹ آرڈر سمت غیر جانبدار ہیں۔ فراہم کنندہ اڈاپٹر مختلف اپ لوڈ، فولڈر، اور مواد APIs کو ہینڈل کرتے ہیں۔

غیر متناسب مواد سیمنٹکس ہے۔ گوگل کے مقامی دستاویزات کو برآمد کی ضرورت ہے، اور دونوں پلیٹ فارمز میں سروس کے لیے مخصوص اشتراک اور ورژن کا برتاؤ ہے۔ بائٹ سے تصدیق شدہ فائل کے مواد کو ہر تعاون کی خصوصیت کے مکمل کلون کے طور پر فروخت نہیں کیا جانا چاہئے۔

چار حصوں پر مشتمل قبولیت کا منصوبہ استعمال کریں۔

  1. سسٹم ریکارڈ کو جوڑیں۔

    جائزہ مکمل، زیر التواء، جاری، اور ناکام شمار۔ کسی بھی ناکام چیز کو دور نہیں کیا جانا چاہئے کیونکہ مجموعی فیصد زیادہ ہے۔

  2. خطرہ کے لحاظ سے نمونہ

    ان فائلوں کو کھولیں جن کے کھونے سے سب سے زیادہ نقصان پہنچے گا، نیز بڑے میڈیا، آرکائیوز، پرانے دستاویزات، غیر انگریزی نام، نیسٹڈ پاتھ، اور کنورٹڈ کلاؤڈ مقامی فائلیں۔

  3. منزل کے رویے کی توثیق کریں۔

    حقیقی آلات اور صارفین سے رسائی کی جانچ کریں۔ مطلوبہ اشتراک کو دوبارہ بنائیں اور تصدیق کریں کہ آفس یا ایکسپورٹ شدہ گوگل فائلیں توقع کے مطابق کھلی ہیں۔

  4. اوورلیپ کی مدت رکھیں

    ماخذ کو دستیاب اور مستحکم رکھیں جب کہ عام استعمال منزل کی مشق کرتا ہے۔ منسوخی یا حذف کرنے کا فیصلہ بعد میں کریں۔

اکثر پوچھے گئے سوالات

کیا فائل آرک ہر فائل کے لئے قطار استعمال کرتا ہے؟

جی ہاں سکینر فی ماخذ فائل کے حساب سے ڈیٹا بیس ریکارڈ بناتا یا دوبارہ استعمال کرتا ہے اور مستقل منتقلی کا پیغام شائع کرتا ہے۔ کارکنان ان پیغامات کو دستی اعتراف کے ساتھ کھینچتے ہیں۔

قطار کے پیغام کو کب تسلیم کیا جاتا ہے؟

منزل مقصود کی ID کے بعد، سائز، اور SHA-256 کی تصدیق ہو چکی ہے اور اپ لوڈ اور تصدیق شدہ حالت کو برقرار رکھا گیا ہے۔ نامکمل ڈیلیوری دوبارہ ڈیلیور کی جا سکتی ہے۔

کیا مکمل فائل ریکارڈز ڈیٹا بیس سے حذف ہو گئے ہیں؟

نمبر۔ تکمیل پائیدار ریکارڈ پر ایک ریاستی منتقلی ہے۔ قطار منزل کی شناخت، تصدیقی ثبوت، وقت، اور پیش رفت اور آڈٹ کے لیے کوشش کی معلومات رکھتی ہے۔

کیا SHA-256 اجازتوں اور ورژنز کو منتقل کر سکتا ہے؟

نہیں، یہ ثابت کرتا ہے کہ ڈیسٹینیشن فائل بائٹس منتقل شدہ سورس پے لوڈ سے مماثل ہیں۔ اشتراک، اجازت، ورژن، تبصرے، لیبلز، شارٹ کٹس، اور فراہم کنندہ کے مقامی رویے کو علیحدہ توثیق کی ضرورت ہے۔

کیا OneDrive to Google Drive کی اسی طرح تصدیق ہوتی ہے جس طرح ریورس ہوتی ہے؟

بنیادی اصول دونوں سمتوں میں یکساں ہے: سورس پے لوڈ ڈائجسٹ، منزل آبجیکٹ کی شناخت، منزل کا سائز، عین مطابق آبجیکٹ دوبارہ ڈاؤن لوڈ ڈائجسٹ، مسلسل تصدیق، پھر قطار تسلیم۔

اس رہنما مضمون کے لیے استعمال کیے گئے سرکاری وسائل

رہنما پڑھیں