ڈیزاسٹر ریکوری پلان کیسے بنائیں (RTO اور RPO)

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

SKYLINE Engineering @skyline

شائع ہوا 9 جون، 2026 | مطالعے کا وقت: 6 منٹ

ڈیزاسٹر ریکوری پلان دراصل کیا ہے

ڈیزاسٹر ریکوری (DR) پلان وہ دستاویزی، آزمودہ طریقہ کار ہے جس پر آپ کی ٹیم کسی بندش کے بعد IT سسٹمز اور ڈیٹا بحال کرنے کے لیے عمل کرتی ہے — ایک ناکام سرور، رینسم ویئر، حذف شدہ ڈیٹابیس، سیلاب زدہ ڈیٹا سینٹر، یا کلاؤڈ ریجن کی ناکامی۔ یہ بیک اپ جیسی چیز نہیں ہے۔ بیک اپ ڈیٹا کی ایک نقل ہے؛ DR پلان وہ پلے بک ہے جو اس نقل کو دوبارہ ایک چلتے ہوئے کاروبار میں بدل دیتی ہے۔

ہر DR پلان کی بنیاد دو اعداد پر ہوتی ہے: RTO اور RPO۔ ان دونوں کو درست کر لیں تو باقی پلان تقریباً خود بخود بن جاتا ہے۔

RTO بمقابلہ RPO: وہ دو اعداد جو اہم ہیں

• Recovery Time Objective (RTO) وہ زیادہ سے زیادہ قابلِ قبول وقت ہے جس تک کوئی سسٹم بند رہ سکتا ہے اس سے پہلے کہ وہ سنگین نقصان کا باعث بنے۔ اگر آپ کی ای-کامرس سائٹ کا RTO 2 گھنٹے ہے، تو ریکوری واقعے کے 2 گھنٹے کے اندر مکمل ہونی چاہیے۔
• Recovery Point Objective (RPO) وہ زیادہ سے زیادہ قابلِ قبول مقدارِ ڈیٹا ہے، جسے وقت کے لحاظ سے ناپا جاتا ہے، جسے کھونے کے آپ متحمل ہو سکتے ہیں۔ 15 منٹ کا RPO اس کا مطلب ہے کہ آپ کے بیک اپ (یا ریپلیکیشن) 15 منٹ سے زیادہ پرانے نہ ہوں، تاکہ آپ زیادہ سے زیادہ 15 منٹ کا کام کھوئیں۔

اسے یاد رکھنے کا ایک آسان طریقہ: RTO آگے دیکھتا ہے ("ہم کب تک واپس آئیں گے؟") اور RPO پیچھے دیکھتا ہے ("ہم کتنا حالیہ ڈیٹا کھو سکتے ہیں؟")۔

سخت تر اہداف کی لاگت زیادہ ہوتی ہے، لہٰذا انہیں ہر ورک لوڈ کے حساب سے مقرر کریں، نہ کہ ایک ساتھ ہر چیز کے لیے۔

مرحلہ 1: بزنس امپیکٹ اینالیسس (BIA) چلائیں

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

ایماندار رہیں۔ ایک مارکیٹنگ بلاگ کے لیے 5 منٹ کا RTO ضائع شدہ رقم ہے؛ ایک پیمنٹ لیجر کے لیے 24 گھنٹے کا RPO ایک کاروبار ختم کر دینے والی غلطی ہے۔

مرحلہ 2: ہر تہہ کے لیے ریکوری حکمتِ عملی منتخب کریں

ہر تہہ کو ایک آرکیٹیکچر سے ملائیں:

• بیک اپ اور ریسٹور (سب سے سستا، سب سے سست): آبجیکٹ اسٹوریج پر شیڈولڈ بیک اپ؛ ضرورت پڑنے پر دوبارہ تعمیر۔ تہہ 3 اور بہت سے تہہ 2 ورک لوڈز کے لیے موزوں۔
• پائلٹ لائٹ / وارم اسٹینڈ بائی: ماحول کی ایک کم سے کم نقل جو دوسرے مقام پر چلتی رہتی ہے، فیل اوور کے دوران بڑھا دی جاتی ہے۔ معتدل RTO کے ساتھ تہہ 1 کے لیے موزوں۔
• ہاٹ اسٹینڈ بائی / ایکٹو-ایکٹو: ایک مکمل چلتا ہوا ریپلیکا جو تقریباً فوری طور پر ذمہ داری سنبھال لیتا ہے۔ سب سے زیادہ لاگت؛ صرف تہہ 1 سسٹمز کے لیے مخصوص کریں جہاں منٹوں کی بندش بھی ناقابلِ قبول ہو۔

سعودی اداروں کے لیے، یہ بھی تصدیق کریں کہ ہر نقل جسمانی طور پر کہاں موجود ہے۔ PDPL اور NCA رہنمائی کے تحت، بنیادی اور DR نقلوں کو اندرونِ مملکت (in-Kingdom) کلاؤڈ انفراسٹرکچر پر رکھنا آپ کو ڈیٹا-ریزیڈنسی کی توقعات کے درست پہلو پر رکھتا ہے اور سرحد پار منتقلی کے جائزوں سے بچاتا ہے۔

مرحلہ 3: 3-2-1 بیک اپ اصول لاگو کریں

تہہ خواہ کوئی بھی ہو، بیک اپ کو آزمودہ 3-2-1 اصول کے گرد ڈیزائن کریں:

• آپ کے ڈیٹا کی 3 نقلیں (1 بنیادی + 2 بیک اپ)
• 2 مختلف میڈیا یا اسٹوریج اقسام
• 1 نقل آف-سائٹ (ایک مختلف ریجن یا فراہم کنندہ)

ایک جدید قسم، 3-2-1-1-0، اس میں 1 ناقابلِ تبدیل/آف لائن نقل (رینسم ویئر سے بچاتی ہے) اور 0 خرابیاں جو ریسٹور پر تصدیق شدہ ہوں کا اضافہ کرتی ہے۔ ناقابلِ تبدیلی (immutability) اہم ہے: رینسم ویئر اب سب سے پہلے بیک اپس کو نشانہ بناتا ہے۔

یہاں ایک قابلِ اعتماد، ڈی ڈپلیکیٹنگ، انکرپٹڈ بیک اپ ہے جو restic کا استعمال کرتے ہوئے ایک ڈیٹابیس اور ایپ ڈائریکٹری کو S3-مطابقت پذیر آبجیکٹ اسٹوریج پر محفوظ کرتا ہے:

# Install restic (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y restic

# Point restic at your object storage bucket
export RESTIC_REPOSITORY="s3:https://s3.example.com/dr-backups"
export AWS_ACCESS_KEY_ID="<access-key>"
export AWS_SECRET_ACCESS_KEY="<secret-key>"
export RESTIC_PASSWORD="<strong-repo-passphrase>"   # keep this safe & off-server

# One-time: initialise the encrypted repository
restic init

# Dump the database, then back up the dump + app files
mysqldump --single-transaction --routines --triggers \
  -u backup -p"$DB_PASS" appdb > /var/backups/appdb.sql

restic backup /var/backups/appdb.sql /srv/app --tag nightly

# Enforce retention (keeps storage and RPO sane)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

آپ کی بیک اپ تعدد آپ کے RPO کو پورا کرنی چاہیے۔ اگر RPO 1 گھنٹہ ہے، تو cron کے ذریعے جاب کو ہر گھنٹے شیڈول کریں اور تصدیق کریں کہ ہر عمل گھنٹے کے اندر اچھی طرح مکمل ہو جاتا ہے:

# /etc/cron.d/dr-backup — hourly backup at minute 5
5 * * * * root /usr/local/bin/dr-backup.sh >> /var/log/dr-backup.log 2>&1

ڈیٹابیسز پر سخت تر RPOs کے لیے، مسلسل طریقے استعمال کریں — MySQL/MariaDB بائنری-لاگ شپنگ یا PostgreSQL WAL آرکائیونگ / اسٹریمنگ ریپلیکیشن — بجائے اکیلے اسنیپ شاٹس پر انحصار کرنے کے۔

مرحلہ 4: ریکوری رن بک لکھیں

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

1. واقعے کا اعلان کریں اور DR کوآرڈینیٹر کو مطلع کریں۔
2. ریکوری انفراسٹرکچر فراہم کریں (ایک اسٹینڈ بائی کلاؤڈ سرور یا ہوسٹنگ ماحول جسے آپ تیزی سے چالو کر سکیں)۔
3. تازہ ترین تصدیق شدہ بیک اپ سے ڈیٹا بحال کریں۔
4. سالمیت کی تصدیق کریں، پھر ٹریفک کو دوبارہ ہدایت دیں (DNS/لوڈ بیلنسر)۔
5. اسٹیک ہولڈرز کو صورتِ حال سے آگاہ کریں۔

اوپر دی گئی restic مثال سے بحالی بس اتنی سی ہے:

# List recovery points, then restore the latest into a target path
restic snapshots
restic restore latest --target /srv/recovery

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

مرحلہ 5: جانچیں، پھر دوبارہ جانچیں

DR پلان بوسیدہ ہو جاتے ہیں۔ تہہ 1 سسٹمز کے لیے کم از کم سہ ماہی ریکوری مشقیں شیڈول کریں:

• ٹیبل ٹاپ ٹیسٹ: کاغذ پر رن بک سے گزریں۔
• ریسٹور ٹیسٹ: حقیقت میں ایک بیک اپ کو ایک الگ تھلگ ماحول میں بحال کریں اور تصدیق کریں کہ ڈیٹا درست ہے (3-2-1-1-0 میں موجود "0")۔
• مکمل فیل اوور: DR سائٹ پر منتقل ہوں اور اسی پر چلائیں۔

ہر مشق کے بعد، اپنے حقیقی ریکوری وقت اور ڈیٹا کے نقصان کو اپنے RTO اور RPO کے مقابلے میں ناپیں۔ اگر آپ ان سے چُوک گئے، تو خلا دور کریں — زیادہ کثرت سے بیک اپ، زیادہ آٹومیشن، یا ایک گرم تر اسٹینڈ بائی — اور دوبارہ جانچیں۔

سب کچھ ملا کر

ایک قابلِ عمل DR پلان مختصر ہوتا ہے: ایک صفحے کی تہہ بندی جدول، فی تہہ RTO/RPO اہداف، ایک 3-2-1-1-0 بیک اپ ڈیزائن، ایک آزمودہ رن بک، اور ایک مشق کا شیڈول۔ اپنے سب سے اہم ورک لوڈ سے شروع کریں، ثابت کریں کہ بحالی سرے سے سرے تک کام کرتی ہے، پھر تہہ در تہہ توسیع کریں۔

اگر آپ ایسے بیک اپ اور اسٹینڈ بائی انفراسٹرکچر چاہتے ہیں جو PDPL اور NCA کی تعمیل کے لیے مملکت کے اندر رہیں، تو متعلقہ رہنمائیوں کے لیے کلاؤڈ بیک اپ کلسٹر دریافت کریں، یا Skyline Cloud اکاؤنٹ بنائیں اور منٹوں میں اندرونِ مملکت آبجیکٹ اسٹوریج، کلاؤڈ سرورز، اور بیک اپ فراہم کریں۔