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

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

የሚጠበቀውና እንዴት እንደሚጠበቅ

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

ሁለት ስህተቶች በተደጋጋሚ ይፈጠራሉ። ፋይሎቹ ሳይመለሱ የተመለሰ ውሂብ ጎታ የተሰበሩ ገጾችን ያሳያል። 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

ወይም stackው በራሱ እንዲያቀናጅ ያድርጉ፦ backup profile backup-schedulerን ያስነሳል፤ ይህም በየQUIRE_BACKUP_INTERVAL_HOURS (በነባሪ 24) የመነሻ ምትኬ ይወስዳል፣ ቀጥሎም backup-offsiteን እንደሚከተለው ያስኬዳል።

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

ከአገልጋዩ ውጭ የተመሰጠሩ ቅጂዎች

ሁለቱም ድምጾች ከውሂብ ጎታው ጋር በአንድ አገልጋይ ላይ ናቸው፤ የወደቀው ማሽን ላይ ያለ ምትኬ ምትኬ አይደለም። 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ው በመጨረሻ ከተጻፈ ብቻ እንደተቀመጠ ይቆጠራል።

ተመሳሳይ ትእዛዝ በእጅ ማስኬድ ይቻላል፦

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 ድምጽ ፋንታ በመጠቀም የሚከተሉትን ደረጃዎች ይከተሉ፦

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

ወደ ተወሰነ ጊዜ መመለስ

ይህን ከውሂብ መጥፋት በኋላ ይጠቀሙ፦ ችግር ያለበት 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. የተጎዳውን ክላስተር ያቆዩ፣ መመለሱ እስኪረጋገጥ ድረስ፦

   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. ከዒላማው በፊት የተወሰደውን አዲሱን የመነሻ ምትኬ ወደ ውሂብ ድምጹ ያውጡና የተወሰነ መመለስ ይጠይቁ፦

   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ን አንድ ጊዜ ያስነሱ፦

   # 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 ያካትቱ።

   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 ትክክለኛውን ስም ያሳያል።

የታቀደ የማረጋገጫ ልምምድ

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

የመመለስ ልምምድ

ፈጽሞ ተመልሶ ያልተሞከረ ምትኬ ምትኬ አይደለም። ልምምዱ ከዒላማው በፊት የተወሰደውን አዲሱን ሙሉ የመነሻ ምትኬና WAL ማህደሩን ከቀጥታው Postgres ምንም የማይጋራ ጊዜያዊ 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 ብቻ ያስፈልጋሉ።

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

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 አገልጋዩም በሰዓት መርሐግብር ያስኪዱ፦

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 መመለስ እንዲያካሂድ ያድርጉ።

ፋይሎች

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

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ው ያስተናግዳል።