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

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

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

Шаг 1. Найдите, что именно заняло диск

Прежде чем что-то удалять, определите структуру занятого пространства. На Windows удобны бесплатные утилиты вроде WinDirStat или TreeSize — они показывают дерево каталогов с размерами. На Linux достаточно команды du.

du -h --max-depth=2 / | sort -rh | head -20

Типичные кандидаты на сервере 1С: каталог кластера сервера 1С (reg_1541 и папки журналов), каталоги баз данных СУБД (data и log), папка временных файлов, каталог с резервными копиями, корзина и теневые копии Windows. Отдельно проверьте каталог srvinfo — в нём лежат журналы регистрации файловых и серверных баз.

Сократите журнал регистрации

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

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

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

1. 1
   Сделайте резервную копию базы перед сокращением
2. 2
   Откройте конфигуратор: Администрирование → Настройка журнала регистрации
3. 3
   Нажмите «Сократить», укажите дату и файл для сохранения удаляемой части
4. 4
   Дождитесь завершения и проверьте размер 1Cv8.lgd
5. 5
   Настройте уровень регистрируемых событий для замедления роста

Разберитесь с файлами СУБД: tempdb, логи транзакций, индексы

Если сервер 1С работает на MS SQL Server, проверьте размер tempdb и файлов журнала транзакций (.ldf) рабочих баз. Tempdb очищается автоматически при перезапуске службы SQL Server — часто это самый быстрый способ вернуть десятки гигабайт. Сжимать tempdb штатными средствами без перезапуска не рекомендуется.

Журнал транзакций рабочей базы раздувается, если база в полной модели восстановления (Full), а бэкапы журнала не выполняются. Решение: либо настроить регулярное резервное копирование журнала (после него место внутри файла освобождается), либо, если восстановление на момент времени не требуется, перевести базу в простую модель (Simple) и выполнить сжатие файла журнала.

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

Наведите порядок в резервных копиях и выгрузках

Самый частый источник «тихого» заполнения диска — автоматические бэкапы, которые пишутся локально годами. Проверьте папки заданий обслуживания СУБД, скрипты выгрузки .dt и планировщик задач. Установите политику хранения: например, локально — последние несколько копий для быстрого восстановления, всё остальное — на сетевое хранилище, NAS или в облако.

При переносе проверяйте целостность копий: для .dt — тестовая загрузка в отдельную базу, для бэкапов SQL Server — команда RESTORE VERIFYONLY. Удалять старые копии до проверки новых нельзя: иначе рискуете остаться вообще без работоспособного бэкапа.

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

Временные файлы накапливаются в нескольких местах: каталоги temp пользователей и системной учётной записи, под которой работает агент сервера 1С (например, C:\Windows\Temp и профили USR1CV8), папка очереди печати, загруженные обновления Windows. Очистка этих каталогов безопасна при остановленных службах сервера 1С и СУБД.

На Windows дополнительно проверьте: теневые копии (vssadmin list shadows), файл подкачки и гибернации, старые дампы памяти, каталог SoftwareDistribution с обновлениями. На сервере 1С также посмотрите папку с хранилищем конфигурации и каталоги полнотекстового поиска — индексы можно перестроить после очистки.

Предотвратите повторное заполнение диска

Разовая очистка решает проблему на недели. Чтобы ситуация не повторилась, настройте регламент: автоматическое сокращение журнала регистрации по расписанию, ротацию бэкапов с ограничением глубины хранения, мониторинг свободного места с оповещением при снижении ниже порога (обычно 15–20% диска).

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

Проверьте результат и границы самостоятельной работы

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

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

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