Կրկնօրինակումներ և աղետից վերականգնում
AiHummer-ի վիճակը փոքր է և լավ սահմանված, ինչը կրկնօրինակումները դարձնում է պարզ — քանի դեռ հիշում եք, որ master key-ը տվյալների բազայում չէ և պետք է պաշտպանված լինի առանձին։ Այս էջն ընդգրկում է, թե ինչ կրկնօրինակել, ինչպես, և ինչպես վերականգնել։
Ինչ կրկնօրինակել
Կան երեք անկախ բան, որ պետք է պաշտպանել.
| Ինչ | Որտեղ | Ինչու |
|---|---|---|
| Տվյալների բազա | PostgreSQL | Ճշմարտության աղբյուրը — agent-ներ, զրույցներ, հիշողություն, կարգավորումներ, ծածկագրված secret-ներ |
| Blob-ներ | AIHUMMER_BLOB_DIR |
Մեդիա և ֆայլերի կցորդներ, որոնց հղում է անում տվյալների բազան |
| Master key | AIHUMMER_MASTER_KEY |
Ապակոդավորում է vault-ը. երբեք չի պահվում տվյալների բազայում |
[!DANGER] Կրկնօրինակեք
AIHUMMER_MASTER_KEY-ն առանձին և պահեք այն տվյալների բազայի dump-ից այլ տեղ։ Vault-ը envelope-ծածկագրված է այս բանալու տակ — կորցրեք master key-ը, և ծածկագրված secret-ները անվերականգնելի են, նույնիսկ կատարյալ տվյալների բազայի կրկնօրինակմամբ։
PostgreSQL-ը ճշմարտության աղբյուրն է
Տվյալների բազան դիտեք որպես authoritative։ Առաջարկվող բազայինը ամենօրյա
pg_dump գումարած WAL archiving՝ point-in-time recovery (PITR)-ի համար, որպեսզի կարողանաք
roll forward անել dump-երի միջև ցանկացած պահի։
# Daily logical dump
pg_dump "$AIHUMMER_DATABASE_URL" --format=custom --file=aihummer-$(date +%F).dumpԶուգակցեք dump-երը շարունակական WAL archiving-ի (PITR) հետ՝ snapshot-ների միջև մանրակրկիտ վերականգնման համար։
Blob-ների կրկնօրինակում
Մեդիան և ֆայլերի կցորդներն ապրում են AIHUMMER_BLOB_DIR-ի տակ։ Կրկնօրինակեք այս գրացուցակը
տվյալների բազայի հետ միասին, որպեսզի վերականգնված զրույցները դեռ կարողանան լուծել իրենց
կցորդները։ Եթե AIHUMMER_BLOB_DIR-ը կարգավորված չէ, մեդիա/ֆայլերի ծառայությունը
ակտիվ չէ, և պատճենելու լրացուցիչ ոչինչ չկա։
aihummer backup & restore հրամանները
CLI-ն այս աշխատանքը միավորում է երկու հրամանի մեջ.
aihummer backup [dir] # write a backup into [dir]
aihummer restore <file> # restore from a backup fileՕգտագործեք դրանք սովորական գործառնական կրկնօրինակումների և վերականգնումների համար։ Տես CLI հղում՝ առնչվող հրամանների համար։
[!WARNING] Միայն տվյալների բազայի վերականգնումը լիարժեք վերականգնում չէ։ Վերականգնեք նաև blob գրացուցակը, և համոզվեք, որ նույն
AIHUMMER_MASTER_KEY-ն առկա է թիրախային host-ի վրա — հակառակ դեպքում vault-ը չի կարող ապակոդավորվել։
Աղետից վերականգնում
Host-ի լրիվ կորստի սցենարի համար հետևեք աղետից վերականգնման runbook-ին
(docs/runbooks/disaster-recovery.md)։ Վերականգնման հերթականությունն է.
- Տրամադրեք host և տեղադրեք AiHummer-ի նույն տարբերակը։
- Վերականգնեք master key-ը
AIHUMMER_MASTER_KEY-ի մեջ։ - Վերականգնեք տվյալների բազան (վերջին dump-ը, ապա roll forward WAL/PITR-ով, եթե օգտագործվել է)։
- Վերականգնեք blob գրացուցակը
AIHUMMER_BLOB_DIR-ում։ - Բարձրացրեք ծառայությունները (
aihummer up) և ստուգեք/readyz-ով ևdeploy/host/smoke.sh-ով։
[!TIP] Նաև պահեք
AIHUMMER_MEDIA_TOKEN_SECRET-ը ձեր master key-ի հետ։ Այն պահում է ստորագրված մեդիա ներբեռնման URL-ները վավեր՝ վերագործարկումների և վերակառուցումների ընթացքում։
Ո՞ւր հաջորդիվ
- Probe-ները և smoke test-ը, որ օգտագործվում են վերականգնումը ստուգելու համար. systemd և առողջության ստուգումներ։
- Տարբերակավորում և migration-ներ թարմացման ընթացքում. Թարմացման քաղաքականություն։