Что за файлы с названиями типа BBLxxxxxxx.sql в папке WinTEMP и можно ли их удалять при работе 1С на PostgreSQL

Системный администратор IT и автоматизация бизнеса
← На главную

При администрировании серверов, на которых развернута связка 1С:Предприятие и PostgreSQL, системные администраторы часто сталкиваются с проблемой стремительного исчезновения свободного места на системном диске. Одной из причин этого явления становятся загадочные файлы в папке WinTEMP (обычно это C:\Windows\Temp или временные папки пользователей), имеющие маску названия типа BBL202004221400.sql. Разберем подробно природу этих файлов, выясним, откуда они берутся, и решим, что с ними делать.

Анализируем происхождение и структуру названия файлов

Проанализируем структуру имени типичного файла, например, BBL202004221400.sql. Как показывает практика и опыт участников сообщества, такое именование не является случайным набором символов. Рассмотрим его по частям:

  1. Первые символы (Префикс): В данном примере BBL — это сокращенное или полное имя (алиас) базы данных в PostgreSQL. Часто администраторы настраивают скрипты так, чтобы имя файла начиналось с идентификатора информационной базы 1С.
  2. Цифровой блок: Числа 202004221400 представляют собой метку времени (Timestamp) в формате ГГГГММДДЧЧММ (Год-Месяц-День-Час-Минута). Это позволяет легко определить, в какой именно момент был создан данный файл.
  3. Расширение .sql: Указывает на то, что внутри файла находится текстовый дамп базы данных, состоящий из SQL-команд.

Выясним причину их появления. Эти файлы являются результатом работы утилиты pg_dump — стандартного инструмента для создания резервных копий PostgreSQL. Если расширение файла .sql, значит, бэкап был запущен в текстовом (plain text) формате. Это объясняет их гигантский размер (десятки и сотни гигабайт), так как данные хранятся не в сжатом бинарном виде, а в виде открытого текста, где таблицы выгружаются через операторы COPY.

Почему временные файлы остаются в папке WinTEMP

Рассмотрим механизм работы скриптов резервного копирования. Когда запускается процесс создания дампа через pg_dump, система может использовать переменную окружения %TEMP% для промежуточного хранения данных. Это происходит в следующих случаях:

Как проверить содержимое огромного файла

Проанализируем ситуацию, когда файл настолько велик (например, 35 Гб), что обычные редакторы типа "Блокнот" просто зависают при попытке открытия. Для идентификации содержимого нам не нужно читать весь файл, достаточно просмотреть первые несколько строк.

Рассмотрим использование Far Manager для этой задачи:

  1. Запустите Far Manager от имени администратора.
  2. Найдите нужный файл в папке WinTEMP.
  3. Нажмите клавишу F3 (Просмотр). Far Manager умеет открывать файлы практически любого размера мгновенно, так как не загружает их целиком в оперативную память.

В самом начале файла вы увидите служебную информацию PostgreSQL. Там будет указана версия сервера, дата создания дампа и, возможно, комментарии о том, какая база данных выгружалась. Это окончательно подтвердит, что перед вами старая копия базы, а не критически важный системный файл.

Безопасность удаления и риски

Проясним главный вопрос: можно ли удалять эти файлы? Да, удаление файлов с расширением .sql из временных папок безопасно для текущей работоспособности 1С и PostgreSQL. Это не активные файлы базы данных (которые обычно хранятся в /var/lib/postgresql/data или C:\Program Files\PostgreSQL\...\data), а лишь "снимки" состояния на прошлый момент времени.

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

Рекомендации по оптимизации процесса бэкапа

Чтобы ситуация с переполнением диска не повторялась, проанализируем настройки ваших инструментов резервного копирования и внесем коррективы:

  1. Использование сжатия: При использовании утилиты pg_dump всегда добавляйте флаг -Fc (формат custom). Это позволит создавать сжатые бинарные архивы, которые в 5–10 раз меньше по объему, чем текстовые .sql файлы.
  2. Явное указание путей: В скриптах резервного копирования всегда указывайте полный путь к целевой директории, минуя системные временные папки.
  3. Контроль очистки: Если вы используете внешние обработки 1С для вызова pg_dump через ЗапуститьПриложение(), обязательно добавьте блок Попытка...Исключение, который будет удалять временный файл в случае неудачи основной операции.

Таким образом, обнаружив файлы типа BBLxxxxxxx.sql, вы можете смело их удалять, предварительно убедившись (через Far Manager или по дате), что это старые временные копии, которые не были вовремя перемещены или удалены автоматикой.

← На главную