Backup আর disaster recovery — RPO, RTO, snapshot আর চারটি কৌশল

১ · বিপর্যয় কী — মানুষের ভুল থেকে account চুরি পর্যন্ত

আপনার বাড়ির জমির দলিলের কথা ভাবুন। আসল দলিল থাকে আলমারিতে। সাবধানী মানুষ একটি ফটোকপি রাখেন ব্যাংকের লকারে, আরেকটি গ্রামের বাড়িতে। আলমারিতে উই ধরলে লকারের কপি বাঁচায়। বাড়িতে আগুন লাগলে গ্রামের কপি। চোর আলমারি আর লকারের চাবি, দুটোই পেয়ে গেলে গ্রামের কপিই শেষ ভরসা। Backup মানে এই ফটোকপি। আর পুরো ব্যবস্থা, মানে বিপদের পর সেবা আর ডেটা গ্রহণযোগ্য সময়ে ফেরানোর পরিকল্পনা, প্রস্তুতি ও চর্চার নাম disaster recovery (DR).

নকশার তত্ত্ব, মানে replication-এর ধরন আর multi-region-এর গঠন, আছে System Design-এর disaster recovery পর্বে। এখানে আমাদের প্রশ্ন operational: backup কীভাবে নেবেন, কোথায় রাখবেন, ফেরাতে কত সময় লাগবে, মাসে কত খরচ হবে, আর রাত তিনটায় কে কী করবেন। পর্ব ২২-এ managed database-এর backup দেখেছেন; এবার পুরো সেবার ছবি।

পর্ব ৫-এ দেখেছেন, multi-AZ নকশা একটি zone হারালে বাঁচায়। কিন্তু সব বিপদ zone-এর মাপে আসে না। চার ধরনের বিপদ আলাদা করে ভাবতে হয়:

এই চারটির মধ্যে নাটকীয় হলো region হারানো, কিন্তু সাধারণ অভিজ্ঞতায় সবচেয়ে ঘনঘন আসে মানুষের ভুল আর software-এর bug. কারণটি সহজ: প্রতিদিন শতবার deploy আর migration হয়, region প্রায় পড়েই না। তাই DR পরিকল্পনা শুরু করুন “কেউ ভুল করে ডেটা মুছলে কী হবে” দিয়ে, “পুরো region ডুবে গেলে কী হবে” দিয়ে নয়। এই ক্রমই খরচের দিক থেকেও সস্তা।

২ · RPO আর RTO — দুটি সংখ্যা, আর কোন কাজের জন্য কোনটি

DR-এর সব সিদ্ধান্ত দুটি প্রশ্ন থেকে আসে। ব্যাংকে বিদ্যুৎ চলে গেলে আর খাতা পুড়ে গেলে দুটি জিনিস জানতে হয়: শেষ কখনকার হিসাব হাতে আছে, আর কতক্ষণে কাউন্টার আবার খুলবে।

• RPO (Recovery Point Objective): সর্বোচ্চ কত সময়ের ডেটা হারানো মেনে নেবেন। পেছনের দিকে মাপা হয়।
• RTO (Recovery Time Objective): বিপর্যয়ের পর সর্বোচ্চ কত সময়ে সেবা ফেরাতে হবে। সামনের দিকে মাপা হয়।

দুটিই লক্ষ্য। মহড়ায় মাপা আসল মান আলাদা হতে পারে, আর পার্থক্যটিই সবচেয়ে দামি তথ্য। RPO-তে ডেটার মাপ নেই, আছে সময়। “১ TB পর্যন্ত হারানো চলে” এমন কথার মানে নেই। অর্ডারের হিসাবে বলুন: “১৫ মিনিটের অর্ডার হারালে ক্ষতি কত।”

সংখ্যা আসে ব্যবসার ক্ষতি থেকে

প্রতিটি সেবার জন্য জিজ্ঞেস করুন: এক ঘণ্টা বন্ধ থাকলে কত টাকা আর কতটা আস্থা যায়? এক ঘণ্টার ডেটা হারালে সেটি কি আবার বানানো যায়? এই বিশ্লেষণের নাম business impact analysis. এর ফল হলো workload tiering, মানে সেবাগুলোকে স্তরে ভাগ করা। সবকিছুকে সর্বোচ্চ স্তরে রাখলে বিল আকাশে ওঠে; কিছু না ভাগ করলে আসল জরুরি সেবাটি পড়ে থাকে সারির পেছনে।

একটি কাল্পনিক অনলাইন বাজার অ্যাপের উদাহরণ (সংখ্যাগুলো উদাহরণ মাত্র):

একটি ফাঁদ মনে রাখুন: নির্ভরতা। Tier 0-এর অর্ডার সেবা যদি লগইন ছাড়া চলতে না পারে, তাহলে লগইনও আসলে Tier 0. কাগজের স্তর নয়, নির্ভরতার গ্রাফ দেখে স্তর দিন। DNS, secret store আর certificate-ও এই গ্রাফের অংশ।

৩ · Backup বনাম replication — ভুলও কপি হয়

পর্ব ২২-এ দেখেছেন replica কী। অনেকেই ভাবেন, replica যখন আছে, backup-এর কী দরকার? দুটির কাজ আলাদা। ক্লাসে পাশের বন্ধু আপনার খাতা হুবহু টুকে নিচ্ছে, এটি replication. আপনি ভুল লিখলে সেও ভুল লেখে। পরীক্ষার আগের রাতে খাতার ফটোকপি করে রাখা হলো backup; পরে যত ভুলই লিখুন, ফটোকপি বদলায় না।

একটি কাল্পনিক অনলাইন বাজার অ্যাপে বিকেল ১৪:৩৭-এ একজন প্রকৌশলী orders টেবিলে WHERE ছাড়া DELETE চালালেন। মিনিটে ১০টি অর্ডার আসে, আর রাত ০২:০০-তে টেবিলে ছিল ১,০০,০০০ সারি। হাতে আছে চারটি ব্যবস্থা: replica (lag ২ সেকেন্ড), রাতের full backup, ঘণ্টায় একটি snapshot আর point-in-time recovery. “পরে” চেপে দেখুন কে কতটা ফেরাতে পারে।

দুটি বিষয় খেয়াল করুন। এক, এখানে PITR-এর ক্ষতি শূন্য, কারণ primary বেঁচে ছিল, log-ও বেঁচে ছিল। Region হারালে শেষ না-পাঠানো log-টুকু যায়। তাই একই ব্যবস্থার RPO বিপদভেদে আলাদা। দুই, মাঝামাঝি একটি হাতিয়ার আছে: delayed replica, যা ইচ্ছা করে ধরুন এক ঘণ্টা পিছিয়ে চলে (PostgreSQL-এ recovery_min_apply_delay). ভুল ধরা পড়লে replay থামিয়ে সেখান থেকে ডেটা তুলে আনা যায়। এটি backup-এর বিকল্প নয়, দ্রুত উদ্ধারের সংযোজন।

৪ · 3-2-1, immutable কপি আর চাবি — backup বাঁচাবে কে

Backup নিজেও আক্রমণের লক্ষ্য। যে মানুষ বা ভুল আসল ডেটা শেষ করে, সে backup-এও পৌঁছাতে পারে। তাই backup কোথায় আর কার নাগালে আছে, সেটিই আসল নকশা।

• Immutable কপি: নির্দিষ্ট মেয়াদের আগে কেউ মুছতে বা বদলাতে পারে না। একে অনেক provider-এ object lock বা vault lock বলে। কড়া mode-এ এটি অনুমতির ওপর নির্ভর নয়, storage-এর নিজের নিয়ম; নরম mode-এ বিশেষ অনুমতি থাকলে সরানো যায়। মেয়াদ বুঝে দিন: কড়া mode-এ ভুল করে ১০ বছর লিখলে ১০ বছরের বিলও আটকে থাকে।
• Air-gap: ইংরেজি শব্দটির অর্থ মাঝখানে ফাঁকা হাওয়া। পুরোনো দিনে tape খুলে আলমারিতে রাখা। Cloud-এ এটি সাধারণত যৌক্তিক দেওয়াল: আলাদা account, আলাদা পরিচয়, কড়া নিয়ন্ত্রণ।
• Cross-region কপি: Region হারানোর বিরুদ্ধে। সাবধান: ডেটা অন্য দেশে গেলে data localisation-এর নিয়ম প্রযোজ্য হতে পারে। বাংলাদেশে আপনার ডেটার ক্ষেত্রে কী প্রযোজ্য, আইনি পরামর্শ নিয়ে জেনে নিন।
• Cross-account কপি: Account চুরি আর ভেতরের ভুলের বিরুদ্ধে। Production-এর পরিচয় backup account-এ শুধু নতুন কপি লিখতে পারবে, মুছতে নয়। Backup account-এর root আলাদা মানুষের হাতে, আলাদা MFA-সহ। Account ভাগের নকশা আসবে পর্ব ৩৫-এ।
• Retention: কত দিনের কপি রাখবেন। এটি হতে হবে ভুল ধরা পড়তে যত সময় লাগে, তার চেয়ে বেশি। পুরোনো কপি মোছার নিয়মের জন্য পর্ব ১০-এর backup rotation দেখুন।

তিন provider-এ একই ধারণার নাম (লেখার সময়ের নাম, service-এর সুবিধা অঞ্চল আর সময়ভেদে বদলাতে পারে):

# উদাহরণ: অন্য region-এ snapshot কপি। সব ID নমুনা, খরচ হতে পারে।
aws ec2 copy-snapshot \
  --region ap-southeast-1 \
  --source-region ap-south-1 \
  --source-snapshot-id snap-0example1234567890 \
  --encrypted --kms-key-id alias/dr-backup \
  --description "orders nightly, DR copy"

এবার সবচেয়ে কঠিন দৃশ্যটি। একটি কাল্পনিক অ্যাপে চুরি যাওয়া একটি admin credential দিয়ে ransomware চলল। Backup-এর নকশা কীভাবে পরিণতি বদলায়, ধাপে ধাপে দেখুন। এখানে শুধু প্রতিরক্ষা আর উদ্ধার দেখানো হয়েছে।

একটি সীমা মনে রাখুন: backup ফেরায় প্রাপ্যতা, গোপনীয়তা নয়। ডেটা চুরি হয়ে থাকলে backup সেই ক্ষতি ঠিক করে না। সে জন্য লাগে encryption, least privilege আর নজরদারি। আর আইনি জানানো, মুক্তিপণ ইত্যাদি প্রশ্ন আগে থেকেই ব্যবস্থাপনা আর আইনজীবীর সাথে ঠিক করে রাখুন।

৫ · Snapshot — crash-consistent, application-consistent আর incremental চেইন

Snapshot হলো একটি disk-এর নির্দিষ্ট মুহূর্তের ছবি। পর্ব ১৫-এ VM-এর disk-এর সাথে নামটি দেখেছেন। কিন্তু ছবিটি ঠিক কী ধরল, সেই প্রশ্নটিই এখানে গুরুত্বপূর্ণ। রান্না চলাকালে হঠাৎ ছবি তুললে দেখা যাবে চুলায় আধসেদ্ধ ভাত; সব থামিয়ে ছবি তুললে দেখা যাবে গোছানো রান্নাঘর।

# উদাহরণ: filesystem থামিয়ে snapshot. নমুনা ID, বাস্তবে trap-সহ লিখুন।
sudo fsfreeze --freeze /data
aws ec2 create-snapshot \
  --volume-id vol-0example1234567890 \
  --description "orders app-consistent"
sudo fsfreeze --unfreeze /data

এখানে ফাঁদ আছে: script ভেঙে গেলে /data জমে থাকে, আর app আটকে যায়। তাই trap দিয়ে unfreeze নিশ্চিত করুন (পর্ব ১০). আর database-এর ক্ষেত্রে শুধু filesystem থামানো যথেষ্ট না-ও হতে পারে; সবচেয়ে ভরসার পথ database-এর নিজের backup পদ্ধতি বা managed service-এর backup. একাধিক disk একসাথে নিতে হলে provider-এর multi-volume snapshot সুবিধা দেখুন, নইলে দুই disk-এর ছবি দুই মুহূর্তের হবে।

Incremental চেইন

Full backup পুরো ডেটা কপি করে। Incremental শুধু আগের কপির পরে বদলানো অংশ রাখে। সোমবার full ১০০ GB, বাকি ছয় দিন ৫ GB করে বদল হলে সপ্তাহে জমে ১৩০ GB, সাতটি full-এ লাগত ৭০০ GB. কিন্তু শনিবারের অবস্থা ফেরাতে নিজে বানানো চেইনে সোমবারের full-এর ওপর পাঁচটি incremental পরপর বসাতে হয়, আর মাঝের একটি নষ্ট হলে তার পরের সব অকেজো।

Cloud-এর block snapshot সাধারণত ভিন্নভাবে চলে। প্রথমটি সব ব্যবহৃত block রাখে, পরেরগুলো শুধু বদলানো block, তবু প্রতিটি snapshot থেকে সরাসরি পুরো disk ফেরানো যায়। যেমন AWS-এর documentation অনুযায়ী, EBS-এর মাঝের snapshot মুছলে পরেরগুলো ফেরাতে দরকারি block রেখে দেওয়া হয়। তবে এই আচরণ সব ব্যবস্থায় এক নয়, নিজের tool-এর documentation মিলিয়ে নিন।

৬ · হিসাব — backup-এর ব্যবধান থেকে RPO, গতি থেকে RTO

RPO-এর সূত্র

ধরুন backup নেওয়া হয় I ব্যবধানে, আর কপিটি নিরাপদ জায়গায় পৌঁছাতে সময় লাগে S. Backup শুরু হওয়ার মুহূর্তের ডেটাই তাতে থাকে, কিন্তু কপি নিরাপদ না হওয়া পর্যন্ত ভরসা নেই। সবচেয়ে খারাপ সময় হলো পরের কপি নিরাপদ হওয়ার ঠিক আগে:

উদাহরণ: দিনে একবার ০২:০০-তে backup, পৌঁছাতে ২ ঘণ্টা। সবচেয়ে খারাপ ক্ষতি ২৪ + ২ = ২৬ ঘণ্টা, গড় ১২ + ২ = ১৪ ঘণ্টা। নিচের simulator পুরো দিনের প্রতিটি মিনিটে বিপর্যয় ঘটিয়ে এই সংখ্যা মেলায়। plans-এ নিজের সময়সূচি বসিয়ে দেখুন।

// Data loss across one day for a backup schedule. Clock is in minutes (0..1439).
// A backup taken at b is only safe at b + ship (copied to the other place).
const every = (step, from = 0) => { const a = []; for (let m = from; m < 1440; m += step) a.push(m); return a; };
const plans = [
  { name: "daily 02:00",  times: [120],      ship: 120 },
  { name: "every 6 h",    times: every(360), ship: 30 },
  { name: "hourly",       times: every(60),  ship: 10 },
  { name: "log, 5 min",   times: every(5),   ship: 1 },
];
const hm = m => `${Math.floor(m / 60)}h ${String(m % 60).padStart(2, "0")}m`;

function lossAt(p, t) {                 // t = failure minute today
  let best = -Infinity;
  for (const b of p.times) for (const day of [0, -1440]) {
    const taken = b + day;
    if (taken + p.ship <= t && taken > best) best = taken;
  }
  return t - best;
}
const FAIL = 14 * 60 + 37;              // the failure in the story: 14:37
const hours = [0, 3, 6, 9, 12, 15, 18, 21];
console.log("plan         worst    average  at 14:37");
for (const p of plans) {
  let worst = 0, sum = 0;
  for (let t = 0; t < 1440; t++) { const l = lossAt(p, t); sum += l; if (l > worst) worst = l; }
  console.log(p.name.padEnd(12), hm(worst).padStart(7), hm(Math.round(sum / 1440)).padStart(8), hm(lossAt(p, FAIL)).padStart(8));
}
console.log("\nloss in hours if the failure hits at (daily plan):");
const d = plans[0];
for (const h of hours) {
  const l = lossAt(d, h * 60) / 60;
  console.log(`${String(h).padStart(2, "0")}:00 ${String(l.toFixed(1)).padStart(5)} ${"#".repeat(Math.round(l))}`);
}

plan         worst    average  at 14:37
daily 02:00  25h 59m  14h 00m  12h 37m
every 6 h     6h 29m   3h 30m   2h 37m
hourly        1h 09m   0h 40m   0h 37m
log, 5 min    0h 05m   0h 03m   0h 02m

loss in hours if the failure hits at (daily plan):
00:00  22.0 ######################
03:00  25.0 #########################
06:00   4.0 ####
09:00   7.0 #######
12:00  10.0 ##########
15:00  13.0 #############
18:00  16.0 ################
21:00  19.0 ###################

RTO-এর সূত্র

RTO একটি সংখ্যা নয়, কয়েকটি ধাপের যোগফল:

গতি হলো পথের সবচেয়ে সরু অংশ: network, disk-এর লেখা আর সমান্তরাল download, এই তিনের সর্বনিম্ন। একটি বড় ফাঁদ বিট আর বাইট। Network মাপা হয় bit-এ, ডেটা byte-এ। ১ Gbps = ১,০০০ Mbit/s ÷ ৮ = ১২৫ MB/s.

কষে দেখা: ২ TB ডেটা, ১ Gbps পথ। গতি ১২৫ MB/s, তাই ২ × ১০^১২ ÷ (১২৫ × ১০^৬) = ১৬,০০০ সেকেন্ড, মানে প্রায় ২৬৭ মিনিট। বাকি ধাপ ৮০ মিনিট। মোট প্রায় ৩৪৭ মিনিট, মানে ৫ ঘণ্টা ৪৭ মিনিট। ডেটা কত বড়, সেই একটি সংখ্যাই RTO-এর বেশিরভাগ ঠিক করে দিল।

// Restore time: RTO = fixed steps + data / bottleneck speed.
// ASSUMED numbers for a 2 TB database. Change them and press Run.
const GB = 1e9, TB = 1e12;
const DATA = 2 * TB;
const disk = 300;                     // restore target disk write, MB/s
const streams = 8, perStream = 40;    // parallel downloads, MB/s each
const steps = { detect: 15, decide: 15, build: 20, verify: 20, traffic: 10 }; // min
const fixed = Object.values(steps).reduce((a, b) => a + b, 0);

const speed = gbps => Math.min(gbps * 125, disk, streams * perStream); // 1 Gbit/s = 125 MB/s
const copyMin = (bytes, mbps) => bytes / (mbps * 1e6) / 60;
const hm = m => `${Math.floor(m / 60)}h ${String(Math.round(m % 60)).padStart(2, "0")}m`;

console.log(`fixed steps = ${fixed} min`);
console.log("link     bottleneck   copy     total RTO");
for (const g of [1, 2.5, 10]) {
  const s = speed(g), c = copyMin(DATA, s);
  console.log(`${String(g).padEnd(4)}Gbps ${String(s).padStart(5)} MB/s ${hm(c).padStart(8)} ${hm(fixed + c).padStart(9)}`);
}
// an incremental chain: every piece is applied in order, each with its own overhead
const s = speed(1), parts = 23, partGB = 5, overheadMin = 2;
const chain = parts * (copyMin(partGB * GB, s) + overheadMin);
console.log(`\n1 full + ${parts} incrementals adds ${chain.toFixed(1)} min`);
console.log(`total with chain: ${hm(fixed + copyMin(DATA, s) + chain)}`);
// reverse question: how big can the data be for a 4 h RTO?
for (const g of [1, 10]) {
  const left = 240 - fixed;
  console.log(`RTO 4h on ${g} Gbps: at most ${(left * 60 * speed(g) * 1e6 / TB).toFixed(2)} TB`);
}

fixed steps = 80 min
link     bottleneck   copy     total RTO
1   Gbps   125 MB/s   4h 27m    5h 47m
2.5 Gbps   300 MB/s   1h 51m    3h 11m
10  Gbps   300 MB/s   1h 51m    3h 11m

1 full + 23 incrementals adds 61.3 min
total with chain: 6h 48m
RTO 4h on 1 Gbps: at most 1.20 TB
RTO 4h on 10 Gbps: at most 2.88 TB

৭ · Restore পরীক্ষা — যাচাই না করা backup, backup নয়

পরীক্ষার হলে গিয়ে কলম খুলে দেখলেন কালি শুকিয়ে গেছে। কলম ব্যাগে ছিল, কিন্তু কাজের ছিল না। Backup-এরও তাই। Backup job-এর “success” মানে শুধু job শেষ হয়েছে। কপিটি পড়া যায়, পুরো, আর তা দিয়ে app চলে, এই কথা কেবল restore test প্রমাণ করে।

যাচাইয়ের চারটি ধাপ আছে, প্রতিটি আগেরটির চেয়ে শক্ত প্রমাণ:

1. আছে: কপি জায়গামতো আছে, মাপ স্বাভাবিক। শূন্য বা হঠাৎ ছোট ফাইলে alert.
2. অক্ষত: Checksum মিলছে, পথে একটি byte-ও বদলায়নি।
3. ফেরানো যায়: আলাদা পরিবেশে restore হয়, key-সহ, আর সময় মাপা হয়।
4. কাজ করে: App চলে, সারির সংখ্যা মেলে, নমুনা অর্ডার খোলে।

দ্বিতীয় ধাপটি নিচের block-এ চালিয়ে দেখুন। সব কিছু একটি temporary directory-তে হয়, আর শেষে মুছে যায়। sha256sum প্রতিটি ফাইলের একটি ছাপ বানায়। একটি অক্ষর বদলালেও ছাপ সম্পূর্ণ বদলে যায়।

#!/usr/bin/env bash
# Verify backup copies with checksums, inside a temporary directory.
set -euo pipefail
work=$(mktemp -d); trap 'rm -rf "$work"' EXIT; cd "$work"
mkdir src offsite

printf 'id,amount\n1,450\n2,1200\n3,875\n' > orders-mon.csv
printf 'id,amount\n4,300\n5,450\n'         > orders-tue.csv
: > orders-wed.csv                  # the export job failed: empty file
mv orders-*.csv src/

( cd src && sha256sum orders-*.csv > ../MANIFEST )
cut -c1-12,65- MANIFEST             # first 12 hex digits are enough to read
cp src/orders-*.csv offsite/

# One byte changes in the offsite copy. Same size, no error from cp.
sed -i 's/,450/,950/' offsite/orders-tue.csv

check() { ( cd offsite && sha256sum -c --quiet ../MANIFEST 2>&1 ); }
echo "--- check 1"
if check; then echo "all copies match"; else echo "BAD COPY, do not trust offsite"; fi

cp src/orders-tue.csv offsite/      # repair from the other copy
echo "--- check 2 after repair"
if check; then echo "all copies match"; fi

# A checksum proves "same as the source", not "the source was good".
echo "--- restore test: count rows"
for f in offsite/orders-*.csv; do
  rows=$(awk 'NR > 1' "$f" | wc -l)
  [ "$rows" -gt 0 ] && s=ok || s="EMPTY, backup job failed"
  echo "$(basename "$f"): $rows rows, $s"
done

81abb2ac62df  orders-mon.csv
b53a3b222e3a  orders-tue.csv
e3b0c44298fc  orders-wed.csv
--- check 1
orders-tue.csv: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
BAD COPY, do not trust offsite
--- check 2 after repair
all copies match
--- restore test: count rows
orders-mon.csv: 3 rows, ok
orders-tue.csv: 2 rows, ok
orders-wed.csv: 0 rows, EMPTY, backup job failed

এই পরীক্ষা হাতে করবেন না, স্বয়ংক্রিয় করুন। প্রতি রাতে একটি job সর্বশেষ কপি ছোট আলাদা পরিবেশে restore করবে, সারি গুনবে, সময় লিখবে, পরিবেশ মুছবে, আর ব্যর্থ হলে alert দেবে। এই job নিজে না চললেও alert আসা চাই; পর্ব ১০-এর dead man's switch এই কাজের জন্যই। এতে যে সময়টি মাপা হলো, সেটিই আপনার সত্যিকার RTO-এর ভিত্তি।

৮ · চারটি DR কৌশল — খরচ আর RTO-এর সিঁড়ি

পুরো region হারালে কী হবে, তার চারটি পরিচিত উত্তর আছে। AWS তার disaster recovery whitepaper-এ এগুলোর নাম দিয়েছে backup and restore, pilot light, warm standby আর multi-site active/active. অন্য provider-রা ধারণাটি একই রাখে, নাম কিছুটা বদলায়। বিয়েবাড়ির উদাহরণে এগুলো সহজে মনে থাকে:

এই সময়গুলো মোটা দিকনির্দেশ, আপনার ডেটার মাপ আর মহড়াই আসল সংখ্যা বলবে। প্রথম তিনটি মূলত active-passive. একটি সতর্কতা: সিঁড়ির ওপরে উঠলে region হারানোর ঝুঁকি কমে, কিন্তু ভুল DELETE আর ransomware-এর ঝুঁকি একটুও কমে না। সবচেয়ে দামি active-active-এও backup লাগে।

পথটি কেমন, দেখা যাক। কাল্পনিক অনলাইন বাজার অ্যাপের মূল region রাত ০৩:১০-এ বন্ধ হয়ে গেল। অন্য region-এ আছে ছোট একটি database replica, lag ৮ সেকেন্ড। App server শূন্য, তবে image আর IaC তৈরি। দরকার ১২টি VM আর TTL ৬০ সেকেন্ড।

এবার খরচের হিসাব। নিচের সব দাম ধরে নেওয়া গোল সংখ্যা; আসল দাম provider-এর pricing page-এ দেখুন। Production-এ ১০টি VM (ঘণ্টায় $০.১০), একটি database (ঘণ্টায় $০.৫০) আর ১,০০০ GB disk. মাস ধরা ৭২০ ঘণ্টা।

কষে দেখা, pilot light: Backup: ২,০০০ GB × $০.০২ + ৩০০ GB transfer × $০.০২ = $৪৬. ছোট database: $০.১২৫ × ৭২০ = $৯০. DB disk: ১,০০০ × $০.১০ = $১০০. মোট $২৩৬ মাসে। লক্ষ্য করুন, এই খরচ production-এর ওপরে অতিরিক্ত। প্রত্যাশিত ক্ষতি = বছরে বিপর্যয়ের সম্ভাবনা × (RTO × ঘণ্টার ক্ষতি + RPO × ঘণ্টাপ্রতি ডেটার ক্ষতি)। সবচেয়ে সস্তা কৌশলটি হলো চালানোর খরচ আর প্রত্যাশিত ক্ষতির যোগফল যেখানে কম।

// Four DR strategies: yearly cost vs expected yearly disaster loss.
// All prices are ASSUMED round numbers. Check your provider's pricing page.
const H = 720;                         // hours in a 30-day month
const vm = 0.10, db = 0.50, smallDb = 0.125;   // $ per hour
const diskGB = 0.10, backupGB = 0.02, xferGB = 0.02;  // $ per GB (month or transfer)
const backup = 2000 * backupGB + 300 * xferGB;  // 2 TB kept, 300 GB moved
const dbDisk = 1000 * diskGB;
const S = [
  { n: "backup-restore", m: backup,                                  rto: 8,    rpo: 1 },
  { n: "pilot light",    m: backup + smallDb * H + dbDisk,           rto: 1,    rpo: 0.02 },
  { n: "warm standby",   m: backup + db * H + dbDisk + 3 * vm * H,   rto: 0.25, rpo: 0.01 },
  { n: "active-active",  m: backup + db * H + dbDisk + 10 * vm * H + 1000 * xferGB, rto: 0.05, rpo: 0.005 },
];
function yearly(s, perYear, downPerH, dataPerH) {
  const run = s.m * 12;
  const risk = perYear * (s.rto * downPerH + s.rpo * dataPerH);
  return { run, risk, total: run + risk };
}
const usd = x => "$" + Math.round(x).toLocaleString("en-US");
const P = 0.2, D = 2000, L = 3000;     // once in 5 years; $/h down; $/h of data lost
console.log(`assumed: ${P} disasters/year, ${usd(D)}/h down, ${usd(L)}/h of lost data`);
console.log("strategy        $/month     run/yr    risk/yr   total/yr");
for (const s of S) {
  const y = yearly(s, P, D, L);
  console.log(s.n.padEnd(15), usd(s.m).padStart(7), usd(y.run).padStart(10), usd(y.risk).padStart(10), usd(y.total).padStart(10));
}
console.log("\ncheapest total as the cost of downtime grows:");
for (const d of [200, 2000, 10000, 50000, 200000]) {
  const best = S.map(s => [s.n, yearly(s, P, d, L).total]).sort((a, b) => a[1] - b[1])[0];
  console.log(`${usd(d).padStart(9)}/h -> ${best[0].padEnd(15)} ${usd(best[1])}`);
}

assumed: 0.2 disasters/year, $2,000/h down, $3,000/h of lost data
strategy        $/month     run/yr    risk/yr   total/yr
backup-restore      $46       $552     $3,800     $4,352
pilot light        $236     $2,832       $412     $3,244
warm standby       $722     $8,664       $106     $8,770
active-active    $1,246    $14,952        $23    $14,975

cheapest total as the cost of downtime grows:
     $200/h -> backup-restore  $1,472
   $2,000/h -> pilot light     $3,244
  $10,000/h -> pilot light     $4,844
  $50,000/h -> warm standby    $11,170
 $200,000/h -> active-active   $16,955

৯ · Failover চালানো — DNS, runbook, game day, failback আর দায়িত্ব

DNS failover

DNS failover-এ health check মূল ঠিকানাকে অসুস্থ দেখলে DNS উত্তর বদলে দ্বিতীয় ঠিকানা দেয়। এটি সস্তা আর provider-নিরপেক্ষ। কিন্তু এটি তাৎক্ষণিক নয়: TTL ৬০ সেকেন্ড হলেও পথের কোনো resolver বেশি সময় রাখতে পারে, আর আগে খোলা connection নিজে থেকে সরে না। তাই বদল ধীরে ছড়ায়। TTL আগে থেকেই ছোট রাখুন; বিপদের সময় কমালে পুরোনো মান শেষ হওয়ার অপেক্ষাই করতে হবে। Global load balancing বা anycast ঠিকানায় এই দেরি কম, খরচ ও নির্ভরতা আলাদা। DNS-এর বিস্তারিত পর্ব ২৯-এ।

একটি গভীর নিয়ম: failover-এর পথ যেন নষ্ট জিনিসের ওপর নির্ভর না করে। যে স্বয়ংক্রিয় ব্যবস্থা মূল region-এ বসে আছে, সে region-এর সাথেই যায়। এই গুণের নাম static stability: বিপদের সময় নতুন কিছু তৈরি না করেই টিকে থাকা। পর্ব ৫ থেকে পরিচিত এই ধারণাটিই warm standby-কে pilot light-এর চেয়ে ভরসার করে। মনে রাখুন, automatic failover সবসময় ভালো নয়: ছোট network ঝাঁকুনিতে region বদলে গেলে ক্ষতি বেশি হয়। অনেক দল ডেটার failover-এ মানুষের সিদ্ধান্ত রাখে।

Runbook আর game day

Runbook হলো রাত তিনটায় ঘুমচোখে পড়ার মতো নির্দেশিকা। এখানে কমান্ড লেখা থাকে, ধারণা নয়। সবচেয়ে গুরুত্বপূর্ণ কথা: runbook থাকবে নষ্ট হওয়া ব্যবস্থার বাইরে। সেটি যদি নষ্ট region-এর wiki-তে থাকে, তাহলে দরকারের সময়ই পাবেন না।

Runbook: orders region failover (নমুনা)
ঘোষণা করেন: incident lead; না পেলে তাঁর সহকারী
শর্ত: মূল region ১৫ মিনিট অচল, আর provider-এর ফেরার সময় অজানা
১. Fencing: পুরোনো primary-র পথ বন্ধ, যাচাই
২. Replica lag লিখে রাখুন (এটিই আসল RPO)
৩. Promote, তারপর database বড় করুন
৪. IaC চালান: app 12, quota যাচাই
৫. ধোঁয়া পরীক্ষা: লগইন, পরীক্ষামূলক অর্ডার
৬. DNS বদলান, error rate দেখুন
থামার নিয়ম: ধাপ ৩ ব্যর্থ হলে incident lead-কে জানান

Game day হলো নির্ধারিত দিনে ইচ্ছা করে বিপর্যয় সাজিয়ে চর্চা করা, স্কুলের অগ্নি-মহড়ার মতো। ছোট থেকে শুরু করুন: প্রথমে টেবিলে বসে আলোচনা, তারপর একটি backup restore, তারপর staging-এ failover, শেষে সাবধানে production-এ। প্রতিবার মাপুন আসল RPO আর RTO, আর runbook-এ যা ভুল পেলেন তা ঠিক করুন। Quota, হারানো key, মেয়াদ-উত্তীর্ণ certificate আর যে মানুষ ছুটিতে, এসব কাগজে ধরা পড়ে না, মহড়ায় পড়ে। Chaos engineering-এর বিস্তারিত পর্ব ৬৮-এ।

Failback

বিপদ কাটলে মূল region-এ ফেরার নাম failback বা ফিরে আসা। অনেকে এটিকে ছোট কাজ ভাবেন, অথচ এটিও একটি পুরো failover, উল্টো দিকে। পুরোনো primary-তে সেই ৮ সেকেন্ডের লেখা থাকতে পারে, যা নতুন primary পায়নি। তাই পুরোনো ডেটাকে সরাসরি চালু করা যায় না। ক্রমটি হলো: পুরোনো region-কে নতুন করে replica বানানো, ফাঁকে পড়া লেখাগুলো আলাদা করে দেখা, lag শূন্যের কাছে আনা, শান্ত সময়ে পরিকল্পিত বদল, তারপর আবার DR-এর পুরো সুরক্ষা চালু। তাড়াহুড়ো নেই; সেবা এখন চলছে। আর failback শেষের পরই যেন পরের বিপদের সুরক্ষা ফেরে, এই কথাটি runbook-এ লিখুন।

দায়িত্ব — সহজ করে

কঠিন ছক লাগে না। প্রতিটি প্রশ্নের পাশে একজন নাম আর একজন বিকল্প লিখে রাখলেই হয়:

• Disaster কে ঘোষণা করবেন? (incident lead)
• Backup আর restore test-এর মালিক কে?
• ডেটা ঠিক ফিরেছে, এই কথা কে বলবেন? (সেবার মালিক দল)
• গ্রাহক আর ব্যবস্থাপনাকে কে জানাবেন?
• Backup account-এর চাবি কার হাতে?

Provider-এর দায়িত্ব কোথায় শেষ, সেটিও পর্ব ২-এর shared responsibility মনে রেখে দেখুন: Managed service-এর backup সুবিধা provider দেয়, কিন্তু চালু করা, মেয়াদ ঠিক করা আর ফিরিয়ে দেখা আপনার কাজ। মানুষের ভূমিকার বিস্তারিত পর্ব ৬৭-এ।

১০ · AI-এর যুগে backup আর DR যাচাই

AI কয়েক সেকেন্ডে backup script আর DR পরিকল্পনা লিখে দেয়। কিন্তু সে আপনার ডেটার মাপ, ঝুঁকি বা account-এর গঠন জানে না। আর সবচেয়ে বড় কথা, সে কখনো restore করে দেখে না। সাধারণ ভুলগুলো:

চেকলিস্ট

• Workload-এর স্তর আর প্রতিটির RPO-RTO লেখা আছে, নির্ভরতাসহ
• অন্তত একটি কপি অন্য account-এ, immutable, আর key-ও তার সাথে বাঁচে
• শেষ restore-এর তারিখ আর মাপা সময় জানি
• Backup ব্যর্থ হলে, এমনকি না চললেও, alert আসে
• AI-এর লেখা script throwaway পরিবেশে চালিয়েছি, plan বা --dry-run দেখেছি, diff পড়েছি
• * permission, 0.0.0.0/0, public storage, hardcoded secret আর latest নেই
• Budget alert চালু আছে, আর prompt-এ কোনো secret দিইনি