Возврат информационной базы 1С из резервной копии PostgreSQL без потери данных

Базу 1С на PostgreSQL восстанавливают двумя способами. Если есть дамп СУБД, создайте пустую базу с той же кодировкой и выполните pg_restore -d имя_базы файл.dump. Если есть выгрузка .dt, откройте Конфигуратор и выберите Администрирование → Загрузить информационную базу.

Сбой случился, бухгалтерия стоит, а под рукой только файл копии. Ниже порядок, при котором база вернётся целой с первого раза: без конфликтов кодировки, «чужих» ролей и ошибки про тип mvarchar. Порядок одинаков для Windows и Linux, различаются только пути к утилитам и имена служб.

1. Подготовка сервера перед восстановлением

Сначала определите, что у вас на руках. От этого зависит весь дальнейший путь.

Что проверить на сервере

• 🧩 Сборка PostgreSQL. Нужна версия с патчами для 1С: PostgreSQL от фирмы 1С или Postgres Pro для 1С. В обычной сборке нет типов mchar и mvarchar, и восстановление упадёт.
• 🔢 Версия СУБД. Номер версии на целевом сервере не ниже той, на которой сделан дамп. Утилита pg_restore тоже должна быть той же версии или новее.
• 🔤 Кодировка и локаль исходной базы. Посмотрите их командой \l в psql на старом сервере или в свойствах базы в pgAdmin. Обычно это UTF8 и ru_RU.UTF-8 на Linux или Russian_Russia.1251 на Windows.
• 💾 Свободное место. Развёрнутая база занимает в 3–6 раз больше сжатого дампа. Плюс запас под индексы, которые строятся в конце.
• 🖥️ Версия платформы 1С на сервере не ниже той, на которой работала база.

Как остановить работу пользователей

Восстанавливать базу, в которой кто-то работает, нельзя. Останавливать весь сервер 1С при этом обычно не нужно — достаточно закрыть доступ к одной базе.

1. Откройте консоль администрирования серверов 1С.
2. Разверните кластер, найдите информационную базу и откройте её свойства.
3. Включите флажки Блокировка начала сеансов включена и Блокировка регламентных заданий включена. Укажите сообщение для пользователей и код разрешения.
4. В ветке Сеансы этой базы завершите оставшиеся сеансы.

После этого закройте лишние соединения со стороны СУБД:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'buh' AND pid <> pg_backend_pid();

Если нужно остановить службы целиком, на Linux это systemctl stop для службы агента сервера 1С и службы PostgreSQL. Их имена зависят от версии и сборки, точное имя покажет systemctl list-units | grep -E "1c|postgres". На Windows службы называются «Агент сервера 1С:Предприятия 8.3» и PostgreSQL с номером версии, их останавливают в оснастке services.msc.

2. Восстановление базы 1С из дампа PostgreSQL через pg_restore

Главный приём практика: не восстанавливайте поверх рабочей базы. Разверните копию в новую базу СУБД, проверьте её и только потом переключите на неё информационную базу 1С. Испорченный оригинал при этом остаётся на месте до конца проверки.

Шаг 1. Создайте пустую базу

Создавайте от шаблона template0, иначе не получится задать свою кодировку и локаль:

createdb -U postgres -h localhost -T template0 -E UTF8 \
  --lc-collate=ru_RU.UTF-8 --lc-ctype=ru_RU.UTF-8 buh_restore

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

Шаг 2. Запустите восстановление

Для дампа в формате custom:

pg_restore -U postgres -h localhost -d buh_restore \
  -j 4 --no-owner --role=postgres -v /backup/buh.dump

Что делают ключи:

• -j 4 — восстановление в 4 потока. Ставьте по числу ядер, но не больше 8: дальше упрётесь в диск.
• --no-owner и --role — объекты получат владельца из --role. Это спасает, если на новом сервере нет пользователя, от имени которого делали дамп.
• -v — подробный вывод, по нему видно, на какой таблице идёт работа.

Для SQL-скрипта pg_restore не подходит, используйте psql:

psql -U postgres -h localhost -d buh_restore -f /backup/buh.sql

На Windows утилиты лежат в папке bin каталога установки PostgreSQL, например C:\Program Files\PostgreSQL\15.x\bin. Номер версии в пути у вас свой.

Шаг 3. Обновите статистику

После pg_restore у таблиц нет статистики, и первые часы 1С будет работать медленно. Соберите её сразу:

vacuumdb -U postgres -h localhost -d buh_restore --analyze -j 4

Шаг 4. Подключите базу к 1С

1. В консоли администрирования откройте свойства информационной базы.
2. В поле База данных замените старое имя на buh_restore.
3. Сохраните и снимите блокировку начала сеансов после проверки.

Второй вариант — переименовать базы в PostgreSQL и ничего не менять в 1С:

ALTER DATABASE buh RENAME TO buh_broken;
ALTER DATABASE buh_restore RENAME TO buh;

3. Восстановление базы из выгрузки 1С (dt-файл)

Выгрузка .dt не зависит от СУБД. Её можно загрузить в базу на PostgreSQL, даже если сделана она была в файловом варианте или на MS SQL.

Порядок загрузки

1. В консоли кластера создайте новую информационную базу: тип СУБД PostgreSQL, сервер СУБД, имя базы, пользователь. Флажок Создать базу данных в случае ее отсутствия включите — PostgreSQL-базу 1С создаст сама.
2. Добавьте базу в список запуска и откройте её в режиме Конфигуратор.
3. Выберите Администрирование → Загрузить информационную базу и укажите файл .dt.
4. Подтвердите, что текущие данные будут заменены. Дождитесь сообщения об успешной загрузке.

Загрузка требует монопольного режима: в базе не должно быть других сеансов, включая фоновые задания.

Загрузка из командной строки

Для больших файлов удобнее запуск без интерфейса — он не зависнет при случайном клике в окне Конфигуратора:

"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8.exe" DESIGNER /S "srv1c\buh" /N "Администратор" /P "пароль" /RestoreIB "D:\backup\buh.dt" /Out "D:\backup\restore.log"

Номер платформы в пути замените на свой. Результат смотрите в файле из /Out.

dt или дамп: что выбрать

Дамп СУБД восстанавливается в разы быстрее: база на 100 ГБ поднимается через pg_restore за десятки минут, а из .dt — за несколько часов. Зато .dt переносится между любыми СУБД и версиями PostgreSQL. Хорошая практика — делать оба вида копий: ежедневный дамп и еженедельную выгрузку .dt.

4. Проверка восстановленной базы

Восстановление без ошибок в консоли ещё не значит, что база рабочая. Проверьте её до того, как пустить пользователей.

На стороне PostgreSQL

• 📋 В конце вывода pg_restore не должно быть строки errors ignored on restore. Если она есть, прокрутите лог вверх и найдите каждую ошибку.
• 📏 Сравните размер баз: SELECT pg_size_pretty(pg_database_size('buh_restore'));. Резкая разница с оригиналом — повод разобраться.
• 🔍 Проверить, читается ли сам дамп, можно ещё до восстановления: pg_restore -l buh.dump > list.txt. Утилита выведет оглавление архива. Если файл обрезан, команда завершится ошибкой.

На стороне 1С

1. Откройте базу в режиме 1С:Предприятие под администратором.
2. Сверьте контрольные цифры за последний закрытый период: оборотно-сальдовую ведомость, остатки по ключевым счетам, число документов за месяц.
3. Проверьте последние документы перед сбоем: так вы поймёте, на какой момент сделана копия.
4. Запустите Администрирование → Тестирование и исправление в Конфигураторе. Для первой проверки отметьте Проверка логической целостности информационной базы и Проверка ссылочной целостности информационной базы в режиме «только проверка», без исправления.

Если база восстановлена на тот же адрес

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

5. Автоматические резервные копии по расписанию

Восстановить можно только ту копию, которая есть. Настройте дампы по расписанию один раз и проверяйте, что они создаются.

Linux: скрипт и cron

#!/bin/bash
# /opt/backup/pg_1c_backup.sh
BACKUP_DIR=/backup/pg
DB=buh
DATE=$(date +%Y-%m-%d_%H-%M)

pg_dump -U postgres -h localhost -Fc -Z 6 -f "$BACKUP_DIR/${DB}_${DATE}.dump" "$DB" \
  || echo "Ошибка дампа $DB" | logger -t pg_backup

# хранить 14 дней
find "$BACKUP_DIR" -name "${DB}_*.dump" -mtime +14 -delete

Пароль не пишите в скрипт. Положите его в файл ~/.pgpass пользователя, от которого запускается задание, в формате localhost:5432:*:postgres:пароль и выставьте права chmod 600 ~/.pgpass.

Строка для crontab -e, запуск каждый день в 2:30:

30 2 * * * /opt/backup/pg_1c_backup.sh

Windows: bat-файл и Планировщик заданий

@echo off
set PGBIN=C:\Program Files\PostgreSQL\15.x\bin
set DB=buh
set D=%date:~6,4%-%date:~3,2%-%date:~0,2%
"%PGBIN%\pg_dump.exe" -U postgres -h localhost -Fc -f "D:\backup\%DB%_%D%.dump" %DB%
forfiles /p "D:\backup" /m "%DB%_*.dump" /d -14 /c "cmd /c del @path"

Пароль храните в %APPDATA%\postgresql\pgpass.conf того пользователя, под которым работает задание. В Планировщике создайте задачу с ежедневным триггером и включите запуск независимо от входа пользователя в систему.

Что ещё настроить

• 🗄️ Копируйте дампы на другой диск или сервер. Копия на том же диске пропадёт вместе с базой.
• 🧪 Раз в месяц восстанавливайте свежий дамп в тестовую базу. Только так вы узнаете, что копии рабочие.
• 🔔 Следите за размером файлов: дамп, который вдруг стал в два раза меньше вчерашнего, — сигнал проблемы.

6. Частые ошибки при восстановлении и их решение

Нехватка места посреди восстановления

Если диск закончился во время pg_restore, база останется недовосстановленной. Не пытайтесь «доуложить» её повторным запуском: удалите базу командой dropdb buh_restore, освободите место и начните заново с пустой базы. Повторный прогон поверх частично восстановленной базы даёт ошибки дублирования ключей.

Восстановление идёт слишком долго

• ⚡ Увеличьте -j до числа ядер процессора.
• ⚙️ На время восстановления поднимите maintenance_work_mem до 1–2 ГБ в postgresql.conf: так быстрее строятся индексы. После окончания верните прежнее значение.
• 💽 Держите дамп и каталог данных на разных дисках, чтобы чтение и запись не мешали друг другу.

7. Частые вопросы