پچھلے ہفتے میں نے اپنے پروڈکشن ڈیٹا بیس کو صاف کیا۔ میرا کام کرنے والا [Neotoma](https://neotoma.io) مثال ایک کمانڈ میں 6,174 مشاہدات اور 3,862 اداروں سے 84 مشاہدات اور 67 اداروں تک گیا۔ مہینوں کے رابطوں، کاموں، بات چیتوں، تاثرات کے نوٹس، لین دین، اور مستقل اصول: ختم ہو گئے۔

مجھے واپس مل گیا۔ حتمی ڈیٹا بیس میں 6,296 مشاہدات اور 3,951 ادارے ہیں جو پانچ ہفتوں کی سرگرمی پر محیط ہیں۔ بحالی میں تقریباً ایک گھنٹہ لگا۔ یہ پوسٹ اس کے بارے میں ہے کہ یہ کیسے ہوا، بازیابی کیوں ممکن ہوئی، اور ایک میموری سسٹم بنانے کے بارے میں جو تجربے سے پتہ چلتا ہے آپ واقعی پر بھروسہ کر سکتے ہیں۔

## کیا ہوا؟

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

غلطی دنیاوی تھی۔ میں نے `neotoma reset` چلایا جبکہ `NEOTOMA_ENV` پروڈکشن پر سیٹ تھا۔ میں نے سوچا کہ میں دیو کو نشانہ بنا رہا ہوں۔ جب تک میں نے دیکھا، فعال ڈیٹا بیس میں دوبارہ شروع کرنے کے عمل سے 84 تازہ مشاہدات تھے اور کچھ نہیں۔

## بیک اپ تلاش کرنا

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

| ماخذ فائل | مشاہدات | ادارے | تازہ ترین سرگرمی |
|---|---|---|---|
| `neotoma.prod.db.db` | 6,174 | 3,862 | 9 مارچ |
| `neotoma.prod 2.db` | 4,406 | 3,073 | 10 مارچ |
| لائیو ہدف (پوحنے کے بعد) | 84 | 67 | 11 مارچ |
| `neotoma.prod.db.recovered-*` | 4,381 | 3,059 | 3 مارچ |
| `ڈیٹا بیک اپ/ڈیٹا کاپی/` | 4,158 | 2,955 | 2 مارچ |
| مختلف پرانی کاپیاں | 3,100 سے 3,931 | 2,558 سے 2,806 | فروری 17 تا 27 فروری |

بیک اپ کاپیاں موجود تھیں کیونکہ میں ڈیٹا بیس فائل کو فاسد وقفوں سے دستی طور پر کاپی کر رہا تھا۔ کوئی باضابطہ بیک اپ سسٹم نہیں، بس کبھی کبھار 'cp' کمانڈز جب مجھے یاد آتا ہے یا مجھے گھبراہٹ محسوس ہوتی ہے۔ ان کاپیوں میں سے ایک، `neotoma.prod.db.db`، نے 9 مارچ تک تقریباً ہر چیز کو محفوظ رکھا۔ ایک دوسری کاپی، `neotoma.prod 2.db` میں 10 مارچ تک کا ڈیٹا موجود تھا جو پہلی کاپی چھوٹ گیا۔

ان دو فائلوں اور لائیو ڈیٹا بیس میں زندہ بچ جانے والے 84 مشاہدات کے درمیان، میرے پاس مکمل ٹائم لائن کی تشکیل نو کے لیے کافی مواد تھا۔

## انضمام کیسے کام کرتا ہے۔

Neotoma میں SQLite ڈیٹا بیس کو یکجا کرنے کے لیے ایک بلٹ ان 'merge-db' کمانڈ ہے۔ عمل:

1. اس میں شامل ہر فائل (ذرائع اور ہدف دونوں) کو ٹائم اسٹیمپڈ ڈائرکٹری میں بیک اپ کریں۔ بازیابی کی کسی بھی کوشش کو اصل کو خطرہ نہیں ہونا چاہئے۔
2. کنکرنٹ رائٹز کو روکنے کے لیے چل رہا نیوٹوما سرور بند کریں۔
3. یہ دیکھنے کے لیے کہ کون سے تنازعات موجود ہیں انضمام کو خشک کریں۔
4. انضمام کو `--mode Keep-target` کے ساتھ انجام دیں، جو اس ذریعہ سے قطاریں داخل کرتا ہے جو ہدف غائب ہے اور کسی بھی قطار کے ہدف کے ورژن کو محفوظ رکھتا ہے جو دونوں ڈیٹا بیسز کا اشتراک کرتے ہیں۔
5. دوسرے ماخذ کے لیے دہرائیں۔
6. مشاہدے اور ہستی کے شمار کی تصدیق کریں۔
7. سرور کو دوبارہ شروع کریں۔

بنیادی انضمام نے سب سے بڑے بیک اپ سے 6,174 مشاہدات حاصل کیے ہیں۔ ثانوی انضمام میں 10 مارچ کی ونڈو سے تقریباً 100 مزید شامل ہوئے۔ حتمی گنتی: 6,296 مشاہدات، 3,951 ادارے، 9 فروری سے 11 مارچ تک پھیلی سرگرمی۔

دوبارہ شروع کرنے کے بعد، میں نے Neotoma MCP کے ذریعے اداروں کا نمونہ لیا تاکہ یہ تصدیق کی جا سکے کہ ہر چیز قابل رسائی تھی۔ رابطے، کام، بات چیت، تاثرات کے ریکارڈ: سبھی موجود اور صحیح طریقے سے ترتیب دیے گئے ہیں۔

## یہ بحالی کیوں ممکن ہوئی؟

بحالی نے نیوٹوما کے فن تعمیر کی تین خصوصیات کی وجہ سے کام کیا۔

**مشاہدات سچائی کا ماخذ ہیں۔** جب کچھ تبدیل ہوتا ہے تو نیوٹوما قطار کو اوور رائٹ کرکے ہستیوں کو ذخیرہ نہیں کرتا ہے۔ ہر حقیقت ایک ناقابل تغیر مشاہدے کے طور پر سسٹم میں داخل ہوتی ہے: "ایلس کا ای میل alice@example.com ہے، جو 3 مارچ کو Gmail سے مشاہدہ کیا گیا تھا۔" ہستی کی حالت کا شمار مشاہدات کے مکمل سیٹ سے کیا جاتا ہے۔ مشاہداتی لاگ صرف ضمیمہ ہے۔

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

**اینٹیٹی اسنیپ شاٹس اخذ کیے گئے ہیں، پرائمری نہیں۔** مشاہدات کو ضم کرنے کے بعد، نیوٹوما مشاہداتی لاگ سے ہستی کے سنیپ شاٹس کی دوبارہ گنتی کرتا ہے۔ ہر ایک ہستی کا سنیپ شاٹ تعییناتی ہے: ایک جیسے مشاہدات کے پیش نظر، آپ کو ہمیشہ ایک ہی ہستی کی حالت ملتی ہے۔ یہی وجہ ہے کہ مرج کمانڈ میں اسنیپ شاٹ کی دوبارہ گنتی کا مرحلہ شامل ہے۔ ایک بار جب مشاہدات اپنی جگہ پر آجائیں تو ادارے خود کو صحیح طریقے سے دوبارہ بنا لیتے ہیں۔

**پرائمری کلید کا تنازعات کا پتہ لگانے کے ساتھ انضمام۔** `merge-db` کمانڈ ہر ٹیبل پر چلتا ہے، ان قطاروں کو داخل کرتا ہے جو ماخذ میں موجود ہیں لیکن ہدف میں نہیں، اور بنیادی کلید کے ذریعے تنازعات کو ہینڈل کرتی ہے۔ `کیپ-ٹارگٹ` موڈ میں، ہدف کا ورژن کسی بھی ٹکراؤ پر جیت جاتا ہے۔ ڈرائی رن موڈ پیش نظارہ کرتا ہے کہ آپ کے ارتکاب سے پہلے کیا داخل کیا جائے گا اور کیا تنازعہ ہوگا۔ میں نے دونوں انضمام کے لیے ڈرائی رن دوڑائے اور عمل کرنے سے پہلے تنازعات کی رپورٹس کا جائزہ لیا۔

یہ تینوں خصوصیات مل کر ڈیٹا بیس کو اس طرح سے خود شفا بخشتی ہیں جیسے روایتی قطار کی سطح کے بیک اپ نہیں ہیں۔ آپ کو فکر کرنے کی ضرورت نہیں ہے کہ کس بیک اپ میں کسی ہستی کا "صحیح ورژن" ہے۔ آپ مشاہدات کو ضم کرتے ہیں، دوبارہ گنتی کرتے ہیں، اور درست حالت سامنے آتی ہے۔

## جو میں نے سیکھا۔

تجربے نے کچھ چیزوں کو تقویت دی۔

**غیر رسمی بیک اپ بیک اپ نہ کرنے سے بہتر ہیں۔** کبھی کبھار ڈیٹا بیس فائل کاپی کرنے کی میری عادت نے مہینوں کے کام کو بچا لیا۔ لیکن کبھی کبھار دستی کاپیاں ایک نظام نہیں ہیں۔ وہ خلا چھوڑ دیتے ہیں۔ اگر میں 11 مارچ کے بجائے 7 مارچ کو ڈیٹا بیس کو صاف کر دیتا، تو میں 28 فروری سے 7 مارچ تک ڈیٹا کھو دیتا کیونکہ کسی بھی کاپی نے اس ونڈو کا مکمل احاطہ نہیں کیا تھا۔ میں اب اپنے میک پر ٹائم مشین کے ساتھ خودکار روزانہ بیک اپ ترتیب دے رہا ہوں۔

**env فلیگ کی غلطی ایک کلاسک ہے۔** ہر وہ سسٹم جو dev اور prod ماحول میں کام کرتا ہے اس میں یہ خطرہ ہوتا ہے۔ تخفیف تباہ کن کارروائیوں، کلر کوڈڈ ٹرمینل پرامپٹس، یا فی ماحول کے لیے علیحدہ اسناد کے تصدیقی اشارے ہیں۔ اس واقعے کے بعد جب بھی پروڈکشن ماحول کا پتہ چلتا ہے تو میں نے 'neotoma reset' میں جبری تصدیق شامل کی۔ پروڈ کے لیے `-y` پرچم کو نظر انداز کر دیا گیا ہے۔ آپ کو "نیوٹوما ری سیٹ (پیداوار)" اور کچھ ہونے سے پہلے ایک انتباہ نظر آتا ہے۔

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

**میں نے ان ٹولز کا تجربہ کیا جو میں بنا رہا تھا۔** میں نے 'merge-db' کمانڈ مہینوں پہلے مختلف استعمال کے معاملے کے لیے لکھی تھی: متعدد نیوٹوما مثالوں کو چلانے والے صارفین کے ڈیٹا کو یکجا کرنا۔ میں نے اسے اپنے پروڈکشن ڈیٹا پر استعمال کرنے کی کبھی توقع نہیں کی۔ لیکن چونکہ یہ ٹول موجود تھا اور تنازعات کے حل اور اسنیپ شاٹ کی دوبارہ گنتی کو ہینڈل کرتا تھا، اس لیے بحالی دباؤ کی بجائے میکانکی تھی۔

## آپ کا ڈیٹا آپ کی غلطیوں سے بچ جائے۔

اس واقعے نے ایسے خلاء کو بے نقاب کیا جو Neotoma کو بند کر دینا چاہیے تاکہ صارفین کو کبھی بھی وہ کام نہ کرنا پڑے جو میں نے دستی طور پر کیا تھا۔

**خودکار سنیپ شاٹس۔** نیوٹوما کو ڈیٹا بیس کو شیڈول کے مطابق اور کسی بھی تباہ کن آپریشن سے پہلے اسنیپ شاٹ کرنا چاہیے۔ ٹائم اسٹیمپ شدہ کاپیوں کا ایک گھومتا ہوا سیٹ، جو 30 دنوں تک برقرار رکھا جاتا ہے۔ اگر آپ غلطی سے پروڈ پر ری سیٹ چلاتے ہیں، تو پری ری سیٹ سنیپ شاٹ وہیں ہے۔ بحالی کا انحصار اس بات پر نہیں ہونا چاہیے کہ آیا آپ کو اس ہفتے `cp` چلانا یاد تھا۔

**بے ​​ضابطگی کا پتہ لگانا۔** ہزاروں مشاہدات سے اچانک صفر کے قریب گرنا معمول کی بات نہیں ہے۔ Neotoma اس پیٹرن کا پتہ لگا سکتا ہے اور ارتکاب کرنے سے پہلے تصدیق کرسکتا ہے۔ ایک سادہ ہورسٹک، "یہ آپریشن 90 فیصد سے زیادہ مشاہدات کو ہٹا دے گا، تصدیق کریں؟" میرے مسح کو مکمل طور پر روک دیا ہوتا۔

**ایجنٹ کے ذریعے ریکوری۔** چونکہ ایجنٹ نیوٹوما کے لیے بنیادی UX ہیں، اس لیے ریکوری ایجنٹوں کے ذریعے بھی کام کرنی چاہیے۔ آپ اپنے ایجنٹ سے کہتے ہیں "میرا ڈیٹا بیس غلط لگتا ہے، مجھے لگتا ہے کہ میں نے ڈیٹا کھو دیا ہے۔" ایجنٹ مشاہدے کی گنتی کی جانچ کرتا ہے، دستیاب سنیپ شاٹس تلاش کرتا ہے، تاریخ کی حدود کا موازنہ کرتا ہے، اور MCP کے ذریعے آپ کو انضمام کے ذریعے لے جاتا ہے۔ کوئی CLI سپلنکنگ کی ضرورت نہیں ہے۔

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

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

## نمبر

| میٹرک | مسح کرنے سے پہلے | مسح کے بعد | صحت یابی کے بعد |
|---|---|---|---|
| مشاہدات | 6,174 | 84 | 6,296 |
| ادارے | 3,862 | 67 | 3,951 |
| تاریخ کی حد | 9 فروری تا 9 مارچ | مارچ 10 تا 11 مارچ | 9 فروری تا 11 مارچ |

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

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

Neotoma [GitHub پر اوپن سورس](https://github.com/neotoma-app/neotoma) ہے۔ اگر آپ میموری کی ایک تہہ چاہتے ہیں جہاں آپ کا ڈیٹا آپ کی بدترین غلطیوں سے بچ سکے، [اسے آزمائیں](https://neotoma.io/install)۔