ٹیسٹ ریسٹور: اپنے بیک اپ پہلے سے جانچیں

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

کیا چیک کرنا ہے

کسی بھی واقعے سے پہلے تین سوالات جن کے جواب آپ کے پاس ہونے چاہئیں:

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

مشق کیسے چلائیں

سب سے ایماندار طریقہ الگ مشین پر ہے، پروڈکشن والی پر نہیں۔ ایک ماہ کے لیے VDS-1 لیں، اس پر شروع سے بحالی کریں، اور وقت نوٹ کریں۔

export RESTIC_REPOSITORY="sftp:backup@backup.example.com:/srv/restic"
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic snapshots
restic restore latest --target /restore
ls -la /restore

ڈیٹا بیس بحال کریں:

docker compose up -d db
gunzip -c /restore/var/backups/db.sql.gz | docker compose exec -T db psql -U postgres app
docker compose exec -T db psql -U postgres app -c "select count(*) from users;"

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

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

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

عام طور پر کیا سامنے آتا ہے

• .env فائل بھول جاتی ہے۔ ڈیٹا موجود ہے، مگر اس کے پاس ورڈ نہیں۔
• سرٹیفکیٹس بھول جاتے ہیں۔ سائٹ چل پڑتی ہے مگر HTTPS پر جواب نہیں دیتی۔
• شیڈول بھول جاتا ہے۔ سب کچھ کام کرتا ہے، مگر بیک اپ بننا بند ہو جاتے ہیں — اور پتہ ایک ماہ بعد چلتا ہے۔
• اسٹارٹ اپ کی ترتیب لکھی ہی نہیں ہوتی۔ ایپلیکیشن ڈیٹا بیس سے پہلے شروع ہو جاتی ہے اور کریش کر جاتی ہے۔
• ریپوزٹری کا پاس ورڈ صرف گمشدہ مشین پر تھا۔ بیک اپ موجود ہیں، مگر ان تک رسائی نہیں۔
• بحالی دو کے بجائے دس گھنٹے لیتی ہے۔ ریسیور بینڈوتھ یا ڈسک شیلف، دیکھیں ڈسک کی رفتار۔

ترتیب لکھ لیں

مشق کی بنیاد پر ایک مختصر ہدایت نامہ لکھیں اور اسے مشین سے باہر رکھیں:

1. اسی یا بڑے ٹیئر کی مشین آرڈر کریں — پروویژننگ میں تقریباً ایک منٹ لگتا ہے۔
2. Docker انسٹال کریں اور بیک اپ سے /opt/myapp بحال کریں۔
3. ڈیٹا بیس ڈمپ بحال کریں، ریکارڈز کی تعداد چیک کریں۔
4. /etc/nginx اور سرٹیفکیٹس بحال کریں، ویب سرور چلائیں۔
5. ڈومین کو نئے ایڈریس کی طرف پوائنٹ کریں۔
6. crontab.txt سے شیڈول بحال کریں۔
7. چیک کریں: سائٹ کھلتی ہے، لاگ ان کام کرتا ہے، بیک اپ دوبارہ بن رہے ہیں۔

نکتہ 5 سب سے زیادہ نظر انداز کیا جاتا ہے۔ DNS ریکارڈز فوراً اپ ڈیٹ نہیں ہوتے، اور اگر آپ مائیگریشن کا امکان رکھتے ہیں تو ریکارڈ کا TTL پہلے سے 300 سیکنڈ کر دیں۔

کتنی بار

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

بیک اپ میں کیا ہونا چاہیے — بالکل کیا بیک اپ کرنا ہے۔ کہاں رکھنا ہے — آف سائٹ بیک اپ۔ اگر واقعہ پہلے ہی پیش آ چکا ہو — ڈیٹا ضائع ہو گیا۔