အက်ပ်ဒေတာဘေ့စ်ကို အရန်သိမ်းနည်း (နှင့် တကယ် ပြန်ရယူနိုင်အောင်)

ဒေတာဘေ့စ်ကို အရန်သိမ်းရန်အတွက် အချိန်ဇယားအလိုက် ဖိုင်တစ်ခုသို့ export လုပ်ပါ (Postgres အတွက် စံ ကိရိယာမှာ pg_dump ဖြစ်ပါတယ်)၊ မိတ္တူများကို ဒေတာဘေ့စ်နှင့် ခွဲခြားထားသော နေရာတွင် သိမ်းပြီး အလွတ်ဒေတာဘေ့စ်တစ်ခုထဲသို့ အကြိမ်ကြိမ် ပြန်ရယူကာ အလုပ်လုပ်ကြောင်း သက်သေပြပါ။ အန္တရာယ်ရှိသော ပြောင်းလဲမှုမတိုင်မီ အပို အရန်တစ်ခု ထပ်သိမ်းပါ။ သင့်ကုဒ် အရန်ဖြစ်စေ GitHub repository ဖြစ်စေ export ဖြစ်စေ ဒေတာကို မပါဝင်ပါ။

ဤလမ်းညွှန်သည် ဆုံးရှုံးမှု စိုးရိမ်ရမည့်အပြင် သေးငယ်သော အက်ပ် လုပ်ဆောင်သူများအတွက် ဖြစ်ပါတယ်။ AI ဖြင့် တည်ဆောက်သော အက်ပ်အများစုက Postgres သုံးသဖြင့် ဥပမာများအတွက် Postgres ကို အသုံးပြုထားသော်လည်း နိယာမများသည် ဒေတာဘေ့စ်အမျိုးအစားအားလုံးနှင့် သက်ဆိုင်ပါတယ်။

အရန်ဖိုင်တွင် ဘာတွေ ပါရမလဲ

အက်ပ်တစ်ခုသည် ဒေတာဘေ့စ်ထက် ပိုကြီးပါသည်။ အရန်တစ်ခုစီက ဘာကို ကာကွယ်ပေးသလဲ သိထားပါ။

ပြန်ဖန်တီး၍ မရနိုင်သော အပိုင်းမှာ ဒေတာ ဖြစ်ပါတယ်။ ကုဒ်ကို ပြန်ရေးနိုင်ပြီး settings များကို ပြန်ထည့်နိုင်ပါတယ်။ သို့သော် သင့်ဖောက်သည်များ၏ မှာယူမှုများကို ပြန်ဖန်တီး၍ မရပါ။

အဆင့် ၁ - ဘယ်လောက် ဆုံးရှုံးနိုင်သလဲ ဆုံးဖြတ်ပါ

မေးခွန်း နှစ်ခုက အရန်အစီအစဉ်ကို သတ်မှတ်ပေးပါတယ်-

• နောက်ဆုံး ဒေတာ ဘယ်လောက် ဆုံးရှုံးနိုင်သလဲ? တစ်နေ့ တစ်ကြိမ် အရန်သိမ်းပြီး ညနေမှာ ဒေတာဘေ့စ် ပျက်သွားရင် ထိုနေ့ ပြောင်းလဲမှုများ ဆုံးရှုံးပါမယ်။ ဝါသနာအတွက် အက်ပ်အတွက် ဒါက ရပါတယ်။ အမှာစာများ လက်ခံနေသော အက်ပ်အတွက်တော့ မရနိုင်ပါ။
• ပြန်ရယူနေစဉ် အက်ပ် ဘယ်လောက်ကြာ ရပ်နေနိုင်သလဲ? သေးငယ်သော ဒေတာဘေ့စ်ကို မိနစ်အနည်းငယ်အတွင်း ပြန်ရယူနိုင်ပါတယ်။ ကြီးမားသော ဒေတာဘေ့စ်ဆိုရင် ပိုကြာနိုင်ပါတယ်။ လိုအပ်လာမှ မသိရအောင် ကြိုသိထားပါ။

သေးငယ်သော အက်ပ်အများစုအတွက် နေ့စဉ် အလိုအလျောက် အရန်သိမ်းခြင်းနှင့် အန္တရာယ်ရှိသော ပြောင်းလဲမှုမတိုင်မီ လက်ဖြင့် အရန်တစ်ခု ထပ်သိမ်းခြင်းသည် သင့်တော်သော စတင်နည်း ဖြစ်ပါတယ်။ ငွေကြေး သို့မဟုတ် ကျန်းမာရေး အချက်အလက် ပါဝင်သော အက်ပ်များသည် ပိုမကြာခဏ အရန်သိမ်းခြင်း သို့မဟုတ် point-in-time recovery (နောက်ဆုံး အရန်သို့သာမက မည်သည့် အချိန်ကိုမဆို ပြန်ရယူနိုင်ခြင်း) ပါသော managed ဒေတာဘေ့စ် လိုအပ်ပါသည်။

အဆင့် ၂ - host က ဘာလုပ်ပေးပြီးသားလဲ စစ်ပါ

managed ဒေတာဘေ့စ် provider အများအပြားက အလိုအလျောက် အရန်သိမ်းပေးပါတယ်။ အောက်ပါတို့ကို ရှာကြည့်ပါ-

• သင့် plan အတွက် အရန်သိမ်းခြင်း ဖွင့်ထားလား၊ ဘယ်လောက်ကြာကြာ လုပ်သလား?
• ဘယ်လောက်ကြာကြာ သိမ်းထားလဲ?
• point in time သို့ ပြန်ရယူနိုင်လား၊ သို့မဟုတ် နေ့စဉ် snapshot သို့သာ ရလား?
• အရန်ဖိုင်ကို ဒေါင်းလုဒ်ဆွဲနိုင်လား၊ သို့မဟုတ် သူတို့စနစ်အတွင်းမှာသာ ပြန်ရယူနိုင်လား?

provider ၏ အရန်များသည် အသုံးဝင်ပါသည်။ သို့သော် ၎င်းတို့သည် သင့်ဒေတာဘေ့စ်နှင့် တူညီသော single point of failure ရှိပါသည်။ ဆိုလိုသည်မှာ account ပါ။ account ပိတ်ခံရလျှင်၊ ရပ်ဆိုင်းခံရလျှင် သို့မဟုတ် project ဖျက်ခံရလျှင် အရန်များလည်း ပါသွားနိုင်ပါတယ်။ ထို့ကြောင့် သင့်ကိုယ်ပိုင် မိတ္တူတစ်ခု ထားရှိဖို့ လိုပါတယ်။

အဆင့် ၃ - pg_dump ဖြင့် dump လုပ်ပါ

pg_dump သည် Postgres ဒေတာဘေ့စ်ကို ဖိုင်တစ်ခုသို့ export လုပ်ပါတယ်။ ၎င်းသည် တသမတ်တည်းဖြစ်သော snapshot ကို ဖတ်ပါသဖြင့် အက်ပ်သည် အလုပ်လုပ်နေစဉ်တွင် ဆက်လည်း ပြေးနေနိုင်ပါတယ်။

သင့်အက်ပ်တွင် environment variable အနေဖြင့် ရှိပြီးသား connection string ကို အသုံးပြု၍ ပုံမှန် command တစ်ခုမှာ-

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

option များ၏ အလုပ်လုပ်ပုံ-

• --format=custom သည် pg_restore ဖတ်နိုင်သော ချုံ့ဖိုင်ကို ရေးပြီး နောက်မှ ဇယားတစ်ခုချင်းစီကို ပြန်ရယူခွင့် ပေးပါတယ်။ ဖတ်ရလွယ်သော .sql ဖိုင် လိုချင်ပါက --format=plain ကို သုံးပါ။
• --no-owner သည် ownership command များကို ဖယ်ထုတ်ပေးပြီး မတူညီသော ဒေတာဘေ့စ်ထဲသို့ ပြန်ထည့်ရာတွင် ပိုလွယ်ကူစေပါတယ်။
• ဖိုင်နာမည်ထဲရှိ ရက်စွဲက အရန်များကို ခွဲခြားပေးပါတယ်။

pg_dump ဗားရှင်းသည် သင့်ဒေတာဘေ့စ်၏ Postgres ဗားရှင်းနှင့် တူညီရမည် သို့မဟုတ် ပိုသစ်ရမည်ဖြစ်ပါတယ်။ ပိုဟောင်းသော pg_dump သည် အလုပ်မလုပ်ဘဲ ငြင်းဆိုနိုင်ပါတယ်။

AI ဖြင့် တည်ဆောက်ပြီး command line ကို မထိချင်ပါက အောက်ပါအတိုင်း မေးနိုင်ပါတယ်-

pg_dump ကို custom format ဖြင့် အက်ပ်ဒေတာဘေ့စ်၏ အရန်ကို ဖန်တီးပါ၊ ဖိုင်နာမည်တွင် ဒီနေ့ရက်စွဲ ပါစေပါ။ connection string သို့မဟုတ် လျှို့ဝှက်ချက်တစ်ခုခုကို မပြပါနဲ့။ ပြီးသွားရင် ဖိုင်နာမည်နှင့် အရွယ်အစားကို ပြောပြပါ။

အဆင့် ၄ - အလိုအလျောက် လုပ်ပါ

လက်ဖြင့် အရန်သိမ်းခြင်းကို မကြာခဏ မေ့သွားတတ်ပါတယ်။ သင့် setup က ပံ့ပိုးသော နည်းလမ်းဖြင့် အလိုအလျောက် လုပ်ပါ-

• သင့် ဒေတာဘေ့စ် provider ၏ အချိန်ဇယားအလိုက် အရန်များ၊ ပံ့ပိုးပေးပါက။
• scheduled job တစ်ခု၊ server သို့မဟုတ် CI service ပေါ်တွင် pg_dump ကို run ပြီး ဖိုင်ကို storage သို့ upload လုပ်ခြင်း။
• hosted backup service တစ်ခု၊ သင့်ဒေတာဘေ့စ်သို့ ချိတ်ဆက်ပေးသော။

မည်သည့်နည်းကို ရွေးချယ်သည်ဖြစ်စေ အရန်သိမ်းခြင်း မအောင်မြင်ပါက သင့်ကို အကြောင်းကြားအောင် လုပ်ပါ။ အရန် job တစ်ခုသည် သုံးလကြာအောင် တိတ်တဆိတ် မအောင်မြင်နေခြင်းသည် ကျော်ကြားသော ဆိုးရွားသည့် ဇာတ်လမ်း ဖြစ်ပါတယ်။

အဆင့် ၅ - မတူညီသော နေရာတွင် မိတ္တူထားပါ

3-2-1 စည်းမျဉ်းအဖြစ် မကြာခဏ ခေါ်ကြပါတယ်။ ဒေတာ မိတ္တူ သုံးခု၊ storage အမျိုးအစား နှစ်မျိုးပေါ်တွင်၊ မိတ္တူ တစ်ခုသည် site ပြင်ပတွင် ရှိရမည်။ သေးငယ်သော အက်ပ်အတွက် လက်တွေ့ဆန်သော ပုံစံမှာ-

• live ဒေတာဘေ့စ်
• provider ၏ကိုယ်ပိုင် အလိုအလျောက် အရန်များ
• သင့်ကိုယ်ပိုင် dump များကို အခြား account ရှိ object storage bucket ကဲ့သို့ သီးခြား storage တွင်

ထို့အပြင်-

• ဝင်ရောက်ခွင့် ကန့်သတ်ပါ။ အရန်တွင် အသုံးပြုသူ အားလုံး၏ ဒေတာ ပါဝင်ပါတယ်။ live ဒေတာဘေ့စ်ကဲ့သို့ ဆက်ဆံပါ။
• retention မူဝါဒ ထားပါ။ ဥပမာ နေ့စဉ် အရန်များကို ရက်ပေါင်း ၁၄ ရက်၊ လစဉ် အရန်များကို တစ်နှစ်။ ဟောင်းသော အရန်များကို ရည်ရွယ်ချက်ရှိရှိ ဖျက်ပါ၊ နှင့် ပုဂ္ဂိုလ်ရေးဆိုင်ရာ ဒေတာကို တောင်းဆိုသည့်အခါ ဖျက်ရန် ပုဂ္ဂိုလ်ရေးဥပဒေများက လိုအပ်နိုင်ကြောင်း မမေ့ပါနဲ့။
• အရန်များကို Git တွင် ဘယ်တော့မှ commit မလုပ်ပါနဲ့။ repository ထဲရှိ dump သည် ဒေတာ ယိုဖိတ်မှု စောင့်နေတဲ့ အန္တရာယ် ဖြစ်ပါတယ်။

အဆင့် ၆ - ပြန်ရယူခြင်းကို စမ်းသပ်ပါ

အရန်တစ်ခုသည် နောက်ဆုံး အောင်မြင်သော ပြန်ရယူမှုနှင့်သာ တန်ဖိုးရှိပါတယ်။ အနည်းဆုံး ရက်အနည်းငယ်အတွင်း၊ နှင့် backup process ပြောင်းလဲပြီးတိုင်း-

1. အသစ်၊ အလွတ် ဒေတာဘေ့စ်တစ်ခု ဖန်တီးပါ။ စမ်းသပ်ရန် live ဒေတာဘေ့စ်ပေါ် ဘယ်တော့မှ ပြန်မထည့်ပါနဲ့။
2. နောက်ဆုံး အရန်ကို ထိုဒေတာဘေ့စ်ထဲ ပြန်ထည့်ပါ-

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

.sql ရိုးရိုး ဖိုင်အတွက် ၎င်းအစား psql "$TEST_DATABASE_URL" -f backup.sql ကို သုံးပါ။

1. ဇယားအားလုံး ရှိမရှိ စစ်ပါ၊ live ဒေတာဘေ့စ်နှင့် row အရေအတွက်များကို နှိုင်းယှဉ်ပြီး နောက်ဆုံး record အချို့ကို ကြည့်ပါ။
2. နိုင်လျှင် အက်ပ်ကော်ပီတစ်ခုကို ထိုဒေတာဘေ့စ်သို့ ညွှန်ပြပြီး login ဝင်ကြည့်ပါ။
3. ပြန်ရယူချိန်ကို မှတ်ထားပါ။ ၎င်းသည် သင့်ရဲ့ အမှန်တကယ် ပြန်ထူထောင်ချိန် ဖြစ်ပါတယ်။

အဆင့် ၇ - အန္တရာယ်ရှိသော ပြောင်းလဲမှုမတိုင်မီ အရန်သိမ်းပါ

အောက်ပါတို့မတိုင်မီ အသစ်တစ်ကြိမ် အရန်သိမ်းပါ-

• ကော်လံများကို ဖျက်ခြင်း သို့မဟုတ် နာမည်ပြောင်းခြင်း ပါသော ဒေတာဘေ့စ် migration ကို run ခြင်း
• ဒေတာကို အစုလိုက် import လုပ်ခြင်း
• AI agent အား data model ကို ကြီးမားစွာ ပြောင်းခွင့်ပေးခြင်း
• ဟောင်းသော record များကို ဖျက်ခြင်း

AI ဖြင့် တည်ဆောက်သော အက်ပ်တွင် agent သည် feature တစ်ခု၏ အစိတ်အပိုင်းအနေဖြင့် ဇယားဖွဲ့စည်းပုံကို ပြောင်းနိုင်ပါတယ်။ Checkpoint နှင့် version control များက ကုဒ်ကို ပြန်ပြောင်းပေးနိုင်သော်လည်း ဖျက်ပြီးသား row များကို ပြန်မပေါ်စေပါ။ ကြီးမားသော ပြောင်းလဲမှုမတိုင်မီ စက္ကန့် ၃၀ အရန်သိမ်းခြင်းသည် စျေးသက်သာသော အာမခံ ဖြစ်ပါတယ်။

အဖြစ်များသော အမှားများ

• Git သို့မဟုတ် ကုဒ် export ကို အရန်ဟု ယူဆခြင်း။ ၎င်းတွင် ကုဒ်ပါပြီး ဒေတာ မပါပါ။
• ပြန်ရယူခြင်းကို တစ်ခါမှ မစမ်းခြင်း။ အရန်များစွာသည် လိုအပ်မှသာ အလွတ်၊ မပြည့်စုံ သို့မဟုတ် ဖတ်မရဖြစ်နေတတ်ပါတယ်။
• အရန်များကို ဒေတာဘေ့စ်နှင့် account တူညီသည့်နေရာတွင် ထားခြင်း။ account တစ်ခုတည်း ပျက်စီး သို့မဟုတ် ပိတ်ခံရလျှင် နှစ်ခုလုံး ဆုံးရှုံးပါမည်။
• တင်ထားသော ဖိုင်များကို မေ့ခြင်း။ ဒေတာဘေ့စ်က ဖိုင်၏ path ကိုသာ သိမ်းထားပြီး ပုံသည် storage ထဲတွင် ရှိပါတယ်။
• အရန် script များထဲတွင် လျှို့ဝှက်ချက်များ ထားခြင်း။ connection string ကို script စာသားထဲမှ မဖတ်ဘဲ environment variable မှ ဖတ်ပါ။ API key များကို ဘေးကင်းစွာ သိမ်းနည်း ကို ကြည့်ပါ။

အရန်သိမ်းခြင်းနှင့် Mythex

Mythex ပရောဂျက်များတွင် သီးသန့် Postgres ဒေတာဘေ့စ် ရှိနိုင်ပြီး ၎င်း၏ connection အချက်အလက်များကို workspace နှင့် ထုတ်ဝေထားသော အက်ပ်သို့ inject လုပ်ပေးပါတယ်။ Mythex docs တွင် ဒေတာဘေ့စ် အရန်သိမ်း/ပြန်ရယူ feature ကို ဖော်ပြထားခြင်း မရှိသဖြင့် သင့်ကိုယ်ပိုင် အစီအစဉ် ရေးဆွဲပါ။ agent ကို dump တစ်ခု ပြုလုပ်ရန် ပြောပြီး ဒေါင်းလုဒ်ဆွဲကာ လုံခြုံသော နေရာတွင် သိမ်းပါ၊ အထူးသဖြင့် ကြီးမားသော ပြောင်းလဲမှုမတိုင်မီ။ ပရောဂျက် export (Pro) တွင် ကုဒ်ပါပြီး လျှို့ဝှက်ချက်များနှင့် node_modules ကို ချန်ထားပါတယ်။ ဒေတာဘေ့စ် row များ မပါဝင်ပါ။ docs ရှိ Database နှင့် Data ownership ကို ကြည့်ပါ။ ဒေတာဘေ့စ်အကြောင်း နောက်ထပ် သိလိုပါက Postgres ဆိုတာ ဘာလဲ ကို ဖတ်ပါ။

အရန်သိမ်းခြင်း စစ်ဆေးစာရင်း

• ဘယ်လောက် ဒေတာဆုံးရှုံးနိုင်လဲ နှင့် ဘယ်လောက်ကြာ ရပ်နေနိုင်လဲ ဆုံးဖြတ်ပြီး
• ဒေတာဘေ့စ် host က ပေးသော အလိုအလျောက် အရန်များကို စစ်ဆေးပြီး
• ကိုယ်ပိုင် dump ကို အချိန်ဇယားအလိုက် run ပြီး ပျက်ကွက်ပါက အကြောင်းကြားသည်
• မိတ္တူများကို ဒေတာဘေ့စ်နှင့် သီးခြား၊ ဝင်ခွင့် ကန့်သတ်ထားသော နေရာတွင် သိမ်းထားပြီး
• retention မူဝါဒကို ရေးမှတ်ထားပြီး
• တင်ထားသော ဖိုင်များကိုလည်း အရန်သိမ်းပြီး
• အလွတ် ဒေတာဘေ့စ်သို့ ပြန်ရယူခြင်းကို စမ်းသပ်ပြီး row အရေအတွက်များ စစ်ပြီး
• ကြီးမားသော ပြောင်းလဲမှုတိုင်းမတိုင်မီ အရန်သိမ်းပြီး

မေးခွန်းများ