Рэзервовае капіраванне і аднаўленне пасля катастроф

# 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 | Крыніца праўды — агенты, размовы, памяць, налады, шыфраваныя сакрэты | | **Кляксы** | `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) для дакладнага аднаўлення паміж здымкамі. Памяць Эйнштэйна таксама захоўваецца ў базы даных: чытальны чалавекам кананічны Markdown`MEMORY.md`) і вектарнае сховішча v2 з'яўляюцца **праекцыі** атрымана з яго, а не з асобных аўтарытэтных крыніц. ## Рэзервовае капіраванне аб'ектаў Медыа і файлавыя ўкладанні знаходзяцца пад `AIHUMMER_BLOB_DIR`Рэзервова капіруйце гэты каталог разам з базай даных, каб адноўленыя размовы маглі па-ранейшаму атрымліваць доступ да сваіх укладаў. `AIHUMMER_BLOB_DIR` не наладжаны, сэрвіс медыя/файлаў не актыўны, і няма нічога лішняга для капіравання. ## Каманды рэзервовага капіравання і аднаўлення aihummer CLI аб'ядноўвае руціну ў два каманды: ```bash aihummer backup [dir] # write a backup into [dir] aihummer restore <file> # restore from a backup file ``` Выкарыстоўвайце гэта для звычайнага аперацыйнага рэзервовага капіравання і аднаўлення. Глядзіце [Даведнік CLI](/be/v1.0/reference/cli) для звязаных каманд. > [!WARNING] > Адна аднаўленне базы дадзеных не з'яўляецца поўным аднаўленнем. Аднавіце таксама дырэкторыю blob. > і пераканайцеся, што **той жа** `AIHUMMER_MASTER_KEY` прысутнічае на мэтавым хосце — > інакш сейф нельга расшыфраваць. ## Аднаўленне пасля катастрофы Для сцэнару поўнай страты хоста, прытрымлівайцеся **кніга па аднаўленні пасля катастрофы** (`docs/runbooks/disaster-recovery.md`). Парадак аднаўлення: 1. Падайце хост і ўсталюйце тую ж версію AiHummer. 2. Аднавіць **голавы ключ** у `AIHUMMER_MASTER_KEY`. 3. Аднавіць **база дадзеных** (апошні дамп, затым аднаўленне праз WAL/PITR, калі выкарыстоўваецца). 4. Аднавіць **каталог блобаў** ў `AIHUMMER_BLOB_DIR`. 5. Аднавіць **канфігурацыя модуля і артэфакты** (наладкі захоўваюцца ў базе дадзеных; аднаўляйце любыя канфігурацыйныя файлы, спецыфічныя для модуля, з вашай рэзервовай копіі. 6. Аднавіць **Файлы памяці Эйнштэйна** — `MEMORY.md` і кананічны Markdown (праекцыя памяці) — у іх каталог (ці дазволіць аднаўленне з база даных). 7. Калі выкарыстоўваецца дапаможны кампанент убудавання, аднавіць **вэктарнае захаванне v2** (ці адбудаваць індэксы з адноўленай базы даных/Markdown) 8. Падняць паслугі`aihummer up`) і праверыць з `/readyz` і `deploy/host/smoke.sh`. > [!TIP] > Таксама трымаць `AIHUMMER_MEDIA_TOKEN_SECRET` з вашым галоўным ключом. Ён застаецца падпісаным > URL для загрузкі медыя дзейнічаюць пасля перазагрузак і перабудаваў. ## Куды далей - Зондавыя пробы і дымовы тэст, якія выкарыстоўваюцца для праверкі аднаўлення: [systemd і праверкі здароўя](/be/v1.0/operations/systemd-health). - Версійнасць і міграцыі падчас абнаўлення: [Палітыка абнаўлення](/be/v1.0/operations/upgrade-policy).