Бэкап PostgreSQL для 1С 8.3: pg_dump, WAL и point-in-time recovery

Базы 1С на PostgreSQL требуют продуманной стратегии резервного копирования. Штатная выгрузка .dt через Конфигуратор останавливает работу пользователей на 15-30 минут. Средства PostgreSQL решают эту задачу иначе: pg_dump создаёт логический дамп без блокировок, а pg_basebackup копирует кластер целиком с возможностью восстановления на конкретную секунду.

В этой статье: pg_dump vs pg_basebackup — когда что использовать, WAL-архивирование и point-in-time recovery, скрипты автоматизации с ротацией через cron, мониторинг бэкапов и типичные ошибки. Результат — автоматический бэкап PostgreSQL для 1С с проверкой, ротацией и уведомлениями.

Статья для администраторов, которые работают с 1С на PostgreSQL в клиент-серверном режиме. Если выбираете между СУБД — начните с сравнения SQL Server и PostgreSQL для 1С. Общий обзор всех методов резервного копирования 1С 8.3 — в полном руководстве по бэкапу 1С. Бэкап на SQL Server описан в отдельной инструкции.

Два подхода к бэкапу PostgreSQL для 1С

PostgreSQL предлагает два принципиально разных механизма резервного копирования. Логический дамп (pg_dump) экспортирует данные в SQL-формате. Физическое копирование (pg_basebackup + WAL) дублирует файлы кластера на уровне блоков.

Для продуктивного сервера 1С с 10+ пользователями используйте оба метода. pg_dump — ежедневный дамп для переносимости и быстрого восстановления отдельной базы. pg_basebackup + WAL — непрерывная защита с возможностью восстановления на конкретную секунду.

Бэкап базы 1С через pg_dump

pg_dump создаёт логический дамп одной базы данных. Работает без остановки PostgreSQL, без блокировки пользователей 1С. Использует MVCC-снимок — дамп консистентен на момент начала, даже если пользователи продолжают работать.

Базовая команда

# Дамп одной базы 1С в custom-формат (сжатый, с возможностью выборочного восстановления)
pg_dump -h localhost -U postgres -Fc -Z 6 -f /backup/1c/mybase1c_$(date +%Y-%m-%d_%H%M).dump mybase1c

# Дамп в plain SQL (для переноса между версиями PostgreSQL)
pg_dump -h localhost -U postgres -Fp -f /backup/1c/mybase1c_$(date +%Y-%m-%d_%H%M).sql mybase1c

# Дамп всех баз кластера (pg_dumpall — включает роли и настройки)
pg_dumpall -h localhost -U postgres -f /backup/1c/cluster_$(date +%Y-%m-%d_%H%M).sql

Флаг -Fc создаёт custom-формат — сжатый бинарный файл. Восстанавливается через pg_restore с возможностью выбрать отдельные таблицы. Флаг -Z 6 задаёт уровень сжатия (0-9). Базы 1С сжимаются в 3-5 раз: база 20 ГБ даёт дамп 4-7 ГБ.

Параллельный дамп (ускорение на многоядерных серверах)

На сервере с несколькими ядрами pg_dump можно запустить в параллельном режиме. Каждый поток дампит отдельную таблицу — на базе с десятками таблиц это сокращает время в 2-4 раза.

# Параллельный дамп в directory-формат (4 потока)
pg_dump -h localhost -U postgres -Fd -j 4 -Z 6 -f /backup/1c/mybase1c_$(date +%Y-%m-%d_%H%M) mybase1c

# Параллельное восстановление (4 потока)
pg_restore -h localhost -U postgres -d mybase1c_restored -j 4 /backup/1c/mybase1c_2026-03-15_0100

Флаг -Fd создаёт каталог с отдельными файлами для каждой таблицы. Только этот формат поддерживает параллельный дамп и восстановление. Для базы 1С на 50 ГБ с 4 потоками дамп занимает 5-8 минут вместо 15-20.

Восстановление из pg_dump

# Восстановление custom-формата в новую базу
createdb -h localhost -U postgres mybase1c_restored
pg_restore -h localhost -U postgres -d mybase1c_restored /backup/1c/mybase1c_2026-03-15_0100.dump

# Восстановление с перезаписью существующей базы
dropdb -h localhost -U postgres mybase1c
createdb -h localhost -U postgres mybase1c
pg_restore -h localhost -U postgres -d mybase1c /backup/1c/mybase1c_2026-03-15_0100.dump

# Восстановление plain SQL
psql -h localhost -U postgres -d mybase1c_restored -f /backup/1c/mybase1c_2026-03-15_0100.sql

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

Физический бэкап: pg_basebackup и WAL-архивирование

pg_basebackup создаёт полную копию кластера PostgreSQL на уровне файлов. В связке с WAL-архивированием это даёт непрерывную защиту данных и возможность восстановления на конкретную секунду — point-in-time recovery (PITR).

Принцип: pg_basebackup копирует файлы данных, а WAL-сегменты (Write-Ahead Log) записывают каждое изменение после бэкапа. При восстановлении PostgreSQL проигрывает WAL-сегменты поверх базовой копии — вы получаете состояние базы на любую секунду.

Настройка WAL-архивирования

Перед использованием pg_basebackup для PITR настройте архивирование WAL-сегментов. Откройте postgresql.conf:

# postgresql.conf — настройки WAL-архивирования

wal_level = replica                    # минимум для PITR (по умолчанию с PG 10)
archive_mode = on                      # включить архивирование
archive_command = 'cp %p /backup/wal/%f'  # команда копирования WAL-сегмента
archive_timeout = 300                  # принудительная смена WAL каждые 5 минут (для низкой нагрузки)

Параметр archive_command вызывается PostgreSQL для каждого заполненного WAL-сегмента (16 МБ по умолчанию). Команда должна вернуть код 0 при успехе. Если вернёт ненулевой код — PostgreSQL повторит попытку. WAL-сегменты не удаляются, пока не заархивированы.

Параметр archive_timeout важен для серверов 1С с низкой нагрузкой (5-10 пользователей). Без него WAL-сегмент может заполняться часами — и при сбое вы потеряете все изменения с момента последнего заполненного сегмента. С archive_timeout = 300 максимальная потеря — 5 минут.

После изменения конфигурации перезапустите PostgreSQL:

sudo systemctl restart postgresql

Создание базового бэкапа

# Полная копия кластера в tar-формате со сжатием
pg_basebackup -h localhost -U postgres -D /backup/base/$(date +%Y-%m-%d_%H%M) \
  -Ft -z -Xs -P

# Ключи:
# -Ft    — tar-формат (один файл, удобно для хранения)
# -z     — gzip-сжатие
# -Xs    — включить WAL-сегменты за время бэкапа (stream)
# -P     — показать прогресс

Флаг -Xs (WAL streaming) критичен. Без него PostgreSQL может переработать WAL-сегменты, которые нужны для консистентности бэкапа. С -Xs pg_basebackup открывает второе соединение и получает WAL в реальном времени.

На сервере с базой 1С 20 ГБ pg_basebackup занимает 3-10 минут в зависимости от дисковой подсистемы. На NVMe — ближе к 3 минутам, на SAS — до 10. Подробнее о влиянии дисков — в сравнении SAS, SSD и NVMe для сервера 1С.

Point-in-time recovery (PITR)

Сценарий: в 14:35 оператор случайно удалил документы за месяц. Нужно восстановить базу на 14:34. Для этого нужен базовый бэкап (pg_basebackup) + WAL-архивы с момента бэкапа до 14:34.

# 1. Остановить PostgreSQL
sudo systemctl stop postgresql

# 2. Переименовать текущий каталог данных
mv /var/lib/postgresql/16/main /var/lib/postgresql/16/main_broken

# 3. Распаковать базовый бэкап
mkdir /var/lib/postgresql/16/main
tar xzf /backup/base/2026-03-15_0100/base.tar.gz -C /var/lib/postgresql/16/main
tar xzf /backup/base/2026-03-15_0100/pg_wal.tar.gz -C /var/lib/postgresql/16/main/pg_wal

# 4. Создать файл восстановления
cat > /var/lib/postgresql/16/main/postgresql.auto.conf << 'EOF'
restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '2026-03-15 14:34:00'
recovery_target_action = 'promote'
EOF

# 5. Создать сигнальный файл
touch /var/lib/postgresql/16/main/recovery.signal

# 6. Установить владельца
chown -R postgres:postgres /var/lib/postgresql/16/main

# 7. Запустить PostgreSQL
sudo systemctl start postgresql

PostgreSQL при запуске увидит recovery.signal, прочитает WAL-архивы через restore_command и применит все транзакции до 14:34:00. Транзакции после этого момента будут отброшены. После завершения восстановления файл recovery.signal удалится автоматически.

После восстановления проверьте базу в 1С — откройте документы за последний рабочий день. Если всё корректно — сделайте новый pg_basebackup, чтобы начать свежую цепочку WAL-архивов.

Автоматизация бэкапа PostgreSQL через cron

Ручной запуск pg_dump или pg_basebackup — источник ошибок. Забыли, заболели, в отпуске — и бэкапов нет неделю. Автоматизация через cron и bash-скрипты решает проблему.

Скрипт ежедневного pg_dump с ротацией

#!/bin/bash
# /opt/scripts/backup-1c-pgdump.sh
# Ежедневный дамп всех баз 1С с ротацией

BACKUP_DIR="/backup/1c/dumps"
RETENTION_DAYS=14
PG_USER="postgres"
TIMESTAMP=$(date +%Y-%m-%d_%H%M)
LOG_FILE="/var/log/backup-1c-pgdump.log"

mkdir -p "$BACKUP_DIR"

echo "[$TIMESTAMP] Начало бэкапа" >> "$LOG_FILE"

# Получить список баз 1С (исключить системные)
DATABASES=$(psql -U "$PG_USER" -t -c \
  "SELECT datname FROM pg_database WHERE datistemplate = false AND datname NOT IN ('postgres');" \
  | tr -d ' ')

ERRORS=0

for DB in $DATABASES; do
  DUMP_FILE="$BACKUP_DIR/${DB}_${TIMESTAMP}.dump"

  pg_dump -U "$PG_USER" -Fc -Z 6 -f "$DUMP_FILE" "$DB" 2>> "$LOG_FILE"

  if [ $? -eq 0 ]; then
    SIZE=$(du -sh "$DUMP_FILE" | cut -f1)
    echo "[$TIMESTAMP] OK: $DB -> $DUMP_FILE ($SIZE)" >> "$LOG_FILE"
  else
    echo "[$TIMESTAMP] ОШИБКА: $DB — pg_dump вернул ненулевой код" >> "$LOG_FILE"
    ERRORS=$((ERRORS + 1))
  fi
done

# Ротация: удалить дампы старше RETENTION_DAYS
find "$BACKUP_DIR" -name "*.dump" -mtime +$RETENTION_DAYS -delete
echo "[$TIMESTAMP] Ротация: удалены файлы старше $RETENTION_DAYS дней" >> "$LOG_FILE"

# Уведомление при ошибках
if [ $ERRORS -gt 0 ]; then
  echo "Бэкап 1С PostgreSQL: $ERRORS ошибок. Подробности: $LOG_FILE" | \
    mail -s "ОШИБКА: бэкап 1С PostgreSQL" admin@example.com
fi

echo "[$TIMESTAMP] Завершено. Ошибок: $ERRORS" >> "$LOG_FILE"

Скрипт еженедельного pg_basebackup

#!/bin/bash
# /opt/scripts/backup-1c-basebackup.sh
# Еженедельный физический бэкап кластера PostgreSQL

BACKUP_DIR="/backup/1c/base"
RETENTION_DAYS=28
PG_USER="postgres"
TIMESTAMP=$(date +%Y-%m-%d_%H%M)
TARGET_DIR="$BACKUP_DIR/$TIMESTAMP"
LOG_FILE="/var/log/backup-1c-base.log"

mkdir -p "$TARGET_DIR"

echo "[$TIMESTAMP] Начало pg_basebackup" >> "$LOG_FILE"

pg_basebackup -U "$PG_USER" -D "$TARGET_DIR" -Ft -z -Xs -P 2>> "$LOG_FILE"

if [ $? -eq 0 ]; then
  SIZE=$(du -sh "$TARGET_DIR" | cut -f1)
  echo "[$TIMESTAMP] OK: pg_basebackup -> $TARGET_DIR ($SIZE)" >> "$LOG_FILE"
else
  echo "[$TIMESTAMP] ОШИБКА: pg_basebackup вернул ненулевой код" >> "$LOG_FILE"
  echo "Бэкап 1С pg_basebackup: ОШИБКА. Подробности: $LOG_FILE" | \
    mail -s "ОШИБКА: pg_basebackup 1С" admin@example.com
  exit 1
fi

# Ротация: удалить каталоги бэкапов старше RETENTION_DAYS
find "$BACKUP_DIR" -maxdepth 1 -type d -mtime +$RETENTION_DAYS -exec rm -rf {} +
echo "[$TIMESTAMP] Ротация: удалены бэкапы старше $RETENTION_DAYS дней" >> "$LOG_FILE"

Скрипт очистки WAL-архивов

#!/bin/bash
# /opt/scripts/cleanup-wal.sh
# Удаление WAL-архивов, которые больше не нужны для восстановления

WAL_DIR="/backup/wal"
LOG_FILE="/var/log/backup-1c-wal-cleanup.log"
TIMESTAMP=$(date +%Y-%m-%d_%H%M)

# Определить самый старый базовый бэкап
OLDEST_BACKUP=$(ls -1t /backup/1c/base/ | tail -1)

if [ -z "$OLDEST_BACKUP" ]; then
  echo "[$TIMESTAMP] Нет базовых бэкапов — WAL не удаляем" >> "$LOG_FILE"
  exit 0
fi

# pg_archivecleanup удаляет WAL-сегменты, которые не нужны для восстановления
# из самого старого базового бэкапа
OLDEST_WAL=$(tar tzf "/backup/1c/base/$OLDEST_BACKUP/pg_wal.tar.gz" | head -1)

pg_archivecleanup "$WAL_DIR" "$OLDEST_WAL" 2>> "$LOG_FILE"
echo "[$TIMESTAMP] Очистка WAL до $OLDEST_WAL" >> "$LOG_FILE"

Настройка cron

# crontab -e (от пользователя postgres или root)

# Ежедневный дамп всех баз 1С в 01:00
0 1 * * * /opt/scripts/backup-1c-pgdump.sh

# Еженедельный pg_basebackup в воскресенье в 02:00
0 2 * * 0 /opt/scripts/backup-1c-basebackup.sh

# Очистка WAL-архивов — ежедневно в 03:00
0 3 * * * /opt/scripts/cleanup-wal.sh

Права на скрипты: chmod +x /opt/scripts/backup-1c-*.sh. Запускайте от пользователя postgres или от root с -U postgres в командах. Для pg_dump и pg_basebackup без ввода пароля настройте файл ~/.pgpass:

# ~/.pgpass — автоматическая аутентификация без пароля
# формат: hostname:port:database:username:password
localhost:5432:*:postgres:ВашПароль

# Права (обязательно — PostgreSQL откажется читать файл с широкими правами)
chmod 600 ~/.pgpass

Рекомендуемое расписание бэкапов

Расписание зависит от числа пользователей, объёма изменений и допустимого RPO (максимальная потеря данных).

Для баз 1С с интенсивной работой (ERP, управление торговлей, 50+ пользователей) установите archive_timeout = 60 — принудительная смена WAL каждую минуту. Максимальная потеря — 1 минута. Для бухгалтерии на 5-10 человек — 10 минут достаточно.

Мониторинг бэкапов

Бэкап без мониторинга — бомба замедленного действия. Скрипт может падать неделями, диск заполниться, WAL-архивирование остановиться — и вы узнаете об этом при аварии.

Что проверять

Скрипт мониторинга

#!/bin/bash
# /opt/scripts/check-backup-1c.sh
# Проверка свежести бэкапов — запускать через cron каждый час

DUMP_DIR="/backup/1c/dumps"
BASE_DIR="/backup/1c/base"
WAL_DIR="/backup/wal"
MAX_DUMP_AGE_HOURS=25
ALERT_EMAIL="admin@example.com"
ERRORS=""

# Проверка свежести pg_dump
LATEST_DUMP=$(find "$DUMP_DIR" -name "*.dump" -mmin -$((MAX_DUMP_AGE_HOURS * 60)) | head -1)
if [ -z "$LATEST_DUMP" ]; then
  ERRORS="$ERRORS\n- pg_dump: нет свежих дампов за последние ${MAX_DUMP_AGE_HOURS}ч"
fi

# Проверка WAL-архивирования
FAILED_WAL=$(psql -U postgres -t -c "SELECT last_failed_wal FROM pg_stat_archiver;" | tr -d ' ')
if [ -n "$FAILED_WAL" ] && [ "$FAILED_WAL" != "" ]; then
  LAST_FAIL_TIME=$(psql -U postgres -t -c "SELECT last_failed_time FROM pg_stat_archiver;" | tr -d ' ')
  ERRORS="$ERRORS\n- WAL: ошибка архивирования $FAILED_WAL в $LAST_FAIL_TIME"
fi

# Проверка свободного места
USAGE=$(df --output=pcent /backup | tail -1 | tr -d ' %')
if [ "$USAGE" -gt 85 ]; then
  ERRORS="$ERRORS\n- Диск /backup заполнен на ${USAGE}%"
fi

# Отправить алерт
if [ -n "$ERRORS" ]; then
  echo -e "Проблемы с бэкапом 1С PostgreSQL:\n$ERRORS" | \
    mail -s "АЛЕРТ: бэкап 1С PostgreSQL" "$ALERT_EMAIL"
fi

Добавьте скрипт в cron: 0 * * * * /opt/scripts/check-backup-1c.sh — проверка каждый час. Для критичных серверов настройте отправку в Telegram через бот — email может прийти с задержкой.

Пошаговая инструкция: настройка бэкапа 1С на PostgreSQL

Типичные ошибки при бэкапе PostgreSQL для 1С

Переполнение pg_wal из-за сломанного archive_command

Симптом: каталог pg_wal вырос до десятков гигабайт, диск заполнен, PostgreSQL останавливается. Причина: archive_command возвращает ненулевой код (ошибка прав, каталог не существует, диск заполнен). PostgreSQL не удаляет WAL-сегменты, пока они не заархивированы.

Решение: проверьте SELECT * FROM pg_stat_archiver — поле last_failed_wal покажет проблемный сегмент. Исправьте archive_command (проверьте путь, права, свободное место на /backup). Выполните SELECT pg_switch_wal() для принудительного переключения. Мониторьте размер pg_wal — если больше 2 ГБ, что-то не так.

pg_dump без --no-owner при переносе между серверами

Симптом: при восстановлении дампа на другом сервере — ошибки role "usr1cv8" does not exist. Причина: pg_dump по умолчанию сохраняет владельца объектов. Если на целевом сервере нет этого пользователя — ошибки.

Решение: при переносе между серверами используйте pg_dump --no-owner --no-privileges. Для бэкапа на тот же сервер — не нужно, пользователи на месте. Если база 1С работает от пользователя usr1cv8 — создайте его на целевом сервере перед восстановлением: CREATE ROLE usr1cv8 WITH LOGIN PASSWORD 'пароль';

Бэкап на тот же диск с данными

Бэкап в /var/lib/postgresql/ рядом с файлами данных — не бэкап. Отказ диска, шифровальщик, ошибка файловой системы — потеряете и данные, и копии одновременно.

Решение: отдельный физический диск для /backup. Ежедневное копирование на NAS или в облако. Правило 3-2-1. Подробнее о дисках — в руководстве по выбору SSD для сервера 1С.

Не настроен archive_timeout — потеря данных при низкой нагрузке

Симптом: PITR восстанавливает базу не на указанный момент, а на несколько часов раньше. Причина: WAL-сегмент заполняется только при активных транзакциях. На сервере с 5 пользователями сегмент (16 МБ) может заполняться 2-4 часа.

Решение: установите archive_timeout = 300 (5 минут) в postgresql.conf. PostgreSQL будет принудительно переключать WAL-сегмент каждые 5 минут, даже если он не заполнен. Это генерирует дополнительные WAL-файлы (до 192 МБ в час), но гарантирует RPO не более 5 минут.

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

Дампы создаются каждую ночь, файлы копируются на NAS. При аварии выясняется: дамп повреждён, версия pg_restore не совпадает, пароль от пользователя postgres утерян.

Решение: раз в месяц — тестовое восстановление. Создайте тестовую базу из последнего дампа, откройте в 1С, проверьте документы. Автоматизируйте: скрипт, который восстанавливает дамп, подключается к базе, проверяет количество записей в ключевых таблицах и удаляет тестовую базу.

Хранение бэкапов PostgreSQL

Локальные бэкапы защищают от сбоя СУБД — повреждение файлов, ошибка обновления, случайное удаление базы. Но не защищают от отказа сервера, шифровальщика, пожара. Правило 3-2-1: три копии данных, два типа носителей, одна копия вне площадки.

Копирование на удалённый сервер (rsync)

# Ежедневное копирование дампов на резервный сервер
rsync -az --delete /backup/1c/dumps/ backup-user@nas:/backup/1c-postgresql/dumps/

# Еженедельное копирование базовых бэкапов
rsync -az --delete /backup/1c/base/ backup-user@nas:/backup/1c-postgresql/base/

# WAL-архивы — ежедневно (или чаще для критичных серверов)
rsync -az /backup/wal/ backup-user@nas:/backup/1c-postgresql/wal/

Копирование в S3 (rclone)

# Копирование дампов в Yandex Object Storage
rclone sync /backup/1c/dumps/ yandex-s3:my-bucket/1c-postgresql/dumps/ --min-age 1h

# Копирование базовых бэкапов
rclone sync /backup/1c/base/ yandex-s3:my-bucket/1c-postgresql/base/ --min-age 1h

Добавьте rsync или rclone как завершающий шаг в скрипты бэкапа. При ошибке копирования — отправляйте уведомление.

Сколько места нужно

WAL-архивы при активной работе генерируют 1-5 ГБ в день. На сервере с 50+ пользователями — до 10-15 ГБ. Регулярная очистка через pg_archivecleanup обязательна, иначе WAL-архивы заполнят диск за месяц.

Вопросы и ответы

Итог

Бэкап 1С на PostgreSQL строится на двух уровнях. Первый: ежедневный pg_dump — быстрый логический дамп для оперативного восстановления отдельной базы. Второй: pg_basebackup + WAL-архивирование — физический бэкап с point-in-time recovery для защиты от любых сбоев.

Автоматизация через cron, ротация старых файлов, мониторинг свежести бэкапов и ежемесячное тестовое восстановление — обязательные элементы. Без них бэкап существует только на бумаге.

Скорость бэкапа и восстановления зависит от дисковой подсистемы. На NVMe pg_dump 20 ГБ занимает 3-5 минут, на SAS — 10-15. Производительность дисков влияет и на время простоя бизнеса при восстановлении. Подробнее о выборе оборудования — в требованиях к серверу для 1С. Сравнение SQL Server и PostgreSQL для 1С — в отдельном обзоре. Методология наших тестов — на странице методологии.

Если нужна помощь с настройкой резервного копирования PostgreSQL, выбором стратегии бэкапов или подбором серверного оборудования — оставьте заявку. Настроим бэкапы с проверкой восстановления, ротацией и мониторингом.