Как восстановить базу данных PostgreSQL 1С из папки data и устранить ошибку "Connection refused"?

← На главную

При миграции информационных систем 1С, использующих PostgreSQL, на новую операционную систему или новое аппаратное обеспечение, одной из наиболее частых и сложных задач становится восстановление базы данных из существующего каталога data. Особенно это актуально, когда отсутствуют регулярные резервные копии в формате .dt или сделанные средствами pg_dump. В этом руководстве мы рассмотрим пошаговые инструкции и распространенные проблемы, такие как ошибка "Connection refused", с которой столкнулся наш пользователь.

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

Общий подход к восстановлению баз данных PostgreSQL 1С

Прежде чем углубляться в специфику восстановления из папки data, рассмотрим основные стратегии, которые мы можем использовать для возвращения работоспособности базы данных 1С:

Восстановление через файл .dt: Это наиболее предпочтительный и безопасный метод для баз 1С, поскольку он оперирует на уровне приложения 1С и минимизирует риски, связанные с низкоуровневым переносом данных PostgreSQL.
Использование виртуализации для создания бэкапа: Если старая операционная система все еще запускается (хотя бы в виртуальной машине), мы можем загрузить ее, сделать полноценный бэкап средствами PostgreSQL (pg_dump) или 1С (.dt) и затем восстановить его на новой системе.
Прямое копирование каталога data: Этот метод является наиболее сложным и потенциально рискованным, но часто единственно возможным, если старая система недоступна для запуска, а есть только сама папка с файлами базы данных. Именно этот метод и вызывает ошибку "Connection refused".

Давайте подробнее разберем каждый из этих подходов.

Метод 1: Восстановление через файл .dt (рекомендуемый для 1С)

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

Запустим старую систему или подключим диск: Убедимся, что старая ОС или старый жесткий диск с ее файлами доступны. Если старая ОС загружается, это идеальный вариант.
Запустим 1С и войдем в базу: Откроем 1С Предприятие на старой системе и войдем в нужную базу данных.
Создадим выгрузку информационной базы в файл .dt:
В режиме "Конфигуратор" перейдем в меню Администрирование -> Выгрузить информационную базу.... Укажем путь для сохранения файла .dt. Этот файл будет содержать все данные и структуру вашей базы 1С.
Перенесем файл .dt на новую систему: Скопируем созданный файл .dt на новый SSD.
Настроим PostgreSQL на новой системе:
Установим PostgreSQL (желательно ту же версию, что была на старом диске, и ту же сборку, например, Postgres Pro 1C). Убедимся, что служба PostgreSQL запущена и доступна.
Создадим новую пустую базу 1С на новой системе:
В окне запуска 1С Предприятия добавим новую информационную базу, выбрав тип "Создание новой информационной базы" и указав "Создание базы из шаблона" или "Создание пустой информационной базы". Тип СУБД - PostgreSQL. Укажем параметры подключения к PostgreSQL (сервер, порт, имя базы, пользователь).
Загрузим данные из .dt в новую базу:
Откроем новую пустую базу в режиме "Конфигуратор". Перейдем в меню Администрирование -> Загрузить информационную базу.... Укажем путь к файлу .dt, который мы скопировали.

После завершения загрузки база 1С будет восстановлена.

Метод 2: Использование виртуализации для создания бэкапа PostgreSQL

Этот метод особенно полезен, если старый жесткий диск физически цел, но загрузка старой ОС на нем затруднена или нежелательна, а также если вы хотите получить бэкап именно средствами PostgreSQL (pg_dump).

Подготовим старый диск для виртуальной машины:
Подключим старый жесткий диск к компьютеру, на котором будем запускать виртуальную машину. Возможно, нам потребуется использовать специальные инструменты для преобразования физического диска в образ виртуальной машины (например, VBoxManage convertfromraw для VirtualBox или VMware vCenter Converter Standalone для VMware).
Настроим виртуальную машину:
Создадим новую виртуальную машину (например, в VirtualBox или VMware Workstation). В качестве виртуального диска укажем образ или физический диск старой системы.
Запустим старую ОС в виртуальной машине:
Запустим виртуальную машину и убедимся, что старая Windows с установленными 1С и PostgreSQL загружается корректно.
Сделаем бэкап базы данных PostgreSQL:
После успешного запуска старой системы в ВМ, мы можем использовать утилиту pg_dump, входящую в состав PostgreSQL, для создания резервной копии базы данных. Это позволит получить целостный SQL-файл или специальный формат для pg_restore.
```
pg_dump -h localhost -p 5432 -U postgres -F c -b -v -f "D:\backup\my_1c_db.backup" my_1c_database
```
Где:
- -h localhost: Хост, на котором работает PostgreSQL.
- -p 5432: Порт PostgreSQL.
- -U postgres: Имя пользователя PostgreSQL.
- -F c: Формат вывода (custom archive format, рекомендуется для pg_restore).
- -b: Включает большие объекты (блобы), используемые 1С.
- -v: Подробный вывод.
- -f "D:\backup\my_1c_db.backup": Путь к файлу бэкапа.
- my_1c_database: Имя вашей базы данных 1С в PostgreSQL.
Также на этом этапе мы можем выполнить выгрузку в .dt, как описано в Метод 1.
Перенесем бэкап на новую систему и восстановим:
Скопируем полученный файл бэкапа (.backup или .dt) на новую систему. Если это был pg_dump-файл, мы можем восстановить его с помощью pg_restore на новом сервере PostgreSQL.
```
pg_restore -h localhost -p 5432 -U postgres -C -d postgres -v "C:\path\to\my_1c_db.backup"
```
Где -C создаст базу данных, а -d postgres указывает, что подключение идет к системной базе для выполнения команды CREATE DATABASE. Затем нам потребуется изменить владельца базы на пользователя 1С.

Метод 3: Прямое копирование каталога data PostgreSQL (детальный разбор)

Этот метод является наиболее прямым, но и самым требовательным к соблюдению условий. Он был основной причиной проблем у автора темы. Мы должны быть очень внимательны к каждой детали, чтобы избежать ошибки "Connection refused".

Подготовка и первичные проверки

Критическое совпадение версий PostgreSQL:
Мы должны понимать, что успешное восстановление из папки data возможно ТОЛЬКО, если версия PostgreSQL на новом сервере (включая минорные версии, например, 12.0 и 12.5 могут быть несовместимы) ТОЧНО такая же, как и на старом. Различные версии используют разные форматы данных, что приведет к невозможности запуска службы. Удостоверимся, что мы установили правильную версию. В случае автора это была PostgreSQL 12 (1C версии).
Остановка службы PostgreSQL:
Перед тем как копировать или заменять папку data, мы обязаны полностью остановить службу PostgreSQL на новой системе. Мы можем это сделать через "Службы" Windows (services.msc) или командной строкой:
net stop postgresql-x64-12
(Замените postgresql-x64-12 на актуальное имя вашей службы PostgreSQL).
Копирование всей папки data:
Найдем старую папку data (обычно по пути типа C:\Program Files\PostgreSQL\12\data или C:\Program Files\PostgreSQL 1C\12\data). Скопируем всю эту папку со всеми ее вложенными файлами и каталогами. Затем мы заменим ею новую папку data, созданную при установке PostgreSQL на новом SSD. Не будем копировать только отдельные файлы или подпапки, всегда весь кластер баз данных.

Устранение ошибки "Connection refused" и запуск службы

Ошибка "Connection refused" (0x0000274D/10061) означает, что попытка подключения была активно отклонена сервером PostgreSQL. Это происходит, когда сервер либо не запущен, либо настроен так, что отклоняет ваше соединение. Разберем основные шаги по ее устранению.

Шаг 1: Проверка статуса службы PostgreSQL.
Прежде всего, мы убедимся, что служба PostgreSQL вообще запущена. Мы можем это сделать через "Диспетчер задач" (вкладка "Службы") или через оснастку "Службы" (services.msc).
- Если служба не запущена, попытаемся запустить ее вручную.
- Если она не запускается, это указывает на более глубокую проблему (часто связанные с правами доступа или конфигурацией), которую мы будем решать далее.
Шаг 2: Проверка и настройка прав доступа к папке data.
Это одна из наиболее частых причин, по которой служба PostgreSQL отказывается запускаться на Windows после переноса папки data. Служба PostgreSQL запускается от имени специального пользователя (обычно "Сетевая служба", "Local System" или специально созданный пользователь PostgreSQL, например, postgres). Этот пользователь должен иметь полные права на папку data и все ее содержимое.

Порядок действий:
1. Найдем папку data на новом диске.
2. Кликнем правой кнопкой мыши по ней, выберем Свойства -> Безопасность.
3. Нажмем Изменить..., затем Добавить....
4. Введем имя пользователя или группы, от имени которой запускается служба PostgreSQL (например, NETWORK SERVICE или postgres, если создавали специального пользователя). Нажмем Проверить имена и ОК.
5. Выделим добавленного пользователя/группу и установим галочку Полный доступ.
6. Нажмем Применить и ОК. Убедимся, что права применены ко всем вложенным объектам.
После изменения прав доступа, попробуем запустить службу PostgreSQL снова.
Шаг 3: Проверка конфигурационных файлов (`postgresql.conf`).
Этот файл находится внутри папки data. Мы откроем его текстовым редактором (например, Notepad++ или VS Code) и проверим следующие параметры:
- data_directory: Если вы переместили папку data в нестандартное место, убедимся, что этот параметр (или путь, который указан в службе Windows) указывает на корректный путь. Однако, чаще всего, если мы заменяем всю папку data, этот параметр не требует изменения, так как он обычно определяет местоположение каталога данных относительно установки PostgreSQL.
- port: Проверим, какой порт указан. У автора темы фигурирует порт 5433. Если на старой системе использовался этот порт, убедимся, что он установлен и здесь. Если нет, установим port = 5433 или вернем к стандартному port = 5432 и будем подключаться к нему. Важно, чтобы порт в конфигурации PostgreSQL совпадал с портом, к которому пытается подключиться pgAdmin или 1С.
- listen_addresses: Этот параметр определяет, какие IP-адреса будет прослушивать PostgreSQL.
 - Если установлено listen_addresses = 'localhost', PostgreSQL будет принимать соединения только с локального компьютера.
 - Для возможности подключения извне (или даже из pgAdmin, если он запускается под другим сетевым контекстом) мы установим listen_addresses = '*'.
```
# Пример настройки в postgresql.conf
listen_addresses = '*'
port = 5433
```
После любых изменений в postgresql.conf, нам необходимо перезапустить службу PostgreSQL, чтобы изменения вступили в силу.
Шаг 4: Настройка файла аутентификации (`pg_hba.conf`).
Этот файл также находится в папке data и контролирует аутентификацию и доступ к базам данных. Если в нем нет соответствующей записи для вашего клиента, соединение будет отклонено (что также может привести к "Connection refused").

Мы откроем pg_hba.conf текстовым редактором. Убедимся, что есть записи, разрешающие подключение с "localhost" или с конкретных IP-адресов. Ниже приведены примеры записей:
```
# TYPE  DATABASE        USER            ADDRESS                 METHOD
# Для локальных подключений (с сервера, где установлен PostgreSQL)
host    all             all             127.0.0.1/32            md5
host    all             all             ::1/128                 md5

# Для подключений с любого IP-адреса (будьте осторожны с безопасностью!)
# host    all             all             0.0.0.0/0               md5
```
Где:
- TYPE: Тип соединения (host для TCP/IP).
- DATABASE: К какой базе разрешен доступ (all - ко всем).
- USER: Какому пользователю разрешен доступ (all - всем).
- ADDRESS: С каких IP-адресов разрешено подключение. 127.0.0.1/32 для IPv4 локалхоста, ::1/128 для IPv6 локалхоста. 0.0.0.0/0 разрешает подключения с любого IPv4-адреса, что менее безопасно.
- METHOD: Метод аутентификации (md5 - пароль по MD5, trust - без пароля, крайне не рекомендуется для продакшн-систем).
После любых изменений в pg_hba.conf, нам также необходимо перезапустить службу PostgreSQL.
Шаг 5: Удаление файла postmaster.pid.
Иногда после неудачных попыток запуска PostgreSQL в папке data остается файл postmaster.pid. Этот файл служит для индикации, что сервер уже запущен. Если он остался от предыдущего сбойного запуска, PostgreSQL может посчитать, что сервер уже работает, и откажется запускаться. Найдем и удалим этот файл перед очередной попыткой запуска службы.
Шаг 6: Перерегистрация службы PostgreSQL в Windows (если требуется).
Если мы скопировали папку data, а служба все равно не запускается или указывает на старый каталог данных (особенно если мы меняли путь установки PostgreSQL), может потребоваться перерегистрация службы. Мы будем использовать утилиту pg_ctl, которая находится в каталоге bin установленного PostgreSQL.

Откроем командную строку от имени администратора и выполним следующие команды:
```
# Сначала удалим существующую службу (замените имя службы на ваше)
pg_ctl unregister -N postgresql-x64-12

# Затем зарегистрируем новую службу, указав правильный путь к data
pg_ctl register -N postgresql-x64-12 -D "C:\Path\To\Your\New\PostgreSQL\Data"
```
После этого попробуем запустить службу PostgreSQL через services.msc.
Шаг 7: Анализ логов PostgreSQL.
Если служба PostgreSQL не запускается, логи являются нашим лучшим источником информации. Мы найдем их в подкаталоге log внутри папки data или в каталоге pg_log, если настроено иначе. В логах мы увидим точную причину, по которой сервер не смог стартовать (например, "permission denied", "incompatible data format", "port already in use"). Внимательно изучим последние записи в лог-файле.

Особенности PostgreSQL для 1С

Мы должны учитывать, что для 1С часто используются специальные сборки PostgreSQL (например, Postgres Pro 1C), которые содержат патчи и оптимизации для лучшей работы с платформой 1С. При восстановлении базы данных крайне рекомендуется использовать ту же сборку и версию PostgreSQL, что и на старом сервере.

При переносе каталога данных для 1С PostgreSQL на Windows, нам также может потребоваться изменить путь к базам данных в реестре Windows. Это относится к параметру ImagePath для соответствующей службы PostgreSQL, например, в ветке HKLM\SYSTEM\CurrentControlSet\Services\postgresql-1c-XX, где XX – это версия PostgreSQL.

Работа с разными версиями PostgreSQL и утилита pg_upgrade

Если старая и новая версии PostgreSQL отличаются (например, вы переходите с PostgreSQL 10 на PostgreSQL 12), прямое копирование папки data не сработает. В таком случае нам на помощь приходит утилита pg_upgrade. Она предназначена для обновления кластера баз данных PostgreSQL до новой основной версии без необходимости полного дампа и восстановления.

Принцип работы pg_upgrade:

Мы устанавливаем обе версии PostgreSQL (старую и новую).
Запускаем pg_upgrade, указывая пути к каталогам bin и data для обеих версий.
Утилита pg_upgrade сравнивает каталоги данных, выполняет необходимые преобразования на месте или путем создания ссылок, затем запускает новую версию PostgreSQL с обновленными данными.

Важно: Перед использованием pg_upgrade всегда делаем полную резервную копию старой базы данных! Хотя pg_upgrade безопасна, бэкап всегда является страховкой. Для этой задачи можно использовать скрипты архивации и восстановления PostgreSQL средствами pg_dump и pg_restore для Windows.

Альтернативные и аварийные методы

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

Ручное восстановление из файлов: Это очень сложная и рискованная процедура, требующая глубоких знаний внутренней структуры файлов PostgreSQL. Она крайне не рекомендуется без крайней необходимости и помощи высококвалифицированных специалистов. Попытки ручного изменения файлов могут привести к безвозвратной потере данных.
Сброс лога транзакций (pg_resetwal / pg_resetxlog): В крайних случаях, если лог транзакций (WAL - Write-Ahead Log) поврежден и мешает запуску сервера, мы можем попробовать использовать утилиту pg_resetwal (или pg_resetxlog для очень старых версий). Эта утилита сбрасывает информацию о состоянии WAL до пустого состояния, что может позволить запустить сервер. Однако, это чрезвычайно рискованная операция, которая почти наверняка приведет к потере данных, которые не были записаны в основные файлы базы до момента повреждения WAL. Применяем ее только как последнее средство и с полным пониманием рисков.

Заключение

Восстановление базы данных PostgreSQL для 1С из папки data на новой системе – это задача, которая требует системного подхода и внимательности к деталям. Мы рассмотрели несколько основных стратегий: использование .dt файлов, виртуализацию для создания бэкапа и прямое копирование папки data.

При выборе прямого копирования каталога data, критически важно обеспечить полное совпадение версий PostgreSQL, настроить права доступа к файлам, правильно сконфигурировать postgresql.conf и pg_hba.conf, а также внимательно изучать логи PostgreSQL при возникновении проблем, таких как "Connection refused". Последовательное выполнение всех шагов и анализ диагностической информации помогут нам успешно восстановить работоспособность вашей информационной базы 1С.