docs(tasks): restore-elasticsearch-indices-books-vds — books VDS ES stack 33 пуст

Prod incident в репо books: slovo поиск товаров+EPZ лежит. `elasticsearch.kzntsv.site`
отвечает 200 на _cluster/health (green, 0 active shards, 0 docs); source
`elasticold.kzntsv.site` (Windows rollback) — полный набор: epz 820604 /
products 105922 / artmone 2621. Окно поломки 27.05 10:24 → 28.05 13:59, в нём
шла bookva-tenant-cutover-prep (bookva-es stack 37 создавался) — возможный
конфликт.

Playbook в task-файле: forensics (Portainer stack 33 audit + docker volume
inspect) → snapshot restore из kreknin repo если post-25.05 snapshot с
непустыми индексами → иначе reindex повторно по migrate-elasticsearch-to-books-vds
procedure (730MB ~5-10 мин). После — restart 4 consumer'ов.

NEXT_SESSION.md перезаписан, restore поставлен как приоритет 1, carried
items (registry GC, netplan artifacts, board-viewer-build) сохранены.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.tasks/restore-elasticsearch-indices-books-vds.md

@@ -0,0 +1,82 @@
+# restore-elasticsearch-indices-books-vds
+
+## Goal
+
+Восстановить 3 ES индекса (`epz`, `products`, `artmone`) на canonical endpoint `elasticsearch.kzntsv.site` (books VDS, Portainer stack 33). Сейчас target ES пустой → весь поиск в books-app (slovo) сломан (404 `index_not_found_exception` для `epz` и `products`).
+
+## Симптомы (зафиксировано 2026-05-28 ~15:50 MSK)
+
+- `bookva.kzntsv.site/api/products/search?q=...` → 500 `no such index [products]`.
+- `bookva.kzntsv.site/api/epz/search?q=...` → 500 `no such index [epz]`.
+- `books-api` + `books-web` логи (stderr) — десятки `ResponseError: index_not_found_exception` за час.
+- User-facing impact: страница `/epz/search` и поиск товаров в slovo UI не работают.
+
+## Текущее состояние ES endpoint'ов
+
+**Source (Windows host, rollback — не выключен):** `https://elasticold.kzntsv.site/`
+
+```
+index    health docs.count store.size
+artmone  yellow       2621      1.4mb
+epz      yellow     820604    699.7mb
+products yellow     105922     26.6mb
+```
+
+Проверено `curl -u books:<pw> https://elasticold.kzntsv.site/_cat/indices`.
+
+**Target (books VDS, Portainer stack 33, canonical):** `https://elasticsearch.kzntsv.site/`
+
+```
+_cluster/health: status=green, active_primary_shards=0, docs=0
+_cat/indices:    (пусто, ни одного индекса)
+_snapshot/_all:  kreknin fs repo зарегистрирован (location=/snapshots)
+```
+
+ES жив, отвечает 200 на _cluster/health, basicAuth работает. Но **индексов нет вообще** — даже placeholder `read_me` из 25.05 исчез. Значит volume был стёрт ИЛИ контейнер recreate'нут с пустым томом между 25.05 (migration complete, smoke green) и 28.05.
+
+## Когда сломалось
+
+- **2026-05-25:** [`migrate-elasticsearch-to-books-vds`](migrate-elasticsearch-to-books-vds.md) closed. Все 3 индекса reindex'нуты с elasticold на books VDS, consumer configs sed'd `elasticold → elasticsearch`, smoke green.
+- **2026-05-27 10:24 MSK:** books-api / books-web рестартовали (текущий uptime 29h). Это **до** появления ошибок — значит ES опустел уже **после** рестарта, иначе они бы залогировали 404 сразу.
+- **2026-05-28 13:59 MSK** (по UTC в логах) — самая ранняя зафиксированная ошибка `no such index [epz]`. Окно поломки: 27.05 10:24 → 28.05 13:59.
+- В этом окне на books VDS происходила работа `bookva-tenant-cutover-prep` (Step 2 — 9 Portainer stacks created, в т.ч. **bookva-es=37**). Возможная гипотеза — конфликт volume mount'а или случайный delete на slovo ES при подготовке bookva ES. Точная причина — детектить надо на VDS (Portainer audit log + volume listing + container restart history).
+
+## Pointers
+
+- **Migration task** (canonical процедура reindex-from-remote с elasticold на books VDS): [migrate-elasticsearch-to-books-vds.md](migrate-elasticsearch-to-books-vds.md) — playbook применим повторно как есть.
+- **Frozen mappings/settings**: `.scratch/source-mappings.json` + `.scratch/source-settings.json` (от 2026-05-25, source структура не менялась — проверить на свежесть до reindex).
+- **Snapshot repo** на books VDS: `kreknin` (`/snapshots`). Snapshot `pre-migration-2026-05-25` содержал только `read_me` placeholder — **не годится для восстановления** (предмиграционный, до reindex). Полезным может быть kreknin daily snapshot **после** 25.05 если он сохранил полные индексы.
+- **Consumer configs:** уже указывают на `elasticsearch.kzntsv.site` (sed 25.05). После восстановления — никаких config changes, только рестарт consumers (на случай stale connection pool).
+
+## Acceptance
+
+- `curl -u books:<pw> https://elasticsearch.kzntsv.site/_cat/indices` показывает 3 индекса (`epz`/`products`/`artmone`) с doc counts ≈ source: 820604 / 105922 / 2621 (±несколько на дельту со source).
+- `books-api` + `books-web` stderr за 5 минут после рестарта — 0 строк `index_not_found_exception`.
+- Smoke: `https://bookva.kzntsv.site/api/epz/search?q=пушкин&...` → 200 с непустым `rows`.
+- Source `elasticold.kzntsv.site` остаётся live (rollback policy не меняется, как было при оригинальной миграции).
+
+## Подходы (выбрать на месте)
+
+1. **Reindex повторно** — точно та же процедура что 25.05 (см. migrate-elasticsearch-to-books-vds.md Steps 4–6). 730MB, ~5-10 мин. Source доступен и полный.
+2. **Snapshot restore** — если в `kreknin` repo есть свежий snapshot (после 25.05) с непустым `epz`/`products`/`artmone`. Проверить `_snapshot/kreknin/_all?verbose=true`. Быстрее reindex'а, если есть.
+3. **Volume forensics** — параллельно (или до восстановления) посмотреть Portainer stack 33 history + `docker volume inspect /usr/docker/elasticsearch/data` + audit log в Portainer когда менялся stack. Цель — понять что произошло, чтобы оно не повторилось после bookva cutover.
+
+Recommendation: начать с (3) для understanding root cause, дальше (2) если snapshot есть, иначе (1).
+
+## Branch
+
+n/a (admin ops)
+
+## Status
+
+ready
+
+## Where I stopped
+
+(not started — created 2026-05-28 ~16:00 MSK by vitya@books session после диагностики prod-инцидента)
+
+## Next action
+
+См. секцию «Подходы» — старт с volume forensics (Portainer stack 33 history + docker volume inspect), параллельно проверить `_snapshot/kreknin/_all` на наличие post-25.05 snapshot'ов с непустыми индексами. Дальше выбрать между snapshot restore и reindex repeat. Восстановить → smoke от `bookva.kzntsv.site/api/epz/search`.
+
+<!-- created-by: vitya@books-session / 2026-05-28 / trigger: prod slovo поиск товаров+EPZ сломан, ES indices пусты на canonical endpoint -->