Backup, Disaster Recovery, နှင့် High Availability

နားလည်ထားရမယ့် အချက်

Production system တစ်ခုက local dev မှာ စဉ်းစားစရာမလိုတဲ့ ပုံစံနဲ့ fail ဖြစ်နိုင်ပါတယ် — server သေတာ၊ database corrupt ဖြစ်တာ၊ region offline ဖြစ်တာ၊ credential leak ဖြစ်တာ။ ဒါအတွက် ကြိုတင်ပြင်ဆင်တာက pessimism မဟုတ်ဘဲ အလုပ်ပါ။

Term	အဓိပ္ပာယ် + ဥပမာ
RPO	Data ဘယ်လောက်ပျောက်ရင် ခံနိုင်လဲ, time နဲ့။ RPO 1 hour -> နည်းဆုံး hourly backup လုပ်ရမယ်။
RTO	Fail ဖြစ်ပြီးနောက် system ဘယ်လောက်မြန်မြန် ပြန်တက်ရမလဲ။ RTO 30 min -> outage ကို မိနစ် ၃၀ အတွင်း ဖြေရှင်းရမယ်။

Test မလုပ်ဖူးတဲ့ backup ဟာ backup အစစ် မဟုတ်ဘူး

Restore တစ်ခါမှ မလုပ်ဖူးတဲ့ backup ဟာ confirm မလုပ်ရသေးတဲ့ ခန့်မှန်းချက်တစ်ခုပါ။ Restore လုပ်ပြီး အလုပ်ဖြစ်လား confirm လုပ်တာကို schedule ချထားတဲ့ ထပ်ခါထပ်ခါ task အဖြစ် သတ်မှတ်ပါ၊ တစ်ကြိမ်တည်း setup step မဟုတ်ပါဘူး။

High availability က single point of failure ကို fail မဖြစ်ခင် ဖယ်ရှားပါတယ် — instance အများကြီး, failover ပါတဲ့ redundant database, unhealthy ဖြစ်တာကနေ traffic ကို ရွှေ့ခြင်း။

Deploy မကောင်းတာကို rollback လုပ်တာက အမြန်ဆုံး recovery ပါ — ဖိအားအောက်မှာ forward-fix လုပ်မယ့်အစား ချက်ချင်း ဒါကို ကိုင်ပါ။ Blue-green/canary mechanics အတွက် CI/CD tutorial ရဲ့ deployment-strategies lesson ကို ကြည့်ပါ။

RPO: Recovery Point Objective — ခွင့်ပြုနိုင်တဲ့ data ပျောက်ဆုံးအများဆုံးပမာဏ, time နဲ့ တိုင်းတာ။

RTO: Recovery Time Objective — fail ဖြစ်ပြီးနောက် system ပြန်တည်ဆောက်ဖို့ ခွင့်ပြုနိုင်တဲ့ အများဆုံး time။

High Availability: Component တစ်ခုချင်း fail ဖြစ်ရင်လည်း service ဆက်run နေအောင် single point of failure ကို ဖယ်ရှားထားတဲ့ system design။

text

BACKUP-RESTORE CYCLE AND HIGH AVAILABILITY
------------------------------------------
BACKUP-RESTORE CYCLE AND HIGH AVAILABILITY
----------------------------------------------

BACKUP CYCLE                    HIGH AVAILABILITY
--------------                  -------------------
[ LIVE DATA ]                     [ LOAD BALANCER ]
      |                             /      |     \
      | backup (every X min)       v       v      v
      v                       [inst-1] [inst-2] [inst-3]
 [ BACKUP STORE ]                  X  (one fails)
      |
      | disaster happens           traffic still flows
      v                            through inst-2, inst-3
 [ RESTORE ]  <-- test this          (no single point
      |            regularly!         of failure)
      v
[ DATA IS BACK ]

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

RPO ကို ကိုက်ညီအောင်လုပ်တာက comparison တစ်ခုပါပဲ — backup interval က RPO target ထက် နည်းလား ညီလား?

Scenario	ရလဒ်
Daily backups, RPO 1 hour	ဆိုးရွားစွာ fail — worst case က တစ်ရက်လုံး data ပျောက်တာ။
Every 15 min, RPO 1 hour	အဆင်ပြေပြေ pass။
Hourly, RPO 1 hour	Boundary အတိအကျမှာ pass — margin ဘာမှ မကျန်ဘူး။

RPO planning အစစ်ဟာ boundary ကို အတိအကျ target ထားတာထက် slack ထည့်ဆောက်ပါတယ်၊ မိနစ်အနည်းငယ် နောက်ကျတဲ့ backup job ဆိုတာ ဖြစ်တတ်တာမို့ပါ။

RPO က data ဘယ်လောက်ပျောက်လို့ ခံနိုင်လဲ သတ်မှတ်ပါတယ် (backup frequency ကို ဆုံးဖြတ်ပေး); RTO က system ဘယ်လောက်မြန်မြန် ပြန်တက်ရမလဲ သတ်မှတ်ပါတယ် (outage response ကို ဆုံးဖြတ်ပေး)။
Test မလုပ်ဖူးတဲ့ backup ဟာ confirm မလုပ်ရသေးတဲ့ ခန့်မှန်းချက်ပါ — ခဏခဏ restore စမ်းတာက backup plan အစစ်ရဲ့ အစိတ်အပိုင်းပါ၊ optional မဟုတ်ပါဘူး။
High availability က single point of failure ကို fail မဖြစ်ခင် ဖယ်ရှားပါတယ်; rollback ဟာ deploy မကောင်းတာကနေ အမြန်ဆုံး recovery ပါ။

Test မလုပ်ဖူးတဲ့ backup ဟာ backup အစစ် မဟုတ်ဘူး

Restore test ကို schedule ချထားပါ။ Restore တစ်ခါမှ မလုပ်ဖူးတဲ့ backup ဟာ ခန့်မှန်းချက်တစ်ခုပါ၊ disaster ဖြစ်တဲ့အချိန်ဟာ ဒါ အလုပ်မလုပ်ဘူးဆိုတာ ရှာတွေ့ရဖို့ အဆိုးဆုံးအချိန်ပါ။

အတူတူ စမ်းရေးကြည့်မယ်

javascript

function meetsRpoTarget(backupIntervalMinutes, rpoTargetMinutes) {
  const meetsTarget = backupIntervalMinutes <= rpoTargetMinutes;
  return {
    backupIntervalMinutes,
    rpoTargetMinutes,
    worstCaseDataLossMinutes: backupIntervalMinutes,
    meetsTarget,
  };
}

const scenarios = [
  { label: "daily backups, RPO 1 hour", interval: 24 * 60, rpo: 60 },
  { label: "every 15 min, RPO 1 hour", interval: 15, rpo: 60 },
  { label: "hourly backups, RPO 1 hour", interval: 60, rpo: 60 },
];

for (const s of scenarios) {
  const result = meetsRpoTarget(s.interval, s.rpo);
  console.log(`${s.label}: ${JSON.stringify(result)}`);
}

You should see

daily backups, RPO 1 hour: {"backupIntervalMinutes":1440,"rpoTargetMinutes":60,"worstCaseDataLossMinutes":1440,"meetsTarget":false}
every 15 min, RPO 1 hour: {"backupIntervalMinutes":15,"rpoTargetMinutes":60,"worstCaseDataLossMinutes":15,"meetsTarget":true}
hourly backups, RPO 1 hour: {"backupIntervalMinutes":60,"rpoTargetMinutes":60,"worstCaseDataLossMinutes":60,"meetsTarget":true}
(output က locale နှစ်ခုစလုံးအတွက် တူညီပါတယ်)

၅ မိနစ် စမ်းကြည့်

Shape တူတူနဲ့ meetsRtoTarget function တစ်ခု ရေးပါ၊ measure လုပ်ထားတဲ့ recovery time နဲ့ RTO target ကို parameter အဖြစ်ယူပါ။ Pass ဖြစ်တဲ့ scenario တစ်ခုနဲ့ fail ဖြစ်တဲ့ scenario တစ်ခုနဲ့ test လုပ်ပါ။

သတိလေးတစ်ချက်

Automated backup ကို တစ်ခါ setup လုပ်ပြီး process က end-to-end အလုပ်ဖြစ်လား confirm လုပ်ဖို့ တစ်ခါမှ restore လက်တွေ့ မလုပ်ဖူးတာ။

Instance တစ်ခုတည်းနဲ့ deployment ကို production-ready လို့ ယူဆထားပြီး၊ ဒီ server တစ်ခုတည်းမှာ ပြဿနာဖြစ်တာနဲ့ app တစ်ခုလုံး ပျောက်သွားတာ။

AWS Well-Architected — Reliability pillar (RPO/RTO) — Cloud & Deployment