ဒီဇိုင်းက docs/architecture/23-ops.md အပိုင်း ၈ ဖြစ်သည်။ ဤက Docker Compose
ထုတ်ကုန်အတွက် လည်ပတ်မှုစာအုပ် ဖြစ်သည်။ ၎င်းကို မရေးသောသူ လိုက်နာရန် ရေးထားသည်။
အဆင့်တစ်ခု မရှင်းပါက၊ ထိုက ဤစာရွက်စာတမ်း၏ချို့ယွင်းချက် ဖြစ်သည်။
ဘာကို ကာကွယ်ထားသနည်း၊ မည်သို့
| ပိုင်ဆိုင်မှု | မည်သို့ | မည်သည့်နေရာ |
|---|---|---|
| ဒေတာဘေ့စ် | WAL ကို စဉ်ဆက်မပြတ် မော်ကွန်းတင်သည်၊ အများဆုံး စက္ကန့် ၆၀ တိုင်း၊ ပထမစတင်မှုကတည်းက | pgwal volume |
| ဒေတာဘေ့စ် | pg_basebackup ဖြင့် အခြေအရန်များ၊ မူလအတိုင်း နေ့စဉ် (backup-scheduler) |
pgbackup volume |
| ဒေတာဘေ့စ် | အခြေအရန်များနှင့် WAL ၏ စာဝှက်မိတ္တူများ၊ ငါးမိနစ်တိုင်း (backup-offsite) |
သင်အမည်ပေးသောသီးခြားသိုလှောင်မှု |
| ဖိုင်များ | files volume။ သင့်အိမ်ရှင်၏အရန်ကိရိယာဖြင့် ကူးပါ၊ သို့မဟုတ် ဗားရှင်းထားသော object သိုလှောင်မှု အသုံးပြုပါ |
files volume |
| လျှို့ဝှက်ချက်များ | docker/.env၊ အထက်၌ QUIRE_MASTER_KEY (အသုံးနေဆဲ မည်သည့် QUIRE_MASTER_KEY_RETIRED မဆို)၊ QUIRE_BACKUP_ENCRYPTION_KEY၊ docker/secrets/audit-signing-key.pem |
ဤအိမ်ရှင်အပြင် မိတ္တူတစ်ခု ထားပါ |
| ရှာဖွေမှုအညွှန်းများ၊ သိမ်းဆည်းမှုများ၊ ပြန်ဖော်ထုတ်မှုများ | အရန်မသိမ်းပါ။ ပြန်တည်ဆောက်သည် |
ပစ်မှတ်များ– ပျက်စီးမှုအပြီး စက္ကန့် ၆၀ အတွင်း ပြန်လည်ရယူမှုအမှတ်၊ 500 GB ဒေတာဘေ့စ်အတွက် မိနစ် ၆၀ အတွင်း ပြန်လည်ဖော်ထုတ်မှု။
အမှားနှစ်ခု အဖြစ်များသည်။ ၎င်း၏ဖိုင်များမပါဘဲ ပြန်လည်ဖော်ထုတ်သောဒေတာဘေ့စ်က
ပျက်နေသောစာမျက်နှာများ ဖော်ပြသည်။ QUIRE_MASTER_KEY မပါဘဲ
ပြန်လည်ဖော်ထုတ်သောဒေတာဘေ့စ် ၎င်းကိုင်သော SSO၊ webhook နှင့် ချိတ်ဆက်မှုအထောက်အထားများ
စာဝှက်ဖြည်၍မရပါ။ မာစတာသော့လှည့်ပြောင်းမှု မဖြေရှင်းရသေးဘာမှမရှိဘဲ ပြီးသည်အထိ
(key-rotation.md)၊ ထိုတွင် အငြိမ်းစားသော့များ ပါဝင်သည်။
နှစ်ခုစလုံး အရန်၏အစိတ်အပိုင်း ဖြစ်သည်။
အရန်များ ယူခြင်း
အစုလိုက်တစ်ခုလုံး၏အခြေအရန်–
docker compose -f docker/compose.yaml --profile backup run --rm backupအသစ်ဆုံး QUIRE_BACKUP_KEEP အခြေအရန်များ (မူလ 5) သိမ်းပြီး အဟောင်းဆုံး မလိုတောသော
WAL ခုတဖြတ်သည်၊ ထို့ကြောင့် မော်ကွန်းက အကန့်အသတ်မရှိ မကြီးနိုင်ပါ။ အိမ်ရှင်တွင် cron
သို့မဟုတ် systemd timer ဖြင့် နေ့စဉ်အချိန်ဇယားဆွဲပါ–
15 2 * * * cd /srv/quire && docker compose -f docker/compose.yaml --profile backup run --rm backup >> /var/log/quire-backup.log 2>&1သို့မဟုတ် အစုကို အချိန်ဇယားဆွဲခိုင်းပါ– backup ပရိုဖိုင်က backup-scheduler
လည်ပတ်သည်၊ QUIRE_BACKUP_INTERVAL_HOURS တိုင်း (မူလ 24) အခြေအရန်တစ်ခု ယူသည်၊
နောက်၌ဖော်ပြမည့် backup-offsite နှင့်။
docker compose -f docker/compose.yaml --profile backup up -dစာဝှက်ထားသောအိမ်ရှင်ပြင်မိတ္တူများ
Volume နှစ်ခုစလုံး ဒေတာဘေ့စ်နှင့် တူညီသောအိမ်ရှင်တွင် နေသည်၊ ပျက်သောစက်ရှိ အရန်က
အရန် မဟုတ်ပါ။ backup-offsite က အခြေအရန်တိုင်းနှင့် မော်ကွန်းတင် WAL အပိုင်းတိုင်းကို
သိုလှောင်မှုပေါက်မှတစ်ဆင့် သီးခြားသိုလှောင်မှုသို့ စာဝှက်လျက် ကူးပြီး၊
ထိန်းသိမ်းမှုအောက်၌ ထိုနေရာတွင် ထားသည်–
- စာဝှက်ခြင်း။
QUIRE_BACKUP_ENCRYPTION_KEYပါသော AES-256-GCM (QUIRE_BACKUP_ENCRYPTION_KEY_FILEအမည်ပေးသောဖိုင် သို့မဟုတ်)– 32 byte၊openssl rand -hex 32မှ။ ဖိုင်တစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင် nonce နှင့် စစ်မှန်ကြောင်းအတည်ပြုတံဆိပ် ပါရှိသည်၊ ထို့ကြောင့် မိတ္တူက သော့မရှိဘဲ ဖတ်၍မရပါ၊ ၎င်းအပေါ် ပြောင်းလဲမှုမဆို တွေ့ရှိသည်။ သော့ကိုQUIRE_MASTER_KEYနှင့် ဤအိမ်ရှင်အဝေး အရန်သိုလှောင်မှုအဝေး ထားပါ။ သော့မရှိပါက ပြန်လည်ဖော်ထုတ်မှု မရှိပါ။ - မည်သည့်နေရာ။
QUIRE_BACKUP_STORAGE_DRIVERကs3၊azureသို့မဟုတ်local(QUIRE_BACKUP_STORAGE_ROOTရှိ တပ်ဆင်ထားသောအဝေးဒစ်ခ်) ဖြစ်သည်။ ဆက်တင်များကQUIRE_BACKUP_ရှေ့ဆက်ပါသော ဖိုင်သိုလှောင်မှုအရာများ ဖြစ်သည်–QUIRE_BACKUP_S3_ENDPOINT၊QUIRE_BACKUP_S3_BUCKET၊QUIRE_BACKUP_S3_ACCESS_KEY_IDစသည်တို့။ မတူသောပုံး၊ ဖြစ်နိုင်ပါက ဖိုင်များနှင့် မတူသောအကောင့်ကို အသုံးပြုပါ၊ ဝန်ဆောင်မှုပေးသူ ခွင့်ပြုပါက ရေးနိုင် ဖျက်၍မရသောအထောက်အထားများနှင့်။ - ထိန်းသိမ်းမှု။ အသစ်ဆုံး
QUIRE_BACKUP_OFFSITE_KEEPအခြေအရန်များ (မူလQUIRE_BACKUP_KEEP၊ မဟုတ်ပါက 7) နှင့် ၎င်းတို့အဟောင်းဆုံး လိုသော WAL။ ဟောင်းသောအစုများနှင့် အပိုင်းများကို သိုလှောင်မှုမှ ဖျက်သည်။ - ဘယ်အချိန်။
QUIRE_BACKUP_SHIP_INTERVAL_SECONDSတိုင်း (မူလ 300)။ ပို့ဆောင်မှုက ထပ်တူညီမှုကင်းသည်– သိမ်းပြီးသားအရာ ကျော်သည်၊ အခြေအရန်က ၎င်း၏ manifest ရေးပြီးမှ၊ နောက်ဆုံး၊ သိမ်းပြီးအဖြစ် ရေတွက်သည်။
တူညီသောအမိန့် ကိုယ်တိုင်လည်ပတ်သည်–
docker compose -f docker/compose.yaml run --rm backup-offsite bun apps/worker/src/backups/main.ts ship
docker compose -f docker/compose.yaml run --rm backup-offsite bun apps/worker/src/backups/main.ts verifyအိမ်ရှင်အသစ်တွင် ပြန်လည်ဖော်ထုတ်ရန် အစုတစ်ခု အရင်ပြန်ယူပါ၊ ထို့နောက် အောက်၌အဆင့်များကို
ယူလာသောလမ်းညွှန်ကို pgbackup volume အစား၊ ယူလာသော wal-archive ကို pgwal
အစား ထားပြီး လိုက်နာပါ–
bun apps/worker/src/backups/main.ts fetch base-20260924T021500Z /srv/restoreအချိန်အမှတ်တစ်ခုသို့ ပြန်လည်ဖော်ထုတ်ခြင်း
ဒေတာဆုံးရှုံးပြီးနောက် ယင်းကို အသုံးပြုပါ– မကောင်းသောတင်သွင်းမှု၊ ဖျက်ခံရသောသင်တန်း၊ ပြန်ဖျက်ရန်လိုသောစာချုပ်ရွှေ့ပြောင်းမှု။ ၎င်းက တိုက်ရိုက်ဒေတာဘေ့စ် အစားထိုးသည်၊ ထို့ကြောင့် အောက်၌လေ့ကျင့်မှုဖြင့် အရင်လေ့ကျင့်ပါ။
- ပစ်မှတ်အချိန် ရွေးပါ၊ UTC ဖြင့်၊ ပျက်စီးမှုမတိုင်မီ–
2026-09-24 09:30:00+00။ စာရင်းစစ်မှတ်တမ်း (/admin/audit) က ပုံမှန်အားဖြင့် အခိုက်ကို ပြသသည်। - ရေးသမျှ အရာအားလုံး ရပ်ပါ–
docker compose -f docker/compose.yaml stop web content worker scheduler collab - ပြန်လည်ဖော်ထုတ်မှု စစ်ဆေးပြီးသည်အထိ ပျက်နေသောအစုကို ဆက်ထားပါ–
docker compose -f docker/compose.yaml stop postgres docker run --rm -v quire_postgres18-data:/from -v quire_postgres-damaged:/to alpine cp -a /from/. /to/ - ပစ်မှတ်ထက် ဟောင်းသောအသစ်ဆုံးအခြေအရန်ကို ဒေတာ volume အတွင်း
ထုပ်ပိုးဖြေပါ၊ ပစ်မှတ်ထားပြန်လည်ရယူမှု တောင်းပါ–
docker run --rm -v quire_pgbackup:/backups:ro -v quire_postgres18-data:/var/lib/postgresql postgres:18-alpine sh -euc ' base="$(ls -1d /backups/base-* | sort | tail -n 1)" # or the one before the target rm -rf /var/lib/postgresql/18/docker && mkdir -p /var/lib/postgresql/18/docker tar -xzf "$base/base.tar.gz" -C /var/lib/postgresql/18/docker touch /var/lib/postgresql/18/docker/recovery.signal chown -R postgres:postgres /var/lib/postgresql/18/docker && chmod 700 /var/lib/postgresql/18/docker' - ပြန်လည်ရယူပါ– Postgres ကို ပြန်လည်ရယူမှုဆက်တင်များဖြင့် တစ်ကြိမ်စတင်ပါ၊
ပုံမှန်ဖိုင် မထိစေရန် Compose လွှမ်းမိုးမှုမှ–
လွှမ်းမိုးမှုက အမိန့်တစ်ခုလုံး အစားထိုးသောကြောင့်၊ ပြန်လည်ရယူမှု မှီခိုသောဆက်တင်နှစ်ခု ထပ်လုပ်သည်– ပင်မထက် မနိမ့်သော# docker/compose.recover.yaml services: postgres: command: [postgres, -c, "restore_command=cp /var/lib/postgresql/wal-archive/%f %p", -c, "recovery_target_time=2026-09-24 09:30:00+00", -c, recovery_target_action=promote, -c, archive_mode=off, -c, max_connections=200, -c, hba_file=/etc/postgresql/pg_hba.conf]max_connections(မဟုတ်ပါက ပြန်လည်ရယူမှု “insufficient parameter settings” ဖြင့် ရပ်သည်) နှင့် တပ်ဆင်ထားသောpg_hba.conf။docker compose -f docker/compose.yaml -f docker/compose.recover.yaml up -d postgres docker compose -f docker/compose.yaml logs -f postgres # wait for "database system is ready" - မည်သူမဆို ဝင်မည့်အလား ၎င်းကို စစ်ဆေးပါ– စာရင်းစစ်ကွင်းဆက် (
docker compose -f docker/compose.yaml run --rm worker bun tooling/audit-verify/run.ts)၊ ဆုံးရှုံးသောဒေတာ ပြန်ရောက်သည်ကို။ - ပုံမှန်သို့ ပြန်သွားပါ–
docker compose -f docker/compose.yaml up -d။ ယင်းက Postgres ကို မော်ကွန်းတင်မှု ဖွင့်လျက် ပြန်လည်စတင်သည်၊ WAL အချိန်ဇယားအသစ် စတင်သည်။ လတ်ဆတ်သောအခြေအရန် ချက်ချင်းယူပါ။
ပရောဂျက်အမည် quire က volume တိုင်းကို ရှေ့ဆက်သည်။ docker volume ls က
အမည်အတိအကျ ပြသသည်။
အချိန်ဇယားဆွဲထားသောစစ်ဆေးလေ့ကျင့်မှု
backup-offsite က QUIRE_BACKUP_DRILL_INTERVAL_HOURS တိုင်း (မူလ 168၊ အပတ်စဉ်)
လေ့ကျင့်မှုတစ်ခုလည်း လည်ပတ်သည်၊ တစ်ခုမအောင်ပြီးနောက် နောက်အကြိမ်တွင် ထပ်လုပ်သည်။
အိမ်ရှင်ပြင်အသစ်ဆုံးအခြေအရန်နှင့် ၎င်းနောက် WAL အပိုင်းတိုင်း ယူလာသည်၊ တစ်ခုစီ
စာဝှက်ဖြည်သည် (သော့ ၎င်းတို့ကို ဖွင့်နေဆဲ မပြောင်းလဲထားကြောင်း သက်သေပြသည်)၊
ဖိုင်တစ်ခုစီ ၎င်း၏ manifest နှင့် နှိုင်းယှဉ်သည်၊ မော်ကွန်းက Postgres ဒေတာလမ်းညွှန်
ဟုတ် စစ်ဆေးသည်၊ အရန်မှစ WAL ကွာဟမှုမရှိ စစ်ဆေးသည်။ အစီရင်ခံစာကို သိုလှောင်မှုသို့
reports/drill-<time>.json အဖြစ်၊ ဝန်ဆောင်မှု၏မှတ်တမ်းသို့ ရေးသည်။
မအောင်သောလေ့ကျင့်မှုက ဖိုင် သို့မဟုတ် ပထမပျောက်နေသောအပိုင်း အမည်ပေးသည်။
ပြန်လည်ဖော်ထုတ်လေ့ကျင့်မှု
ဘယ်တော့မှ ပြန်လည်ဖော်ထုတ်မထားသောအရန်က အရန် မဟုတ်ပါ။ လေ့ကျင့်မှုက ပစ်မှတ်မတိုင်မီ ယူသောအသစ်ဆုံးပြည့်စုံအခြေအရန်၊ WAL မော်ကွန်းနှင့်အတူ၊ တိုက်ရိုက်တစ်ခုနှင့် ဘာမှ မမျှဝေသောအစမ်းသုံး Postgres အဖြစ် ပြန်လည်ဖော်ထုတ်ပြီး ရလဒ် သက်သေပြသည်–
docker/scripts/restore-drill.sh # to ninety minutes ago
docker/scripts/restore-drill.sh --target "2026-09-24 09:30:00+00"ပစ်မှတ်က အတိအကျထိုပုံစံဖြင့် UTC ဖြစ်သည်။ ၎င်းထက် ဟောင်းသောအခြေအရန်နှင့် ၎င်းကျော် မော်ကွန်းတင် WAL လိုအပ်သည်– တပ်ဆင်မှုအသစ်တွင် အခြေအရန်တစ်ခု ယူပြီး အရန်နောက် ပစ်မှတ်ရွေးမည့်အလား နောက်မော်ကွန်းတင်အပိုင်း (ရေးမှုများနှင့် အများဆုံး တစ်မိနစ်) စောင့်ပါ။ လေ့ကျင့်မှုက အိမ်ရှင်တွင် Docker နှင့် bash လိုသည်၊ ဘာမှအခြား မဟုတ်ပါ။
အဆင့်တစ်ခုစီ လေ့ကျင့်မှု မအောင်စေသည်–
- ပြန်လည်ရယူနိုင်မှု– အစမ်းသုံး အစုလိုက် ပစ်မှတ်သို့ ပြန်ဖွင့်ပြီး ပွင့်သည်။
- ပြည့်စုံမှု– တိုက်ရိုက်ဒေတာဘေ့စ်နှင့် ဇယားတိုင်း၏အတန်းအရေအတွက်
(
tooling/restore-drill)။ တိုက်ရိုက်ဒေတာဘေ့စ် ပစ်မှတ်ကတည်းက ရှေ့တိုးပြီးဖြစ်သောကြောင့်၊ ဇယားတစ်ခုက အတန်း ၅၀၀ နှင့် ၎င်း၏အရွယ်အစား၏ဆယ်ပုံတစ်ပုံအနက် ပိုကြီးသည့်ပမာဏ ကွာနိုင်သည်၊ ဦးတည်ချက်နှစ်ဖက်စလုံး (ရေးမှုများ ၎င်းကို နောက်ကျစေသည်၊ ဖျက်မှုများ ပြန်လည်ဖော်ထုတ်မှု ပိုကိုင်စေသည်)။ ပစ်မှတ်နောက် ဖန်တီးသောအပိုင်းက ပျောက်သောဇယား မဟုတ်ပါ။ အလုပ်များသောတပ်ဆင်မှုတွင် ခွင့်ပြုမှုကိုQUIRE_DRILL_MAX_BEHINDနှင့်QUIRE_DRILL_MAX_DRIFT_RATIOဖြင့် ကျယ်စေပါ။ ပျောက်နေသော သို့မဟုတ် အလွတ်ဖြစ်နေသောဇယား မအောင်ပါ။ - ခိုင်မာမှု– စာရင်းစစ် hash ကွင်းဆက် ပြန်လည်ဖော်ထုတ်မိတ္တူတွင် စစ်ဆေးသည်။
- အသုံးပြုနိုင်မှု– အက်ပလီကေးရှင်းအခန်းကဏ္ဍ အတန်းအဆင့်လုံခြုံမှုမှတစ်ဆင့် ဖတ်သည်။
- အချိန်– စတင်မှုမှ စိမ်းမှုအထိ၊
QUIRE_DRILL_RTO_SECONDSနှင့် (မူလ 3600)။
တိုက်ရိုက်ဒေတာဘေ့စ် သို့မဟုတ် ၎င်း၏ volume များ ဘယ်တော့မှ မရေးပါ– အရန်နှင့် WAL volume များ ဖတ်ရန်သာ တပ်ဆင်ထားပြီး အစမ်းသုံး အစုလိုက် အဆုံး၌ ဖယ်ရှားသည်၊ အောင် သို့မဟုတ် မအောင်။
QUIRE_DRILL_REPORT ကို JSON အစီရင်ခံစာ ရေးစေရန် လမ်းကြောင်းတစ်ခု အဖြစ် သတ်မှတ်ပါ၊
အောင် သို့မဟုတ် မအောင်၊ Docker အိမ်ရှင်မှ အချိန်ဇယားဖြင့် လည်ပတ်ပါ–
30 3 1 * * cd /srv/quire && QUIRE_DRILL_REPORT=/var/log/quire-drill.json docker/scripts/restore-drill.sh >> /var/log/quire-drill.log 2>&1လစဉ် အဆင့်မြှင့်မှုတိုင်းမပြုမီ လည်ပတ်ပါ။ မအောင်သောလေ့ကျင့်မှုက အဆင့်မြှင့်မှုကို ပိတ်ဆို့သည်။ သုံးလတစ်ကြိမ် ဤလည်ပတ်မှုစာအုပ် မရေးသောသူတစ်ဦး အပိုအိမ်ရှင်တွင် တကယ့်အချိန်အမှတ်ပြန်လည်ဖော်ထုတ်မှု လုပ်ဆောင်ခိုင်းပါ၊ ဤစာရွက်စာတမ်းသာ အသုံးပြု၍။
ဖိုင်များ
ဒေသခံဖိုင်များ files volume တွင် နေသည်။ ဒေတာဘေ့စ်နှင့် အတူ၊ တစ်ချိန်တည်း
အရန်သိမ်းပါ၊ နှစ်ခုစလုံး အတူ ပြန်လည်ဖော်ထုတ်ပါ–
docker run --rm -v quire_files:/files:ro -v "$PWD":/out alpine tar -czf /out/files-$(date -u +%Y%m%d).tar.gz -C /files .object သိုလှောင်မှုဖြင့် ပုံးဗားရှင်းထား ဖွင့်ပြီး လက်ရှိမဟုတ်သောဗားရှင်းများ ၃၅ ရက် သိမ်းပါ။ ဖိုင်များအတွက် အချိန်အမှတ်ပြန်လည်ရယူမှုက ထို့နောက် ပုံး၏ကိုယ်ပိုင် ဖြစ်သည်။