Где находится база 1С в PostgreSQL: поиск файлов и структура хранения

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

Местоположение данных зависит не только от настроек PostgreSQL, но и от операционной системы, под управлением которой работает сервер. Администратору необходимо различать логическое имя информационной базы в кластере 1С и физическое представление файлов на диске. Ошибочное вмешательство в эти файлы напрямую, минуя инструменты СУБД, может привести к полной потере работоспособности учетной системы.

В данном материале мы подробно разберем путь к данным, структуру хранения больших объектов (BLOB), а также способы проверки конфигурации через консольные утилиты. Вы узнаете, как найти нужный каталог даже в нестандартных инсталляциях и какие меры предосторожности следует соблюдать при работе с файловой системой базы данных.

Стандартные пути расположения данных в различных ОС

По умолчанию сервер PostgreSQL создает специальный каталог для хранения всех своих данных, который называется кластером данных. Путь к этому каталогу определяется в момент инициализации базы данных и зависит от дистрибутива операционной системы. В среде Linux наиболее распространенным расположением является директория /var/lib/postgresql. Внутри неё обычно находится подпапка с версией СУБД, например, 14 или 15, а затем папка main, содержащая непосредственно файлы баз.

Если вы работаете в среде Windows Server, ситуация немного отличается. Установщик PostgreSQL по умолчанию предлагает путь вида C:\Program Files\PostgreSQL\<версия>\data. Однако опытные администраторы часто меняют этот путь при установке, направляя данные на отдельные физические диски для повышения производительности подсистемы ввода-вывода. Поэтому слепо следовать стандартному пути не стоит — всегда проверяйте конфигурацию.

⚠️ Внимание: Прямое копирование файлов из директории base или global при работающем сервере PostgreSQL недопустимо. Это приведет к повреждению контрольных сумм и невозможности запуска базы данных. Используйте только утилиты pg_dump или механизмы снимков файловой системы (LVM, ZFS).

Для точного определения пути к данным можно воспользоваться SQL-запросом, выполнив его в любой базе данных кластера (например, в template1 или postgres). Команда SHOW data_directory; вернет абсолютный путь к корневой папке с данными. Это наиболее надежный способ, который работает независимо от операционной системы и версии дистрибутива.

Структура хранения данных 1С внутри PostgreSQL

Внутри каталога данных PostgreSQL вы не найдете файлов с именами ваших информационных баз 1С, таких как "Бухгалтерия" или "УТ". СУБД использует внутренний механизм идентификации, присваивая каждой базе данных уникальный числовой идентификатор — OID (Object Identifier). Физически данные каждой базы 1С хранятся в подкаталоге base, имя которого соответствует этому OID.

Чтобы связать имя базы 1С с её физическим расположением, необходимо узнать её OID. Это можно сделать, подключившись к серверу через утилиту psql и выполнив запрос к системному каталогу pg_database. Запрос SELECT datname, oid FROM pg_database WHERE datname LIKE '%имя_базы%'; покажет соответствие между логическим именем и числовым кодом. Именно папка с этим числом внутри .../data/base/ и содержит файлы вашей учетной системы.

Внутри папки с OID вы обнаружите множество файлов без расширений или с расширениями вида .vm, .fsm, .init. Это сегменты таблиц и индексов. 1С:Предприятие хранит основные данные в таблицах с префиксом _1cv8, а конфигурацию и метаданные — в специализированных системных таблицах. Файлы разбиваются на сегменты по 1 ГБ (по умолчанию), чтобы обойти ограничения файловых систем на размер одного файла.

Почему файлов так много?

Файловая система PostgreSQL использует механизм MVCC (Multiversion Concurrency Control). При обновлении записи старая версия не перезаписывается, а помечается как устаревшая, а новая пишется в другое место. Это создает множество файлов сегментов, которые со временем могут быть очищены процессом VACUUM, но физически занимают место до момента сжатия.

Особое внимание стоит уделить каталогу pg_tblspc. Если при создании базы данных 1С администратор указывал пользовательские tablespace (табличные пространства) для выноса тяжелых таблиц на быстрые SSD, то ссылки на эти данные будут храниться именно здесь. Символические ссылки в этой папке ведут к реальным директориям на других дисках, где могут лежать самые объемные файлы вашей базы.

Особенности хранения больших объектов (BLOB)

Информационные базы 1С активно используют механизм больших объектов (BLOB) для хранения двоичных данных: картинок, сканов документов, печатных форм и файлов в полях типа "Хранение файла". В PostgreSQL эти данные не лежат внутри основных таблиц пользовательских данных, а вынесены в отдельное системное хранилище.

Физически большие объекты располагаются в подкаталоге pgsql_tmp или, что более верно для постоянных данных, в каталоге base внутри специальной таблицы pg_largeobject. Однако, начиная с определенных версий, для оптимизации работы с BLOB может использоваться отдельное табличное пространство. Размер файлов в этом хранилище может составлять значительную часть от общего объема базы 1С, особенно в конфигурациях с большим количеством прикрепленных файлов.

• 📁 Основные таблицы данных хранятся в папке base/{OID} и занимают место под текстовую и числовую информацию справочников и документов.
• 🖼️ Большие объекты (BLOB) могут храниться как внутри сегментов таблиц, так и в выделенном хранилище, в зависимости от настроек СУБД и версии 1С.
• 🗑️ Удаление записей в 1С не всегда мгновенно освобождает место на диске в PostgreSQL из-за особенностей работы VACUUM и хранения версий строк.

Для анализа занятого места большими объектами можно использовать расширение pg_stat_statements или специализированные скрипты, проверяющие размер таблицы pg_largeobject. Если этот объект занимает аномально много места, возможно, в базе остались "висячие" ссылки на удаленные файлы, которые требуют ручной очистки через SQL-запросы или специальные обработки в самой 1С.

Настройка путей через postgresql.conf и pg_hba.conf

Конфигурационный файл postgresql.conf является главным центром управления параметрами сервера баз данных. Именно здесь, в параметре data_directory, прописан основной путь к файлам. Изменение этого параметра требует остановки сервиса и переноса всего каталога данных, поэтому его задают один раз при первоначальной настройке сервера.

Более гибкой настройкой является использование параметра tablespace. В файле конфигурации или через SQL-команды можно определить дополнительные пути для хранения данных. Например, вы можете создать табличное пространство fast_ssd, указав путь /mnt/ssd/postgres_data, и перенести туда тяжелые таблицы регистраов 1С. Это позволяет распределить нагрузку на дисковую подсистему.

Файл pg_hba.conf (Host-Based Authentication) не содержит путей к данным, но критически важен для доступа. В нем прописываются правила, разрешающие серверу 1С (radmin или rmngr) подключаться к конкретным базам PostgreSQL. Ошибки в этом файле часто интерпретируются пользователями как "база не найдена", хотя физически файлы лежат на месте, просто доступ к ним заблокирован правилами безопасности.

Параметр / Файл	Назначение	Влияние на путь к базе
data_directory	Основной каталог данных	Определяет корень хранения всех баз (OID)
tablespace	Дополнительные хранилища	Позволяет вынести конкретные таблицы на другие диски
pg_hba.conf	Правила доступа	Не влияет на путь, но регулирует возможность подключения
wal_level	Журнал транзакций	Определяет объем и место хранения логов предзаписи (WAL)

⚠️ Внимание: После любого изменения в файле postgresql.conf необходимо перезагрузить конфигурацию сервера командой SELECT pg_reload_conf(); или перезапустить службу PostgreSQL. Без этого новые пути к табличным пространствам не будут задействованы.

Поиск базы через консольные утилиты и SQL

Наиболее профессиональным способом определения расположения данных является использование командной строки. Утилита psql позволяет не только выполнять запросы, но и выводить мета-информацию о структуре баз данных. Для начала подключитесь к серверу под суперпользователем (обычно это пользователь postgres).

Выполните команду \l+ (elist plus). Она выведет расширенный список всех баз данных с указанием их владельца, кодировки, прав доступа и, что самое важное, размера на диске. Хотя эта команда не показывает прямой путь к файлам, она помогает идентифицировать базу по размеру, сопоставив его с содержимым папок в каталоге base.

psql -U postgres -c "SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database ORDER BY pg_database_size(datname) DESC;"

Этот SQL-запрос отсортирует все базы данных по убыванию размера. Сопоставив имя базы 1С из списка с размером папок в файловой системе (команда du -sh * в каталоге base), вы легко найдете нужную директорию. Такой подход исключает ошибки, связанные с ручным поиском OID.

Проблемы доступа и права файловой системы

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

Попытка открыть файлы базы из-под пользователя root или другого администратора для просмотра содержимого текстовым редактором бессмысленна и опасна. Данные хранятся в бинарном формате страниц (pages). Более того, изменение прав доступа (chmod) на файлы внутри каталога base может привести к тому, что сервер СУБД откажется стартовать из соображений безопасности.

Если вы планируете перенос базы на другой диск или сервер, необходимо останавливать службу PostgreSQL, копировать файлы с сохранением атрибутов (ключ -a в команде cp или rsync) и тщательно проверять владельца файлов после переноса. Команда chown -R postgres:postgres /путь/к/новым/данным является обязательным шагом в такой процедуре.

Можно ли перенести базу 1С просто копированием папки base?

Технически это возможно, но крайне рискованно. Простое копирование файлов base/{OID} без использования pg_dump и pg_restore может привести к рассинхронизации системных таблиц и журналов транзакций (WAL). Такой метод допустим только при полном клонировании всего каталога data на остановленном сервере с идентичной архитектурой ОС и версией PostgreSQL.

Почему размер папки на диске больше, чем размер базы в 1С?

Разница обусловлена служебными данными PostgreSQL: журналами предзаписи (WAL), файлами статистики, временными файлами сортировки и особенностями выделения места (extents). Также место занимают "мертвые" версии строк, которые еще не были очищены процессом автовакуумирования. Это нормальная ситуация для СУБД.

Где хранятся файлы временных таблиц 1С?

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

Как найти базу, если я не знаю её имя в PostgreSQL?

В консоли администрирования 1С (ras) можно выполнить команду cluster info или посмотреть свойства информационной базы. В описании часто указывается имя базы данных в СУБД (параметр DBName). Если имена совпадают, поиск упрощается. Если имя сгенерировано автоматически (например, ib_12345), используйте метод сравнения размеров через SQL.

Влияет ли сжатие файлов ОС на работу базы 1С в PostgreSQL?

Категорически не рекомендуется включать сжатие NTFS (в Windows) или использовать сжатые файловые системы для каталога данных PostgreSQL. Это создает дополнительную нагрузку на процессор при каждом обращении к данным и может привести к повреждению файлов при сбоях питания. Производительность дисковой подсистемы важнее экономии места.