تسلسل اور بحالی: بحالی جو کوئی نے جانچی ہی نہیں

ہر backup dashboard سبز checkmarks دکھاتا ہے۔ Jobs مکمل ہوئیں، retention policy مطمئن ہوئی، storage متوقع طریقے سے استعمال ہوئی۔ ان میں سے کوئی بھی نہیں بتاتا کہ آپ ایک domain controller کو bare metal سے چار گھنٹوں میں واپس لا سکتے ہیں یا نہیں، خاص طور پر جب کوئی حقیقی واقعہ رونما ہو۔ "backup succeeded" اور "restore succeeded" کے درمیان کا فاصلہ وہ جگہ ہے جہاں زیادہ تر continuity plans خاموشی سے ناکام ہو جاتے ہیں۔

checkmark جھوٹ بولتا کیوں ہے

Backup software اس وقت کامیابی کی رپورٹ دیتا ہے جب وہ bytes کو destination پر لکھنا مکمل کر دے۔ اسے نہیں معلوم کہ وہ bytes قابل استعمال ہیں یا نہیں۔ ایک SQL Server backup صاف طریقے سے مکمل ہو سکتا ہے اور پھر بھی unrestorable ہو سکتا ہے کیونکہ transaction log chain تین دن پہلے ٹوٹ گئی اور کسی نے دیکھا ہی نہیں۔ VM snapshots console میں اچھے لگ سکتے ہیں جبکہ بنیادی VSS writer خاموشی سے guest OS کے اندر ناکام ہو گیا ہو، ایک crash-consistent (application-consistent نہیں) image تیار کر رہا ہو۔

Ransomware operators یہ جانتے ہیں۔ گروپس جو ماضی کے واقعات میں Conti-style playbooks چلا رہے تھے نے جان بوجھ کر backup infrastructure کو نشانہ بنایا — shadow copies کو vssadmin delete shadows /all /quiet سے delete کیا، Veeam repositories کو disable کیا، NAS-based backup targets کو encrypt کیا جو SMB پر reachable تھے۔ اگر آپ کے backups production کے ساتھ ایک ہی network segment پر ہیں domain credentials کے ساتھ جو انہیں access کر سکتے ہیں، تو وہ ایک target ہیں، safety net نہیں۔

restore runbook بنائیں، backup policy نہیں

ایک continuity plan کو step-by-step restore instructions کی ضرورت ہے جو اس شخص کے لیے لکھی جائیں جو عام طور پر یہ کام نہیں کرتا۔ لکھیں:

• درست recovery order (domain controllers اور DNS پہلے، پھر core apps، پھر باقی سب)
• جہاں backup console کے credentials ہیں اگر آپ کا password vault بھی down ہے
• مخصوص restore command یا console path، "Veeam استعمال کرتے ہوئے VM restore کریں" نہیں
• ہر system کے لیے متوقع duration، اصل measured tests پر مبنی، vendor marketing numbers نہیں

Veeam Backup & Replication کے لیے، اس کا مطلب اصل steps کو document کرنا ہے: console کھولیں، Backups > Disk میں navigate کریں، restore point پر right-click کریں، scenario کے لحاظ سے Instant VM Recovery یا Full VM Restore منتخب کریں، target host کو کافی free capacity کے ساتھ منتخب کریں۔ اگر آپ کا primary host بھی compromised ہے، تو آپ کو ایک دوسرا، isolated host پہلے سے منتخب اور licensed کرنا پڑے گا۔

restore کو schedule کے مطابق test کریں، نہ کہ کبھی کبھار

ایک rotation منتخب کریں۔ ہر ماہ، ایک critical system کو isolated VLAN میں restore کریں اور validate کریں کہ یہ boot ہوتا ہے، authenticate ہوتا ہے، اور data صحیح طریقے سے serve کرتا ہے۔ ہر تین ماہ میں، ایک مکمل scope test چلائیں: اپنے domain controller، اپنے file server، اور اپنے primary database کو isolated infrastructure میں restore کریں، پھر backup team سے باہر کسی کو login کرنے اور رپورٹ pull کرنے کی کوشش کرنے دیں۔

Databases کے لیے، صرف .bak file restore نہ کریں — verify کریں:

RESTORE VERIFYONLY FROM DISK = 'D:\\Backups\\prod_2024.bak'

پھر اسے test instance میں actually restore کریں اور اس کے خلاف DBCC CHECKDB چلائیں۔ ایک backup جو VERIFYONLY pass کرتا ہے وہ logical corruption بھی رکھ سکتا ہے جو صرف اس وقت ظاہر ہوتا ہے جب آپ اسے query کریں۔

Linux systems کے لیے جو کچھ اور استعمال کرتے ہیں جیسے Bacula یا restic، اصل restore path کو test کریں:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

پھر restored config files کو production کے خلاف diff کریں تاکہ تصدیق ہو کہ کچھ خاموشی سے drop نہیں ہوا۔

Immutable copies اور 3-2-1-1 rule

روایتی 3-2-1 rule (تین copies، دو media types، ایک offsite) کو ransomware era کے لیے update کی ضرورت ہے: 3-2-1-1، جہاں اضافی "1" ایک immutable یا air-gapped copy ہے۔ S3-compatible storage (Wasabi، Backblaze B2، یا AWS S3 with Object Lock enabled) پر Object lock deletion یا modification کو define کی گئی retention window کے لیے روکتا ہے، حتیٰ کہ admin credentials کے ساتھ account کے لیے بھی۔ اسے configure کریں:

aws s3api put-object-lock-configuration \\
  --bucket backup-vault \\
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

COMPLIANCE mode کا مطلب ہے کہ کوئی بھی، root account سمیت، retention کو مختصر نہیں کر سکتا یا objects کو جلدی delete نہیں کر سکتا۔ یہ اہم ہے جب attacker کے پاس domain admin ہو۔

RTO اور RPO کو حقیقی numbers سے measure کریں، guesses نہیں

Recovery Time Objective اور Recovery Point Objective کاغذی کام کی سی مشق لگتے ہیں جب تک ایک executive نہ پوچھے "ہم کتنا data کھوتے ہیں اور ہم کتنی دیر down ہوتے ہیں۔" اپنی آخری تین test restores کو time کریں۔ اگر آپ کا RPO target ایک گھنٹہ ہے لیکن آپ کا backup job صرف ہر چھ میں چلتا ہے، تو آپ کے پاس ایک documented gap ہے، اور یہ بہتر ہے کہ یہ gap ایک tabletop exercise میں تلاش کریں بجائے ایک actual encryption event کے دوران رات کے دو بجے ہفتے کے دن۔

Test چلائیں، اصل clock time لکھیں، اور اسے اپنے disaster recovery document میں وعدہ کے مقابلے میں compare کریں۔ ان دونوں numbers کے درمیان فرق آپ کے continuity plan کی اصل حالت ہے۔

آپ جن systems کو protect کر رہے ہیں انہیں harden کرنے اور incident response workflows تیار کرنے کے بارے میں مزید معلومات کے لیے، Korra Studio پر متعلقہ Blue Team اور Digital Forensics segments دیکھیں۔