Files
knowledge-base/decisions/2026-05-07-buzharovo-migration-plan.md
dttb bf565f1392 mmfb/lionart-1c: SSH + фикс efsaveragent + накопленный backlog vault-а
Сегодня (mmfb / LionART 1C):
- projects/mmfb/lionart-1c.md — новый файл: VM 100 на pve LionART
  (WIN-70M2VEJIKEF, 10.253.1.240, Win Server 2022, 1С+SQL+Effector Saver),
  SSH-доступ claude/Kl@udeD1ag!2026 заведён, RDP под Администратор + 2FA.
- projects/mmfb/proxmox-inventory.md — hostname WIN-70M2VEJIKEF в VM 100.
- decisions/2026-05-28-mmfb-effector-saver-locked-admin.md — диагноз
  цикла 7038 (SCM-пароль разъехался с .\Администратор) + lockout учётки,
  и пошаговое решение (disable службы → ADSI unlock → LogonUser-проверка
  → sc.exe config password= → start auto).

Накопившийся backlog (без отдельной правки в эту сессию):
- decisions/: buzharovo (recon, migration-plan, 1c-licensing), sergey
  (instagram iPhone fakeip), amneziavpn macOS v1/v2 incompat, benelux
  compromise 2026-05-20, glavtorg autologon off, omni domain+update.
- projects/: benilux README, buzharovo README+server1c, dttb
  (nextcloud-talk-bot, npm-proxy-hosts, proxmox-inventory, vpn-clients),
  glavtorg, sergey README, projects/_index.
- claude-memory/: benelux, omniroute.
- snippets/mac-dictation/groq-dictate.sh.
- notes/claude/: ~80 авто-сохранённых транскриптов сессий за май.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-29 12:33:03 +03:00

22 KiB
Raw Permalink Blame History

date, type, tags, status, target_stack, related
date type tags status target_stack related
2026-05-07 decision
buzharovo
1c
migration
plan
approved windows-mssql
decisions/2026-05-07-buzharovo-recon
projects/buzharovo/server1c
projects/buzharovo/migration-prompt-2026-05-07
decisions/2026-05-07-buzharovo-1c-rmngr-loop-after-crash

Решение по стеку (07.05.2026): идём на Windows Server VM + MSSQL (Вариант W). Linux/PostgreSQL отложен на потом. Причина выбора: простая миграция через нативный SQL .bakRESTORE, без переобучения 6 терминальных юзеров (они продолжают работать через RDP), без отдельного термсервера. На масштаб ~6 юзеров и ~гигабайтной БД разница в скорости с Linux незаметна.

Лицензионная часть (1С Server, клиентские, Windows Server) — за Олегом, обрабатывается отдельно. План описывает только техническую миграцию.

План миграции 1С Бужарово → HomeLab Proxmox

Цель: перенести 1С с физического Server1C (Win 2012 R2, бытовая мать ASUS, без ИБП, 24+ крашей в день) на VM на HomeLab Proxmox (10.0.0.250), сохранив работу 6 терминальных юзеров и двух ПК-касс KASSA3/KASSIRULICA2.

Базис: decisions/2026-05-07-buzharovo-recon.md (отчёт разведки 07.05.2026).

Критерии успеха

  1. Все 4 инфобазы 1С восстановлены и доступны для пользователей
  2. 6 RDP-юзеров (АртемК, ГорячевАЕ, Павел, ПальмановаН, ФирсовС, dttb) работают в 1С через RDP к новой VM
  3. KASSA3 (192.168.1.18) и KASSIRULICA2 (192.168.1.99) пробивают чеки через новую инфраструктуру (TCP до 1С-сервера через NetBird)
  4. Время простоя при cutover ≤ 4 часов (вечер пятницы или ночь субботы)
  5. Откат за ≤ 30 минут (старый Server1C остаётся включённым в Бужарово до недели после миграции)

Архитектура: Вариант A (приоритетный)

                    Интернет
                        │
   ┌────────────────────┼─────────────────────────┐
   │                    │                         │
   ↓                    ↓                         ↓
[Бужарово офис]    [сельский WISP/РТК?]    [HomeLab Москва]
192.168.1.0/24                              10.0.0.0/24
                                                │
   ┌─────────────┐                              │
   │  KASSA3     │                              ↓
   │  192.168.   │     NetBird VPN              ┌────────────────┐
   │  .1.18      ├──────────────────────────────│  Proxmox PVE   │
   │  KASSIRUL2  │     (~96 ms RTT)             │  10.0.0.250    │
   │  192.168.   │                              │                │
   │  .1.99      │                              │  ┌──────────┐  │
   │             │                              │  │ VM 1Cnew │  │
   │  6× RDP-    │                              │  │ Win22/25 │  │
   │  юзеров     │     RDP 3389 + 1С 1541       │  │ + 1С 8.3 │  │
   │  (тонкие    │←─────────────────────────────│  │ + MSSQL  │  │
   │  клиенты)   │                              │  │ 8 vCPU   │  │
   │             │                              │  │ 32GB RAM │  │
   │  Router-    │                              │  │ 200GB SSD│  │
   │  Office     │                              │  └──────────┘  │
   │ (NetBird    │                              │                │
   │  + advertise│                              └────────────────┘
   │  192.168.1/ │
   │  24)        │
   └─────────────┘

Ключевые элементы

  • Целевая VM: новая на Proxmox 10.0.0.250 (имя vm-1c-buzharovo или подобное), Win Server 2022 или 2025, 8 vCPU, 32GB RAM, 200GB SSD (LVM/qcow на NVMe пуле)
  • 1С: 8.3.27.1606 (тот же билд для совместимости), x64, только одна служба 1C:Enterprise 8.3 Server Agent (x86-64) Auto
  • MSSQL: 2019 или 2022 (Express если суммарный объём всех 4 БД ≤ 10GB; Standard если больше — нужно подтвердить размер!)
  • NetBird-агент на VM с advertise-route 10.0.0.0/24 (или подключение к существующему "Dom" route group)
  • NetBird на офисном роутере в Бужарово с advertise 192.168.1.0/24 — это позволит KASSA3/KASSIRULICA2 общаться с новой VM прозрачно

Почему Вариант A, а не B

  • Сейчас ИДЕНТИЧНАЯ схема уже работает: 6 юзеров через RDP в Server1C запускают 1С локально на сервере → переезд просто меняет адрес сервера
  • 1С↔MSSQL остаются в одной локалке VM (latency 0.1ms внутри Proxmox), как сейчас
  • RDP толерантен к 96ms; толстый клиент 1С через NetBird тормозил бы при открытии справочников
  • Касса KASSA3 уже общается с 1С через TCP (порт 1560) → меняется только адрес, протокол сохраняется

Фазы и эстимейты

Фаза 0: Pre-flight (1 час, до миграции)

Кто: Олег + Claude Code Что: ответы на 8 открытых вопросов из recon.md:

# Вопрос Action
1 sa-пароль MSSQL? Олег → 1Password / память / создать SQL-login
2 Лицензия 1С: пинкоды? Олег → ЛК на portal.1c.ru
3 Имена 4 инфобаз Олег → проверить через 1С-клиент или v8i-ярлык на ПК пользователя
4 ПО на KASSA3/KASSIRULICA2 Удалёнкой через RDP/AnyDesk на 192.168.1.18
5 Провайдер в Бужарово Олег → договор / счёт
6 Окно простоя Олег + бизнес → согласовать
7 Бюджет на ИБП / альтернатива «починить на месте» Олег
8 AnyDesk оставлять? Олег

Также: определить SQL backup-метод (FULL+DIFF или COPY_ONLY backup → restore).

Фаза 1: Подготовка целевой VM (2-4 часа)

Шаги:

  1. Создать VM на Proxmox 10.0.0.250:
    • VM ID: например 112 (или соседний свободный)
    • OS: Win Server 2022 RU (или 2025; ISO у Олега есть, ставился на VM 111)
    • vCPU: 8 (с host-passthrough cpu-type)
    • RAM: 32 GB (можно ballooning)
    • Disks: 1 OS-disk 100GB qcow2 на быстром пуле + 1 data-disk 200GB для БД
    • Сеть: vmbr0 → 10.0.0.0/24 (статический IP, например 10.0.0.197)
  2. Базовая настройка Windows:
    • Hostname: s1c-buzharovo (или согласуем)
    • Локаль: Russian
    • Network: статика 10.0.0.197/24, gw 10.0.0.1, DNS 10.0.0.250
    • Firewall: разрешить in 3389 (RDP), 1540-1591 (1С), 1433 (SQL только из NetBird-подсетей)
    • Обновления Windows
  3. Установка MSSQL:
    • Express или Standard (зависит от размера БД)
    • Default instance MSSQLSERVER
    • Mixed Mode auth, sa-пароль strong
    • SQL Browser: Disabled (нам не нужен)
  4. Установка 1С Предприятие 8.3.27.1606:
    • Server (x64), administrator components
    • Создать 1 службу: 1C:Enterprise 8.3 Server Agent (x86-64) — Automatic
    • Ничего лишнего: ни 8.3.18, ни RagentServer_xxx
  5. Настройка ОС:
    • Crash Dump: CrashDumpEnabled=3, pagefile фикс 8GB на C: (как на старом сервере)
    • Performance: Set-MpPreference -DisableRealtimeMonitoring $false (или установить полноценный AV)
    • Time zone: МСК
  6. NetBird:
    • Установить netbird-агент
    • Подключить к нашему tenant
    • Проверить ping к Server1C (100.70.75.103) и доступ из NetBird-сети
  7. RDP-юзеры:
    • Создать локальные учётки: АртемК, ГорячевАЕ, Павел, ПальмановаН, ФирсовС, dttb
    • Добавить в Remote Desktop Users (для RDP) и Users
    • Пароли на временных, потом сменить
  8. WinRM 5985 / 5986 для нашей автоматизации (basic auth, Private network).

Артефакт фазы: живая VM на 10.0.0.197, доступна по RDP/WinRM из NetBird.

Фаза 2: Тестовая миграция данных (3-5 часов)

Шаги:

  1. Бэкап SQL на Server1C (вне рабочего времени!):
    BACKUP DATABASE [<db1>] TO DISK = 'D:\backup\<db1>.bak' WITH COPY_ONLY, COMPRESSION;
    -- повторить для всех 4 БД
    
    • Размер бэкапов оценим сразу; время — зависит от размера, при 39GB может быть 30-60 мин
  2. Передача .bak на HomeLab:
    • Через NetBird SMB (Server1C → s1c-buzharovo) или scp/rsync
    • 39GB через 96ms NetBird ≈ зависит от throughput; реалистично 1-3 часа
    • Альтернатива: бэкапить на USB на Server1C, привезти физически
  3. Восстановление на новой VM:
    RESTORE DATABASE [<db1>] FROM DISK='C:\restore\<db1>.bak' WITH MOVE ...;
    
  4. Регистрация инфобаз в 1С на новой VM:
    • Через 1cv8.exe админ-консоль или ручной ввод
    • 4 инфобазы → подключение к локальному s1c-buzharovo:1541
  5. Smoke-тест:
    • Запустить тонкий клиент 1С на VM локально, открыть каждую базу
    • Проверить: журнал регистрации, последние документы, базовые отчёты
    • Сверить контрольные суммы / счётчики документов с боевой
  6. Лицензия 1С:
    • Активировать программную лицензию через PIN (получить от Олега)
    • Если резервных PIN нет — заявка в 1С-Партнёр на восстановление

Артефакт фазы: на новой VM работают все 4 инфобазы (read-only тест).

Фаза 3: Тест с кассой (1-2 часа)

Шаги:

  1. На одном ПК KASSA3 (192.168.1.18):
    • Поднять временный VPN/proxy до новой VM (либо через NetBird-агент на самой кассе, либо через NetBird на офисном роутере)
    • В настройках кассового ПО изменить адрес сервера 1С (или v8i базы)
    • Открыть тестовую копию рабочей базы
    • Сделать тестовый чек: товар → пробить → ответ от ОФД
  2. То же самое для KASSIRULICA2 если есть time
  3. Откатить изменения на касса-ПК (вернуть на боевой Server1C)

⚠ Важно: не работать с боевой БД! Создать тестовую копию инфобазы для проверки чеков. Иначе двойной чек в ОФД.

Артефакт фазы: подтверждение что новая инфраструктура совместима с кассой.

Фаза 4: Cutover (3-4 часа, окно простоя)

Окно: вечер пятницы 18:00 → 22:00 МСК (после рабочего дня) или ночь сб → вс.

Шаги:

  1. Заранее (за день): уведомить юзеров и кассиров о времени простоя
  2. T-0:00 Объявить начало миграции, остановить работу пользователей
  3. T+0:05 На Server1C финальный бэкап SQL (FULL + последний DIFF):
    BACKUP DATABASE [<db>] TO DISK='D:\backup\<db>_final.bak' WITH COPY_ONLY, COMPRESSION;
    
  4. T+0:30 Перенести _final.bak на новую VM через SMB
  5. T+1:00 Восстановить на новой VM поверх тестовой копии
  6. T+1:30 Smoke-test: 1С запускается, контрольные суммы совпадают
  7. T+1:45 Перенаправить пользователей и кассу:
    • RDP-юзеры: новый ярлык RDP к 10.0.0.197 (или через NetBird FQDN)
    • KASSA3 / KASSIRULICA2: новый адрес 1С-сервера
  8. T+2:00 Тестовая транзакция от первого юзера и первой кассы
  9. T+2:30 Миграция завершена, пользователи возобновляют работу
  10. T+3:00 Лог финального состояния, обновить vault

На Server1C в Бужарово: НЕ выключать! Оставить работать ещё неделю как backup (можно перевести в read-only режим в 1С — отключить пишущие фоновые задания).

Фаза 5: Стабилизация (неделя)

  • Мониторинг: rmngr CPU на новой VM (watchdog уже есть на LXC 137)
  • Сбор обратной связи от пользователей
  • Бэкапы: настроить ежедневные на Proxmox-уровне (snapshot) + еженедельный SQL FULL backup
  • Через 7 дней без проблем — можно гасить старый Server1C

Risk Register

# Риск Вероятн. Импакт Митигация
R1 Лицензия 1С не активируется на новой VM (нет PIN, HWID-привязка) Средняя Критичный Pre-flight: получить пинкоды от Олега; запасной план — обращение в 1С-Партнёр
R2 Размер SQL БД >10GB → нужен MSSQL Standard (платный) Неизвестна Средний Pre-flight: получить sa-пароль, измерить размер; иметь готовую лицензию SQL Standard
R3 Касса KASSA3/KASSIRULICA2 не общается с новой 1С (firewall, COM, специфический протокол) Низкая Высокий Фаза 3 — тест ДО cutover; держать резервный туннель на Server1C
R4 Канал в Бужарово упал в момент миграции → юзеры не могут переключиться Низкая Высокий Cutover ночью; держать резерв (мобильный 4G)
R5 Бэкап повреждён или RESTORE с ошибкой Низкая Критичный Сначала FULL+DIFF, проверка восстановлением до cutover; держать оригинал
R6 rmngr-loop повторится на новой VM (баг 8.3.27.1606) Низкая Средний Watchdog уже работает; в крайнем случае — даунгрейд до 8.3.26
R7 Production crash во время Phase 4 backup'а на Server1C Высокая Низкий Бэкап быстрый (COMPRESSION), краш просто откатит наш cutover на 4 часа
R8 Юзеры не находят свои документы / сбит порядок (если несколько ИБ перепутали) Средняя Средний Маппинг GUID→имя ИБ зафиксировать в pre-flight; дублирующие тесты с реальными документами
R9 Закрытие RDP в Интернет на старом Server1C преждевременно — юзер не сможет подключиться Средняя Низкий Закрывать только после полного cutover + 1 неделя стабильности
R10 Касса в офисе работает с особым ПО (1С Розница нестандартного билда) Низкая Высокий Phase 0: проверить через AnyDesk что стоит на 192.168.1.18

План отката (≤ 30 минут)

Если после cutover (Фаза 4) обнаружили блокирующий баг:

  1. T-rollback+0:00: объявить откат
  2. T+0:05: На клиентских ПК и кассах вернуть старый адрес сервера (1С: 100.70.75.103 / 192.168.1.249; кассы: 192.168.1.249)
  3. T+0:15: На Server1C запустить службу 1С (она и так работает в RO-режиме)
  4. T+0:25: Smoke-test от пары юзеров
  5. T+0:30: Откат завершён, работа на старом

Условие отката: производственный блокер, не косметический.


Чек-лист готовности к Phase 4 (Cutover)

[ ] sa-пароль SQL получен (#1)
[ ] Лицензия 1С: пинкоды известны или есть онлайн-активация (#2)
[ ] Маппинг GUID → имя инфобазы зафиксирован (#3)
[ ] Кассовое ПО изучено (#4) и протестировано в Phase 3
[ ] Канал в Бужарово протестирован (#5), резерв есть
[ ] Окно простоя согласовано с бизнесом (#6)
[ ] Решение по AnyDesk (#8): убрать или оставить
[ ] Phase 1: VM s1c-buzharovo живая, RDP/WinRM/NetBird работают
[ ] Phase 2: тестовая миграция данных прошла, 4 инфобазы открываются
[ ] Phase 3: касса прошла тест чека через новую инфраструктуру
[ ] Бэкап Server1C перед cutover есть и проверен restore'ом
[ ] План отката известен команде, контакты Олега для эскалации
[ ] Юзеры уведомлены за >24 часа до простоя

Альтернатива: «починить на месте»

Если миграция отложена, минимальная починка Server1C в Бужарово:

  1. Купить ИБП (Eaton/APC, ~10000-15000 ₽) на 1500ВА для покрытия 5-10 минут просадок и корректного shutdown
  2. Заменить мать на серверную (с ECC, IPMI) — сложно/дорого, лучше тогда уж VM
  3. Watchdog уже есть (LXC 137 → rac.exe restart-service при rmngr-loop)
  4. Бэкапы: настроить ежедневный Veeam Free / Native SQL Backup → внешний диск + копия в HomeLab Nextcloud

Не отменяет миграцию, но снижает срочность. Хорошая идея сделать ИБП параллельно с подготовкой VM — уменьшит крашы пока VM готовится.


Open для обсуждения

  • Кто администратор новой VM — Олег (как сейчас Server1C) или предложить более ограниченную модель (отдельный admin-аккаунт)?
  • Public IP / порт RDP на HomeLab — нет; всё через NetBird. Согласовано?
  • Версия Win Server — 2022 (стабильнее, дольше поддержка) или 2025 (новее, current на VM 111)?
  • Версия MSSQL — оставить 2012 (max совместимость с 8.3.27, но EOL) или прыгнуть на 2019/2022 (поддерживается, может быть несовместимость с конфигурациями 1С)?

Дефолтные параметры новой VM (для запуска Phase 1)

Параметр Значение
Proxmox host 10.0.0.250
VM ID 112 (если свободен; иначе ближайший свободный)
Имя s1c-buzharovo
OS Windows Server 2022 Standard RU
vCPU 8 (host-passthrough)
RAM 32 GB
OS-диск 100 GB qcow2
Data-диск 200 GB (для SQL БД)
Сеть vmbr0, статический IP 10.0.0.197/24, gw 10.0.0.1, DNS 10.0.0.250
MSSQL 2019 Standard (если БД >10GB) или 2019 Express (если ≤10GB — пока неизвестно)
1С платформа 8.3.27.1606 (та же что на старом)
NetBird агент установлен, подключён к нашему tenant
WinRM 5985 для автоматизации

Если параметры устраивают — начинаем Phase 1 с этими дефолтами.