meta(kreknin): backups re-enabled + verified after power-cut; rebuild restarted

- cron restored vds-kzntsv 05:00 + books-vds 06:00; manual runs VERIFIED on kreknin (vds-kzntsv 66G / books-vds 15G, latest->08-10, 7 snaps each)
- books-vds was stale since 08-05 (rsync fails, no alternate trigger); stale ES snapshot daily-2026-08-10 removed
- md3 rebuild restarted from 0 after power-cut (progress not checkpointed); md0/md1 all 4 disks green
- add kreknin_rebuild_mon.sh array monitor (md0/md1/md3 + CRC)

Co-Authored-By: Claude <noreply@anthropic.com>

.wiki/entities/kreknin-synology.md

@@ -111,7 +111,10 @@ USB **2TB WD20EARX** (sdq) отформатирован в один btrfs, см
 
 **Системные разделы (md0/md1) починены 2026-08-10:** DSM ругался «Отказ системного раздела» на sda/sdb/sdc — после инцидента при загрузке в 16-слотовое boot-зеркало собрался только sdd, системные разделы HDD остались вне массива (superblock'и валидны, UUID совпадали). `mdadm --add /dev/md0 {sda1,sdb1,sdc1}` + `mdadm --add /dev/md1 {sda2,sdb2,sdc2}` → ресинхронизация, диски **зелёные** в DSM. На md3 не влияло (копейки I/O: 8MB+2GB).
 
-**Бэкапы: всё ещё ЗАГЛУШЕНЫ** (`vds-backup` + `books-vds-backup` на vds-kzntsv) — вернуть ТОЛЬКО после завершения ребилда + scrub. Задача: `.tasks/kreknin-reenable-backups-after-rebuild.md` (blocked).
+**Бэкапы ВОЗВРАЩЕНЫ 2026-08-10 (18:00)** по прямому указанию vitya (ДО завершения ребилда — ребилд в фоне на idle-IO). Cron-строки раскомментированы: vds-kzntsv `0 5 * * *`, books-vds `0 6 * * *` (снят префикс `#DISABLED-kreknin-sick `). Оба прогнаны вручную и **ПОДТВЕРЖДЕНЫ на kreknin**: vds-kzntsv `2026-08-10` 66G (7 снапшотов), books-vds `2026-08-10` 15G (7 снапшотов), latest→08-10, `/volume1` 5.4T free (24%).
+**Находка:** бэкапы books-vds НЕ доезжали до kreknin с **08-05** — run.sh гонялся 08-01..08-09 + 08-10 06:05 (локальные ES-снапшоты создавались), но rsync падал (`Connection timed out` / `No route to host`). Другого триггера кроме cron.d-строки не найдено (нет crontab/systemd-таймера) — вероятно ручные запуски. vds-kzntsv отключение держалось (не ходил с 07-31). Застрявший ES-снапшот `daily-2026-08-10` от упавшего прогона удалён (коллизия имён → 400 убил бы следующий прогон). Осталось после ребилда: `btrfs scrub /volume1`.
+
+**Отключение питания 2026-08-10 (~11:40, деревня, временно):** NAS недоступен с 2 сетей (рабочая станция + VDS); роутер/WAN жив (traceroute доходит до 195.19.90.188 ~5мс — на UPS/другой линии). Причина — временное отключение электричества у Алексея, не поломка. После возврата питания (16:20) md3 собрался деградированным `[_UU]` (sdb3 сам в массив не вернулся), **md0/md1 — все 4 диска `[UUUU]`** (утренний ремонт пережил ребут), md2 здоров. Прогресс ребилда утра **сброшен** — `mdadm --add /dev/md3 /dev/sdb3` повторён (валидный член, UUID 717d6154…), recovery с 0.0%, ETA ~4+ дня (разгон с ~3МБ/с до 10-25). **Урок: прогресс mdadm-rebuild НЕ переживает жёсткое отключение** (контрольной точки нет) — после power-loss надо проверять /proc/mdstat и пере-dadd sdb3.
 
 ## План ремонта (статус)
 
@@ -119,5 +122,5 @@ USB **2TB WD20EARX** (sdq) отформатирован в один btrfs, см
 2. ~~Переподключить SATA~~ ✅ сделано (sda/sdc/sdb), все на 6 Gbps
 3. **Repair md3 — В ПРОЦЕССЕ** (rebuild ~4 дня, DSM «оптимизация»)
 4. ✅ sda вернулся на 6 Gbps, CRC=10 (не растёт)
-5. ⏳ **Вернуть бэкапы** после ребилда + scrub (task `kreknin-reenable-backups-after-rebuild`)
+5. ✅ **Бэкапы возвращены ДОСРОЧНО** 2026-08-10 (указание vitya — ребилд фоновый); `btrfs scrub /volume1` — после завершения ребилда
 6. ⏳ VMM win10 — проверить в GUI (storage здоров)