Переход с файловой версии базы данных 1С:Предприятие на клиент-серверный вариант (особенно под управлением СУБД PostgreSQL) — это важный шаг в развитии ИТ-инфраструктуры любой компании. С ростом количества пользователей и объемов данных требования к отказоустойчивости системы возрастают в геометрической прогрессии. В этот момент перед системными администраторами встает критический вопрос: достаточно ли продолжать делать привычные выгрузки базы в формате .dt по ночам, или же необходимо настраивать полноценное резервное копирование на уровне самой СУБД?
В этой статье мы подробно разберем, почему выгрузка средствами 1С не может считаться полноценным и надежным бэкапом для клиент-серверных баз данных, проанализируем риски этого подхода, изучим механизмы PostgreSQL и построим профессиональную стратегию резервного копирования.
Выгрузка в файл с расширением .dt — это внутренний механизм платформы 1С, предназначенный в первую очередь для переноса данных между различными СУБД (например, при переходе с файловой базы на MS SQL Server или PostgreSQL) или для свертки баз. Платформа 1С сама неоднократно заявляла, что данный механизм не проектировался как средство создания резервных копий. Рассмотрим подробнее основные причины, почему это так:
.dt заключается в том, что сам процесс выгрузки может пройти абсолютно штатно и без ошибок, создав красивый файл на диске. Но при попытке восстановить из него базу в критический момент вы можете столкнуться с ошибками вроде «Ошибка формата потока» или сообщениями о невозможности загрузить все таблицы. Вы будете пребывать в иллюзии безопасности, имея ежедневные файлы выгрузки, которые по факту окажутся бесполезными..dt, платформе требуется эксклюзивный доступ к базе данных. Это означает, что вам придется принудительно завершать сеансы всех пользователей, блокировать регламентные и фоновые задания на сервере 1С. В условиях круглосуточной работы (режим 24/7) или при наличии ночных обменов данными предоставить такое технологическое окно становится невозможно..dt является крайне ресурсоемким. Серверу 1С приходится считывать терабайты данных из СУБД, упаковывать их в свой внутренний формат и сжимать. На больших базах (более 100 Гб) этот процесс может занимать долгие часы, в течение которых процессор и оперативная память сервера будут загружены на максимум, что может привести к сбоям других баз на этом же сервере..dt происходит логическое резервирование объектов метаданных. При обратной загрузке СУБД перестраивает индексы и заново создает таблицы. В результате восстановленная база не будет являться абсолютно точной физической копией исходной базы на момент выгрузки.Резервной копией на клиент-сервере может считаться только копия, сделанная на как можно более низком уровне — средствами самой СУБД PostgreSQL или на уровне физических файлов базы данных (при остановленной службе СУБД).
Для создания правильных резервных копий баз данных на PostgreSQL нам необходимо четко различать два основных подхода: логический и физический.
Логический бэкап выполняется с помощью стандартной утилиты pg_dump (для одной базы) или pg_dumpall (для всего кластера СУБД). Утилита генерирует набор SQL-команд или архив специального формата СУБД, которые при восстановлении воссоздают структуру таблиц и наполняют их данными.
Плюсы логического бэкапа:
Минусы логического бэкапа:
mchar).Физический бэкап заключается в копировании непосредственно бинарных файлов табличных пространств СУБД «на лету» с помощью утилиты pg_basebackup. Этот метод гарантирует стопроцентную согласованность данных на физическом уровне.
Плюсы физического бэкапа:
Минусы физического бэкапа:
Для крупных enterprise-баз 1С стандартного ночного бэкапа бывает недостаточно. Если база данных повредится в 18:00, вы потеряете результаты работы 20 пользователей за весь рабочий день. Чтобы этого избежать, в PostgreSQL применяется технология непрерывного архивирования журналов упреждающей записи — Write-Ahead Logs (WAL).
Каждое изменение в базе данных сначала записывается в WAL-файл, а затем применяется к таблицам. Настроив копирование этих файлов в безопасное хранилище (параметры wal_level = replica, archive_mode = on и archive_command в файле конфигурации postgresql.conf), мы получаем возможность использовать механизм Point-in-Time Recovery (PITR).
С помощью PITR мы можем восстановить базу данных на любую секунду в прошлом (например, на 14:25:01, ровно за секунду до того, как неопытный пользователь запустил ошибочную групповую обработку документов). Это сводит к минимуму возможную потерю данных в случае аварии.
Просто запустить утилиту один раз вручную — не выход. Процесс должен быть полностью автоматизирован. Рассмотрим популярные инструменты для решения этой задачи:
Разберем по шагам, как настроить безопасное автоматическое резервное копирование базы 1С на PostgreSQL с помощью командного файла в Windows, избегая типичной ошибки — хранения пароля администратора СУБД в открытом виде внутри скрипта.
Для безопасной авторизации утилиты pg_dump используют файл конфигурации паролей pgpass.conf. Создадим этот файл в каталоге пользователя, под которым будет запускаться служба бэкапа (по умолчанию это %APPDATA%\postgresql\pgpass.conf). Строка внутри файла должна иметь следующий формат:
имя_хоста:порт:имя_базы_данных:имя_пользователя:пароль
Например:
localhost:5432:trade_db:backup_user:SuperStrongPassword123
Теперь создадим командный файл backup_1c.bat и добавим в него следующий код:
@echo off
:: Установка переменных окружения
SET PGUSER=backup_user
SET PGDATABASE=trade_db
SET BACKUP_DIR=D:\Backups\PostgreSQL
SET DATETIME=%date:~6,4%-%date:~3,2%-%date:~0,2%_%time:~0,2%-%time:~3,2%-%time:~6,2%
:: Замена пробелов в имени файла (для предотвращения ошибок в ночные часы)
SET DATETIME=%DATETIME: =0%
:: Путь к утилитам PostgreSQL (зависит от установленной версии)
SET PG_BIN="C:\Program Files\PostgreSQL\15\bin"
:: Создание папки для бэкапов, если она не существует
if not exist "%BACKUP_DIR%" mkdir "%BACKUP_DIR%"
:: Запуск логического копирования базы в сжатом пользовательском формате (.backup)
%PG_BIN%\pg_dump.exe -h localhost -p 5432 -U %PGUSER% -F c -b -v -f "%BACKUP_DIR%\%PGDATABASE%_%DATETIME%.backup"
:: Удаление архивов старше 14 дней для экономии места
forfiles /p "%BACKUP_DIR%" /s /m *.backup /d -14 /c "cmd /c del @path"
Данный скрипт достаточно поместить в Планировщик задач Windows (Task Scheduler) и настроить его ежедневный запуск во внерабочее время. Он будет создавать сжатые копии базы данных без прерывания сеансов пользователей и автоматически очищать старые архивы.
Проанализируем крайне важный нюанс, о котором часто забывают даже опытные специалисты. При развертывании базы данных 1С из логической копии (дампа) у PostgreSQL полностью сбрасывается внутренняя статистика распределения данных в таблицах.
Если сразу после успешного восстановления запустить пользователей в 1С, они столкнутся с катастрофическим падением производительности системы. СУБД просто не будет знать, сколько записей находится в таблицах и как строить оптимальные планы SQL-запросов, из-за чего отчеты и проведения документов начнут зависать.
Чтобы решить эту проблему, сразу после восстановления базы из бэкапа администратор обязан выполнить команду обновления статистики СУБД. Запустите в консоли запросов PostgreSQL следующую команду:
VACUUM ANALYZE;
Эта команда выполнит очистку базы от остаточного мусора после импорта данных и принудительно пересчитает статистику, вернув производительность 1С на штатный уровень.
Подводя итог нашему разбору, выделим ключевые правила построения надежной системы бэкапов для 1С на PostgreSQL:
.dt в качестве единственного и основного способа резервного копирования серверной базы. Применяйте его исключительно как вспомогательный инструмент (например, для разворачивания копии базы на локальном компьютере разработчика).pg_dump или физические копии через pg_basebackup).