Как перевести базы 1С на новую версию PostgreSQL без потери данных

Обновить PostgreSQL для 1С можно тремя способами. Внутри одной мажорной версии (например, 15.4 → 15.8) достаточно поставить новые бинарные файлы поверх старых: формат данных не меняется. При переходе между мажорными версиями (13 → 16) данные переносят утилитой pg_upgrade, через pg_dump/pg_restore или выгрузкой каждой базы в файл .dt и загрузкой обратно.

Главное условие для всех способов — новая СУБД должна быть сборкой с доработками для 1С: от фирмы «1С» или Postgres Pro для 1С. Обычный PostgreSQL с сайта сообщества базы 1С не поднимет: в нём нет нужных типов данных и расширений.

Зачем обновлять PostgreSQL под сервером 1С

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

Что даёт обновление на практике:

• 🔒 закрытые уязвимости. Для сервера, который смотрит в локальную сеть с десятками рабочих мест, это не формальность;
• ⚡ производительность. Новые версии лучше строят планы запросов, быстрее делают VACUUM и параллельные операции;
• 🧩 совместимость с платформой. Свежие релизы платформы 8.3 рассчитаны на свежие версии СУБД, а старые версии со временем выпадают из списка поддерживаемых;
• 🛠️ исправленные ошибки самой сборки для 1С: в ней правят то, что проявляется именно на типовых конфигурациях.

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

Какая версия PostgreSQL подойдёт вашей платформе 1С

Совместимость определяет пара «версия платформы 1С — мажорная версия СУБД». Чем новее платформа, тем более свежие версии PostgreSQL она поддерживает. Точный список приводится в системных требованиях к конкретной версии платформы. Перед переходом откройте их для вашего номера платформы и найдите в таблице СУБД нужную мажорную версию.

Ориентир по срокам поддержки сообществом:

Если платформа старая и новую версию СУБД не поддерживает, порядок такой: сначала обновить платформу 1С на сервере и клиентах, проверить работу, и только потом менять СУБД. Менять оба компонента в одну ночь не стоит: при сбое вы не поймёте, кто виноват.

Подготовка к обновлению: что сделать заранее

Большинство проблем при обновлении PostgreSQL для 1С возникает не во время переноса, а из-за того, что о чём-то забыли до него. Пройдите пункты по порядку.

1. Сделайте две копии каждой базы. Выгрузку .dt через Конфигуратор (Администрирование → Выгрузить информационную базу) и дамп средствами СУБД: pg_dump -Fc -f base.dump имя_базы. Две независимые копии — страховка на случай, если одна окажется битой.
2. Сохраните настройки сервера. Скопируйте postgresql.conf и pg_hba.conf из каталога данных. Ни один способ обновления их не переносит.
3. Выгрузите роли. Команда pg_dumpall --globals-only -f roles.sql сохранит пользователей и их пароли. Это нужно для способа с pg_dump.
4. Проверьте свободное место. Для pg_upgrade в режиме копирования нужен объём, равный каталогу данных, плюс запас. Для дампа — место под файлы дампа.
5. Скачайте дистрибутив той же линейки. Старая и новая версии должны быть сборками для 1С. Смешивать сборку «1С» и Postgres Pro при pg_upgrade не стоит.
6. Запишите параметры информационных баз. В консоли администрирования серверов 1С откройте свойства каждой базы и выпишите поле «Сервер баз данных», имя базы в СУБД и пользователя.
7. Предупредите пользователей и назначьте окно. На время переноса базы недоступны.

Перед самим переносом остановите службу агента сервера 1С. Все сеансы пользователей оборвутся, а несохранённые документы пропадут — делайте это в согласованное окно, когда в базах никто не работает . Затем остановите службу PostgreSQL.

Способы обновить PostgreSQL для 1С

Способ 1. Минорное обновление

Версии вида 16.2 и 16.6 используют один формат каталога данных. Остановите агент 1С и службу PostgreSQL, запустите установщик новой сборки той же мажорной версии и укажите прежний каталог данных. После установки запустите службу СУБД, затем агент 1С.

Перед установкой прочитайте примечания к выпуску. Иногда после минорного обновления требуется перестроить отдельные индексы — об этом пишут прямо в описании релиза.

Способ 2. pg_upgrade — быстро и для больших баз

Утилита из новой версии читает каталог старого кластера и создаёт новый кластер того же содержания. Порядок такой.

1. Установите новую сборку рядом со старой, в отдельный каталог. Установщик предложит другой порт, например 5433, — согласитесь.
2. Убедитесь, что новый кластер создан с той же локалью и кодировкой, что и старый. Иначе pg_upgrade откажется работать.
3. Остановите обе службы PostgreSQL.
4. Запустите пробный прогон с ключом --check. Он ничего не меняет, только проверяет совместимость.
5. Если проверка чистая — повторите команду без --check.

Пример для Linux (пути замените на свои):

sudo -u postgres /новая/версия/bin/pg_upgrade \
  --old-bindir=/старая/версия/bin \
  --new-bindir=/новая/версия/bin \
  --old-datadir=/старый/каталог/data \
  --new-datadir=/новый/каталог/data \
  --check

На Windows команду запускают из каталога, куда у учётной записи службы PostgreSQL есть права на запись: утилита пишет туда журналы.

Ключ --link вместо копирования файлов создаёт жёсткие ссылки. Перенос базы в 300 ГБ занимает минуты, а не часы, и не требует двойного места на диске. Цена — старый кластер после запуска нового использовать уже нельзя.

Способ 3. pg_dump и pg_restore

Подходит, когда новая СУБД ставится на другой сервер или нужно заодно поменять локаль. Сначала на новом сервере восстановите роли из roles.sql, затем переносите базы по одной:

pg_dump -Fd -j 4 -f /backup/buh_dump buh
createdb -T template0 buh
pg_restore -j 4 -d buh /backup/buh_dump

Формат каталога (-Fd) позволяет и выгружать, и загружать в несколько потоков. Число потоков ставьте по числу ядер сервера, не больше.

Базу создавайте из template0: так в неё не попадут лишние объекты из template1.

Способ 4. Выгрузка и загрузка .dt

На новом сервере СУБД создайте пустую информационную базу через консоль кластера 1С, затем в Конфигураторе загрузите в неё файл .dt (Администрирование → Загрузить информационную базу). Способ медленный: база на 50 ГБ может загружаться несколько часов. Зато платформа сама создаёт все таблицы и заодно проверяет данные.

Что сделать сразу после переноса

1. Перенесите нужные параметры из старого postgresql.conf в новый: shared_buffers, work_mem, max_connections и всё, что вы настраивали сами. Не копируйте файл целиком — в новой версии могут исчезнуть или поменяться параметры.
2. Перенесите правила доступа из старого pg_hba.conf.
3. После pg_upgrade соберите статистику: vacuumdb --all --analyze-in-stages. Без неё планировщик строит плохие планы, и первые часы 1С «тормозит» на ровном месте.
4. Решите вопрос с портом. Проще всего поменять порт новой СУБД на 5432 в postgresql.conf, а старую службу отключить. Тогда свойства баз в кластере 1С трогать не придётся.

Если оставляете новый порт, в консоли кластера 1С в свойствах каждой базы укажите в поле «Сервер баз данных» значение вида localhost port=5433.

Проверка: базы 1С работают на новой версии

Запустите службу PostgreSQL, затем агент сервера 1С. Проверку ведите от СУБД к пользователю.

• ✅ SELECT version(); показывает новую версию;
• ✅ команда \l в psql выводит все базы, ни одна не потерялась;
• ✅ в журнале СУБД (каталог log внутри каталога данных) нет ошибок при запуске;
• ✅ каждая база открывается в режиме «1С:Предприятие» и в Конфигураторе;
• ✅ тяжёлые отчёты (оборотно-сальдовая ведомость за год, расчёт зарплаты) формируются за привычное время;
• ✅ проходят регламентные задания: проверьте их в консоли кластера или в базе;
• ✅ работают обмены и резервное копирование — пути и пароли в скриптах могли указывать на старый порт.

Если отчёт, который раньше строился за 10 секунд, идёт минуту, первым делом проверьте, собрана ли статистика. Сразу после pg_upgrade её нет, и запросы идут по случайным планам.

Откат, если после обновления что-то пошло не так

План отката продумайте до начала работ. Он зависит от выбранного способа.

После pg_upgrade без --link. Старый кластер не тронут. Остановите новую службу, верните старую на прежний порт и запустите её. Базы вернутся в состояние на момент остановки.

После pg_upgrade с --link. Если новый кластер ещё не запускался, старый можно вернуть: утилита подсказывает, какой файл переименовать обратно. После первого запуска нового кластера — только восстановление из копии.

После pg_dump/pg_restore и .dt. Старый сервер остаётся рабочим. Достаточно вернуть его порт и снова запустить службу.

Если пользователи успели поработать на новой версии, а потом вы откатились, их изменения останутся только в новой СУБД. Перед откатом выгрузите .dt из проблемной базы, чтобы ничего не потерять, и решите, какие данные переносить вручную.

Частые вопросы об обновлении PostgreSQL под 1С