---
title: "ምትኬ፣ በጊዜ ወደ ኋላ መመለስ እና የrestore ልምምድ"
description: "የQuire ምትኬ ይውሰዱ፣ ወደ ተወሰነ ጊዜ ይመልሱት፣ በrestore ልምምዱም ያረጋግጡ።"
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/am/llms.txt
> Use this file to discover all available pages before exploring further.

# ምትኬ፣ በጊዜ ወደ ኋላ መመለስ እና የrestore ልምምድ

<span id="backup-point-in-time-recovery-and-the-restore-drill"></span>

ንድፉ በ`docs/architecture/23-ops.md` ክፍል 8 ውስጥ ነው። ይህ ለDocker Compose ምርት የስራ መመሪያ ነው። ያልጻፈው ሰው እንዲከተለው ተዘጋጅቷል፤ ደረጃ ግልጽ ካልሆነ የዚህ ሰነድ ጉድለት ነው።

## የሚጠበቀውና እንዴት እንደሚጠበቅ <!--quire:what-is-protected-and-how-->

| ንብረት | ዘዴ | ቦታ |
| --- | --- | --- |
| ውሂብ ጎታ | ከመጀመሪያው ማስነሻ ጀምሮ WAL በየ60 ሰከንዱ ቢበዛ በቀጣይነት ይቀመጣል | `pgwal` ድምጽ |
| ውሂብ ጎታ | በነባሪ በየቀኑ በ`pg_basebackup` የመነሻ ምትኬ፤ (`backup-scheduler`) | `pgbackup` ድምጽ |
| ውሂብ ጎታ | የመነሻ ምትኬና WAL በየ5 ደቂቃው የሚወሰዱ የተመሰጠሩ ቅጂዎች (`backup-offsite`) | እርስዎ የሰየሙት የተለየ ማከማቻ |
| ፋይሎች | `files` ድምጹን በአገልጋይዎ ምትኬ መሣሪያ ይቅዱ ወይም ስሪት የሚይዝ የobject storage ይጠቀሙ | `files` ድምጽ |
| ሚስጥሮች | `docker/.env`፣ በተለይ `QUIRE_MASTER_KEY` (አሁንም በጥቅም ላይ ካሉ የ`QUIRE_MASTER_KEY_RETIRED` ቁልፎች)፣ `QUIRE_BACKUP_ENCRYPTION_KEY` እና `docker/secrets/audit-signing-key.pem` | ከዚህ አገልጋይ ውጭ ቅጂ ያቆዩ |
| የፍለጋ ኢንዴክሶች፣ cacheዎች፣ የፋይል ቅጂዎች | ምትኬ አይወሰድም፤ እንደገና ይገነባሉ | |

ዓላማው ከመውደቁ በ60 ሰከንድ ውስጥ ያለ የማገገሚያ ነጥብ፣ እና 500 GB ውሂብ ጎታን በ60 ደቂቃ ውስጥ መመለስ ነው።

ሁለት ስህተቶች በተደጋጋሚ ይፈጠራሉ። **ፋይሎቹ ሳይመለሱ** የተመለሰ ውሂብ ጎታ የተሰበሩ ገጾችን ያሳያል። **`QUIRE_MASTER_KEY` ሳይመለስ** የተመለሰ ውሂብ ጎታ ያለበትን የSSO፣ የwebhookና የውህደት ምስክርነቶች መፍታት አይችልም፤ ከቁልፍ ማሽከርከሩ ምንም ያልተፈታ ሳይቀር እስኪጠናቀቅ ድረስ ([key-rotation.md](/am/ops/key-rotation/)) የተወገዱ ቁልፎችም ያስፈልጋሉ። ሁለቱም የምትኬው አካል ናቸው።

## ምትኬ መውሰድ <!--quire:taking-backups-->

የሙሉ ክላስተሩ መነሻ ምትኬ፦

```sh
docker compose -f docker/compose.yaml --profile backup run --rm backup
```

አዲሶቹን `QUIRE_BACKUP_KEEP` የመነሻ ምትኬዎች (በነባሪ 5) ያቆያል፤ ከእንግዲህ የማያስፈልገውን አሮጌ WAL ይሰርዛል፣ ስለዚህ መዝገቡ ያለገደብ አያድግም። በአገልጋዩ ላይ በ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ው በራሱ እንዲያቀናጅ ያድርጉ፦ `backup` profile `backup-scheduler`ን ያስነሳል፤ ይህም በየ`QUIRE_BACKUP_INTERVAL_HOURS` (በነባሪ 24) የመነሻ ምትኬ ይወስዳል፣ ቀጥሎም `backup-offsite`ን እንደሚከተለው ያስኬዳል።

```sh
docker compose -f docker/compose.yaml --profile backup up -d
```

## ከአገልጋዩ ውጭ የተመሰጠሩ ቅጂዎች <!--quire:encrypted-off-host-copies-->

ሁለቱም ድምጾች ከውሂብ ጎታው ጋር በአንድ አገልጋይ ላይ ናቸው፤ የወደቀው ማሽን ላይ ያለ ምትኬ ምትኬ አይደለም። `backup-offsite` እያንዳንዱን የመነሻ ምትኬና የተቀመጠ 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` እሴት ይይዛል (ከርቀት የተገናኘ ዲስክ በ`QUIRE_BACKUP_STORAGE_ROOT`)። ቅንብሮቹ የፋይል ማከማቻ ቅንብሮች በ`QUIRE_BACKUP_` ቅድመ ቅጥያ ናቸው፦ `QUIRE_BACKUP_S3_ENDPOINT`፣ `QUIRE_BACKUP_S3_BUCKET`፣ `QUIRE_BACKUP_S3_ACCESS_KEY_ID` ወዘተ። ከፋይሎቹ የተለየ bucket፣ ከተቻለም የተለየ account ይጠቀሙ፤ አቅራቢው ከፈቀደ መጻፍ የሚችሉ ግን መሰረዝ የማይችሉ ምስክርነቶችን ይምረጡ።
- **የማቆያ ጊዜ።** አዲሶቹ `QUIRE_BACKUP_OFFSITE_KEEP` መነሻ ምትኬዎች (ነባሪው `QUIRE_BACKUP_KEEP` ከተቀመጠ፣ ካልሆነ 7) እና ከአሮጌው የሚያስፈልገው WAL ይቀመጣሉ፤ አሮጌ ስብስቦችና ክፍሎች ከማከማቻው ይሰረዛሉ።
- **መቼ እንደሚላክ።** በየ`QUIRE_BACKUP_SHIP_INTERVAL_SECONDS` (ነባሪ 300)። መላኩ idempotent ነው፤ ቀድሞ የተቀመጠው ይዘለላል፣ የመነሻ ምትኬም 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
```

በአዲስ አገልጋይ ለመመለስ መጀመሪያ የምትኬ ስብስቡን ያመጡ። ከዚያ `pgbackup` ድምጽ ፋንታ ያመጡትን ማውጫ፣ እንዲሁም ያመጡትን `wal-archive` በ`pgwal` ድምጽ ፋንታ በመጠቀም የሚከተሉትን ደረጃዎች ይከተሉ፦

```sh
bun apps/worker/src/backups/main.ts fetch base-20260924T021500Z /srv/restore
```

## ወደ ተወሰነ ጊዜ መመለስ <!--quire:restoring-to-a-point-in-time-->

ይህን ከውሂብ መጥፋት በኋላ ይጠቀሙ፦ ችግር ያለበት import፣ የተሰረዘ ኮርስ ወይም መመለስ የሚያስፈልግ contract migration። ይህ በቀጥታ የሚሰራውን ውሂብ ጎታ ይተካል፤ ስለዚህ መጀመሪያ ከታች ባለው ልምምድ ይሞክሩት።

1. **የዒላማ ጊዜውን** ጉዳቱ ከመከሰቱ ትንሽ በፊት በUTC ይምረጡ፦ `2026-09-24 09:30:00+00`። የaudit መዝገቡ (`/admin/audit`) ብዙውን ጊዜ ያንን ጊዜ ያሳያል።
2. **መጻፍ የሚያደርጉትን ሁሉ ያቁሙ፦** `docker compose -f docker/compose.yaml stop web content worker scheduler collab`
3. **የተጎዳውን ክላስተር ያቆዩ፣** መመለሱ እስኪረጋገጥ ድረስ፦
   ```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. **ከዒላማው በፊት የተወሰደውን አዲሱን የመነሻ ምትኬ** ወደ ውሂብ ድምጹ ያውጡና የተወሰነ መመለስ ይጠይቁ፦
   ```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. **መመለስ፦** መደበኛውን ፋይል እንዳይቀይሩ፣ ከCompose override የመመለሻ ቅንብሮች ጋር Postgresን አንድ ጊዜ ያስነሱ፦
   ```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 ሙሉውን command ይተካል፤ ስለዚህ ለመመለስ የሚያስፈልጉትን ሁለት ቅንብሮች እንደገና ያካትቱ፦ `max_connections` ከዋናው አገልጋይ እሴት ያነሰ መሆን የለበትም (ካልሆነ መመለሱ "insufficient parameter settings" በሚል ስህተት ይቆማል)፣ የተገጠመውንም `pg_hba.conf` ያካትቱ።
   ```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. **ያረጋግጡ**፣ ማንንም ከማስገባትዎ በፊት፦ audit chain (`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ን WAL ማስቀመጥ እንደገና በማብራት ያስነሳል፣ አዲስ WAL timelineም ይጀምራል። ወዲያውኑ አዲስ የመነሻ ምትኬ ይውሰዱ።

የፕሮጀክቱ `quire` ስም በእያንዳንዱ ድምጽ ስም ቅድሚያ ይጨመራል፤ `docker volume ls` ትክክለኛውን ስም ያሳያል።

## የታቀደ የማረጋገጫ ልምምድ <!--quire:the-scheduled-verification-drill-->
`backup-offsite` በየ`QUIRE_BACKUP_DRILL_INTERVAL_HOURS` (በነባሪ 168፣ በየሳምንቱ) የማረጋገጫ ልምምድ ያካሂዳል፤ ካልተሳካ በሚቀጥለው ዙር እንደገና ይሞክራል። ከአገልጋዩ ውጭ ያለውን አዲስ የመነሻ ምትኬና ከእሱ በኋላ ያሉትን WAL ክፍሎች ሁሉ ያመጣልና ይፈታቸዋል (ቁልፉ መክፈት እንደሚችልና ምንም እንዳልተቀየረ ያረጋግጣል)፤ እያንዳንዱን ፋይል ከmanifest ጋር ያነጻጽራል፣ archiveው የPostgres ውሂብ ማውጫ መሆኑንና ከምትኬው በኋላ በWAL ውስጥ ክፍተት አለመኖሩን ይፈትሻል። ሪፖርቱን `reports/drill-<time>.json` ስም በማድረግ ማከማቻውና የአገልግሎቱ ሎግ ውስጥ ይጽፋል፤ ካልተሳካ ፋይሉን ወይም መጀመሪያ የጎደለውን ክፍል ይጠቅሳል።


## የመመለስ ልምምድ <!--quire:the-restore-drill-->

ፈጽሞ ተመልሶ ያልተሞከረ ምትኬ ምትኬ አይደለም። ልምምዱ ከዒላማው በፊት የተወሰደውን አዲሱን ሙሉ የመነሻ ምትኬና WAL ማህደሩን ከቀጥታው Postgres ምንም የማይጋራ ጊዜያዊ Postgres ውስጥ ይመልሳል፣ ውጤቱንም ያረጋግጣል፦

```sh
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 ብቻ ያስፈልጋሉ።

ከዚህ በታች ያሉት ደረጃዎች ሁሉ መሳካት አለባቸው፦

1. **መመለስ መቻል፦** ጊዜያዊው cluster WALን እስከ ዒላማው ድረስ በድጋሚ ተጫውቶ ይከፈታል።
2. **ሙሉነት፦** የእያንዳንዱን ሰንጠረዥ ረድፍ ብዛት ከቀጥታው ውሂብ ጎታ ጋር ያነጻጽራል (`tooling/restore-drill`)። ቀጥታው ውሂብ ጎታ ከዒላማው በኋላ ስለተቀየረ፣ በሁለቱም አቅጣጫ ከ500 ረድፎች ወይም ከሰንጠረዡ መጠን አንድ አስረኛ ከሚበልጠው መጠን ጋር የሚመጣ ልዩነት ሊኖር ይችላል (ጽሁፎች እየጨመሩ ከሆነ የተመለሰው ይዘገያል፣ ስረዛዎች ካሉ ግን የተመለሰው ተጨማሪ ረድፎች ሊይዝ ይችላል)፤ ከዒላማው በኋላ የተፈጠረ partition የጠፋ ሰንጠረዥ አይደለም። በበዛ ጭነት `QUIRE_DRILL_MAX_BEHIND` እና `QUIRE_DRILL_MAX_DRIFT_RATIO` በመጠቀም የሚፈቀደውን ልዩነት ያስፋፉ። የጎደለ ወይም ባዶ ሰንጠረዥ ስህተት ነው።
3. **ታማኝነት፦** በተመለሰው ቅጂ ላይ የaudit hash chain ያልተነካ መሆኑ ይረጋገጣል።
4. **ጥቅም ላይ መዋል፦** application role በrow-level security በኩል ማንበብ ይችላል።
5. **ጊዜ፦** ከመጀመሪያ እስከ ስኬት ያለው ጊዜን ከ`QUIRE_DRILL_RTO_SECONDS` (በነባሪ 3600) ጋር ያነጻጽሩ።

ይህ ልምምድ በቀጥታ የሚሰራው ውሂብ ጎታ ወይም ድምጾቹ ላይ ምንም አይጽፍም፦ የምትኬና WAL ድምጾቹ ለማንበብ ብቻ ይገጠማሉ፣ ጊዜያዊው clusterም በመጨረሻ ይሰረዛል (ስኬትም ሆነ ስህተት)።

JSON ሪፖርት ለማስጻፍ `QUIRE_DRILL_REPORT`ን ወደ ፋይል መንገድ ያቀናብሩ፣ ከDocker አገልጋዩም በሰዓት መርሐግብር ያስኪዱ፦

```cron
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
```

በየወሩና ከእያንዳንዱ ማሻሻያ በፊት ያስኪዱት። ልምምዱ ካልተሳካ ማሻሻያው ይቆማል። በየሩብ ዓመቱ ይህን የስራ መመሪያ ያልጻፈ ሰው በተጠባባቂ አገልጋይ ላይ ይህን ሰነድ ብቻ በመጠቀም እውነተኛ የpoint-in-time መመለስ እንዲያካሂድ ያድርጉ።

## ፋይሎች <!--quire:files-->

የአካባቢ ፋይሎች `files` ድምጽ ውስጥ ናቸው። ከውሂብ ጎታው ጋር አንድ ጊዜ ምትኬ ይውሰዱና ሁለቱንም አብረው ይመልሱ፦

```sh
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 storage ሲጠቀሙ bucket versioningን ያብሩና የአሁን ያልሆኑ ስሪቶችን 35 ቀን ያቆዩ፤ ከዚያ የፋይሎች point-in-time መመለስን bucketው ያስተናግዳል።

Source: https://docs.quirelms.com/am/ops/backup-restore/index.mdx