Пять действий, после которых сервер 1С не поднимается, и как их не совершить

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

Всё это касается клиент-серверного варианта 1С:Предприятия 8.3: сервер 1С плюс MS SQL Server или PostgreSQL. По каждой ошибке есть признаки, по которым её узнают, и способ восстановить работу без потери данных.

Из чего состоит сервер 1С и что в нём хрупкое

Чтобы понимать, где тонко, полезно держать в голове схему. Клиент сначала обращается к агенту сервера (ragent, порт 1540). Агент передаёт его менеджеру кластера (rmngr, порт 1541), а тот направляет к рабочему процессу (rphost) из диапазона портов, заданного в свойствах рабочего сервера, по умолчанию 1560–1591.

Сами данные 1С хранит не у себя, а в СУБД. На сервере 1С лежит только служебная информация:

• 📁 реестр кластера — файл 1CV8Clst.lst в каталоге reg_1541;
• 📁 сеансовые данные и кэши — папки snccntx* там же;
• 📁 журнал регистрации каждой базы — папка 1Cv8Log внутри каталога с GUID базы;
• 📁 технологический журнал — туда, куда указывает logcfg.xml, если он включён.

Каталог по умолчанию — srvinfo: в Windows обычно C:\Program Files\1cv8\srvinfo, в Linux — /home/usr1cv8/.1cv8/1C/1cv8. Его путь виден в параметрах запуска службы агента.

Хрупкие места три: реестр кластера, связь «база в кластере ↔ база в СУБД» и свободное место на дисках. Все пять ошибок бьют именно по ним.

Ошибка 1. Удалять файлы базы и служебные каталоги вручную

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

Что ломается в каждом случае:

Как правильно чистить сеансовый кэш

Сеансовые данные действительно иногда «засоряются»: база не открывается, сеансы висят, хотя пользователи давно вышли. Чистят их так:

1. Предупредите пользователей и выберите время вне рабочего дня: все сеансы оборвутся, несохранённые документы пропадут.
2. Скопируйте каталог reg_1541 целиком в другое место.
3. Остановите службу агента сервера 1С.
4. Удалите только папки snccntx*. Файл 1CV8Clst.lst и папки с GUID баз не трогайте.
5. Запустите службу и проверьте подключение к одной базе.

Если после этого кластер не видит баз, верните скопированный каталог при остановленной службе.

Как правильно удалить базу

Удаляют её через консоль администрирования серверов 1С: правой кнопкой по информационной базе → «Удалить». Консоль предложит выбрать, что сделать с базой в СУБД: оставить, очистить или удалить. Так запись в кластере и данные в СУБД уходят согласованно. Перед этим выгрузите .dt или сделайте резервную копию средствами СУБД.

Ошибка 2. Обновлять платформу сразу на рабочем сервере

Новая сборка платформы ставится за пять минут, а последствия разгребают неделю. Вот что обычно ломается:

• 🔌 версия клиента перестаёт совпадать с версией сервера, и пользователи не могут подключиться, пока у каждого не обновится платформа;
• 🧩 внешние компоненты, обработки и обмены, которые работали на старой сборке, начинают падать с ошибками;
• 🗄️ новая платформа не поддерживает используемую версию СУБД или требует другую сборку PostgreSQL;
• 📜 конфигурация старого релиза рассчитана на старую платформу и выдаёт предупреждения или ошибки в типовых механизмах.

Отдельный риск — удалить старую версию до проверки новой. Тогда откатиться за минуты уже не получится.

Безопасный порядок обновления

1. Посмотрите в документации к релизу вашей конфигурации, какая минимальная версия платформы ей нужна, и не ставьте «самую свежую» без причины.
2. Разверните копию рабочей базы на тестовом сервере или на втором кластере.
3. На тестовой копии отключите регламентные задания и обмены: в консоли кластера, в свойствах базы, отметьте «Блокировка регламентных заданий включена».
4. Установите новую платформу на тестовый сервер, прогоните основные сценарии: проведение документов, закрытие месяца , печать, обмены, отчёты.
5. Только после этого ставьте платформу на рабочий сервер, не удаляя прежнюю версию.
6. Обновите клиентов. Автоматическую раздачу удобно настроить через 1cestart и общий каталог дистрибутивов.

Пункт 3 пропускать нельзя. Копия базы с включёнными обменами и регламентными заданиями отправит в банк платёжки, выгрузит заказы на сайт или отчёты в контролирующие органы от имени реальной организации.

Ошибка 3. Менять настройки кластера серверов 1С наугад

Параметры кластера и рабочего сервера влияют на всех пользователей сразу. Одна неудачная цифра — и рабочие процессы начинают перезапускаться посреди дня или, наоборот, раздуваются до исчерпания памяти.

Параметры, которые чаще всего «крутят» без понимания:

Как менять безопасно:

1. Перед изменением запишите текущие значения: сделайте снимок экрана свойств или выведите их через rac cluster list.
2. Меняйте один параметр за раз и наблюдайте за поведением сервера хотя бы день.
3. Ориентируйтесь на объём оперативной памяти: лимит памяти рабочих процессов должен оставлять запас под СУБД, если она стоит на той же машине.
4. Порты рабочих процессов проверяйте по брандмауэру до сохранения настроек, а не после жалоб пользователей.

Пароль администратора кластера тоже относится к настройкам, которые ломают сервер. Если его забыли, восстанавливают реестр кластера из резервной копии при остановленной службе или обращаются к тому, кто его задавал. Сброс «через удаление файлов» превращается в ошибку №1.

Ошибка 4. Прерывать реструктуризацию базы данных

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

Что бывает после обрыва:

• 🔒 база остаётся с незавершённым обновлением: Конфигуратор при следующем входе снова предлагает принять изменения;
• 🧱 часть таблиц уже перестроена, часть нет — при входе в режиме 1С:Предприятие появляются ошибки при обращении к данным;
• 💥 если обрыв случился из-за переполнения диска или падения СУБД, страдает уже сама база в СУБД.

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

Как не прерывать реструктуризацию

1. Перед обновлением сделайте резервную копию средствами СУБД — она надёжнее и быстрее выгрузки .dt на больших базах.
2. Проверьте свободное место: на диске с данными СУБД и с журналом транзакций нужен запас не меньше размера самой большой таблицы базы.
3. Установите блокировку начала сеансов в свойствах базы в консоли кластера и завершите сеансы пользователей. Монопольный доступ для обновления структуры обязателен.
4. Запускайте обновление вечером или в выходные и не трогайте процесс, даже если индикатор долго стоит на месте.
5. Следите за активностью не по окну Конфигуратора, а по СУБД: в MS SQL — по активным запросам, в PostgreSQL — по pg_stat_activity.

Если реструктуризацию всё же оборвали, зайдите в Конфигуратор и снова выполните обновление конфигурации базы данных. Не помогло — восстанавливайте базу из резервной копии, сделанной в пункте 1. «Тестирование и исправление» в клиент-серверной базе не заменяет проверку целостности средствами самой СУБД.

После реструктуризации типовые конфигурации запускают обработчики обновления данных. Их прерывание менее опасно: при следующем входе обработчики продолжат работу, а отложенные доработаются в фоне.

Ошибка 5. Не следить за журналами транзакций и логами

Самая тихая из пяти ошибок. Сервер работает месяцами, а потом в один день останавливается из-за заполненного диска. Источников роста обычно три.

Журнал транзакций MS SQL

Если база в полной модели восстановления (FULL), а резервного копирования журнала нет, файл .ldf растёт без ограничений. Когда место на диске заканчивается, MS SQL перестаёт принимать изменения, и любой сеанс 1С получает ошибку записи.

Проверить модель восстановления и причину, по которой журнал не очищается:

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases;

Если в колонке log_reuse_wait_desc стоит LOG_BACKUP, журнал ждёт резервной копии. Решения два: настроить регулярное копирование журнала или, если восстановление на момент времени вам не нужно, перевести базу в простую модель и сжать файл журнала:

ALTER DATABASE [buh] SET RECOVERY SIMPLE;
USE [buh];
SELECT name FROM sys.database_files WHERE type_desc = 'LOG';
DBCC SHRINKFILE (N'buh_log', 1024);

Логическое имя файла журнала (buh_log в примере) возьмите из результата запроса к sys.database_files. После перехода в простую модель сразу сделайте полную резервную копию.

WAL у PostgreSQL

У PostgreSQL аналог — каталог pg_wal. Он раздувается, если не работает архивирование WAL или висит неактивный слот репликации:

SELECT slot_name, active, restart_lsn FROM pg_replication_slots;

Неактивный слот, который больше не нужен, удаляют функцией pg_drop_replication_slot('имя_слота'). Файлы в pg_wal вручную не удаляют никогда — это возвращает к ошибке №1.

Журнал регистрации и технологический журнал 1С

Журнал регистрации большой базы легко занимает десятки гигабайт в srvinfo. Уровень записи и сокращение старых событий настраиваются в Конфигураторе: Администрирование → Настройка журнала регистрации.

Технологический журнал опаснее. Его включают через logcfg.xml «на время расследования» и забывают. С событиями уровня всех вызовов он пишет гигабайты в час. После диагностики удаляйте logcfg.xml или ставьте в нём параметр history с ограничением хранения в часах.

Сервер уже упал: в каком порядке поднимать

Когда пользователи звонят одновременно, главное — не сделать хуже. Порядок такой:

1. Проверьте свободное место на всех дисках сервера 1С и сервера СУБД. Заполненный диск — самая частая причина.
2. Проверьте, запущена ли служба СУБД и открывается ли база средствами СУБД.
3. Проверьте, запущена ли служба агента сервера 1С и видит ли консоль кластер и базы.
4. Посмотрите журнал регистрации проблемной базы и журнал событий Windows или journalctl в Linux за время сбоя.
5. Только после диагностики перезапускайте службы — и с предупреждением пользователей, потому что сеансы оборвутся.

Частые вопросы о сбоях сервера 1С