---
title: "ການສຳຮາງ, ການຟື້ນຟູຕາມຈຸດເວລາ ແລະ ການຝຶກການກູ້ຄືນ"
description: "ສຳຮາງ Quire, ຟື້ນຟູມັນໄປຫາຈຸດໜຶ່ງໃນເວລາ, ແລະ ພິສູດມັນດ້ວຍການຝຶກການກູ້ຄືນ."
image: "https://docs.quirelms.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/lo/llms.txt
> Use this file to discover all available pages before exploring further.
# ການສຳຮາງ, ການຟື້ນຟູຕາມຈຸດເວລາ ແລະ ການຝຶກການກູ້ຄືນ
ດີຊາຍນແມ່ນ `docs/architecture/23-ops.md` ບົດທີ 8. ນີ້ແມ່ນ runbook
ສຳລັບຜະລິດຕະພັນ Docker Compose. ມັນຖືກຂຽນເພື່ອໃຫ້ຄົນທີ່ບໍ່ໄດ້
ຂຽນມັນດຳເນີນຕາມ; ຖ້າຂັ້ນຕອນໜຶ່ງບໍ່ຊັດເຈນ ນັ້ນແມ່ນຂໍ້ບົກ
ຜ່ອງໃນເອກະສານສະບັບນີ້.
## ສິ່ງທີ່ຖືກປົກປ້ອງ ແລະ ວິທີ
| ຊັບພະຍາກອນ | ວິທີ | ບ່ອນ |
| --- | --- | --- |
| ຖານຂໍ້ມູນ | WAL ຈັດເກັບຕໍ່ເນື່ອງ, ທຸກໆ 60 ວິນາທີສູງສຸດ, ນັບແຕ່ການບູດຄັ້ງທຳອິດ | volume `pgwal` |
| ຖານຂໍ້ມູນ | base backups ດ້ວຍ `pg_basebackup`, ປະຈຳມື້ໂດຍຄ່າເລີ່ມຕົ້ນ (`backup-scheduler`) | volume `pgbackup` |
| ຖານຂໍ້ມູນ | ສຳເນົາທີ່ລະຫັດຂອງ base backups ແລະ WAL, ທຸກໆ 5 ນາທີ (`backup-offsite`) | ຮ້ານເກັບແຍກທີ່ທ່ານຕັ້ງຊື່ |
| ໄຟລ໌ | volume `files`. ຄັດລອກມັນດ້ວຍເຄື່ອງມືສຳຮາງຂອງເຊີບເວີຂອງທ່ານ ຫຼື ໃຊ້ການເກັບ object ທີ່ມີເວີຊັນ | volume `files` |
| ຄວາມລັບ | `docker/.env`, ເໜືອທຸກຢ່າງ `QUIRE_MASTER_KEY` (ແລະ `QUIRE_MASTER_KEY_RETIRED` ໃດໆທີ່ຍັງໃຊ້ຢູ່), `QUIRE_BACKUP_ENCRYPTION_KEY`, ແລະ `docker/secrets/audit-signing-key.pem` | ເກັບສຳເນົາໄວ້ນອກເຊີບເວີນີ້ |
| index ການຄົ້ນຫາ, caches, renditions | ບໍ່ສຳຮາງ; ສ້າງຄືນ | |
ເປົ້າໝາຍ: ຈຸດຟື້ນຟູພາຍໃນ 60 ວິນາທີຂອງຄວາມລົ້ມແຫຼວ, ແລະ
ການຟື້ນຟູພາຍໃນ 60 ນາທີສຳລັບຖານຂໍ້ມູນ 500 GB.
ຄວາມຜິດສອງຢ່າງແມ່ນເລື້ອຍ. ຖານຂໍ້ມູນທີ່ຟື້ນຟູ **ໂດຍບໍ່ມີ
ໄຟລ໌ຂອງມັນ** ສະແດງໜ້າທີ່ຫັກເສຍ. ຖານຂໍ້ມູນທີ່ຟື້ນຟູ
**ໂດຍບໍ່ມີ `QUIRE_MASTER_KEY`** ບໍ່ສາມາດຖອກລະຫັດລະຫັດເຂົ້າ
ເຖິງ SSO, webhook ແລະ ລະຫັດເຂົ້າເຖິງຂອງການເຊື່ອມຕໍ່ທີ່ມັນ
ຖືກໄວ້; ຈົນກວ່າການປ່ຽນ master key ຈະສຳເລັດໂດຍບໍ່ມີຫຍັງ
ຄ້າງ ([key-rotation.md](/lo/ops/key-rotation/)), ນັ້ນລວມທັງກະແຈ
ທີ່ຫຍັກລົບແລ້ວ. ທັງສອງເປັນສ່ວນໜຶ່ງຂອງການສຳຮາງ.
## ການເອົາການສຳຮາງ
base backup ຂອງ cluster ທັງໝົດ:
```sh
docker compose -f docker/compose.yaml --profile backup run --rm backup
```
ມັນຮັກສາ base backups ໃໝ່ສຸດ `QUIRE_BACKUP_KEEP` (ຄ່າເລີ່ມຕົ້ນ 5)
ແລະ ຕັດ WAL ທີ່ base backup ເກົ່າສຸດບໍ່ຕ້ອງການອີກ ດັ່ງນັ້ນ
ສະຖານທີ່ເກັບບໍ່ສາມາດຂະຫຍາຍໂດຍບໍ່ມີຂີດຈຳກັດ. ຕາຕະລາປັບ
ມັນປະຈຳມື້ດ້ວຍ cron ຫຼື systemd timer ຢູ່ເຊີບເວີ:
```cron
15 2 * * * cd /srv/quire && docker compose -f docker/compose.yaml --profile backup run --rm backup >> /var/log/quire-backup.log 2>&1
```
ຫຼືໃຫ້ stack ຕາຕະລາປັບມັນ: profile `backup` ແລ່ນ `backup-scheduler`,
ເຊິ່ງເອົາ base backup ທຸກ `QUIRE_BACKUP_INTERVAL_HOURS`
(ຄ່າເລີ່ມຕົ້ນ 24), ແລະ `backup-offsite` ທີ່ຈະອະທິບາຍຕໍ່ໄປ.
```sh
docker compose -f docker/compose.yaml --profile backup up -d
```
## ສຳເນົານອກເຊີບເວີທີ່ລະຫັດ
volume ທັງສອງຢູ່ເຊີບເວີດຽວກັນກັບຖານຂໍ້ມູນ ແລະການສຳຮາງ
ຢູ່ເຄື່ອງທີ່ລົ້ມແຫຼວບໍ່ແມ່ນການສຳຮາງ. `backup-offsite` ຄັດລອກ
base backup ທຸກໆອັນ ແລະ segment WAL ທີ່ຈັດເກັບທຸກໆອັນໄປຮ້ານ
ເກັບແຍກຜ່ານ storage port, ທີ່ລະຫັດ, ແລະ ເກັບພວກມັນໄວ້
ທີ່ນັ້ນພາຍໃຕ້ retention:
- **ການລະຫັດ.** AES-256-GCM ດ້ວຍ `QUIRE_BACKUP_ENCRYPTION_KEY`
(ຫຼືໄຟລ໌ທີ່ `QUIRE_BACKUP_ENCRYPTION_KEY_FILE` ລະບຸ): 32 ໂບຍ,
ຈາກ `openssl rand -hex 32`. ໄຟລ໌ແຕ່ລະອັນມີ nonce ເອງ
ແລະ authentication tag ຂອງຕົນ ດັ່ງນັ້ນສຳເນົາໜຶ່ງອ່ານ
ບໍ່ໄດ້ໂດຍບໍ່ມີກະແຈ ແລະການປ່ຽນແປງໃດໆກັບມັນຈະຖືກ
ຈັບໄດ້. ເກັບກະແຈໄວ້ກັບ `QUIRE_MASTER_KEY`, ຫ່າງຈາກ
ເຊີບເວີນີ້ ແລະຫ່າງຈາກຮ້ານສຳຮາງ. ໂດຍບໍ່ມີກະແຈບໍ່ມີ
ການຟື້ນຟູ.
- **ບ່ອນໃດ.** `QUIRE_BACKUP_STORAGE_DRIVER` ແມ່ນ `s3`, `azure`
ຫຼື `local` (ດິດທາງໄກທີ່ mount ໄວ້ທີ່
`QUIRE_BACKUP_STORAGE_ROOT`). ການຕັ້ງຄ່າແມ່ນການຕັ້ງຄ່າ
ໄຟລ໌ເກັບພ້ອມປ້າຍເບື້ອງຕົ້ນ `QUIRE_BACKUP_`:
`QUIRE_BACKUP_S3_ENDPOINT`, `QUIRE_BACKUP_S3_BUCKET`,
`QUIRE_BACKUP_S3_ACCESS_KEY_ID`, ແລະອື່ນໆ. ໃຊ້ bucket
ທີ່ແຕກຕ່າງ ແລະໂດຍສະເພາະບັນຊີທີ່ແຕກຕ່າງຈາກໄຟລ໌,
ພ້ອມລະຫັດເຂົ້າເຖິງທີ່ສາມາດຂຽນແຕ່ບໍ່ສາມາດລຶບຖ້າ
ຜູ້ໃຫ້ບໍລິການອະນຸຍາດ.
- **Retention.** base backups ໃໝ່ສຸດ `QUIRE_BACKUP_OFFSITE_KEEP`
(ຄ່າເລີ່ມຕົ້ນ `QUIRE_BACKUP_KEEP`, ບໍ່ແມ່ນດັ່ງນັ້ນ 7) ແລະ
WAL ທີ່ເກົ່າສຸດຂອງພວກມັນຕ້ອງການ; ຊຸດ ແລະ segment
ທີ່ເກົ່າກວ່າຈະຖືກລຶບອອກຈາກຮ້ານເກັບ.
- **ເມື່ອໃດ.** ທຸກ `QUIRE_BACKUP_SHIP_INTERVAL_SECONDS`
(ຄ່າເລີ່ມຕົ້ນ 300). ການຂົນສົ່ງເປັນ idempotent: ສິ່ງທີ່
ເກັບໄວ້ແລ້ວຈະຖືກຂ້າມ, ແລະ base backup ນັບເປັນສຳເລັດ
ແຕ່ເມື່ອ manifest ຂອງມັນຖືກຂຽນແລ້ວ, ສຸດທ້າຍ.
ຄຳສັ່ງດຽວກັນແລ່ນດ້ວຍມື:
```sh
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
```
ເພື່ອຟື້ນຟູໃນເຊີບເວີໃໝ່ ນຳຊຸດກັບມາກ່ອນ, ຈາກນັ້ນດຳເນີນ
ຂັ້ນຕອນຂ້າງລຸ່ມດ້ວຍຟັງເດີທີ່ດຶງມາແທນ volume `pgbackup`
ແລະ `wal-archive` ທີ່ດຶງມາແທນ `pgwal`:
```sh
bun apps/worker/src/backups/main.ts fetch base-20260924T021500Z /srv/restore
```
## ການຟື້ນຟູຕາມຈຸດເວລາ
ໃຊ້ສິ່ງນີ້ຫຼັງຈາກການສູນເສດຂໍ້ມູນ: ການນຳເຂົ້າທີ່ຜິດ,
ຫຼັກສູດທີ່ຖືກລຶບ, ການຍ້າຍ contract ທີ່ທ່ານຕ້ອງການຍົກ
ເລີກ. ມັນແທນຖານຂໍ້ມູນທີ່ເຮັດວຽກຢູ່ ດັ່ງນັ້ນຝຶກມັນ
ດ້ວຍການຝຶກຂ້າງລຸ່ມກ່ອນ.
1. **ເລືອກເວລາເປົ້າໝາຍ**, ໃນ UTC, ກ່ອນຄວາມເສຍຫາຍໜຶ່ງ
ນາທີ: `2026-09-24 09:30:00+00`. ບັນທຶກການກວດກາ (`/admin/audit`)
ມັກຈະສະແດງຈຸດນັ້ນ.
2. **ຢຸດທຸກສິ່ງທີ່ຂຽນ**: `docker compose -f docker/compose.yaml stop web content worker scheduler collab`
3. **ຮັກສາ cluster ທີ່ເສຍຫາຍ** ຈົນກວ່າການຟື້ນຟູຈະຖືກ
ກວດສອບ:
```sh
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/
```
4. **ແກ້ຊຸດ base backup ໃໝ່ສຸດທີ່ເກົ່າກວ່າເວລາເປົ້າມາຍ**
ເຂົ້າ volume ຂໍ້ມູນ ແລະ ຂໍການຟື້ນຟູເປົ້າມາຍ:
```sh
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'
```
5. **ຟື້ນຟູ**: ເລີ່ມ Postgres ໜຶ່ງຄັ້ງດ້ວຍການຕັ້ງຄ່າການ
ຟື້ນຟູ, ຈາກ Compose override ເພື່ອໃຫ້ໄຟລ໌ປົກກະຕິບໍ່ຖືກ
ແຕະ:
```yaml
# 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]
```
Override ແທນທີ່ຄຳສັ່ງທັງໝົດ ດັ່ງນັ້ນມັນຊ້ຳການຕັ້ງຄ່າ
ສອງຢ່າງທີ່ການຟື້ນຟູພັງພາ: `max_connections` ບໍ່ຕ່ຳກວ່າ
ຂອງ primary (ບໍ່ດັ່ງນັ້ນການຟື້ນຟູຈະຍົກເລີກດ້ວຍ
"insufficient parameter settings") ແລະ `pg_hba.conf`
ທີ່ mount ໄວ້.
```sh
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"
```
6. **ກວດສອບມັນ** ກ່ອນທີ່ຈະອະນຸຍາດໃຜເຂົ້າ: ເສັ້ນການ
ກວດກາ (`docker compose -f docker/compose.yaml run --rm worker bun tooling/audit-verify/run.ts`),
ແລະ ວ່າຂໍ້ມູນທີ່ສູນເສດກັບມາແລ້ວ.
7. **ກັບຄືນສະພາບປົກກະຕິ**: `docker compose -f docker/compose.yaml up -d`.
ນີ້ເລີ່ມ Postgres ຄືນພ້ອມການຈັດເກັບເປີດ ແລະ timeline WAL
ໃໝ່ໜຶ່ງເລີ່ມຕົ້ນ. ເອົາ base backup ໃໝ່ທັນທີ.
ຊື່ໂຄງການ `quire` ເປັນປ້າຍເບື້ອງຕົ້ນຂອງແຕ່ລະ volume;
`docker volume ls` ສະແດງຊື່ທີ່ແນ່ນອນ.
## ການຝຶກການກວດສອບຕາມຕາຕະລາ
`backup-offsite` ຍັງແລ່ນການຝຶກທຸກ `QUIRE_BACKUP_DRILL_INTERVAL_HOURS`
(ຄ່າເລີ່ມຕົ້ນ 168, ລາຍອາທິດ), ແລະອີກຄັ້ງໃນການຜ່ານຕໍ່ໄປ
ຫຼັງຈາກໜຶ່ງຄັ້ງລົ້ມແຫຼວ. ມັນດຶງ base backup ນອກເຊີບເວີ
ໃໝ່ສຸດ ແລະ segment WAL ທຸກໆອັນຫຼັງຈາກມັນ, ຖອກລະຫັດ
ແຕ່ລະອັນ (ເຊິ່ງພິສູດວ່າກະແຈຍັງເປີດພວກມັນໄດ້ ແລະບໍ່ມີ
ຫຍັງຖືກດັດແປງ), ປຽບທຽບແຕ່ລະໄຟລ໌ກັບ manifest ຂອງມັນ,
ກວດສອບວ່າສະຖານທີ່ເກັບເປັນ data directory ຂອງ Postgres,
ແລະ ກວດສອບວ່າ WAL ນັບແຕ່ການສຳຮາງເປັນຕົ້ນມາບໍ່ມີຊ່ອງ
ຫວ່າງ. ລາຍງານຖືກຂຽນໄປຮ້ານເກັບເປັນ
`reports/drill-