auto-sync from MEMORY.md (2026-05-26 18:44)

This commit is contained in:
2026-05-26 18:44:07 +00:00
parent e51c6310f0
commit 35202bc348
7 changed files with 460 additions and 0 deletions

View File

@@ -0,0 +1,75 @@
---
date: 2026-05-08
type: decision
tags: [decision, buzharovo, 1c, backup, mssql, effector-saver]
---
# 2026-05-08: Бэкап Бужарово 1С — переход с Effector Saver DT на native MS SQL Backup
## Контекст
Вечером 2026-05-08, после починки rmngr-loop, регулярная задача `Бэкап 1Cv8` в Effector Saver Free 4.8/2 на `server1c.netbird.cloud` (Win 2012 R2, MSSQL 2012 SP4, 1С 8.3.27.1606) **отказывалась завершаться успешно**. Шесть подряд запусков (19:51 → 22:21) падали с одной и той же связкой ошибок:
1. `HRESULT=800401F3``V83.ComConnector` не зарегистрирован → Olег зарегистрировал через UI Effector Saver, переключился на 64-bit
2. `HRESULT=80004005` — "Администратор кластера не аутентифицирован" — у кластера 1С есть проверка авторизации, но **в кластере нет ни одного admin'а**, а добавить нельзя:
- В Серверной консоли 1С: `Локальный кластер → Администраторы` показывает количество=0, форма "Новый администратор" заполнена, но при OK **просит логин/пароль и не принимает agent-уровневый admin** (создан Olегом отдельно)
- Через COM `V83.COMConnector`: `AuthenticateAgent('admin', '1qaz!QAZ')` проходит, но `RegClusterAdmin` падает "пользователь не выполнил аутентификацию для требуемой операции" (chicken-and-egg: для создания первого cluster admin нужен уже cluster admin)
- Через `rac` с `--agent-user`: cluster operations не принимают agent-уровневую аутентификацию (design choice 1С)
3. `Ошибка исключительной блокировки информационной базы` — даже без cluster admin'а Effector Saver продолжает выгрузку, но не может получить эксклюзив, потому что в БД активные сессии. Особенно "вечная" сессия `КулябинПИ sid=4514, начат 12:55:42` — после моего рестарта службы 1С в 19:30 и последующих SQL `KILL` сессий, она **раз за разом возвращается** (вероятно, реально открытый где-то тонкий клиент Павла Ивановича + persistent state в `1CV8Clst.lst`).
## Что пробовали и почему не сработало
| Попытка | Результат |
|---|---|
| `regsvr32` x64 `comcntr.dll` | ✅ COM зарегистрирован, переключение Effector Saver на 64-bit убрало `800401F3` |
| `Restart-Service '1C:Enterprise 8.3 Server Agent'` | ✅ rmngr вылечен, но session 4514 в реестре кластера **persists** между рестартами |
| `KILL` SQL-сессий через `sa/Qwer1122334400` | ✅ временно (sess=0, locks=0), но 1С rphost восстанавливает соединения за 1-2 мин и сессия 4514 reanimates |
| `rac cluster admin register` без auth | ❌ "оператор не существует" |
| `RegClusterAdmin` через COM с `AuthenticateAgent` | ❌ "пользователь не аутентифицирован для требуемой операции" |
| GUI Серверной консоли 1С — добавить cluster admin | ❌ форма не сохраняет, требует cluster auth (которой нет) |
Тупик: **в кластере БД 1С нет cluster admin'а, и зарегистрировать первого нельзя ни через GUI, ни через rac, ни через COM.** Возможный единственный путь — обнулить `srvinfo\reg_1541\1CV8Clst.lst` целиком (потеря и админов, и регистрации ИБ — нужна перерегистрация ИБ с SQL params; рискованно).
## Решение: native MS SQL Backup
Effector Saver делает **DT-выгрузку через 1С Конфигуратор** (`1cv8.exe DESIGNER /DumpIB`), которая требует эксклюзив на ИБ. Это исторический способ для **файловых** ИБ. Для **клиент-серверных** ИБ на MS SQL правильный путь — **`BACKUP DATABASE` на уровне SQL Server**:
-**Online backup** — снимает копию во время работы, не требует эксклюзива
-Не зависит от 1С-кластера, cluster admin'а, активных сессий
-С `WITH COMPRESSION` файл сжимается ~3:1 (3.8 GB → 1.1 GB)
- ✅ Быстрее — у нас 2 секунды на 3.8 GB БД
- ✅ Восстанавливается одним запросом `RESTORE DATABASE`
Реализация:
```sql
BACKUP DATABASE [RitmUl]
TO DISK = N'C:\backup\RitmUl_<ts>.bak'
WITH FORMAT, INIT, NAME = N'RitmUl-Full',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, COPY_ONLY,
STATS = 5
```
`COPY_ONLY` — чтобы наш бэкап не ломал log chain если потом настроят differential/log backups.
Запускается через WinRM `python3 + System.Data.SqlClient` с LXC 139 `severny-les` (бот). Storage: `C:\backup\` на server1c (374 GB свободно).
## Артефакт
- **Первый успешный бэкап 2026-05-08:** `C:\backup\RitmUl_2026-05-08_2225.bak` (1105 MB)
- **Скрипт:** `/root/clawd/scripts/sql_native_backup.py` на LXC 139
## TODO (после возвращения Olега из Египта)
1. **Автоматизировать** — добавить cron на LXC 139 `severny-les`: каждый день в 03:00 МСК запускать `sql_native_backup.py`, ротировать (хранить N дней). Алерт в Telegram-группу при сбое.
2. **Ротация и трансфер** — настроить копирование `.bak` файлов на внешний носитель (Nextcloud / S3 / Gitea-LFS).
3. **Тест восстановления** — раз в N дней автоматически развернуть бэкап в тестовую БД и проверить целостность.
4. **Effector Saver** оставить как есть, не чинить (чинить cluster admin = разбирать `1CV8Clst.lst` бинарник, риск убить ИБ). Можно отключить регулярную задачу `Бэкап 1Cv8` в Effector Saver чтобы не плодились алерты "ошибка".
5. **TODO документировать** SQL creds в `projects/dttb/credentials.md` (см. блок Бужарово).
## Связанные
- [[projects/buzharovo/server1c]] — обновлён с SQL backup как новый канон
- [[projects/buzharovo/severny-les-bot]] — бот теперь умеет бэкапить через WinRM+SQL
- [[decisions/2026-05-07-buzharovo-1c-rmngr-loop-after-crash]] — про rmngr (отдельная история, починена)