VPS backup နှင့် ပြန်လည်ရယူနည်းကို စမ်းသပ်ပါ
Backup ကို VPS ပြင်ပမှ ပြန်ယူပြီး မျှော်လင့်ထားသောဖိုင်များ ပြန်ရမှ အသုံးဝင်သည်။ ဒီလေ့ကျင့်ခန်းတွင် static page နှင့် Nginx configuration တစ်ခုကို archive လုပ်၊ အခြားကွန်ပျူတာသို့ ကူးပြီး live website မထိဘဲ ပြန်ရသော bytes ကို စစ်မည်။
VPSuntu · ပြင်ဆင်ရက် · ဖတ်ရန် 7 မိနစ်ခန့်
စာမျက်နှာအကြောင်းအရာ
လေ့ကျင့်ခန်း၏ အတိုင်းအတာကို သတ်မှတ်ပါ
Ubuntu သို့မဟုတ် Linux/WSL client တွင် Bash၊ GNU tar၊ sha256sum နှင့် OpenSSH သုံးပါ။ Server ဟုရေးထားသော command များကို server terminal တစ်ခု၊ client ဟုရေးထားသော command များကို သီးခြားကွန်ပျူတာ၏ terminal တစ်ခုတွင် ရိုက်ပါ။ Variables ကျန်ရန် terminal မပိတ်ပါနှင့်။ Command error တစ်ခုခုရှိလျှင် ရပ်ပါ။
Home directory အောက်တွင် disposable files နှစ်ခုကို သုံးသည်။ Nginx၊ firewall သို့မဟုတ် live content မပြောင်းဘဲ extraction ကို root အဖြစ် မလုပ်ပါ။ အောက်မှ fixtures ဖြင့် စပါ။ Optional အစားထိုးခြင်းသည် static HTTPS လမ်းညွှန် ၏ ဖိုင်နှစ်ခုအတွက်သာဖြစ်သည်။
Site ပိုကြီးလျှင် assets၊ redirects၊ included configuration၊ DNS နှင့် dependencies ကို သီးခြားစာရင်းလုပ်ပါ။ နှစ်ဖိုင်ဥပမာသည် စက်တစ်လုံး သို့မဟုတ် app အပြည့်အစုံ backup မဟုတ်ပါ။
ဝက်ဘ်ဆိုက်မပြောင်းဘဲ စမ်းသပ်ဖိုင်နှစ်ခု လုပ်ပါ
Server တွင် private practice directory လုပ်ပါ။ အောက်ပါ config သည် archive လုပ်ရန်ဖိုင်ဖြစ်ပြီး service အဖြစ် activate မလုပ်ရပါ။
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="en"><title>Restore drill</title><h1>Recovered static page</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Practice directory: %s\n' "$backup_lab"Optional — tutorial ၏ တကယ့် page/server block ကို backup လုပ်လိုလျှင် disposable copies နှစ်ခုကိုသာ အောက်ပါ command ဖြင့် အစားထိုးပါ။ မိမိ account က source နှစ်ခုလုံး ဖတ်နိုင်ရမည်။ Config တွင် secret ရှိသလား အရင်စစ်ပြီး release တူသောဖိုင်များရရန် ကူးနေစဉ် deployment ရပ်ထားပါ။ Fixture သာစမ်းလျှင် ဒီ block ကို ကျော်ပါ။
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"ဤ command များသည် live sources ကို မပြင်ဘဲ ဖတ်ကူးသည်။ Certificate private keys သို့မဟုတ် system directories အားလုံး မကူးပါ။ တကယ့် site အတွက် အပိုဖိုင်လိုလျှင် inventory နှင့် checksum manifest နှစ်ခုလုံးတွင် ရည်ရွယ်ချက်ရှိရှိ ထည့်ပါ။
Archive နှင့် checksum နှစ်ဆင့် ဖန်တီးပါ
Server တွင် ရွေးထားသောဖိုင်များ၏ checksum မှတ်၊ relative paths ဖြင့် archive လုပ်ပြီး archive checksum ထုတ်ပါ။ ဒီအဆင့်တွင် payload ကို မပြောင်းပါနှင့်။
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Server export directory: %s\n' "$backup_lab/export"Listing တွင် site/၊ nginx/၊ ရွေးထားသောဖိုင်နှစ်ခုနှင့် SHA256SUMS ပါရမည်။ Archive checksum က transfer ပြောင်းလဲမှုကို စစ်ပြီး internal manifest က extracted files ကို စစ်သည်။ တစ်ယောက်ယောက်က data နှင့် expected checksum နှစ်ခုလုံးကို အစားထိုးနိုင်လျှင် checksum သည် backup ၏ အစစ်အမှန်ဖြစ်မှုကို မအာမခံပါ။
သီးခြားကွန်ပျူတာသို့ backup ကူးပါ
Client ကွန်ပျူတာတွင် remote_backup ကို server ထုတ်ပြသော export directory အတိအကျ သတ်မှတ်ပါ။ IP၊ account နှင့် key filename ကို အလုပ်လုပ်သော SSH details ဖြင့် အစားထိုးပါ။ 203.0.113.10 သည် documentation address ဖြစ်ပြီး REPLACE သည် placeholder ဖြစ်သည်။ mktemp ထုတ်သော suffix မဟုတ်ပါ။
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"Host အသစ်ကို လက်မခံမီ ယုံကြည်ရသောလမ်းမှ fingerprint အတည်ပြုပါ။ SSH ကြောင့်ကူးမရလျှင် SSH လမ်းညွှန် ကို ဖတ်ပါ။ ကူးရစေရန် host-key checking မပိတ်ပါနှင့်။
SCP က SSH ဖြင့် transfer ကို ကာကွယ်သည်။ tar.gz ဖိုင်ကိုယ်တိုင်သည် compressed ဖြစ်ပြီး encrypted မဟုတ်ပါ။ Destination account/storage ကို ကာကွယ်ပြီး လိုအပ်ပါက encryption at rest သုံးပါ။ VPS တစ်ခုတည်းပေါ်ရှိ directory ဒုတိယတစ်ခုသည် off-server copy မဟုတ်ပါ။
စစ်ပြီး ဖိုင်တွဲအလွတ်အသစ်တွင် restore လုပ်ပါ
Client တွင် archive ကို မဖြည်မီ စစ်ပါ။ sha256sum က OK ပြမှ ဆက်ပါ။ Failure ရှိလျှင် စုံစမ်း သို့မဟုတ် ပြန်ကူးပါ။ ဖုံးကွယ်ရန် expected checksum ကို မပြင်ပါနှင့်။
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"ယုံကြည်ရသော archive ကို ဖိုင်တွဲအသစ်တွင်သာ ဖြည်ပါ။ Keep-old-files က ရှိပြီးသားဖိုင် မအစားထိုးစေဘဲ no-same-owner က archived ownership ကို မယူစေပါ။ Destination ကို / မပြောင်းပါနှင့်၊ sudo ဖြင့် မဖြည်ပါနှင့်။
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"site/index.html နှင့် nginx/first-site.conf နှစ်ခုလုံး OK ဖြစ်ပြီး page heading ပြန်ရရမည်။ File contents ကိုသာ အတည်ပြုသည်။ Production ownership၊ ACLs၊ service availability နှင့် dependencies အားလုံးကို မစစ်ရသေးပါ။
ဖိုင် recovery နှင့် service recovery ကို ခွဲပါ
Restore လုပ်ထားသော config သည် inactive text file သာဖြစ်နေဆဲဖြစ်သည်။ Replacement server သီးခြားတွင် မသုံးမီ paths၊ includes၊ modules၊ permissions နှင့် certificates ကို ပြန်စစ်ပါ။ အဲဒီစက်တွင် assembled Nginx config ကို validate လုပ်ပြီးမှ reload ကာ ပြင်ပ HTTP/HTTPS စမ်းပါ။ မပြောင်းထားသော live server တွင် syntax check လုပ်ခြင်းက ဒီ restore copy ကို မစစ်ပေးပါ။
Archive တွင် TLS private keys ကို ရည်ရွယ်ချက်ရှိရှိ ချန်ထားသည်။ Certificate ပြန်ထုတ်ရန် သို့မဟုတ် သီးခြားကာကွယ်ထားသော backup ကို စီစဉ်ပါ။ Active database files ကို ဒီ tar နည်းဖြင့် မကူးပါနှင့်။ Database က ပံ့ပိုးသော consistent backup/restore ကို သုံးပါ။
Provider snapshots က machine recovery ကို ကူညီနိုင်သော်လည်း retention၊ failure domain နှင့် restore နည်းကို စစ်ပါ။ Snapshot ရှိရုံဖြင့် exported site files ကို replacement host တွင် ပြန်ရကြောင်း မပြပါ။
Recovery ပန်းတိုင်နှင့် ရလဒ်ကို မှတ်ပါ
RPO သည် အချိန်ဖြင့်တိုင်းသော လက်ခံနိုင်သည့် data loss၊ RTO သည် service ပြန်ရရန် ရည်မှန်းအချိန်ဖြစ်သည်။ Static information site ငယ်အတွက် RPO 24 နာရီနှင့် RTO 60 မိနစ် ရွေးနိုင်သည်ဟု ဥပမာပေးထားခြင်းသာဖြစ်ပြီး ဒီလေ့ကျင့်ခန်း၏ တိုင်းတာရလဒ် မဟုတ်ပါ။ နေ့စဉ် backup သည် copy အောင်မြင်ပြီး restore ရမှ ရည်ရွယ်ထားသော schedule ကို ဖြည့်နိုင်သည်။
မျက်နှာပြင်ငယ်တွင် ကော်လံအားလုံးကြည့်ရန် ဇယားကို ဘေးတိုက်ရွှေ့ပါ။
| မှတ်တမ်း | သိနိုင်သောအချက် |
|---|---|
| Backup time နှင့် release ID | ဘယ်ဗားရှင်း ပြန်ရနိုင်သလဲ |
| Independent destination နှင့် retention | ဘယ်နေရာတွင် ဘယ်လောက်ကြာ ကျန်မလဲ |
| Archive/file checksum ရလဒ် | ရွေးထားသော bytes ပြန်ရသလား |
| Restore စ/ဆုံးချိန် | သတ်မှတ်ထားသောအဆင့်များ၏ ကြာချိန် |
| မပါသောဖိုင်၊ permission၊ dependencies | Service ပြန်မတင်မီ လိုသေးသည့်အလုပ် |
| Replacement ပေါ်မှ external HTTPS | ဝက်ဘ်ဆိုက် တကယ်ပြန်ရသလား |
RTO ဖြစ်နိုင်ကြောင်း မယူဆမီ access၊ provisioning၊ configuration၊ certificates နှင့် လိုအပ်လျှင် DNS အပါအဝင် replacement အားလုံးကို အချိန်တိုင်းပါ။ Local extraction မြန်ခြင်းသည် outage-recovery benchmark မဟုတ်ပါ။ Restore points အချို့ ထိန်းပြီး failed backup jobs ကို စစ်ပါ။ Hosting recovery criteria ဖြင့် retention နှင့် restore support ကို နှိုင်းယှဉ်ပါ။
အမေးအဖြေ
Backup စမ်းရန် မူလဝက်ဘ်ဆိုက်ကို ဖျက်သင့်သလား။
ဖျက်ရန်မလိုပါ။ သီးခြား empty directory တွင် restore လုပ်ပြီး manifest စစ်ခြင်းက outage မဖြစ်ဘဲ ဖိုင်မိတ္တူကို စမ်းပေးသည်။ Service အပြည့်ကို သီးခြား replacement environment တွင် စမ်းပါ။
Checksum အောင်မြင်လျှင် site အားလုံး backup ပါပြီလား။
Manifest ထဲက ဖိုင်များကိုသာ အတည်ပြုသည်။ ချန်မိသော asset၊ database၊ secret သို့မဟုတ် DNS setting ကို မရှာပေးနိုင်ပါ။ Inventory ထားပြီး service restore နောက်တွင် တကယ့်လုပ်ဆောင်ချက်များကို စမ်းပါ။