Регламентное обслуживание сервера 1С:Предприятия: состав работ и график

Обслуживание серверов 1С — это регулярные работы на трёх уровнях: СУБД (индексы, статистика, проверка целостности), кластер 1С (рабочие процессы, кэш, журнал регистрации) и операционная система (обновления, доступ, диск). Плюс резервные копии и мониторинг. Без этого база через полгода-год начинает тормозить, а при сбое восстанавливать её не из чего.

Работы делят по частоте. Ежедневно — резервная копия и обновление статистики. Еженедельно — перестроение индексов и проверка целостности. Раз в месяц — разбор технологического журнала, чистка кэша, проверка восстановления из копии. Всё ниже относится к клиент-серверному варианту 1С:Предприятия 8.3 на Windows Server 2016 и новее.

Что входит в обслуживание сервера 1С и зачем оно нужно

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

Пользователь видит это так:

• 🐢 отчёт, который строился за 10 секунд, теперь идёт минуту;
• 🔒 при проведении документов всё чаще появляется Конфликт блокировок при выполнении транзакции;
• 💾 на диске с базой внезапно кончается место;
• ❌ после аварийного отключения база не открывается, а свежей копии нет.

Регламентное обслуживание закрывает эти риски заранее. Базовый график выглядит так:

Для маленькой фирмы на 5-10 пользователей это пара часов настройки и полчаса в месяц на контроль. Для базы на сотни гигабайт и 100+ сеансов — отдельная работа администратора.

Обслуживание СУБД: индексы, статистика, целостность

Основная нагрузка 1С ложится на СУБД. Поэтому и основной регламент — там.

MS SQL Server

В SQL Server Management Studio создайте план обслуживания: Management → Maintenance Plans → Maintenance Plan Wizard. Включите в него задачи:

1. Check Database Integrity — проверка целостности, раз в неделю.
2. Rebuild Index или Reorganize Index — раз в неделю, ночью в выходные. Перестроение тяжелее, реорганизация мягче.
3. Update Statistics — ежедневно. После перестроения индексов статистика по ним обновляется сама.
4. Back Up Database (Full) — ежедневно.
5. Maintenance Cleanup Task — удаление копий старше N дней.

То же можно сделать запросом, например для базы buh:

USE buh;
EXEC sp_updatestats;
DBCC CHECKDB (N'buh') WITH NO_INFOMSGS;

Две настройки, о которых часто забывают:

• 📈 Максимальная память сервера (max server memory). Без ограничения SQL заберёт почти всю ОЗУ, и рабочим процессам 1С на том же сервере станет тесно.
• 📄 Модель восстановления. При модели Full журнал транзакций растёт, пока вы не сделаете его копию. Если копий журнала нет — переключите базу на Simple или настройте их.

💡 В SQL Server Express нет SQL Agent, поэтому план обслуживания там не запустить по расписанию. Регламент делают скриптом через sqlcmd и Планировщик заданий Windows.

PostgreSQL

В PostgreSQL роль перестроения статистики и чистки «мёртвых» строк выполняет VACUUM с ANALYZE. Автоочистка (autovacuum) включена по умолчанию, но на больших базах 1С она не всегда успевает. Добавьте ночной проход:

vacuumdb --all --analyze -U postgres

Полный VACUUM FULL блокирует таблицы на время работы. Его запускают только в окно обслуживания, когда пользователей нет.

Обслуживание кластера серверов 1С

Второй уровень — сам сервер 1С:Предприятия. Им управляют через консоль администрирования серверов 1С или утилиту rac (нужна запущенная служба ras).

Рабочие процессы и память

Процесс rphost со временем растёт в памяти. Чтобы он не упирался в потолок, в свойствах кластера задают:

• Интервал перезапуска — например, 86 400 секунд (сутки). Кластер поднимет новый процесс и переведёт на него соединения.
• Допустимый объём памяти рабочих процессов и интервал превышения — при превышении процесс перезапускается.

Порты стоит держать в голове: клиент обращается к агенту сервера (1540), тот направляет к менеджеру кластера (1541) и рабочим процессам. Диапазон портов рабочих процессов (по умолчанию 1560-1591) задаётся в свойствах рабочего сервера.

Кэш сервера 1С

Сервер хранит сеансовые данные в каталоге srvinfo. По умолчанию это C:\Program Files\1cv8\srvinfo\reg_1541\, внутри — папки с идентификаторами баз и папки snccntx*. Когда после обновления конфигурации появляются странные ошибки, «призраки» старых форм или зависшие сеансы, кэш чистят:

1. Предупредите пользователей и дождитесь, пока все выйдут.
2. Остановите службу «Агент сервера 1С:Предприятия 8.3».
3. Удалите папки snccntx* в каталоге reg_1541.
4. Запустите службу.

Журнал регистрации

Журнал регистрации пишется в папку базы 1Cv8Log и может разрастаться до десятков гигабайт. В Конфигураторе через Администрирование → Настройка журнала регистрации можно выбрать уровень событий и сократить журнал, выгрузив старые записи в файл.

Защита сервера 1С и данных

Сервер 1С держит бухгалтерию, зарплату и персональные данные сотрудников. Минимальный набор мер:

• 👤 Отдельная учётная запись службы. Агент сервера работает под непривилегированной учёткой (по умолчанию USR1CV8), а не под администратором домена.
• 🔑 Администратор кластера. Без него любой, кто дотянулся до консоли по сети, может завершать сеансы и удалять базы из кластера.
• 🧱 Брандмауэр. Открыты только 1540, 1541 и диапазон рабочих процессов, и только для подсетей пользователей. Порт СУБД (1433 для MS SQL, 5432 для PostgreSQL) — только для самого сервера 1С.
• 🚫 Нет прямого доступа к СУБД у пользователей. Учётка, под которой 1С ходит в SQL, не выдаётся никому.
• 🛡 Профили безопасности в кластере ограничивают, к каким файлам, COM-объектам и внешним ресурсам может обращаться код базы. Полезно, если вы подключаете внешние обработки.
• 🔐 Пароли пользователей 1С — у каждого свой, у администраторов сложный. Общий логин «Бухгалтер» на трёх человек делает журнал регистрации бесполезным.

Обновления ОС ставьте по графику и с перезагрузкой в окно обслуживания, а не «когда Windows решит сама».

Для персональных данных работает 152-ФЗ: оператор обязан принять меры защиты, а сервер с кадровой базой — первое, что проверят.

Резервное копирование и восстановление базы 1С

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

Способы резервного копирования

Выгрузку .dt автоматизируют пакетным запуском Конфигуратора:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /S "srv1c\buh" /N "Admin" /P "Пароль" /DumpIB "D:\backup\buh_%date:~-4%%date:~3,2%%date:~0,2%.dt" /Out "D:\backup\dump.log"

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

Правило хранения

Держите минимум три копии на двух разных носителях, одну — вне сервера (другая площадка или облако). Копия на том же диске, что и база, погибнет вместе с ним.

Проверка восстановления

Раз в месяц разворачивайте свежую копию в тестовую базу и открывайте её: проводится ли документ, строится ли оборотно-сальдовая ведомость. Засеките время — это ваш реальный срок простоя при аварии.

Мониторинг и диагностика производительности

Тормоза надо ловить по цифрам, а не по жалобам. Что смотреть:

На уровне ОС

• 💽 свободное место на дисках с базами, журналами и копиями — тревога при остатке меньше 15-20%;
• 🧠 загрузка процессора и памяти, длина очереди диска (Монитор производительности Windows);
• ⏱ длительность ночных заданий: если копия раньше шла 20 минут, а теперь 2 часа, что-то не так.

В консоли кластера

В списке сеансов видно, кто и сколько держит вызовов к СУБД, кто занимает лицензии. Подвисший сеанс можно завершить, но пользователь потеряет несохранённую работу — сначала позвоните ему. Из командной строки список сеансов даёт rac session list (параметры подключения — в rac help).

Технологический журнал

Главный инструмент разбора медленной работы. Он включается файлом logcfg.xml в каталоге conf установки платформы. Пример настройки на исключения, взаимоблокировки и таймауты:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <property name="all"/>
  </log>
</config>

history="24" — хранить 24 часа. Технологический журнал пишет много, поэтому выносите его на отдельный диск и не оставляйте подробную запись включённой месяцами.

💡 Для системного мониторинга есть «Центр управления производительностью» из инструментов КИП: он считает показатель APDEX по ключевым операциям и показывает, когда и где пользователи ждут.

Автоматизация регламентных работ

Ручной регламент живёт ровно до первого отпуска администратора. Автоматизируйте всё, что повторяется:

1. Задания SQL Agent (MS SQL) — план обслуживания с расписанием и уведомлением на почту при сбое.
2. Планировщик заданий Windows — выгрузка .dt, vacuumdb для PostgreSQL, чистка старых файлов копий и логов.
3. Настройки кластера — перезапуск рабочих процессов по интервалу и объёму памяти.
4. Окно обслуживания. На время тяжёлых операций в свойствах базы в консоли кластера включают «Блокировку начала сеансов» и «Блокировку регламентных заданий», а потом снимают.

Очистка старых копий на PowerShell, хранить 14 дней:

Get-ChildItem "D:\backup" -Filter *.dt | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-14) } | Remove-Item

Каждому заданию нужен контроль результата: письмо или сообщение в мессенджер при ошибке. Задание, которое тихо падает месяцами, хуже, чем его отсутствие, — оно создаёт ложное чувство защищённости.

Частые вопросы об обслуживании сервера 1С