76 lines
7.4 KiB
Markdown
76 lines
7.4 KiB
Markdown
---
|
||
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 (отдельная история, починена)
|