Диск сервера 1С заполнен: что можно удалить, а что трогать нельзя

Чаще всего место на сервере 1С съедают пять вещей: сеансовые данные кластера (папки snccntx* в каталоге srvinfo\reg_1541), журнал регистрации, забытый технологический журнал, дампы процессов и лог транзакций СУБД. Освободить место можно без переустановки: часть файлов удаляется на ходу, часть — только при остановленной службе агента сервера 1С.

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

Где искать: что занимает место на сервере 1С

Не удаляйте ничего вслепую. Сначала посмотрите, какие папки реально выросли. На Windows подойдёт WinDirStat или TreeSize, на Linux — du.

Типичные «пожиратели» диска:

• 🗂️ Каталог кластера C:\Program Files\1cv8\srvinfo\reg_1541\ — сеансовые данные и журналы регистрации всех серверных баз.
• 📜 Технологический журнал — путь задан в файле logcfg.xml, его часто включают для расследования и забывают выключить.
• 💥 Дампы (*.mdmp) — каждый падающий рабочий процесс оставляет файл от десятков мегабайт до нескольких гигабайт.
• 🗄️ Файлы СУБД — лог транзакций .ldf в MS SQL Server, раздутые таблицы в PostgreSQL.
• 📦 Шаблоны конфигураций и архивы обновлений — каталог tmplts в профиле пользователя.
• 🧹 Временные файлы в TEMP пользователя, от имени которого работает служба (по умолчанию USR1CV8).

Быстрый отчёт по размеру папок кластера в PowerShell:

$root = 'C:\Program Files\1cv8\srvinfo\reg_1541'
Get-ChildItem $root -Directory | ForEach-Object {
  $size = (Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue |
           Measure-Object Length -Sum).Sum
  [PSCustomObject]@{ Folder = $_.Name; GB = [math]::Round($size / 1GB, 2) }
} | Sort-Object GB -Descending | Select-Object -First 15

На Linux то же самое одной строкой (путь каталога кластера смотрите в параметре -d службы):

du -h --max-depth=1 /home/usr1cv8/.1cv8/1C/1cv8/reg_1541 | sort -rh | head -20

Папки с именами-GUID — это информационные базы. Чтобы понять, какой базе принадлежит папка, откройте текстовый файл 1CV8Clst.lst в том же каталоге и найдите GUID поиском: рядом будет имя базы. Только читайте его, не редактируйте и не удаляйте 1CV8Clst.lst — это реестр кластера.

Сеансовые данные и временные файлы кластера

Папки snccntx + GUID в каталоге reg_1541 хранят сеансовые данные: контексты сеансов и служебные кэши кластера. При долгой работе без перезапуска и после аварийных завершений они вырастают до десятков гигабайт. Заодно из-за них появляются «зависшие» сеансы и странные ошибки при входе.

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

Порядок очистки на Windows

1. Попросите пользователей выйти. Проверьте в консоли кластера, что активных сеансов нет, и дождитесь окончания фоновых заданий.
2. Остановите службу агента сервера. Точное имя посмотрите в services.msc — оно зависит от версии и разрядности, например 1C:Enterprise 8.3 Server Agent (x86-64).
3. Откройте C:\Program Files\1cv8\srvinfo\reg_1541\ и удалите все папки, имя которых начинается на snccntx.
4. Очистите временный каталог служебного пользователя: обычно C:\Users\USR1CV8\AppData\Local\Temp. Файлы вида v8_*.tmp удаляйте смело.
5. Запустите службу и проверьте вход в одну-две базы.

То же на Linux

Имя юнита зависит от способа установки. Для новых версий платформы это шаблонный юнит с номером версии, для старых — srv1cv83. Найти его можно так:

systemctl list-units --all | grep srv1cv8

Дальше: systemctl stop <имя_юнита>, удаление папок snccntx* в каталоге reg_1541, очистка /tmp от файлов v8_*, затем systemctl start <имя_юнита>.

Файлы блокировок файловых баз

Если на сервере лежат файловые базы, в каталоге каждой есть файл 1Cv8.1CL. Он создаётся при подключении пользователей и после аварийного завершения иногда остаётся. Места он почти не занимает, но мешает монопольным операциям. Удаляйте его, только когда к базе точно никто не подключён: иначе работающие сеансы получат ошибки.

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

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

Журнал регистрации серверной базы лежит в папке reg_1541\<GUID базы>\1Cv8Log\. Формат бывает двух видов:

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

Для последовательного формата есть быстрый путь. Файлы .lgp названы по дате начала периода. Старые файлы, например старше года, можно переложить на другой диск. Файл 1Cv8.lgf не трогайте: в нём словари журнала.

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

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

Технологический журнал включается файлом logcfg.xml. Он лежит в C:\Program Files\1cv8\conf\ (действует для всех версий платформы) или в bin\conf конкретной версии. Типичная ситуация: техжурнал включили для поиска блокировок, нашли проблему и забыли. Через месяц на диске 200 ГБ логов.

Что сделать:

1. Удалите старые подкаталоги журнала в папке, указанной в атрибуте location. Это можно делать без остановки службы, кроме текущего часа: он занят процессом.
2. Если техжурнал больше не нужен — удалите или переименуйте logcfg.xml. Платформа перечитывает файл примерно раз в минуту, перезапуск не требуется.
3. Если нужен — ограничьте срок хранения атрибутом history (в часах) и уберите лишние события.

Пример «бережливой» настройки: только исключения, хранение двое суток.

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

Выносите техжурнал на отдельный диск, не на системный. Если он заполнит C:, остановится не только 1С, но и сама Windows начнёт сбоить.

Дампы процессов и файлы СУБД

Дампы

При падении рабочего процесса платформа пишет дамп .mdmp. Каталог задаётся элементом dump в logcfg.xml. Если он не задан, дампы попадают в профиль пользователя службы, обычно в AppData\Local\1C\1cv8\dumps. Полные дампы весят гигабайты. Удаляйте старые: для разбора нужен один-два свежих. Если дампы появляются каждый день — это повод разбираться с падениями, а не просто чистить папку.

MS SQL Server: лог транзакций

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

Два варианта решения:

• ✅ Нужно восстановление на момент времени — настройте регулярное резервное копирование журнала (BACKUP LOG), после него файл можно сжать.
• ✅ Достаточно ежедневной полной копии — переведите базу в модель SIMPLE и сожмите лог.

-- узнать логическое имя файла лога
USE [buh];
SELECT name, type_desc, size / 128 AS size_mb FROM sys.database_files;

-- перевести в простую модель и сжать лог до 1 ГБ
ALTER DATABASE [buh] SET RECOVERY SIMPLE;
DBCC SHRINKFILE (N'buh_log', 1024);

Не сжимайте файл данных .mdf регулярно: это фрагментирует индексы, а файл всё равно вырастет снова.

PostgreSQL

В PostgreSQL место часто занимают «мёртвые» строки после массовых удалений и перепроведений. Обычный VACUUM освобождает место для повторного использования внутри файлов, а вернуть его операционной системе может VACUUM FULL. Он блокирует таблицы на время работы — запускайте его только в окно обслуживания, когда пользователей в базе нет.

Каталог pg_wal вручную не чистите никогда. Если он растёт, проверьте настройки архивации WAL и неиспользуемые слоты репликации.

Кэш, шаблоны конфигураций и хранилище

Шаблоны и обновления

При установке обновлений через Конфигуратор шаблоны конфигураций складываются в каталог шаблонов, по умолчанию %APPDATA%\1C\1cv8\tmplts\. Каждый релиз Бухгалтерии или ЗУП — это сотни мегабайт. За пару лет обновлений набираются десятки гигабайт.

Оставьте последний релиз каждой конфигурации, остальное удалите. Шаблон всегда можно скачать заново с портала поддержки. Там же проверьте каталоги со скачанными дистрибутивами и архивами .dt перед обновлением: копии полугодовой давности обычно уже не нужны.

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

Если сервер 1С заодно работает как терминальный, у каждого пользователя в профиле есть кэш: %APPDATA%\1C\1cv8\ и %LOCALAPPDATA%\1C\1cv8\, папки с GUID внутри. На 30 пользователях это легко 20–40 ГБ.

Безопасно удалять папки с GUID, когда пользователь вышел из 1С. Список баз (ibases.v8i) и настройки в корне каталога не трогайте. Альтернатива — запуск клиента с параметром /ClearCache: он очищает кэш конкретной базы при входе.

Хранилище конфигурации

Хранилище хранит все версии конфигурации с момента создания и со временем вырастает до многих гигабайт. Простой кнопки «удалить старые версии » для этого нет. Рабочий вариант — заархивировать старое хранилище и создать новое из текущей конфигурации. Историю версий при этом начинаете заново, поэтому согласуйте шаг с разработчиками.

Регламентные задания, которые раздувают базу

Иногда растёт не служебная папка, а сама база: файл 1Cv8.1CD у файловой базы или файл данных в СУБД. Причина обычно в фоновых механизмах, которые копят данные.

Где смотреть в типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11): Администрирование → Обслуживание → Регламентные и фоновые задания. Найдите задания, связанные с:

• 📚 версионированием объектов — история изменений документов и справочников, при включённом хранении без срока растёт годами;
• 🔄 обменами данными — неотправленные сообщения и пакеты обмена копятся, если узел давно не синхронизировался;
• 📊 полнотекстовым поиском — индекс пересоздаётся и занимает место в каталоге базы;
• 🗑️ удалением помеченных объектов — если его нет, помеченные документы годами лежат в базе.

Что сделать:

1. Проверьте, что регламентное задание очистки устаревших версий объектов включено и имеет расписание. Найти его проще всего фильтром списка по слову «версий».
2. В настройках версионирования задайте срок хранения истории, например один-два года.
3. Удалите мёртвые узлы обмена, с которыми синхронизация больше не идёт.
4. Запустите удаление помеченных объектов: Администрирование → Обслуживание → Удаление помеченных объектов.

Для файловой базы место на диске после удаления данных не вернётся само. Нужно сжать файл: Конфигуратор → Администрирование → Тестирование и исправление, флажок «Сжатие таблиц информационной базы». Эта операция требует монопольного доступа — все пользователи должны выйти. Перед ней обязательно выгрузите базу в .dt.

Автоматическая очистка сервера 1С

Ручная уборка раз в полгода не спасает: диск снова заполнится в самый неудобный момент. Достаточно трёх вещей.

1. Скрипт удаления старых файлов. На Windows — forfiles в планировщике заданий, раз в сутки ночью:

@echo off
rem техжурнал старше 3 дней
forfiles /p "D:\1c_techlog" /s /m *.log /d -3 /c "cmd /c del /q @path"
rem дампы старше 14 дней
forfiles /p "D:\1c_dumps" /m *.mdmp /d -14 /c "cmd /c del /q @path"
rem временные файлы службы старше 2 дней
forfiles /p "C:\Users\USR1CV8\AppData\Local\Temp" /m v8_*.tmp /d -2 /c "cmd /c del /q @path"

На Linux — find в cron:

find /var/log/1c_techlog -type f -name "*.log" -mtime +3 -delete
find /var/1c_dumps -type f -name "*.mdmp" -mtime +14 -delete

2. Плановый перезапуск службы с очисткой сеансовых данных. Раз в неделю или месяц, ночью в выходной. В скрипт: остановка службы, удаление snccntx*, запуск. Перед остановкой убедитесь, что на это время не стоят регламентные задания и ночные обмены — они прервутся.

3. Мониторинг свободного места. Порог предупреждения — 15–20% свободного места на диске с базами и srvinfo. Подойдёт любая система мониторинга или простая задача планировщика, которая пишет в журнал Windows. Важно узнать о проблеме за неделю, а не когда база перестала открываться.

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