К статье
Практический материал

Администрирование · 9 мин

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

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

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

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

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

Кэш метаданных: главный кандидат на удаление

Кэш метаданных — это служебные файлы, которые платформа создаёт для ускорения запуска и работы базы. Они хранятся в профиле пользователя операционной системы и полностью пересоздаются при следующем запуске. Удаление кэша — стандартный приём при ошибках вида «ошибка формата потока», при некорректном отображении форм и при зависании базы на старте.

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

Порядок очистки кэша
  1. 1
    Закройте все сеансы 1С:Предприятие и Конфигуратор на компьютере
  2. 2
    Нажмите Win+R, введите %APPDATA%\1C\1cv8 и удалите папки с GUID-именами
  3. 3
    Повторите для %LOCALAPPDATA%\1C\1cv8
  4. 4
    Запустите базу — платформа пересоздаст кэш, первый запуск займёт больше времени
  5. 5
    Проверьте, что база открывается и формы работают корректно

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

Временные файлы и папка temp

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

Безопасно очищается содержимое папок %TEMP% и C:\Windows\Temp — при условии, что 1С и другие программы закрыты. Файлы, которые сейчас заняты каким-либо процессом, система не даст удалить, и это нормально: пропустите их. Особое внимание стоит уделить файлам с именами вида v8_*.tmp и каталогам с длинными случайными именами — это типичные следы работы платформы.

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

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

Технологический журнал (каталог, указанный в конфигурационном файле logcfg.xml) — другое дело. Это диагностические дампы и логи, которые нужны только для анализа проблем. После того как диагностика завершена и данные переданы специалисту, содержимое каталога технологического журнала можно удалять полностью. Само включение технжурнала без необходимости — частая причина переполнения диска на сервере.

Резервные копии, выгрузки и файлы обновлений

Файлы выгрузок .dt, архивы .zip с копиями баз и дистрибутивы обновлений конфигураций — легитимные кандидаты на удаление, но с условиями. Выгрузка .dt имеет смысл хранить ограниченный период: старые копии, возраст которых превышает несколько месяцев, обычно бесполезны, потому что восстановление из них означает потерю всех данных за прошедший срок.

Дистрибутивы обновлений (папки с шаблонами в каталоге tmplts, обычно %APPDATA%\1C\1cv8\tmplts) занимают заметное место — каждая версия конфигурации может весить сотни мегабайт. Старые версии шаблонов можно удалять: они потребуются только для обновления с очень старого релиза, что на практике редкость. Оставьте шаблоны текущей и предыдущей версии.

Маршрут решения

Как выбрать действие

Файл находится в профиле пользователя (AppData) и создан платформойМожно удалять — платформа пересоздаст его при запуске
Файл лежит в каталоге базы рядом с 1Cv8.1CDНе трогайте напрямую, используйте штатные средства Конфигуратора
Это резервная копия старше нескольких месяцев и есть более свежиеПеренесите на внешний носитель или удалите после проверки актуальных копий
Файл в каталоге srvinfo или в данных СУБДНе удаляйте ни при каких обстоятельствах без полного бэкапа и понимания структуры

Что удалять нельзя: границы безопасной работы

Файл 1Cv8.1CD — это сама файловая база данных. Его удаление, перемещение или переименование во время работы пользователей приводит к разрушению базы. То же относится к служебным файлам 1Cv8.1CL, 1Cv8.cgr и каталогам 1Cv8Log, 1Cv8FTxt (полнотекстовый индекс — перестроится, но это займёт время).

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

Типичные ошибки
01
Удаление кэша при открытых сеансах — пользователи получают ошибки, а кэш пересоздаётся повреждённым
02
Очистка каталога srvinfo «для освобождения места» — теряется список баз кластера и настройки сервера
03
Удаление всех резервных копий ради места на диске — при сбое восстанавливать нечего
04
Ручное удаление файлов журнала регистрации из папки базы — база может перестать открываться
05
Очистка temp во время обмена данными или обновления — обрыв процесса и возможная рассинхронизация

Порядок безопасной очистки и проверка результата

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

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

Контрольные точки

Как проверить результат

Запуск базы после удаления кэша
Норма

База открывается, первый запуск дольше обычного, далее скорость нормальная

Тревожный признак

Ошибка формата потока или база не открывается — нужна проверка chdbfl или восстановление из копии

Место на диске после очистки
Норма

Освободилось ожидаемое количество гигабайт, системные папки не тронуты

Тревожный признак

Место не освободилось — вероятно, основной объём занимает сама база или журналы СУБД

Работа пользователей после очистки
Норма

Все сеансы запускаются, отчёты и документы работают

Тревожный признак

У части пользователей ошибки — на их ПК кэш не очищался или очищен при открытом сеансе

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

Часто задаваемые вопросы

Можно ли удалить папку с GUID-именем в AppData, если база уже удалена из списка?

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

Сколько резервных копий базы стоит хранить?

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

Можно ли удалить файл 1Cv8.1CL и что это такое?

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

Освободит ли удаление кэша много места на диске?

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

Чем чистить базу в клиент-серверном варианте, если растёт размер в SQL?

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

Нужно ли делать бэкап перед удалением кэша?

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

Итог

Что важно запомнить

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