Чужой сервер под 1С: разбираемся, не останавливая бухгалтерию

MAATRIX

Обычный разбор незнакомого сервера начинается с вопроса «что тут вообще работает» — и в крайнем случае можно всё остановить и смотреть на холодную систему. С сервером, на котором крутится 1С, этот путь закрыт с первого дня: пока вы читаете конфиги, бухгалтерия закрывает месяц, а банк-клиент раз в час подтягивает выписку. Остановить это ради вашего удобства — значит сорвать реальную работу реальных людей и, возможно, сроки сдачи отчётности. Разбор сервера с 1С — отдельная дисциплина поверх обычного аудита: нужно понять архитектуру базы, расписание фоновых процессов и правила блокировок прежде, чем прикасаться к чему-либо, что может держать сессию бухгалтера.

Регламентные задания: расписание, которое нельзя нарушать вслепую

В 1С есть собственный планировщик — регламентные и фоновые задания, которые выполняются либо силами кластера серверов (назначается в свойствах информационной базы), либо внешним вызовом через cron/Планировщик заданий Windows, который запускает 1cv8.exe с параметрами конкретной обработки.

Найдите оба источника расписания прежде, чем что-либо трогать:

# внешние вызовы 1С через cron
crontab -l -u <пользователь_1с>
cat /etc/cron.d/* 2>/dev/null | grep -i 1cv8
systemctl list-timers

На Windows-сервере — Планировщик заданий (taskschd.msc) и, отдельно, встроенные регламентные задания внутри самой информационной базы, которые смотрятся уже не из ОС, а из конфигуратора или толстого клиента: раздел «Все функции» → «Регламентные и фоновые задания» (виден при включённом режиме «Все функции» в настройках пользователя).

Типичный набор того, что крутится по расписанию в бухгалтерской конфигурации:

• обновление курсов валют (обычно раз в сутки, рано утром);
• обмен с банк-клиентом — регулярная выгрузка/загрузка выписок, иногда каждые 15–60 минут в рабочее время;
• обмен с кассовым оборудованием и ОФД;
• регламентированная выгрузка отчётности перед сроками сдачи;
• фоновое обновление полнотекстового поиска и переиндексация;
• в крупных базах — расчёт итогов и закрытие месяца, если оно запущено как фоновая, а не интерактивная операция.

Последний пункт — самый опасный для вашего графика работ. Закрытие месяца или квартала — тяжёлая операция с массовыми блокировками, которая может идти от минут до часов на больших базах, и именно в эти дни (обычно первые рабочие дни месяца, острее — по кварталам и году) любое обслуживание сервера стоит отложить в принципе. Спросите бухгалтерию прямо, когда у них закрытие периода — и держите эти даты в календаре наравне с production freeze у разработчиков.

Блокировки базы и активные сеансы: почему нельзя просто перезапустить службу

Разработчики привыкли, что сервис можно перезапустить командой systemctl restart — systemd его поднимет, клиент переподключится, максимум будет разрыв на пару секунд. С 1С это работает иначе: у пользователей открыты интерактивные сеансы с несохранённым состоянием документов, а часть операций (обновление конфигурации, тестирование и исправление информационной базы) требуют монопольного, эксклюзивного доступа — ни одного другого активного сеанса быть не должно.

Прежде чем что-то останавливать, посмотрите, кто сейчас работает в базе. Для клиент-серверной 1С это делается через консоль администрирования серверов 1С:Предприятия (MMC-оснастка на Windows) или утилитой rac, которая обращается к серверу администрирования ras:

# ras обычно слушает порт 1545
rac session list --cluster=<id-кластера>
rac infobase summary list --cluster=<id-кластера>

Список сессий покажет пользователя, время начала, последнюю активность и приложение. Сессия без активности часами не всегда безопасна для убийства: клиент мог свернуть окно, оставив документ в редактировании, и принудительное завершение (rac session terminate) иногда обрывает транзакцию некрасиво — особенно в файловом режиме, где после аварийного разрыва может понадобиться «Тестирование и исправление информационной базы» (chdbfl.exe или встроенная функция конфигуратора).

Для планового обслуживания у 1С есть штатный и куда более вежливый механизм — блокировка начала сеансов. Она задаётся в свойствах информационной базы: сообщение для пользователей, код разрешения (кто может зайти вопреки блокировке) и время начала/окончания. Новые сеансы не открываются, а действующие пользователи получают предупреждение и корректно завершают работу — в отличие от резкого обрыва на файрволе или остановки службы кластера.

# пример установки блокировки через rac (упрощённо, точные ключи зависят от версии платформы)
rac infobase update --cluster=<id> --infobase=<id> \
  --sessions-deny=on --scheduled-jobs-deny=on \
  --denied-message="Плановое обслуживание, окончание в 19:00" \
  --permission-code=maint2026

Флаг scheduled-jobs-deny блокирует именно регламентные задания отдельно от сеансов — можно дать пользователям доработать документы, но не дать стартовать закрытию периода или обмену с банком.

Бэкапы .dt и .1CD: в чём разница и почему нельзя просто скопировать файл

На унаследованном сервере с 1С почти гарантированно найдётся папка с бэкапами, и первое, что нужно сделать — понять, что именно там лежит: под одинаковым названием «бэкап» скрываются вещи с разным назначением и надёжностью.

Файл .dt — логическая выгрузка информационной базы, полученная через «Администрирование → Обслуживание → Создание резервной копии» или пакетным запуском 1cv8.exe с ключом /DumpIB. Это не побайтовая копия, а самодостаточный архив, который можно развернуть на любом сервере с подходящей версией платформы — удобно для переноса и тестового стенда, но создание требует монопольного доступа к базе, и на крупной базе может занять от минут до часов.

Файл .1CD — собственно файл базы данных в файловом режиме. Копировать его cp или rsync, пока база активна, — плохая идея: это не журналируемая СУБД в классическом смысле, и снятая «на живую» копия может оказаться внутренне противоречивой. Безопасные варианты:

• временно включить блокировку сеансов, дождаться закрытия активных соединений, скопировать файл, снять блокировку;
• снять снапшот на уровне LVM/ZFS в момент минимальной активности (не 100%-я гарантия консистентности, но заметно снижает риск по сравнению с копированием на лету);
• использовать выгрузку в .dt как основной бэкап, а .1CD — как дополнительный «холодный» снимок после остановки службы или в блокировке.

Клиент-серверный вариант с СУБД бэкапится штатными средствами самой СУБД, а не файловой системы и не средствами 1С: pg_dump/pg_basebackup для PostgreSQL, BACKUP DATABASE для MS SQL Server. Если на унаследованном сервере вы находите только .dt-выгрузки как единственный вид бэкапа для крупной клиент-серверной базы — это тревожный знак: .dt медленный и не годится как основной ежедневный бэкап на большой базе, он для переноса и разовых снимков. Проверьте, настроены ли реальные бэкапы СУБД, и если нет — это первое, что стоит исправить.

Убедитесь заодно, что бэкапы вообще проверялись на восстановление, а не просто складывались в папку годами — это частая находка на унаследованных серверах, разобранная отдельно в статье про разворачивание чужого бэкапа вслепую.

Окна обслуживания: как договориться с бухгалтерией, а не с самим сервером

Технически подкованный админ по умолчанию мыслит окнами обслуживания в терминах нагрузки: «ночью трафика меньше, значит, можно рестартовать». С бухгалтерией это работает наоборот — важнее не время суток, а фаза учётного цикла.

Практичный порядок:

1. Узнайте расписание закрытия периода (обычно первые 3–5 рабочих дней месяца, острее — по кварталам и году) и не планируйте на эти дни ничего с блокировкой сеансов дольше пяти минут.
2. Узнайте сроки сдачи регламентированной отчётности — за 2–3 дня до дедлайна лучше вообще не трогать сервер без крайней необходимости.
3. Договоритесь о конкретном окне — точный интервал, о котором предупреждены обе стороны, с запасом на непредвиденное (обновление конфигурации иногда идёт медленнее ожидаемого, особенно на большой файловой базе).
4. Заранее поставьте блокировку начала сеансов с понятным сообщением («Технический перерыв до 19:00, обратитесь к администратору») — так спокойнее, чем внезапный обрыв связи посреди заполнения документа.
5. После работ снимите блокировку и проверьте, что регламентные задания этого окна (например, обмен с банком) отработали штатно или запущены вручную — иначе о проблеме бухгалтерия узнает от банка, а не от вас.

Если сервер обслуживает несколько организаций с разными базами на одном кластере, уточните это отдельно: закрытие периода у них может не совпадать, и «безопасное» окно для одной базы придётся на закрытие у другой.

Типовые находки на унаследованном сервере с 1С

Опыт разбора чужих серверов с 1С обычно сводится к нескольким повторяющимся сюрпризам:

• Смешение версий платформы. На сервере установлено сразу несколько версий 1С:Предприятия (/opt/1cv8/x86_64/8.3.XX/) — старую боялись сносить «на всякий случай». Проверьте через консоль кластера, какая версия реально закреплена за каждой базой: несовпадение платформы и требований конфигурации даёт трудноуловимые ошибки при запуске.
• Расширения и доработки без исходников. Расширения конфигурации (.cfe) и правки типовой конфигурации от программиста, который давно уволился. Выгрузите список расширений через конфигуратор («Конфигурация → Расширения») и сохраните отдельно — это отдельный слой риска при обновлении.
• Недокументированные внешние обмены. Помимо банк-клиента почти всегда находится что-то ещё: ЕГАИС, CRM, маркетплейсы, синхронизация с сайтом — как внешние обработки (.epf) по расписанию, так и HTTP-сервисы того же веб-сервера, что публикует саму 1С (модуль _1cws).
• Лицензионный сервер на другой машине. Если HASP-ключ или программная лицензия физически завязаны не на тот сервер, что вы разбираете, любое сетевое изменение может внезапно оборвать вход пользователям.
• Бэкапы без ротации, которые годами копятся и незаметно забивают диск — обычно в самый неподходящий момент, перед закрытием периода.

Если сервер вообще перешёл к вам без документации и внятного контакта прежнего администратора — общий порядок первичного обследования (не специфичный для 1С) описан в статье с чего начинать разбор незнакомой машины, а если единственный доступ — это чужой SSH-ключ, отдельно разобрано, как безопасно вернуть себе контроль.

План действий: перенос или обновление сервера без остановки учёта

Когда картина ясна — база инвентаризирована, расписание регламентных заданий известно, бэкапы проверены на восстановление — встаёт следующий вопрос: как менять инфраструктуру под этой 1С, не останавливая работу бухгалтерии совсем.

Рабочая последовательность для переезда на новый сервер:

1. Разверните целевой сервер с той же (или заведомо совместимой более новой) версией платформы 1С и того же типа СУБД, что и источник.
2. Перенесите тестовую копию базы — из .dt-выгрузки для небольших файловых баз или через бэкап СУБД для клиент-серверных — и прогоните реальные сценарии: открытие документов, отчёты, расширения.
3. Проверьте лицензирование на новом сервере заранее, отдельно от переноса данных — частая причина, по которой миграция «технически готова», но пользователей пустить не удаётся.
4. Запланируйте окно вне закрытия периода, согласованное с бухгалтерией, и заложите время на откат назад, если что-то пойдёт не так.
5. В само окно: заблокируйте начало сеансов на старом сервере, дождитесь завершения активных, снимите финальный бэкап (уже консистентный, потому что сеансов нет), разверните его на новом, переключите точку подключения клиентов (.v8i или DNS), снимите блокировку уже на новом сервере.
6. После переключения оставьте старый сервер «только для чтения» на несколько дней — если обнаружится забытая интеграция, у вас будет живой источник для сверки.

Тот же план работает и для менее радикального сценария — обновления версии платформы или ОС на том же сервере, только «переключение» идёт не между двумя машинами, а между версиями сервиса на одной.

Частые вопросы