اپنے ایپ ڈیٹابیس کا بیک اپ کیسے لیں (اور اسے واقعی ریسٹور کرنا)

اپنی ایپ کے ڈیٹابیس کا بیک اپ لینے کے لیے اسے کسی شیڈول کے مطابق فائل میں ایکسپورٹ کریں (Postgres کے لیے معیاری ٹول pg_dump ہے)، کاپیاں ڈیٹابیس سے الگ جگہ پر رکھیں، اور باقاعدگی سے ایک کاپی کسی خالی ڈیٹابیس میں ریسٹور کریں تاکہ ثابت ہو کہ وہ کام کرتی ہے۔ کسی بھی خطرناک تبدیلی سے پہلے ایک اضافی بیک اپ لیں۔ آپ کا کوڈ بیک اپ، چاہے وہ GitHub ریپوزٹری ہو یا ایکسپورٹ، آپ کا ڈیٹا شامل نہیں کرتا۔

یہ گائیڈ ان لوگوں کے لیے ہے جو ایک چھوٹی ایپ چلاتے ہیں اور چاہتے ہیں کہ اسے کھونے کی فکر ختم ہو۔ اس میں مثالیں Postgres کی ہیں، کیونکہ زیادہ تر AI سے بنی ایپس اسی کو استعمال کرتی ہیں، لیکن یہ اصول کسی بھی ڈیٹابیس پر لاگو ہوتے ہیں۔

بیک اپ میں کیا کیا شامل ہونا چاہیے

ایک ایپ صرف اس کے ڈیٹابیس سے زیادہ ہوتی ہے۔ جان لیں کہ ہر بیک اپ کس حصے کی حفاظت کرتا ہے۔

ڈیٹا وہ حصہ ہے جسے دوبارہ نہیں بنایا جا سکتا۔ کوڈ دوبارہ لکھا جا سکتا ہے اور settings دوبارہ درج کی جا سکتی ہیں، لیکن آپ کے گاہکوں کے آرڈرز نہیں۔

مرحلہ 1: طے کریں کہ آپ کتنا ڈیٹا کھو سکتے ہیں

دو سوالات آپ کا بیک اپ پلان طے کرتے ہیں:

• آپ کتنا تازہ ڈیٹا کھو سکتے ہیں؟ اگر آپ دن میں ایک بار بیک اپ لیتے ہیں اور ڈیٹابیس شام کو خراب ہو جاتا ہے، تو آپ اس دن کی تبدیلیاں کھو دیں گے۔ ایک چھوٹے شوق کے ایپ کے لیے یہ ٹھیک ہے، لیکن جو ایپ آرڈرز لیتی ہے اس کے لیے شاید نہیں۔
• ریسٹور کے دوران ایپ کتنی دیر بند رہ سکتی ہے؟ ایک چھوٹا ڈیٹابیس چند منٹ میں ریسٹور ہو جاتا ہے۔ بڑا ڈیٹابیس کافی زیادہ وقت لے سکتا ہے، اور ضرورت پڑنے سے پہلے یہ جاننا ضروری ہے۔

زیادہ تر چھوٹی ایپس کے لیے روزانہ خودکار بیک اپ کے ساتھ خطرناک تبدیلیوں سے پہلے ایک دستی بیک اپ ایک معقول آغاز ہے۔ جن ایپس میں پیسہ یا صحت سے متعلق ڈیٹا ہو، انہیں زیادہ بار بیک اپ کی ضرورت ہے، یا ایک managed ڈیٹابیس جس میں point-in-time recovery ہو (یعنی کسی بھی لمحے پر ریسٹور کرنے کی صلاحیت، صرف آخری بیک اپ پر نہیں)۔

مرحلہ 2: دیکھیں آپ کا host پہلے سے کیا کرتا ہے

بہت سے managed ڈیٹابیس providers خودکار بیک اپ لیتے ہیں۔ معلوم کریں:

• کیا آپ کے پلان میں بیک اپ آن ہیں، اور وہ کتنی بار چلتے ہیں؟
• وہ کتنی مدت تک رکھے جاتے ہیں؟
• کیا آپ کسی لمحے پر ریسٹور کر سکتے ہیں، یا صرف روزانہ کے snapshot پر؟
• کیا آپ بیک اپ ڈاؤن لوڈ کر سکتے ہیں، یا صرف ان کے سسٹم کے اندر ریسٹور ہو سکتا ہے؟

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

مرحلہ 3: pg_dump سے ڈمپ بنائیں

pg_dump Postgres ڈیٹابیس کو فائل میں ایکسپورٹ کرتا ہے۔ یہ ایک مستقل snapshot پڑھتا ہے، اس لیے کام کے دوران ایپ چلتی رہ سکتی ہے۔

ایک عام کمانڈ، جو اس connection string کو استعمال کرتی ہے جو آپ کی ایپ پہلے سے environment variable میں رکھتی ہے:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

ان options کا کام:

• --format=custom ایک کمپریس شدہ فائل لکھتا ہے جسے pg_restore پڑھ سکتا ہے، اور بعد میں انفرادی ٹیبلز ریسٹور کرنے دیتا ہے۔ اگر آپ پڑھنے کے قابل .sql فائل چاہتے ہیں تو --format=plain استعمال کریں۔
• --no-owner ownership کی کمانڈز چھوڑ دیتا ہے، جس سے کسی دوسرے ڈیٹابیس میں ریسٹور آسان ہو جاتا ہے۔
• فائل کے نام میں تاریخ بیک اپ کو ایک دوسرے سے الگ رکھتی ہے۔

آپ کے pg_dump کا ورژن آپ کے ڈیٹابیس کے Postgres ورژن جتنا، یا اس سے نیا ہونا چاہیے۔ پرانا pg_dump چلنے سے انکار کر سکتا ہے۔

اگر آپ AI سے بنا رہے ہیں اور command line کو ہاتھ نہیں لگانا چاہتے، تو آپ یہ پوچھ سکتے ہیں:

pg_dump کا custom فارمیٹ استعمال کرتے ہوئے ایپ کے ڈیٹابیس کا بیک اپ بنائیں، فائل کے نام میں آج کی تاریخ رکھیں۔ کوئی connection string یا کوئی secret پرنٹ نہ کریں۔ کام مکمل ہونے پر مجھے فائل کا نام اور سائز بتائیں۔

مرحلہ 4: خودکار بنائیں

دستی بیک اپ اکثر بھول جاتے ہیں۔ اپنے سیٹ اپ کے مطابق انہیں خودکار کریں:

• آپ کے ڈیٹابیس provider کے شیڈول بیک اپ، اگر وہ پیش کرتا ہو۔
• ایک شیڈول job کسی سرور یا CI سروس پر جو pg_dump چلائے اور فائل کو storage میں اپلوڈ کرے۔
• ایک hosted بیک اپ سروس جو آپ کے ڈیٹابیس سے جڑتی ہے۔

جو بھی چنیں، یقینی بنائیں کہ ناکامی کی صورت میں وہ آپ کو بتائے۔ ایک بیک اپ job جو تین ماہ سے خاموشی سے ناکام ہو رہا ہو، اس کی کلاسک خوفناک کہانی ہے۔

مرحلہ 5: کاپیاں کہیں اور محفوظ کریں

اصول عموماً 3-2-1 کہلاتا ہے: آپ کے ڈیٹا کی تین کاپیاں، دو مختلف قسم کی storage پر، اور ایک کاپی آف سائٹ۔ ایک چھوٹی ایپ کے لیے ایک عملی شکل یہ ہے:

• لائیو ڈیٹابیس
• provider کے اپنے خودکار بیک اپ
• آپ کے اپنے ڈمپس، کسی الگ اکاؤنٹ میں object storage bucket جیسی جگہ پر

اس کے علاوہ:

• رسائی محدود کریں۔ بیک اپ میں ہر صارف کا ڈیٹا ہوتا ہے۔ اسے لائیو ڈیٹابیس کی طرح سمجھیں۔
• retention پالیسی رکھیں۔ مثلاً روزانہ کے بیک اپ دو ہفتے اور ماہانہ ایک سال تک۔ پرانے بیک اپ جان بوجھ کر حذف کریں، اور یاد رکھیں کہ پرائیویسی قوانین آپ سے ذاتی ڈیٹا کی درخواست پر حذف کرنے کا تقاضا کر سکتے ہیں۔
• بیک اپ کبھی Git میں commit نہ کریں۔ ریپوزٹری میں ایک ڈمپ ڈیٹا لیک کا انتظار کرتا ہوا خطرہ ہے۔

مرحلہ 6: ریسٹور کا ٹیسٹ کریں

بیک اپ تب ہی قابلِ اعتماد ہے جب آخری کامیاب ریسٹور حال ہی میں ہوا ہو۔ کم از کم ہر چند ماہ میں، اور بیک اپ کے عمل میں کسی بھی تبدیلی کے بعد:

1. ایک نیا، خالی ڈیٹابیس بنائیں۔ ٹیسٹ کے لیے لائیو ڈیٹابیس پر کبھی ریسٹور نہ کریں۔
2. تازہ ترین بیک اپ اس میں ریسٹور کریں:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

سادہ .sql فائل کے لیے اس کی بجائے psql "$TEST_DATABASE_URL" -f backup.sql استعمال کریں۔

1. تصدیق کریں کہ ہر ٹیبل موجود ہے، لائیو ڈیٹابیس سے قطاروں کی تعداد کا موازنہ کریں، اور چند حالیہ ریکارڈ دیکھیں۔
2. اگر ممکن ہو تو ایپ کی ایک کاپی اس سے جوڑ کر لاگ ان کر کے دیکھیں۔
3. لکھ لیں کہ ریسٹور میں کتنا وقت لگا۔ یہی آپ کا حقیقی بحالی کا وقت ہے۔

مرحلہ 7: خطرناک تبدیلیوں سے پہلے بیک اپ لیں

یہ کام کرنے سے پہلے تازہ بیک اپ لیں:

• ایسا ڈیٹابیس migration چلانا جو کالم حذف یا تبدیل کرے
• بڑی مقدار میں ڈیٹا امپورٹ کرنا
• AI ایجنٹ کو ڈیٹا ماڈل میں بڑی تبدیلیاں کرنے دینا
• پرانے ریکارڈ حذف کرنا

AI سے بنی ایپ میں ایجنٹ کسی فیچر کے حصے کے طور پر ٹیبل کا ڈھانچہ بدل سکتا ہے۔ Checkpoints اور version control آپ کا کوڈ واپس لا سکتے ہیں، لیکن وہ حذف شدہ قطاریں واپس نہیں لاتے۔ کسی بڑی تبدیلی سے پہلے تیس سیکنڈ کا بیک اپ سستا بیمہ ہے۔

عام غلطیاں

• یہ سمجھنا کہ Git یا کوڈ ایکسپورٹ بیک اپ ہے۔ اس میں کوڈ ہوتا ہے، ڈیٹا نہیں۔
• ریسٹور کبھی ٹیسٹ نہ کرنا۔ بہت سے بیک اپ ضرورت پڑنے پر ہی خالی، ادھورے یا ناقابلِ پڑھائی نکلتے ہیں۔
• بیک اپ اسی اکاؤنٹ میں رکھنا جہاں ڈیٹابیس ہے۔ ایک سمجھوتہ شدہ یا بند اکاؤنٹ دونوں کو کھو دیتا ہے۔
• اپلوڈ شدہ فائلیں بھول جانا۔ ڈیٹابیس فائل کا path رکھتا ہے؛ تصویر خود storage میں رہتی ہے۔
• بیک اپ اسکرپٹس میں secrets چھوڑ دینا۔ connection string environment variable سے پڑھیں، اسکرپٹ کے متن سے نہیں۔ دیکھیں API keys کو محفوظ کیسے رکھیں۔

بیک اپ اور Mythex

Mythex پروجیکٹس کا ایک مخصوص Postgres ڈیٹابیس ہو سکتا ہے، اور اس کی connection تفصیلات workspace اور شائع شدہ ایپ میں inject ہوتی ہیں۔ Mythex docs میں ڈیٹابیس بیک اپ یا ریسٹور کی خصوصیت بیان نہیں کی گئی، اس لیے اپنا منصوبہ خود بنائیں: ایجنٹ سے ڈمپ بنوائیں، اسے ڈاؤن لوڈ کریں، اور محفوظ جگہ پر رکھیں، خاص طور پر بڑی تبدیلیوں سے پہلے۔ پروجیکٹ ایکسپورٹ (Pro) آپ کا کوڈ شامل کرتا ہے، جس میں secrets اور node_modules شامل نہیں ہوتے؛ اس میں ڈیٹابیس کی قطاریں شامل نہیں ہوتیں۔ docs میں Database اور Data ownership دیکھیں۔ ڈیٹابیس کے بارے میں مزید جاننے کے لیے Postgres کیا ہے پڑھیں۔

بیک اپ چیک لسٹ

• طے کیا کہ آپ کتنا ڈیٹا کھو سکتے ہیں اور کتنی دیر بند رہ سکتے ہیں
• چیک کیا کہ آپ کا ڈیٹابیس host کون سے خودکار بیک اپ دیتا ہے
• آپ کا اپنا ڈمپ شیڈول پر چلتا ہے، اور ناکامی پر آپ کو اطلاع ملتی ہے
• کاپیاں ڈیٹابیس سے الگ، محدود رسائی کے ساتھ محفوظ ہیں
• retention پالیسی لکھی ہوئی ہے
• اپلوڈ شدہ فائلوں کا بھی بیک اپ ہے
• ریسٹور خالی ڈیٹابیس میں ٹیسٹ ہو چکا ہے، اور قطاروں کی تعداد چیک ہو چکی ہے
• ہر خطرناک تبدیلی سے پہلے بیک اپ لیا جاتا ہے

سوالات