Рэзервовыя копіі і аварыйнае аднаўленне

# Daily logical dump
pg_dump "$AIHUMMER_DATABASE_URL" --format=custom --file=aihummer-$(date +%F).dump

aihummer backup [dir]      # write a backup into [dir]
aihummer restore <file>    # restore from a backup file

Стан AiHummer невялікі і добра вызначаны, што робіць рэзервовае капіраванне простым — пакуль вы памятаеце, што **майстар-ключ не знаходзіцца ў базе даных** і павінен быць абаронены асобна. Гэтая старонка апісвае, што рэзервіраваць, як і як аднавіць. ## Што рэзервіраваць Існуе тры незалежныя рэчы, якія трэба абараняць: | Што | Дзе | Чаму | |---|---|---| | **База даных** | PostgreSQL | Крыніца праўды — агенты, размовы, памяць, налады, зашыфраваныя сакрэты | | **Blob-аб'екты** | `AIHUMMER_BLOB_DIR` | Медыя і файлавыя ўкладанні, на якія спасылаецца база даных | | **Майстар-ключ** | `AIHUMMER_MASTER_KEY` | Расшыфроўвае сховішча; **ніколі не захоўваецца ў базе даных** | > [!DANGER] > Рэзервіруйце `AIHUMMER_MASTER_KEY` **асобна** і захоўвайце яго недзе, акрамя > дампа базы даных. Сховішча зашыфравана метадам канверта пад гэтым ключом — **страціце > майстар-ключ, і зашыфраваныя сакрэты будуць незваротнымі**, нават з ідэальнай > рэзервовай копіяй базы даных. ## PostgreSQL — крыніца праўды Лічыце базу даных аўтарытэтнай. Рэкамендаваны базавы ўзровень — **штодзённы `pg_dump`** плюс **архіваванне WAL для аднаўлення на момант часу (PITR)**, каб вы маглі пракруціць наперад да любога моманту паміж дампамі. ```bash # Daily logical dump pg_dump "$AIHUMMER_DATABASE_URL" --format=custom --file=aihummer-$(date +%F).dump ``` Спалучайце дампы з бесперапынным архіваваннем WAL (PITR) для дакладнага аднаўлення паміж знімкамі. ## Рэзервовае капіраванне blob-аб'ектаў Медыя і файлавыя ўкладанні знаходзяцца ў `AIHUMMER_BLOB_DIR`. Рэзервіруйце гэты каталог разам з базай даных, каб адноўленыя размовы маглі па-ранейшаму вырашаць свае ўкладанні. Калі `AIHUMMER_BLOB_DIR` не сканфігураваны, сэрвіс медыя/файлаў неактыўны, і няма нічога дадатковага для капіравання. ## Каманды aihummer backup і restore CLI аб'ядноўвае руціну ў дзве каманды: ```bash aihummer backup [dir] # write a backup into [dir] aihummer restore <file> # restore from a backup file ``` Выкарыстоўвайце іх для звычайных аперацыйных рэзервовых копій і аднаўленняў. Гл. [даведнік CLI](/en/v1.0/reference/cli) для адпаведных каманд. > [!WARNING] > Аднаўленне толькі базы даных не з'яўляецца поўным аднаўленнем. Адновіце таксама каталог > blob і пераканайцеся, што **той самы** `AIHUMMER_MASTER_KEY` прысутнічае на мэтавым хосце — > інакш сховішча немагчыма расшыфраваць. ## Аварыйнае аднаўленне Для поўнага сцэнарыя страты хоста выконвайце **рунбук аварыйнага аднаўлення** (`docs/runbooks/disaster-recovery.md`). Парадак аднаўлення: 1. Падрыхтуйце хост і ўсталюйце тую самую версію AiHummer. 2. Адновіце **майстар-ключ** у `AIHUMMER_MASTER_KEY`. 3. Адновіце **базу даных** (апошні дамп, затым пракруціце наперад праз WAL/PITR, калі выкарыстоўваецца). 4. Адновіце **каталог blob** у `AIHUMMER_BLOB_DIR`. 5. Падыміце сэрвісы (`aihummer up`) і праверце праз `/readyz` і `deploy/host/smoke.sh`. > [!TIP] > Таксама захоўвайце `AIHUMMER_MEDIA_TOKEN_SECRET` разам з вашым майстар-ключом. Ён > падтрымлівае сапраўднасць падпісаных URL спампоўкі медыя пры перазапусках і перазборках. ## Куды далей - Пробы і дымавы тэст, які выкарыстоўваецца для праверкі аднаўлення: [systemd і праверкі спраўнасці](/en/v1.0/operations/systemd-health). - Версіянаванне і міграцыі падчас абнаўлення: [Палітыка абнаўлення](/en/v1.0/operations/upgrade-policy).