Ситуация, когда выгрузка информационной базы через Конфигуратор в файл .dt занимает несколько часов, знакома многим администраторам. Особенно остро проблема проявляется после разделения ролей, когда сервер приложений 1С и сервер СУБД (например, PostgreSQL) разносятся на разные физические или виртуальные машины. В этой статье мы подробно разберем, почему «традиционный» метод выгрузки становится неэффективным, и рассмотрим современные способы создания резервных копий, которые сэкономят ваше время.
Рассмотрим механизм работы выгрузки в .dt. Этот процесс является логическим чтением всей базы данных. Сервер 1С последовательно запрашивает данные из каждой таблицы СУБД, упаковывает их и сжимает. Когда СУБД и 1С находятся на одном сервере, обмен данными происходит через общую память или локальный протокол, что практически исключает сетевые задержки.
Проанализируем ситуацию после разделения серверов:
.dt будет конкурировать с трафиком пользователей.Выясним причину, почему формат .dt не является полноценным бэкапом. Согласно официальным рекомендациям фирмы 1С, этот формат предназначен для миграции данных между разными СУБД или перехода с файловой версии на серверную. Для регулярного резервного копирования он избыточен и небезопасен, так как требует монопольного доступа и может «пропустить» ошибки в структуре таблиц.
Самый правильный путь — использование штатных утилит СУБД, таких как pg_dump. Это позволяет делать копию без отключения пользователей и значительно быстрее. Разберем по шагам, как настроить этот процесс, если при нажатии кнопки «Резервная копия» в pgAdmin возникает ошибка.
Чаще всего ошибка в pgAdmin связана с тем, что утилита администрирования не знает, где находятся исполняемые файлы самого PostgreSQL. Исправим это:
File (Файл) — Preferences (Настройки).Paths (Пути) — Binary paths (Бинарные пути).bin, где лежат файлы pg_dump.exe, pg_restore.exe и другие. Обычно это путь вида: C:\Program Files\PostgreSQL\15\bin.Теперь создание бэкапа будет происходить нажатием правой кнопки мыши на базу — «Резервная копия». Вы увидите, что процесс идет в разы быстрее, так как данные не передаются через сервер приложений 1С для перепаковки.
Для профессиональной работы системному администратору стоит один раз написать скрипт, который будет делать бэкап по расписанию. Это исключит человеческий фактор и необходимость ручного запуска Конфигуратора. Рассмотрим пример простейшего скрипта для Windows:
@echo off
set PGPASSWORD=ваш_пароль
set PGPATH="C:\Program Files\PostgreSQL\15\bin\"
set BACKUPPATH="D:\Backups\"
set DATETIME=%date:~6,4%-%date:~3,2%-%date:~0,2%_%time:~0,2%-%time:~3,2%
%PGPATH%pg_dump.exe -h localhost -U postgres -F c -b -v -f %BACKUPPATH%base_backup_%DATETIME%.backup имя_вашей_базы
В данном примере мы используем ключ -F c, который создает сжатый архив в кастомном формате PostgreSQL. Такой файл восстанавливается быстрее и занимает меньше места.
Если вам все же необходимо получить именно .dt (например, для передачи разработчикам), проанализируем использование утилиты ibcmd. Это консольный инструмент автономного сервера 1С, который работает эффективнее, чем графический Конфигуратор.
Рассмотрим пример команды для выгрузки:
ibcmd infobase save --db-type=PostgreSQL --db-server=SQL_Server_Name --db-name=Base_Name --db-user=postgres --db-pwd=password --file=C:\dump.dt
Важное преимущество: ibcmd можно запускать непосредственно на сервере, где установлен PostgreSQL или сервер 1С, минимизируя лишние сетевые пересылки данных на клиентский компьютер администратора.
Если переход на SQL-бэкапы по каким-то причинам откладывается, попробуем оптимизировать текущий процесс. Проанализируем настройки серверов:
.dt сервер 1С активно пишет временные данные. Убедимся, что папка %TEMP% пользователя, под которым работает служба 1C:Enterprise 8.3 Server Agent, находится на быстром SSD-диске. Медленный системный диск часто становится узким местом.rphost.exe, postgres.exe, а также папки с базами данных и временными файлами. Постоянное сканирование гигабайтов данных при выгрузке может замедлить процесс в 2–3 раза.Receive Side Scaling (RSS) и TCP Chimney Offload. В некоторых случаях их отключение (или, наоборот, правильная настройка драйверов) помогает стабилизировать скорость передачи больших массивов данных между сервером 1С и СУБД.postgresql.conf. Если значение work_mem слишком мало, СУБД будет использовать диск для сортировки и обработки данных перед отправкой их серверу 1С, что катастрофически замедляет чтение. Попробуем увеличить его (с учетом доступной оперативной памяти).Разберем идеальную схему организации работы с базой данных:
.dt, если SQL-копия делается за 10–15 минут.Помните, что время администратора и доступность базы для пользователей — это ценные ресурсы. Переход с «привычного» .dt на профессиональные инструменты работы с PostgreSQL — это важный шаг в развитии компетенций специалиста и стабильности ИТ-инфраструктуры предприятия.