WEB board

[GATE-14 + §15.4-5] Бэкап-контур и immutable candidate: WAL-G+restic, /data-контракт, restore-drill, RPO/RTO — ⚠️ НУЖНО OWNER-РЕШЕНИЕ по нормативу

## Суть одной фразой
Бэкап-контур (Hetzner Storage Box) + immutable + подтверждённые RPO/RTO против целей владельца 5 мин / 15 мин.

## Где мы сейчас (13.09.2026)
Контур стоит, Hetzner основной (owner 27.08). RPO-гейт partial-публикации закрыт 01.09 (hetzbkfix3); restore-drill сделан (RTO ~20 мин). Но замер 04.09: точка ~24 мин позади (цель RPO 5), распаковка 14.5 мин (цель RTO 15) — цели НЕ подтверждены. Immutable-свойство НЕ доказано: Storage Box = SFTP, перезаписываем; Object Lock есть только у отдельного Object Storage — нужно owner-решение.

## Хронология
Контур gate14bk (21.08) → Hetzner primary (owner 27.08) → живое учение 01.09 (RTO ~20 мин) → hetzbkfix3, RPO-гейт закрыт 01.09 → 04.09 репетиция вскрыла 2 дефекта (ретенция удаляет свежий релиз; каденция манифеста vs WAL) → мойки 12.09/13.09 (3631).

## Карта документов и кода
/usr/local/libexec/hetzbk-*; отчёты GATE14BK, HETZBK*; брифы 1775 (ретенция), 1776 (каденция); память hetzner-primary-backup-decision.

## Остаток
- Перепрогон репетиции со свежим замером RPO/RTO (rehearsal-<run-id>.json) — волна/координатор (⛔ прод A2).
- Immutable — решение владельца (владелец).
- Приёмка 1775 (ретенция) не заведена — координатор.
- 1776 (каденция манифеста) не завершена — координатор.

## Критерий закрытия
Свежий прогон rpo_seconds ≤ 300 / rto_total ≤ 900 + immutable закрыт решением владельца + 1775 GO + 1776 завершена.
---
_история_ — прежний текст тела (до 13.09.2026) координатор сохраняет ниже этой строки без изменений (append-only по WEB-449).

---

## история (тело до 13.09.2026)

НЕ НАЧАТО + КОНФЛИКТ НОРМАТИВА: R4 требует Hetzner Object Storage (off-provider, Object Lock), owner 20.08 сказал «пока без Хетцнера, третья копия = Малинка». По R4 закрыть Gate 14 малинкой НЕЛЬЗЯ (Pi вне RTO и не независимый провайдер в смысле R4). ВОПРОС OWNER (один): (а) вернуть Hetzner (~5-10 евро/мес) и закрыть гейт по нормативу, или (б) официально изменить R4 (принять слабее: OCI Object Storage + Pi-копия) и переподтвердить у аудитора. ПОСЛЕ решения: WAL-G base+WAL, restic файлов, /data-контракт (RequiresMountsFor), canary-транзакция+измеренный лаг, restore-drill на чистом хосте с измеренными RPO/RTO, immutable candidate.

Эпик: WEB-282. Норматив: PROD-MIGRATION-PLAN-R4.md §7. Аудит-срез: M4 MIGAUDIT-REPORT.md (20.08). Owner 20.08: «по гейтам дожимайте все до конца».

## 21.08 ~09:40 РЕПЕТИЦИЯ ПЕРЕЕЗДА ВЫПОЛНЕНА (волна gate514, отчёт A1 ~/waves/GATE514-REPORT.md, расписки в receipts/)
ИЗМЕРЕННЫЕ ВРЕМЕНА (реальные, на A1, NVMe):
- развёртывание кандидата от sha-проверки артефакта до первого 200 /api/health: 12.06 с (распаковка 18322 файлов 4.44 с, 115 миграций 3.87 с, ожидание health 3.02 с);
- вход в приложение: 0.42 с;
- RESTORE БД (авария dropdb → приложение отдаёт восстановленные данные): 5.94 с; чистый RTO БД-части (createdb+extensions+pg_restore -j4): 2.45 с;
- RESTORE при реалистичном объёме (635 MB, 500 000 строк): 22.05 с (≈29 MB/с, ≈23 000 строк/с);
- RESTORE файлов 253 MB / 8 медиа с холодным кэшем: 3.84 с (sha-сверка 2.73 с);
- ОТКАТ релиза (переключение симлинка + рестарт): 3.53 с; накат обратно: 6.03 с;
- пересборка отсутствующего релиза из исходников (худший случай): 663 с (11 мин), из них next build 600 с.
ВЫВОД ПО RTO: цель R4 ≤4 ч выполняется с гигантским запасом ПРИ УСЛОВИИ, что артефакт и дамп на месте; худший сценарий (нет собранного релиза) — 11 минут на пересборку.
⚠️ НО: гейт НЕ закрыт — репетиция вскрыла P0 WEB-091 (миграции не поднимают боевую БД с нуля: gating по имени БД + расхождение схемы). До его починки честный restore на ЧИСТОМ хосте невозможен.

## 21.08 — ГЕЙТ 14 СДАН: КОНТУР ПОСТРОЕН, ВОССТАНОВЛЕНИЕ ДОКАЗАНО, ПОРОГИ ВЛАДЕЛЬЦА ПЕРЕКРЫТЫ
Волна `gate14bk` (A1), отчёт `/home/ubuntu/waves/GATE14BK-REPORT.md` (42 КБ), ветка `gate14bk` от `landing30b`. Прод на Pi не тронут, всё на `127.0.0.1`.
Контур **применён на A1**: отдельный архивирующий кластер PostgreSQL на порту 5440, непрерывный WAL-архив в два яруса, restic для файлового контура, расписание на systemd, ретенция с проверкой после каждой чистки. Кандидат релиза запечатан неизменяемым.

### Замеры против утверждённых владельцем порогов
| порог владельца | требование | измерено | запас |
|---|---|---|---|
| `RPO_target` | ≤ 5 минут | **60 с** максимум потери | ×5 |
| `RTO_same_artifact` | ≤ 15 минут | БД **8.50 с** (278 МБ) + файлы **1.82 с** | ×87 |
| `RTO_rebuild_required` | ≤ 1 час | **11 мин** (замер gate514) | ×5.4 |
| `PITR tested` | YES | **пройден, 1.93 с** на произвольную точку | — |
| потери файлов | 0 | restic 395 МБ / 11 файлов: расхождений **0**, пропавших **0** | — |

**Ключевое для гейта:** боевая БД собирается **с нуля** на починенных миграциях — `nc_prod_gate14bk`, **118 из 118** миграций за 3.35 с (полная провизия 4.13 с). Это ровно та дыра (WEB-091), из-за которой гейт был красным.
Прочее из расписок: архивация WAL-сегмента 16 МБ — среднее **0.130 с**, сжатие zstd-3 **672 МБ → 58 МБ (11.6×)**, отказов архивации за всю волну **0** (`pg_stat_archiver.failed_count=0`); базовый бэкап 278 МБ — 8.75 с / 25 МБ.

### Два бага нашёл собственный верификатор контура, не человек
1. архиватор писал сегменты, которые верификатор потом **не мог прочитать**;
2. ретенция подрезала WAL, **нужный ещё живому бэкапу**.
Оба починены внутри волны. Это ровно то, ради чего мы требуем негативные тесты: 16 проверок в четырёх группах отработали как надо.

### Честные оговорки волны (не прятать при чтении)
- **wal-g поставить не удалось — с A1 закрыт доступ к GitHub.** Контур построен на штатных средствах PostgreSQL за тем же командным интерфейсом; переключение на wal-g — правка одной строки. (Смежное: с A1 режется и прямой OpenAI — ходим через прокси на M1; тот же класс сетевого ограничения.)
- Дельта-бэкапов нет, каждый базовый — полный.
- **Учения на A1, не на Pi**: числа сняты на NVMe ненагруженного хоста, на Pi (SD/USB) будут заметно хуже, коэффициент не измерен.
- **Восстановление ни разу не гонялось руками по рунбуку** — только скриптами. Человек под настоящей аварией медленнее: реальный RTO выше измеренного.
- `CREATE EXTENSION` требует superuser — не баг, но обязан быть в рунбуке переезда.

### ⚠️ Развилка, ждёт решения владельца (отправлена, id=12618)
Копии лежат **на том же диске**, что и база: от порчи данных и кривой миграции защищают, от потери машины — нет.
- **Вариант 1 — Hetzner Storage Box 1 ТБ, ~€4/мес** (цену с A1 подтвердить не смогли). Код не меняется — одна строка конфига. RPO остаётся 60 с, RTO растёт на скачивание: БД ~15 с вместо 8.5, файлы ~26 с вместо 1.8. Взамен переживаем потерю машины.
- **Вариант 2 — не платить и записать норматив честно**: потерю машины не переживаем; при смерти диска копии умирают вместе с ним, данные пользователей теряются навсегда.
Рекомендация волны и координатора — **вариант 1**.

## 2026-08-23 BOARDSWEEP: STALE-NOT-DEPLOYED
- Evidence: buildFixed is empty. Board body still requires an owner decision on RPO/RTO/restore norm; no production candidate/build pointer is present. No restore or destructive operation run.
- buildFixed: <empty>; canonical: v4-081ff4fb5 / 081ff4fb5f6110f8001daec7ed910ccef2e395dc.
- Status preserved by sweep: review.

[01.09 15:40Z] ЖИВОЕ УЧЕНИЕ ВОССТАНОВЛЕНИЯ (координатор, A1): полный цикл Hetzner→sha→gpg→base verify→WAL replay→promote→сверка данных ПРОШЁЛ. Восстановленная точка = base 14:01Z + WAL манифеста 14:13Z (LSN 1/34000000). Сверка: Users 18=18, Sources 1947=1947, MessageLog 6610 (прод 6640, дельта после точки — норм). RTO факт: ~20 мин чистыми (данные 876с + старт ~3 мин). НАЙДЕНО 5 дыр рестора (root/pg_ctl, Debian-split конфигов, валидация target-LSN, known_hosts, RPO: публикуются только полные 16МБ сегменты → RPO НЕ ОГРАНИЧЕН на тихом проде, цель 5 мин нарушена) — волна 980-hetzbkfix2 в очереди. Гейт «restore-drill сделан» — ЗАКРЫТ, гейт «RPO 5 мин» — открыт до фикса partial-публикации.

[01.09 16:20Z] hetzbkfix2 применён и ОТКАЧЕН: на живом WAL нашлись два дефекта поверх фикстур — (1) pg_receivewal преаллоцирует .partial до 16МБ → size-условие publish мертво; (2) после правки координатора verify_wal_partial падает FATAL на реальном magic (13D1) и роняет ВЕСЬ пайплайн в рестарт-цикл. Откат на .bak-20260901 за 8 минут, WAL-стрим стабилен (RPO-гейт снова открыт). Корректирующий круг 984-hetzbkfix3 поставлен с живыми фактами + требование реальной 16МБ-фикстуры и warn-not-fatal. Урок в копилку «fixture-green ≠ польза».

[01.09 16:45Z] RPO-ГЕЙТ ЗАКРЫТ живым прогоном: hetzbkfix3 применён (magic 13D1 по факту, mtime-сигнал, warn-not-fatal), стрим стабилен, «WAL partial committed segment=…3A snapshot_bytes=16777216 fill_signal=mtime» — на Hetzner две immutable-генерации с шагом 241с + атомарный .latest. RPO теперь ≤ ~5 мин (240с интервал + публикация). Итог гейтов WEB-082: restore-drill ✅ (RTO ~20мин), RPO ✅; остаток: immutable-свойство хранилища (sftp-объекты перезаписываемы владельцем ключа) + опционально drill из partial. Бэкапы l82-скриптов сохранены (.bak-20260901).

## ЭВОЛЮЦИЯ 04.09.2026 (карта для нулевого агента)
**Якорь прода:** живая линия **l103**, коммит **d91ebefe740ae83484c1de16710f2e6a68610432**, флип **13:51Z 04.09**. Раньше в этот же день: l101 `d825eb0d`, l102 `1b081c5a`. Ветка линии в репозитории-базе `/home/ubuntu/nc` на A1: `l103-line` (проверено `git branch -a --contains d91ebefe...` → `l103-line`).
**Доска:** живая доска — `web-board.sqlite` + HTTP API `http://127.0.0.1:8787/api/web/*` на M1 (`ssh poolpooly@192.168.1.74`). НЕ `board.sqlite` (это iOS/легаси, таблицы `issues`/`ios_issues`, 2225 строк, ключи другие).

### СЕЙЧАС (связь с WEB-470)
Гейты WEB-082 упираются в два дефекта самого бэкап-контура, вскрытых 04.09 в ходе репетиции — подробный разбор с доказательствами в [[WEB-470]], здесь только суть, чтобы нулевой агент не искал.

1. **Ретенция артефактов удаляет свежий релиз.** `/usr/local/libexec/hetzbk-publish-artifact:96` сортирует релизы `LC_ALL=C sort -r`, опираясь на комментарий строки 85 «Release IDs are intentionally timestamp-first in the runbook», тогда как реальные id — line-first (`l102-1b081c5a`). Итог в логе: `ARTIFACT retention removed release_id=l102-1b081c5a keep=5` сразу после успешной публикации, вместе с `rm .../ready`, `rm .../att-build.json`, `rm .../artifact.tar.gz.sha256`, `rm .../artifact.tar.gz`, `rmdir .../l102-1b081c5a`. Волна `1775-hetzbkretention` завершена 14:36:21Z, приёмки нет.
2. **Каденция манифеста против каденции WAL.** `FATAL rc=96 WAL manifest has a gap before latest archive end at segment 000000010000000300000023` при том, что сегменты …22/…23/…24 есть и на хранилище, и в `manifest-20260904T141231Z/manifest.tsv`. Манифесты — раз в час (10:12, 11:13, 12:13, 13:12, 14:12), WAL — каждые 3–4 минуты. Решение owner: цель восстановления брать из манифеста + участить публикацию манифеста. Волна `1776-manifestcadence` идёт.

### ЧТО ЭТО МЕНЯЕТ ДЛЯ ГЕЙТОВ
Ранее записанный в этом тикете вывод «restore-drill ✅ (RTO ~20 мин), RPO ✅» надо считать неподтверждённым до перепрогона: замер 04.09 дал ближайшую восстановимую точку ~24 минуты позади и 14.5 минуты только на распаковку базы. Цели owner (RPO 5 / RTO 15) НЕ выполнены.

### СЛЕДУЮЩЕЕ ДЕЙСТВИЕ
Не закрывать гейт RPO/RTO по старым цифрам. После приёмки 1775 и завершения 1776 — полный перепрогон репетиции с новым замером, и только тогда правка вердикта гейтов.

### ЛОВУШКА
Immutable-свойство хранилища так и не доказано (sftp-объекты перезаписываемы владельцем ключа) — этот остаток из тела тикета всё ещё в силе и от сегодняшних правок не закрывается.

[2026-08-25 ~02:00] Backup 1.7GB прерван (диск A1 дошёл до 91%, ENOSPC-риск). КОРЕНЬ роста: ДВА wal-g backup-push параллельно (607973+612611 — запустил дважды из-за timeout-в-фон, конкурировали за канал+диск). Оба убиты. Тестовые данные удалены (nc_prod_realtest + prod-dump.dump), archive_mode off на gate14bk. Диск 90% стабилен. ЗАМЕР-ВЫВОД (качественный, достаточный): маленький 32MB backup 45с; большой 1.7GB упирается в канал A1→Hetzner ~0.4MB/s (>75мин, не долетел) — узкое место для больших первичных backup за океан; но RPO держит непрерывный WAL (мелкие сегменты быстрые). Урок: не запускать backup-push дважды (проверять завершение предыдущего фона).

[2026-08-25 ~02:00] Сейф Hetzner вычищен и перепроверен: в /home/walg-nc лежало 4.1G тестовых артефактов (1.9G обрывки базовых бэкапов от двух убитых параллельных push + 2.3G WAL тестовой прокачки); wal-g delete garbage их не увидел (частичные аплоады не считает мусором) → удалены вручную rm -rf basebackups_005 wal_005 (только тестовые данные, по решению owner «чистая база на Oracle»). Контрольный backup-push стенда gate14bk после чистки: 50с, base_000000010000000100000000 в списке, сейф 7.4M — труба жива. Замер полного цикла на стенде остаётся: 32MB туда 45-50с / fetch+restore обратно 43с. Большой 1.7GB замер снят с повестки (тест-данные удалены, прод поедет чистой базой T-0). Owner уведомлён (tg 13311).

[2026-08-25 ~02:30] ПОПРАВКА к выводу об узком месте: голый замер канала A1↔Hetzner файлом 100МБ — UP 9.0с / DOWN 9.6с ≈ 11 МБ/с в обе стороны. Канал НЕ узкое место (1.7ГБ ≈ 3 мин); ночные ~0.4МБ/с были следствием ДВУХ параллельных wal-g push (соревновались за канал/диск). RTO-порог 15 мин каналом не ломается. Owner задал вопрос о расхождении замеров (голос 23:05) — отвечено tg 13315, поправка tg 13316. Большой тест повторяется: дамп 1.27ГБ сохранился на Pi /tmp/prod-dump.dump, перекачка Pi→A1 запущена (релей, фон), далее: restore в тест-кластер → ОДИН wal-g push с секундомером → fetch обратно с секундомером → удалить тест-данные.

[2026-08-25 ~08:00] БОЛЬШОЙ ЗАМЕР ЗАВЕРШЁН (bigtest3, лог A1 /home/ubuntu/bigtest3.log): кластер gate14bk с тестовой базой 1.65ГБ → tar 2.86ГБ (28.8с) → UPLOAD в Hetzner Storage Box 2м39с → DOWNLOAD обратно 2м37с (~18 МБ/с оба направления) → sha256 roundtrip СОШЁЛСЯ → полная чистка (tar-ы, тест-БД nc_prod_realtest dropped, файл в сейфе удалён), диск A1 90%. Вердикт против порогов owner (RPO 5м/RTO 15м): скачивание из сейфа 2.86ГБ = 2м37с + локальный restore минуты → RTO влезает с запасом; RPO держит WAL-архив. ⚠️ НАХОДКА-класс: wal-g v3 по SFTP ДВАЖДЫ завис на длинном потоке (TCP Send-Q замирает после обрыва, процесс висит вечно; bigtest STEP2 и bigtest2 оба убиты) — прямой scp стабилен. Для боевого сейфа: S3-протокол (Hetzner Object Storage + Object Lock, ~€5/мес — ждёт кнопки owner) или scp-обёртка вместо wal-g storage-слоя; wal-g оставить для WAL-сегментов (мелкие, летают). История отказов: ночь — двойной запуск push (ENOSPC), утро — зависание sftp после UFW-блокировок ssh.

[2026-08-25 ~10:50] СЕЙФ ДОУКОМПЛЕКТОВАН до полного (вопрос owner «в финском только база, не весь проект?» — был прав): в Hetzner /home/app-artifact/ уложены (за 15с): точный прод-артефакт me2-standalone-linux-arm64-0ac410ac0-20260824T172813Z.tar.gz (171918327Б, sha-файл+манифест рядом, источник A1 wt-l40/.next/artifacts), RESURRECTION-RUNBOOK.md (шаги воскрешения с нуля: хост→wal-g fetch БД→распаковка артефакта→конфиг→server.js→health paidReady), CONFIG-TEMPLATE.txt (ИМЕНА env-ключей из боевого drop-in БЕЗ значений — секреты в сейф не кладём до Object Lock), SHA256SUMS.safe. Теперь AWS-репетиция честная: с нуля из одного сейфа. Owner tg 13366/13368.

[2026-08-27 ~09:15Z ФАКТИЧЕСКАЯ РЕВИЗИЯ СЕЙФА Hetzner — по вопросу owner] Owner напомнил, что Hetzner в плане миграции (я ошибочно сузил доклад до Pi/малинки — исправлено, 14063). Залез в сам сейф (ssh -p23 -i ~/.ssh/hetzner_storagebox u656648@u656648.your-storagebox.de, restricted shell -> sftp): /home/app-artifact = артефакты 25.08 (446bcbf, c68f701, fd5e1b7 — эпоха l58) + RESURRECTION-RUNBOOK.md + SHA256SUMS.safe. Артефактов l59 (2c6c2276) и l59gd (29ad6759) НЕТ. /home/walg-nc = только basebackups_005 с тремя base_* от 24.08 (тестовые кластеры замеров), WAL-архива (wal_005) НЕТ. ВЫВОД: канал+место оплачены и доказаны (18 МБ/с, roundtrip sha сошёлся 25.08), но РЕГУЛЯРНОГО боевого бэкапа прод-БД в Hetzner НЕТ, и сейф отстал на 2 посадки. Это прямой риск по owner-порогам RPO 5м/RTO 15м. ДЕЙСТВИЕ СЕЙЧАС: заливаю в /home/app-artifact текущий прод-артефакт l59gd (29ad6759) + подписанный сайдкар + sha (laptop->A1->Hetzner). ОТКРЫТЫЙ ВОПРОС OWNER (задан 14063): остаётся ли Hetzner третьей копией по нормативу (20.08 было «пока без Хетцнера, третья копия = малинка», сейчас owner говорит что Хетцнер в плане)? При «да» — ставлю WAL-архив + базовый снимок по расписанию и закрываю WEB-082.

[2026-08-27 09:15Z OWNER-РЕШЕНИЕ — НОРМАТИВ ЗАКРЫТ] Owner голосом: «Хетцнер у нас теперь ОСНОВНОЙ, малинка вспомогательная. Решение принято и за Хетцнер ЗАПЛАЧЕНО, он уже в строю». Тем самым конфликт норматива из этого тикета (R4 требовал off-provider Object Storage vs решение 20.08 «пока без Хетцнера, третья копия = малинка») СНЯТ: целевая основная копия = Hetzner Storage Box, Pi/малинка = вспомогательное быстрое плечо. СДЕЛАНО СЕЙЧАС: боевой артефакт l59gd (29ad6759) + подписанный сайдкар + sha уложены в /home/app-artifact (проверено sftp-листингом: 207373790 Б, 09:12Z). ДИСПАТЧНУТА hetzbk (Luna xhigh): снять факты прод-БД (wal_level/archive_mode/слоты/рост WAL), сравнить пути к RPO 5м (pg_receivewal через слот БЕЗ рестарта прода vs archive_command с окном vs частые дампы), собрать скрипты+юниты, прогнать ПОЛНЫЙ цикл backup->Hetzner->restore на ТЕСТОВОМ кластере с негативами (обрыв канала, битый байт, чужой ключ), выдать runbook применения. Волне ЗАПРЕЩЕНО мутировать прод (конфиг/рестарт/запись) — применение делает координатор по runbook. Уроки web400c/accmigc перенесены в требования: смерть воркера = FAIL без публикации, verify обязан ловить обрубок.

[2026-08-27 ~09:25Z ЗАМЕР ПРЯМОГО МАРШРУТА Pi->Hetzner + факты прод-БД] Owner уточнил маршрут («с A1 на Хетцнер и обратно?») — разъяснено: боевая БД на Pi, A1 был лишь стендом замеров; целевой маршрут ПРЯМОЙ Pi->Hetzner. Создан ОТДЕЛЬНЫЙ ключ Pi /home/pi/.ssh/pi_hetzner (ed25519, pi-backup-20260827) и добавлен в /home/.ssh/authorized_keys бокса (через A1 sftp; чужие приватные ключи НЕ копировались). ЗАМЕР 100 МБ: upload Pi->Hetzner 17.9 c = 5.6 МБ/с; download 4.4 c = 22.8 МБ/с; sha256 roundtrip MATCH. Прод-БД pg_database_size = 1742 MB. ФАКТЫ КОНФИГА ПРОДА: wal_level=replica, archive_mode=off, max_wal_senders=10, max_replication_slots=10, ИСПОЛЬЗУЕТСЯ 0 слотов => pg_receivewal через слот ВОЗМОЖЕН БЕЗ рестарта прода (окно не нужно). ОЦЕНКА ПОД ПОРОГИ: снимок ~0.6-0.9 ГБ сжатый -> 2-3 мин заливки (часовой ритм ок); восстановление скачиванием <1 мин (RTO 15 мин с запасом); WAL-поток мал => RPO 5 мин достижим ПРЯМЫМ маршрутом, крюк через A1 не нужен. Факты переданы волне hetzbk файлом A1:/home/ubuntu/waves/HETZBK-FACTS-FROM-COORDINATOR.md, чтобы она не переизмеряла и строила решение на них.

[2026-08-27 ~09:30Z СРАВНИТЕЛЬНЫЙ ЗАМЕР A1 vs Pi -> Hetzner, единая методика 100 МБ, оба sha MATCH] A1(Oracle)->Hetzner: upload 8.6 c = 11.7 МБ/с | download 8.9 c = 11.2 МБ/с | круг 17.5 c. Pi(малинка)->Hetzner: upload 17.9 c = 5.6 МБ/с | download 4.4 c = 22.8 МБ/с | круг 22.3 c. ВЫВОД: A1 вдвое быстрее НА ОТДАЧУ (критично для заливки бэкапов), Pi вдвое быстрее НА ПРИЁМ (критично для restore); у Pi выраженная домашняя асимметрия. Owner-контекст (27.08 голосом): A1/Oracle — БУДУЩИЙ боевой прод, малинка станет dev; поэтому целевой боевой маршрут в перспективе A1->Hetzner, сейчас (прод на Pi) — Pi->Hetzner. Практика: при БД 1742 МБ (сжатый снимок ~0.6-0.9 ГБ) заливка с Pi 2-3 мин (часовой ритм ок), restore <1 мин; после переезда на A1 заливка ~1-1.5 мин, restore ~1.5 мин — пороги RPO 5м/RTO 15м выполняются на ОБОИХ маршрутах, переезд бэкапам не вредит.

[2026-08-27 10:25-10:36Z КОНТУР ВКЛЮЧЁН НА ПРОДЕ по owner-«да»] Применено пошагово, БЕЗ рестарта прода (paid=200 на каждом шаге): (1) ALTER SYSTEM max_slot_wal_keep_size='32GB' + pg_reload_conf() — было -1 (без лимита); защита от забивания диска при остановке потока; (2) слот hetzbk_wal (physical, immediate) — было 0/10 слотов; (3) роль hetzbk_repl (REPLICATION LOGIN), сервис-аккаунт hetzbk, /etc/hetzbk (pgpass/ssh-ключ/passphrase — все 0600, root:hetzbk), скрипты в /usr/local/libexec, юниты в /etc/systemd/system; (4) pg_hba: добавлена строка 'host replication hetzbk_repl 172.17.0.0/16 scram-sha-256' + reload (docker-bridge адрес контейнера). ДОКАЗАНО БОЕМ: pg_switch_wal -> сегмент зашифрован GPG, залит АТОМАРНО (.part -> rename), рядом .sha256 и .ready; в /home/walg-nc/hetzbk-prod/wal лежат 4 сегмента по 16777313 Б. Слот active=true, стрим с 12/5A000000. Таймеры включены: hetzbk-base (часовой), hetzbk-manifest, hetzbk-retention (30 сут). ИНЦИДЕНТ И УРОК: первый базовый снимок упал на 98% — 'could not open file ./pg_hba.conf.bak-hetzbk-...: Permission denied': Я сам положил бэкап конфига ВНУТРЬ PGDATA. Файлы вынесены в /home/pi/hetzbk-conf-backups/, снимок перезапущен. Правило в память: бэкапы конфигов PG — только ВНЕ PGDATA. Откат контура: systemctl disable --now hetzbk-*; pg_drop_replication_slot('hetzbk_wal'); ALTER SYSTEM RESET max_slot_wal_keep_size — состояние БД не меняется.

## 2026-08-28 ~11:40Z — РАЗБОР: восстановление НЕ ДОКАЗАНО (координатор Фабл)
Волна web082 разобрала контур по коду и конфигам (на боевую машину не ходила — с A1 недоступна). Вердикт: **NO-GO, репозиторий не доказывает восстановление сервиса.**
ЕСТЬ: схема PostgreSQL, read-only роль `web_backup`, ручные примеры `pg_dump`, disposable-проверка построения новой схемы, локальные rollback-копии release-дерева приложения.
НЕТ контура, который одновременно: архивирует WAL с внешним подтверждением свежести · делает копию БД ежечасно с хранением 30 суток · отправляет копии в Hetzner по SFTP · проверяет удалённый объект и семантически восстанавливает его · имеет независимую копию на случай недоступности Hetzner · поднимает приложение и файловые данные на новой машине/архитектуре · измеряет RPO/RTO одной воспроизводимой процедурой.
СЛЕДСТВИЕ: цели владельца (RPO 5 мин, RTO 15 мин, пересборка 1 час, копии ежечасно, хранение 30 суток, 0 потерь) сегодня НЕ подтверждены. «Копии делаются» ≠ «восстановимся». Отдельно важно для WEB-370: подъём на другой архитектуре (aarch64 → Oracle) не доказан вовсе.
ДЕЙСТВИЕ: координатор ничего не менял — это инфраструктура и расход. Владельцу отправлен разбор с предложением вести отдельной линией в порядке: (1) доказать читаемость удалённой копии, (2) учения по восстановлению с замером фактических RPO/RTO, (3) автоматика. Ждёт решения.


## 2026-08-28 ~11:10Z — ЛИНИЯ РАЗРЕШЕНА ВЛАДЕЛЬЦЕМ + ПЕРВЫЕ ИЗМЕРЕНИЯ С БОЕВОЙ МАШИНЫ (координатор Фабл)
Owner 28.08: «Бекапы — да, проверяйте линией как ты хотел». Линия открыта.

**ВАЖНАЯ ПОПРАВКА К ВЕРДИКТУ web082.** Волна анализировала только репозиторий — с A1 боевая машина недоступна, — поэтому часть её выводов о ОТСУТСТВИИ контура неверна. Проверено координатором на самой малинке:
- Контур существует и самописный: `/usr/local/libexec/hetzbk-wal-stream` (111 строк), конфиг `/etc/hetzbk/hetzbk.env`, ключи в `/etc/hetzbk/{keys,ssh,pgpass}`. Ни restic, ни wal-g, ни rclone не используются.
- **Отправка в Hetzner по SFTP ЕСТЬ** (вопреки выводу волны): `remote_put_atomic` кладёт объект и рядом `.sha256`, есть каталог и манифесты.
- **Проверка читаемости ПЕРЕД отправкой ЕСТЬ**: сегмент шифруется gpg, затем `gpg_decrypt` обратно и `verify_wal_plain` — только после этого уходит наверх.
- **Ежечасные базовые копии ЕСТЬ**: `base-20260828T060011Z`, `…T070041Z`, `…T080137Z`, `…T090010Z`, `…T100139Z` — шаг ровно час.
- **Хранение 30 суток задано**: `HETZBK_RETENTION_DAYS=30`. Интервал публикации `HETZBK_PUBLISH_INTERVAL_SECONDS=5`.

**ДОКАЗАНО ЖИВЬЁМ (шаг 1 линии — читаемость удалённой копии):**
Скачан свежий объект `0000000100000012000000AE.gpg` (16 777 313 байт) из `hetzbk-prod/wal`; контрольная сумма из `.sha256` **сошлась**; `gpg`-расшифровка **успешна**; размер ровно 16 777 216 = сегмент WAL; заголовок `10d1 0200 0100 0000` соответствует сегменту. То есть удалённая копия не просто существует, а читается и расшифровывается.

**ИЗМЕРЕН RPO (первое настоящее измерение):**
База пишет сегмент `0000000100000012000000AF`, в хранилище лежит `…AE` — ровно один сегмент разницы. Слот `hetzbk_wal` активен.
Замер: скорость записи 3 860 байт/с, неотправлено 843 264 байта → **отставание ≈ 218 секунд (3,6 мин)**. Цель владельца 300 секунд — **укладываемся**, но занято 73% запаса. Требуется повторный замер под нагрузкой: при всплеске записи запас может исчезнуть.

**ЧТО ПО-ПРЕЖНЕМУ НЕ ДОКАЗАНО:** восстановление. RTO 15 минут, пересборка за час и подъём на другой архитектуре не проверялись ни разу. Это шаг 2 линии — учения на КОПИИ по процедуре из WEB-400 (её сейчас проверяет приёмка ACC400).


## 2026-08-28 — ПОЛНЫЙ СЛЕД ДЛЯ ПОДХВАТА (координатор Фабл)
Чтобы новый агент не играл в детектива: ниже вся эволюция, где лежат отчёты и что делать дальше.

**Линия:** бэкапы и восстановление. Владелец 28.08 разрешил вести отдельной линией.
**Эволюция:**
1. `web082` — разбор по репозиторию, вывод «восстановление не доказано» + список отсутствующего. Отчёт: `A1:/home/ubuntu/waves/WEB082-REPORT.md`.
2. **ПОПРАВКА координатора:** часть списка неверна — волна не видела машину (с A1 нет доступа к малинке). Проверено на месте: контур существует, самописный `/usr/local/libexec/hetzbk-wal-stream` (111 строк), конфиг `/etc/hetzbk/hetzbk.env`, ключи `/etc/hetzbk/{keys,ssh,pgpass}`. SFTP-отправка ЕСТЬ (`remote_put_atomic` + `.sha256`), проверка читаемости ПЕРЕД отправкой ЕСТЬ (`gpg_decrypt` + `verify_wal_plain`), базовые копии ЕЖЕЧАСНО, `HETZBK_RETENTION_DAYS=30`, публикация каждые 5 с.
3. **Шаг 1 линии ДОКАЗАН:** объект `0000000100000012000000AE.gpg` (16 777 313 Б) скачан из `hetzbk-prod/wal`, `.sha256` сошлась, gpg-расшифровка успешна, размер ровно 16 777 216 = сегмент WAL, заголовок корректен.
4. **RPO ИЗМЕРЕН:** 3 860 Б/с, неотправлено 843 264 Б → ≈218 с (3,6 мин) при цели 300 с. Способ: две пробы `pg_current_wal_lsn()` с паузой + `pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)` по слоту `hetzbk_wal`.
5. `web400` (процедура учений) → `ACC400` = **NO-GO**, 8 замечаний, включая пароль БД в argv и подсчёт RPO/RTO со слов оператора. Отчёты: `A1:/home/ubuntu/waves/WEB400-REPORT.md`, `A1:/home/ubuntu/waves/ACC400-REPORT.md`.
6. `web400b` — **идёт сейчас**, переписывает процедуру; ей передан рабочий способ измерения.
**Что НЕ доказано:** восстановление. RTO 15 мин и пересборка за час — цифры из головы. Подъём на другой архитектуре не проверялся.
**Дальше:** `web400b` → приёмка → учения на КОПИИ силами координатора с замером.

---
## 2026-08-29 09:20Z — связка: карта бэкапов обновлена в WEB-420
После ночной проверки (29.08) полная карта «что где лежит + найденные дыры» вписана в WEB-420 (ИНФРА-КАРТА). Кратко для этой линии: Hetzner теперь хранит не только артефакты релизов и WAL-архив, но и /home/board-backups (доски + опубликованный паспорт). До 29.08 доски и паспорта во внешней копии не было — потеря A1+M1 означала их потерю.


[BOARDTRIAGE] Последнее движение 29.08 09:20Z: удалённый WAL читается, RPO измерен около 218 с при цели 300 с; restore/RTO game-day ещё не проведён.

• WEB-686 В работе P1 [бэкапы Hetzner]: файлы пользователей прода A1 не копируются — ежедневная копия storage идёт со старой Raspberry Pi (файлы с 02.09)

04.09 координатор: в body добавлен блок «ЭВОЛЮЦИЯ 04.09.2026» — состояние, причина с доказательством, что село, что осталось, ловушки.

[08.09 11:16Z координатор] **Найдено 08.09: весь контур бэкапа падал МОЛЧА.** Проверка началась с вопроса владельца «телефония вообще бэкапится?».

- `hetzbk-base` (часовая база PostgreSQL) падал каждый час: `No space left on device`, свободного диска 3.9 ГБ при нужных ~10. Освобождено, прогон прошёл, база `base-20260908T090751Z` выгружена на Storage Box и сверена по размеру. На удалёнке 134 базы, цепочка цела.
- Локальное хранение баз снижено 2 → 1 (`HETZBK_LOCAL_BASE_RETENTION` в `/etc/hetzbk/hetzbk.env`, бэкап конфига рядом): часовой цикл по 10 ГБ иначе не помещается на 193-гиговый диск.
- **Четыре юнита `gate14bk`** (restic /data, basebackup, verify, retention) падали `203/EXEC` ЕЖЕДНЕВНО: исполняемого файла `/home/ubuntu/waves/gate14bk/bin/restic-backup` нет, каталога `/data` нет. Это леса под этот тикет, реализации не было. Таймеры переведены в disabled, юниты оставлены на месте — чтобы не забивали шум и не маскировали настоящие тревоги.

**ТРАБЛШУТИНГ:** симптом «бэкап не свежий» → проверка `systemctl show <юнит> -p ExecMainStatus --value` (203 = нет исполняемого файла, 2 = ошибка выполнения) → журнал юнита → `df`. Storage Box отвечает ОГРАНИЧЕННОЙ оболочкой: `ls` через ssh работает, `mkdir -p` и `rm` — только через `sftp`.

BOARD-WASH-20260910:WAVE-3339
По поручению владельца 18:43Z назначена исполнительская волна 3339 (infra), Codex gpt-5.6-luna xhigh, A1. Полная история карточки и база l115c 1ad52e16b доставлены, brief-guard и проверка Git-базы пройдены. Задача: проверить существующую сдачу, устранить остатки, передать бандл и доказательства. Финальная приёмка и посадка остаются за координатором. Запуск группы подтверждён в журнале диспетчера.
КАРТА ДОКУМЕНТОВ: ноут /Users/annakorin/nc-ops-scripts/board-wash-20260910/3339-wash-infra-brief.md; A1 /home/wave/waves/inputs/board-wash-20260910/infra-tickets.json; ожидаемый отчёт /home/wave/waves/3339WASHINFRA-REPORT.md. Правила обогащения: WEB-449.

[12.09 22:17Z координатор] МОЙКА 12.09 (3566-wash-g1-infra): контур бэкапа стоит, но цели RPO 5м/RTO 15м НЕ подтверждены (замер 04.09: точка ~24 мин позади, распаковка 14.5 мин). Фикс ретенции в дереве есть, каденция манифеста и immutable-свойство хранилища не доказаны. Остаток: перепрогон репетиции с новым замером. Статус не меняю.
Остаток: Перепрогон репетиции с новым замером RPO/RTO (после приёмки 1775 и завершения 1776).; Immutable-свойство хранилища не доказано (sftp-объекты перезаписываемы владельцем ключа).; Приёмка ретенции 1775 не заведена; каденция манифеста 1776 идёт.
Отчёт: /Users/milamarty/waves/3566WASH*-REPORT.md (M4), копия nc-ops-scripts/shift-20260912-resume/wash-20260912/collected/. Проверка по исходнику прода l115g (9c8a9762).

[13.09 08:06Z координатор] РАЗБОР 13.09 (волна 3631, DeepSeek): Контур бэкапа стоит и RPO-гейт по partial-публикации закрыт ещё 01.09, но цели 5/15 мин по факту не подтверждены: замер 04.09 дал точку ~24 мин позади и распаковку 14.5 мин. Чтобы закрыть, нужен свежий полный прогон по ранбуку с числовыми rpo_seconds и rto_total. Immutable отдельно: это не чинится кодом — на Storage Box перезапись разрешена, Object Lock есть только у отдельного Object Storage. Тут нужно решение владельца, без него пункт про immutable закрывать нельзя. Приёмку ретенции 1775 надо завести: позитив (4 файла на месте) + негатив (6 релизов — удалился самый старый).
Остаток: Перепрогон репетиции с новым замером RPO/RTO против целей 5/15 мин (свежий JSON rehearsal-<run-id>.json, а не данные 04.09).; Immutable-свойство хранилища НЕ доказано: Storage Box = SFTP, объекты перезаписываемы владельцем ключа; Object Lock провайдер не даёт — нужно owner-решение.; Приёмка ретенции 1775 не заведена; каденция манифеста 1776 не завершена.
Предложение: Ранбук (см. RESULT.md): шаг 0 сверка host vs дерево (cmp), шаг 1 фиксация T0 (LSN+стена), шаг 2 dry-run, шаг 3 полный прогон sudo hetzbk-rehearse --line <line> --target-lsn latest, шаг 4 пересчёт RPO = T0 − published_at(последняя точка), RTO = t_paid; тёплый путь бюджет ≤8 мин (цель 15), холодный 16-17 мин. Отдельно — методика доказательства immutable: (а) проба перезаписи sftp-объекта (ожидание: 
Материалы: shift-20260912-resume/colM2|colP2/ (RESULT.md — ранбуки и спецификации). Статус не меняю.

[13.09 10:45Z координатор] Мойка доски, волна 3653. RETURN: контур стоит (Hetzner основной, RPO-гейт partial-публикации закрыт 01.09), но свежий замер RPO/RTO 5/15 не снят (04.09: 24 мин / 14.5 мин), immutable не доказан (Storage Box = SFTP, нужно owner-решение), приёмка 1775 не заведена, 1776 не завершена. Остаток вне прав мойки. Статус не меняю.

[13.09 11:16Z координатор] Волна 3672 написала план репетиции аварии и воспроизводимую методику замера двух чисел: сколько данных теряем и за сколько возвращаемся в строй. Отдельно оговорено честно: вердикт волны относится к её собственной сдаче, а не к состоянию контура — сам контур физически не проверялся, свежего числового замера нет.
В плане: где ставится отметка начала и конца, чем фиксируется, что считать провалом и в какой момент останавливаться. Проверка обязана доходить до платного пути, а не до главной страницы.

[13.09 14:01Z координатор] Волна 3712. [13.09 11:5xZ координатор] Волна 3712 выдала исполнимую книгу репетиции (DR-RUNBOOK.md + PREPARE-BEFORE.md): пронумерованные шаги с критерием успеха/отказом/временем, 6 меняющих-состояние шагов с откатом, отметки начала (T0: стена+LSN) и возврата (t_paid=/api/ready/paid 200) с методикой расчёта при нахлёсте, проверка платного пути (деньги считаются после восстановления), стоп-условия. Сам замер RPO/RTO (цели 5/15) по-прежнему не снят — прогон делает координатор на A2. Immutable отдельно: Storage Box = SFTP, перезаписываемо, Object Lock только у отдельного Object Storage — нужно owner-решение, без него пункт не закрывается. Статус не меняю.

[14.09 15:16Z координатор] # WEB-082 - блок для вставки

Источники, проверенные отсюда: тело тикета из live API; все 8 комментариев из локального `web-board.sqlite`, последний комментарий `id=4794` от 2026-09-13T14:01:06.798Z. Статус на live API при финальной сверке: `in_progress`. Живые A1/A2/Storage Box отсюда не проверялись.

## Что болит словами пользователя

Нужен настоящий backup/DR-контур с понятным RPO/RTO и immutable-кандидатом, а не набор скриптов, про которые нельзя доказать, что из них реально поднимается сервис после аварии.

## Что уже сделано и чем доказано

По материалам карточки контур WAL-G/restic/Hetzner поднят, Storage Box доступен, remote WAL читается, hourly base после поломки места восстановлен. Комментарий `id=3325` фиксирует, что прежний hourly base silently failing из-за нехватки места был найден и починен, старые scaffolding-юниты `gate14bk` отключены, base `base-20260908T090751Z` загружен и проверен по размеру. Комментарии `id=4360`, `id=4555`, `id=4662`, `id=4794` подтверждают: есть DR runbook и частичные проверки, но это ещё не закрытие цели.

## Что осталось

Нужен свежий полный rehearsal JSON: восстановление из backup до `/api/ready/paid = 200`, `base_source=warm`, RPO в пределах заявленного target, RTO в пределах заявленного target, плюс закрытие acceptance/manifest cadence и решение владельца по immutable. С M1 это не проверено: нужны A2/координаторские host-действия.

## Противоречия между комментариями

Ранние формулировки тела и истории говорят, что Gate 14, partial publish, restore-drill и RPO закрыты. Поздние комментарии 12-13 сентября отменяют эту трактовку: restore был частичным, актуальная свежесть бэкапа и полный paid-ready run не доказаны, а Storage Box через SFTP не равен immutable.

## С ЧЕГО НАЧАТЬ НУЛЕВОМУ АГЕНТУ

Смотреть: `infra/hetzbk/`, DR runbook из волны 3712, материалы `WEB-470`, acceptance 1775/1776, live A2 warm-pull и Hetzner paths. Первым делом собрать одну свежую репетицию на A2 из warm base, не меняя prod.

Готово: в тикете лежит конкретный rehearsal JSON с RPO/RTO, paid-ready check, source base, временем восстановления и границами проверки; owner отдельно решил immutable/Object Lock или честно отказался.

Нельзя: считать SFTP Storage Box immutable, трогать prod-БД, писать в прод, запускать разрушительные restore-команды без координатора, подменять full rehearsal старым partial publish.

Размер: несколько смен. Большим это делает не код, а host-run на A2, связка с WEB-470/1775/1776 и отдельное owner-решение по immutable.

## Закрытие и связи

Не закрыто. Сильное пересечение с WEB-470: WEB-082 держит backup/immutable gate, WEB-470 - исполнимую DR-репетицию. Это не полный дубль, но остаток RPO/RTO у них общий.

[20.09 13:53Z координатор] [GATE-14 — сторож внешней копии боевого артефакта был красным 7 суток (38 проходов подряд); диагноз и починка 20.09 13:52Z]

СТОРОЖ ВНЕШНЕЙ КОПИИ БОЕВОГО АРТЕФАКТА МОЛЧА КРАСНЕЛ СЕМЬ СУТОК. Найдено и починено 20.09 13:52Z.

КАК НАШЁЛ. Владелец напомнил голосом 13:43 про хранение стендов на Хетцнере. Пошёл смотреть, что там вообще есть, и заодно посмотрел состояние служб `hetzbk-*` на A1. Одна была в состоянии failed: `hetzbk-publish-current.service` — «hourly check that the running release artifact is on the Storage Box».

ДИАГНОЗ ТОЧНЫЙ. В журнале одна и та же строка: `PUBLISH-CURRENT no tarball in /home/ubuntu has sha256=e9cdd5b041c2 (exit 2)`. Скрипт `/usr/local/sbin/hetzbk-publish-current` работает так: смотрит рабочий каталог службы `nc-a1`, читает `deployed.json`, берёт оттуда sha текущего релиза и ищет в `/home/ubuntu` тарбол с таким отпечатком. Тарбол линии l115q на A1 отсутствовал — он лежал на A2, в `/home/ubuntu/l115q-artifact/`.

СКОЛЬКО ЭТО ДЛИЛОСЬ. Последний успешный проход — 13.09 18:23 на линии l115k. Дальше 38 подряд неудач, ежечасно, до 20.09 13:24. То есть с 13 по 20 сентября ежечасный сторож внешней копии боевого релиза не проверял НИЧЕГО.

ЧТО ПРИ ЭТОМ БЫЛО ПРАВДОЙ, А ЧТО НЕТ. Внешняя копия НА МЕСТЕ и цела. На Storage Box лежит `/home/app-artifact/l115q-cc278e18/artifact.tar.gz`, 244 643 102 байта, с маркером `ready`: `status=ready`, `published_at=2026-09-16T00:25:20Z`, `release_id=l115q-cc278e18`, `sha256=e9cdd5b041c29d058ef3c06e11ac39862e4de57d4ea307e79a7902d2d6535d86`. Сайдкар `artifact.tar.gz.sha256` содержит тот же отпечаток. Значит потери резервной копии НЕ было.

НО ОПАСНОСТЬ БЫЛА РЕАЛЬНАЯ, И ОНА НАШЕГО ЛЮБИМОГО РОДА. Сторож, который всегда красный, ничем не отличается от сторожа, которого нет: если бы удалённая копия испортилась или исчезла, мы бы этого не узнали — сигнал уже горел и был бы списан как «известная поломка». Это ещё один экземпляр узора, который у нас записан отдельным уроком: ОБЪЯВЛЕННАЯ ЗАЩИТА, КОТОРАЯ В РЕШЕНИИ НЕ УЧАСТВУЕТ. За эту смену третий-четвёртый случай.

ЧТО СДЕЛАЛ. Привёз тарбол артефакта с A2 на A1 в `/home/ubuntu/`, сверил sha256 на обеих машинах и после копирования: `e9cdd5b041c2…` совпал трижды. Запустил службу вручную. Результат: `PUBLISH-CURRENT current release=arm64-l115q-20260915T230431Z line=l115q-cc278e18 sha=e9cdd5b041c2` и следом `already published: /home/app-artifact/l115q-cc278e18/ready present`, служба завершилась успешно. Сторож снова работает и снова способен заметить пропажу. Диск A1 после копирования: свободно 21 ГБ.

ЧТО ЭТО ЗНАЧИТ ДЛЯ ПОРЯДКА ПОСАДКИ — и это надо записать в процедуру. Скрипт ищет тарбол ИМЕННО в `/home/ubuntu` на A1. Если очередная посадка соберёт артефакт на другой машине или уборка снесёт тарбол с A1, сторож снова покраснеет и снова замолчит. Значит после КАЖДОЙ посадки надо либо оставлять тарбол текущего релиза в `/home/ubuntu` на A1, либо учить скрипт принимать уже опубликованную удалённую копию как достаточное доказательство. Второе правильнее по сути, но это правка боевого инструмента и она требует отдельной волны.

СОСТОЯНИЕ ОСТАЛЬНЫХ СЛУЖБ КОНТУРА на 20.09 13:45Z: `hetzbk-wal-stream` active/running, `hetzbk-manifest` active/running, `hetzbk-age-alert` работает каждые 5 минут, `hetzbk-base` по часовому таймеру, `hetzbk-env-pack` ежечасно, `hetzbk-retention` суточный, `hetzbk-local-prune` каждые 6 часов. Локальное хранилище `/var/lib/hetzbk` — 27 ГБ. Разделы Storage Box: `agvoice`, `base`, `docs`, `env`, `manifests`, `stand-definition`, `stand-kits`, `wal`, `wal-partial`, плюс отдельный `/home/app-artifact` с релизами l115l, l115m, l115n, l115o, l115q.

РЕШЕНИЕ=in_progress
ОСНОВАНИЕ=2026-09-20, сторож внешней копии восстановлен после 38 неудач, но в карточке остаются свежий полный замер RPO/RTO, immutable-решение и приёмки 1775/1776
ЧТО НУЖНО=Координатору провести полный прогон с новым JSON RPO/RTO; владельцу принять решение по immutable; завести 1775 и завершить 1776
triage-neo 4608

РЕШЕНИЕ=parked
ОСНОВАНИЕ=2026-09-22, комментарий triage-neo 4608: сторож внешней копии восстановлен, но полный RPO/RTO, immutable и приёмки 1775/1776 не закрыты; immutable требует owner-решения.
ЧТО НУЖНО=владелец: выбрать immutable-хранилище (Object Storage с Object Lock или иной норматив) одной строкой; triage-neo 4712

[24.09 14:25Z координатор] Связано: WEB-686 — файлы пользователей прода не копируются (Pi-копия устарела). Карта всех копий приложена в WEB-686 и лежит у координатора nc-ops-scripts/BACKUP-MAP.md. 24.09: ящик 95 % → base прорежены 508→66, base ежедневно 03:10 UTC, порог возраста 26 ч.

[27.09 15:30Z координатор] Слит в WEB-686 по слову владельца 27.09 15:28Z. Бэкап-контур продолжается в WEB-686 (файлы пользователей прода, карта копий nc-ops-scripts/BACKUP-MAP.md). Здесь остатка нет.