Как почистить сервер 1С без риска для данных

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

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

Материал ориентирован на типовую связку: Windows Server или Linux, сервер 1С:Предприятия и MS SQL Server или PostgreSQL. Конкретные пути и команды могут отличаться в зависимости от версии платформы и настроек — сверяйте их со своей конфигурацией.

С чего начать: диагностика перед чисткой

Прежде чем что-то удалять, определите, что именно занимает место и замедляет работу. В Windows для поиска крупных каталогов подойдут встроенные средства просмотра диска или сторонние анализаторы, в Linux — команда du -sh /* с последующим углублением в проблемные каталоги. Чаще всего «тяжёлыми» оказываются каталоги кластера 1С (srvinfo), папка данных СУБД, журналы транзакций и системные временные каталоги.

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

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

Обязательный первый шаг — полная резервная копия информационной базы средствами СУБД, а не только выгрузка в dt. Копия средствами СУБД восстанавливается быстрее и надёжнее, а dt-файл служит дополнительной страховкой. Убедитесь, что копия действительно создалась и лежит на другом диске или сетевом хранилище, а не на том же разделе, который вы собираетесь чистить.

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

Чистка журнала регистрации и данных кластера 1С

Журнал регистрации в формате SQLite (файл 1Cv8.lgd в каталоге базы внутри srvinfo) со временем вырастает до десятков гигабайт и замедляет запись событий. Сократить его можно из конфигуратора: меню «Администрирование» → «Настройка журнала регистрации» → кнопка «Сократить». Укажите дату, до которой удалять события, и обязательно поставьте флаг сохранения удаляемой части в отдельный файл, если история может понадобиться для аудита.

В каталоге кластера также накапливаются служебные данные: файлы сеансовых данных, журналы технологического журнала, если он включён. Технологический журнал (каталог, заданный в logcfg.xml) нужно чистить вручную или скриптом по расписанию — платформа сама его не ротирует. Оставляйте журналы за последние дни, остальное архивируйте или удаляйте.

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

Очистка временных файлов и кэша

Временные файлы сервера 1С складываются в каталогах, заданных переменными окружения TMP и TEMP учётной записи, под которой работает агент сервера (по умолчанию на Windows — C:\Windows\Temp и профиль служебного пользователя USR1CV8). Их можно удалять при остановленной службе агента сервера. На работающем сервере часть файлов будет заблокирована — это нормально, удаляйте то, что удаляется.

Кэш метаданных на сервере и клиентах — отдельная история. Признаки «битого» кэша: странные ошибки после обновления конфигурации, формы, которые выглядят не так, как в конфигураторе, сообщения о несоответствии версий. Клиентский кэш лежит в профилях пользователей (%APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8) и удаляется при закрытом клиенте. На сервере пересоздание кэша происходит после перезапуска агента с очисткой соответствующих служебных каталогов.

1. 1
   Остановите регламентные задания и завершите сеансы пользователей
2. 2
   Остановите службу агента сервера 1С
3. 3
   Удалите содержимое каталогов TEMP/TMP служебной учётной записи
4. 4
   Очистите каталоги технологического журнала, оставив свежие файлы
5. 5
   Запустите службу агента и проверьте, что базы доступны
6. 6
   На клиентских машинах при проблемах удалите кэш в %APPDATA%\1C и %LOCALAPPDATA%\1C

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

Самая частая причина переполнения диска на сервере с MS SQL — разросшийся журнал транзакций (файл .ldf). Это происходит при модели восстановления Full без регулярных бэкапов журнала. Решение: либо настроить регулярное резервное копирование журнала транзакций, либо, если точечное восстановление не требуется, перевести базу в модель Simple и выполнить сжатие файла журнала. Просто удалить или «обрезать» файл в обход СУБД нельзя — это разрушит базу.

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

Регулярное обновление статистики и перестроение или реорганизация индексов — основа стабильной производительности. Настройте план обслуживания в MS SQL или задания pg_repack/analyze для PostgreSQL на ночное время. Признак того, что пора: запросы, которые раньше выполнялись секунды, начали «подвисать» без изменения объёма данных.

-- MS SQL: проверить модель восстановления и размер журнала
SELECT name, recovery_model_desc FROM sys.databases;
DBCC SQLPERF(LOGSPACE);
-- Перевод в Simple и сжатие журнала (только если не нужны бэкапы лога)
ALTER DATABASE [Base1C] SET RECOVERY SIMPLE;
DBCC SHRINKFILE (N'Base1C_log', 1024);

Чистка данных внутри информационной базы

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

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

Тестирование и исправление информационной базы (ТиИ) с включённой реиндексацией стоит запускать после массовых удалений и при подозрении на повреждения. Для клиент-серверных баз реиндексация средствами СУБД обычно эффективнее, а ТиИ оставьте для проверки логической целостности. Запускайте его только в монопольном режиме и при наличии свежей копии.

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

На уровне операционной системы проверьте журналы событий Windows (их размер ограничивается в настройках каждого журнала), каталог C:\Windows\SoftwareDistribution\Download с кэшем обновлений, старые файлы подкачки и точки восстановления. В Linux обратите внимание на /var/log (настройте logrotate), кэш пакетного менеджера и старые ядра. Встроенная утилита очистки диска Windows безопасно удаляет временные системные файлы и старые обновления.

Отдельно проверьте, куда пишутся резервные копии СУБД: нередко локальный диск забивается именно старыми бэкапами. Настройте автоматическое удаление копий старше заданного срока и перенос архивов на сетевое хранилище. Диск, на котором лежат данные СУБД, должен иметь запас свободного места — при заполнении выше 90% резко растёт риск остановки базы и повреждения файлов.

Регламент: как не превратить чистку в авральное мероприятие

Разовая генеральная уборка решает проблему на недели, после чего всё возвращается. Рабочая схема — расписание: ежедневно (бэкапы и бэкапы журналов), еженедельно (обновление статистики, проверка свободного места), ежемесячно (реиндексация, сокращение журнала регистрации, удаление помеченных объектов), ежеквартально или раз в полгода (ревизия крупных таблиц, архивация старых данных, проверка восстановления из копии).

Автоматизируйте то, что можно: планы обслуживания в СУБД, скрипты очистки каталогов по расписанию, мониторинг свободного места с оповещением при превышении порога. Любой автоматический скрипт удаления сначала тестируйте на копии и логируйте его действия — чтобы при сбое было видно, что именно он удалил.

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