diff --git a/.wiki/entities/kreknin-synology.md b/.wiki/entities/kreknin-synology.md
index 4723353..c0c6cd2 100644
--- a/.wiki/entities/kreknin-synology.md
+++ b/.wiki/entities/kreknin-synology.md
@@ -3,7 +3,7 @@ title: Kreknin Synology (backup target + DDNS)
 type: entity
 tags: [hardware, nas, synology, backup, hyperbackup]
 sources: [../sources/nas-recovery-session-2026-05-18.md]
-updated: 2026-05-19
+updated: 2026-08-10
 ---
 
 # Kreknin Synology
@@ -94,11 +94,28 @@ USB **2TB WD20EARX** (sdq) отформатирован в один btrfs, см
 - `/mnt/rescue/userdata/`: `docker.tar` 130G (rc=1 — файлы менялись при чтении, архив валиден), `homes.tar` 118G, `work.tar` 32G, `downloads.tar` 25G, `documents.tar` 5.9G
 - Итого 1.1TB / 726G свободно. Массив за 2 суток последовательного чтения — **ноль новых ошибок**.
 
-## План ремонта (осталось)
+## Ремонт 2026-08-10 (кабели перетыкнуты vitya, rebuild запущен)
 
-1. **Power-off** (после подготовки, НЕ до слива — данные теперь спасены, риск холодного старта приемлем)
-2. Переподключить SATA: **sda, sdc** (свежие кабели), **sdb** (питание+дата)
-3. sdb определился + SMART ок → DSM Storage Manager → **Repair md3** → ребилд; не определился → 4TB замена
-4. sda должен вернуться на 6 Gbps, CRC не расти
-5. **Вернуть бэкапы**: раскомментировать `vds-backup` + `books-vds-backup`
-6. (необязательно) sdd в md2 уже восстановлен — проверить VMM виртуалки
+Съезд к Алексею: power-off, переподключены SATA (sda/sdc/sdb), свежие кабели. Проверка через SSH (ключ `id_ed25519_kreknin`):
+
+- **sdb** (WD-WX32D12L8HTE) — снова определяется, разделы на месте, SMART **PASSED** (0 realloc/pending)
+- **sda** (WD40EFPX) — линк вернулся на **6.0 Gbps** (было 1.5), SMART PASSED, **CRC=10** (не растёт)
+- **sdc** (WD40EFAX SMR) — SMART PASSED, CRC=213 (историческое, кабельное)
+- Все 3 диска на 6.0 Gb/s. Заметка: в таблице выше у sda/sdc POH перепутаны местами — реально WD40EFPX=30492ч, WD40EFAX=6800ч.
+
+**Repair md3:** `mdadm --add /dev/md3 /dev/sdb3` (sdb3 валидный stale-член, тот же UUID `717d6154…`, роль slot 0, Events 82069 vs массив 132876). Rebuild запущен 2026-08-10 07:57, `State: active, degraded, recovering`, sdb3 = `spare rebuilding`. **Скорость ~10-25 MB/s, оценка 43-106 ч** — старые диски (30k ч) + live-нагрузка (ownCloud cron, VMM etcd, docker). Не форсировать — массив живой.
+
+**btrfs /volume1:** `corruption_errs 1` (счётчик с инцидента) — после ребилда прогнать `btrfs scrub`.
+
+**VMM (win10):** md2/volume2 здоровы (clean, rw OK). ВМ `win10` определена (4 vcpu, autorun=1), libvirtd/etcd живы. Образ vdisk не искал find'ом (не грузить массив во время ребилда) — проверить в DSM VMM GUI.
+
+**Бэкапы: всё ещё ЗАГЛУШЕНЫ** (`vds-backup` + `books-vds-backup` на vds-kzntsv) — вернуть ТОЛЬКО после завершения ребилда + scrub.
+
+## План ремонта (статус)
+
+1. ~~Power-off~~ ✅ сделано vitya 2026-08-10
+2. ~~Переподключить SATA~~ ✅ сделано (sda/sdc/sdb), все на 6 Gbps
+3. **Repair md3 — В ПРОЦЕССЕ** (rebuild ~43-106ч, мониторинг активен)
+4. ✅ sda вернулся на 6 Gbps, CRC=10 (не растёт)
+5. ⏳ **Вернуть бэкапы** после ребилда + scrub
+6. ⏳ VMM win10 — проверить в GUI (storage здоров)