Бэкап PostgreSQL для 1С на pgBackRest: реальная схема, которую мы внедряем в офисах

Меня зовут Семёнов Евгений Сергеевич, корпоративными IT-инфраструктурами в Москве и Подмосковье я занимаюсь уже 15 лет. За это время через мои руки прошло несколько сотен баз 1С — сперва на файловом варианте, потом на MS SQL, а с 2022 года всё чаще на PostgreSQL. И скажу уверенно: 9 из 10 компаний, перешедших на PostgreSQL, сделали это с одной и той же ошибкой — забыли настроить нормальный бэкап. Эта статья как раз для тех, кто не хочет повторять чужие грабли.

Почему .dt — это не бэкап

Сразу развею главное заблуждение бухгалтеров и неопытных эникеев: «У нас же есть выгрузка .dt из конфигуратора, чего вы переживаете?» Я слышал эту фразу столько раз, что впору книгу писать. Поясню по пунктам, почему .dt — это не бэкап:

• Блокирует базу. На время выгрузки никто не может работать. Для базы 80 ГБ — это 60–120 минут простоя. В рабочее время — катастрофа, в нерабочее — тоже не панацея, потому что у вас часто бывает ночная обработка.
• Не работает при больших объёмах. Я лично видел минимум 8 случаев, когда выгрузка .dt падала на базах 150+ ГБ. Файл создаётся, но при попытке загрузки 1С говорит «нарушена целостность» — и всё, у вас по факту нет ни рабочей базы, ни рабочего бэкапа.
• Нет точки во времени. Если база сломалась в 14:30, а .dt сделан вчера в 23:00 — вы потеряли весь рабочий день. Никакого PITR (восстановления на момент времени) с .dt не получится.
• Один файл — одна точка отказа. Битый сектор на NAS — и вашему .dt конец. У промышленных средств бэкапа есть проверка контрольных сумм каждого блока.

Я не отговариваю делать .dt — как разовая мера он полезен: перенести базу между серверами, отдать в обновление 1С. Но как ежедневный бэкап для боевой инфраструктуры — нет, нет и ещё раз нет.

Что мы используем в АйТи Фреш для бэкапов 1С на PostgreSQL

За последние три года мы внедрили бэкап-схему на PostgreSQL у 47 клиентов — от маленьких офисов с базой 30 ГБ до производств с базой Управление Холдингом на 1.8 ТБ. И везде стоит одна и та же связка:

• pgBackRest — основной инструмент для физических бэкапов. Делает полные, дифференциальные и инкрементальные бэкапы прямо с файлов БД, не блокируя работу пользователей.
• Архивация WAL — журналы транзакций PostgreSQL копируются на бэкап-сервер каждые 60 секунд. Это даёт нам возможность восстановиться на любую секунду внутри окна хранения.
• Barman — на больших инсталляциях (база 500+ ГБ) ставим параллельно как второй уровень защиты и для удобной отчётности по бэкапам.
• Тестовое восстановление — раз в неделю автоматический скрипт восстанавливает последний бэкап на тестовый сервер и проверяет, что он реально работает. Без этого все остальные пункты — самообман.

Почему именно pgBackRest, а не pg_dump или pg_basebackup? pg_dump — это логический бэкап (как .dt, только умнее): медленный и тоже без PITR. pg_basebackup встроен в PostgreSQL, но не умеет инкрементальные бэкапы и плохо тянет большие базы. А pgBackRest — специализированное решение, написанное теми же людьми, что и Crunchy Data PostgreSQL, и оно умеет всё, что нужно для боевой эксплуатации.

Реальная схема для офиса с базой 1С Бухгалтерия и УТ

Опишу типовую инсталляцию, которую мы развернули в феврале 2026 года для торговой компании на 38 рабочих мест. Дано: 1С Бухгалтерия 3.0 (база 45 ГБ) и 1С Управление Торговлей 11.5 (база 180 ГБ), сервер на Ubuntu 22.04 с PostgreSQL 15 (сборка 1С от postgrespro). Решение:

График бэкапов выстроен так: полный — каждое воскресенье в 02:00, дифференциальный — ежедневно в 02:00 (кроме воскресенья), инкрементальный — каждые 6 часов в рабочее время, а WAL архивируются непрерывно с задержкой не больше 60 секунд. Глубина хранения — 14 дней.

Сколько это занимает места и времени

Главный вопрос от финдиров: «А не влетит ли нам это в копеечку, как маленький дата-центр?» Привожу реальные цифры с описанной выше инсталляции:

То есть для базы на 180 ГБ глубина в 14 дней занимает 120 ГБ на NAS — вся история помещается на одном диске и стоит копейки. А восстановление до состояния «на 2 часа назад» (типичный сценарий — кладовщик что-то напортачил в документе) занимает меньше часа.

Случай из практики: шифровальщик и холодная копия

В сентябре 2025 года у нашего клиента — оптовая торговля стройматериалами, 22 рабочих места, база УТ на 95 ГБ — случилась беда. Главбух открыл письмо от «налоговой» с вложением .pdf.exe (классика жанра), и через 4 часа все файлы на сервере, включая бэкапы на NAS, оказались зашифрованы. Шифровальщик из семейства LockBit, выкуп — 4.5 BTC.

А спасло нас вот что: за месяц до этого мы перевели клиента на свою схему, и холодная копия pgBackRest лежала в Яндекс Object Storage с включённым immutable-режимом (файлы нельзя удалить 30 дней даже с правами админа). Шифровальщик до неё физически не дотянулся. Мы:

1. Изолировали заражённый сервер от сети (физически выдернули сетевой кабель).
2. Развернули чистую виртуальную машину с PostgreSQL и 1С Сервером (заняло 90 минут).
3. Скачали из Яндекс.Облака последний бэкап + WAL до момента заражения.
4. Восстановили базу на момент времени за 5 минут до открытия вредоносного письма.
5. Запустили тестирование/исправление в конфигураторе (45 минут).
6. Открыли доступ пользователям.

Полный простой составил 8 часов, потеряно 5 минут работы (несколько накладных, которые потом восстановили руками). Без холодной копии в облаке это была бы потеря всей базы и, в лучшем случае, выплата выкупа. Наша схема бэкапа обходится в 4 200 рублей в месяц (Яндекс Object Storage плюс наша работа). А потерянная база — это, по оценке, 3.5 млн рублей и 2–3 недели ручного восстановления из бумажных документов.

Типовые ошибки при настройке бэкапов 1С на PostgreSQL

Когда я приезжаю на аудит к новому клиенту, который «уже сам всё настроил», вот стандартный список того, что нахожу:

• Бэкапы лежат на том же диске, что и база. Сломался диск — потеряли и базу, и бэкап. Видел такое в 2024 году на крупном производстве — RAID5 деградировал, второй диск умер при ребилде, всё пропало.
• WAL не архивируются. Настроен только полный pg_dump раз в сутки. RPO — 24 часа. То есть в худшем случае теряете весь рабочий день.
• Бэкапы делаются, но никто не проверяет. Самая массовая ошибка. Скрипт работает год, в логах галочки, а когда понадобилось — выясняется, что последние 8 месяцев бэкап был битым. Без тестового восстановления вы не знаете, есть ли у вас бэкап.
• Один экземпляр бэкапа. Локальная копия на NAS — это хорошо, но если NAS сгорит вместе с офисом или его зашифруют — приехали.
• Хранят бэкапы вечно. Видел NAS с 7 ТБ старых бэкапов 2018–2022 годов, которые никогда никому не понадобились, но место съели.
• Используют только встроенные средства 1С. Технологический журнал 1С + .dt не покрывает потребности боевой инфраструктуры. Это инструменты разработчика, а не админа.
• Нет документации. Бэкап есть, но никто, кроме «того парня, который ушёл в декрет», не знает, как из него восстановиться.

Как мы устанавливаем pgBackRest за 2 часа

Не буду превращать статью в инструкцию по командной строке — пара ключевых шагов, чтобы вы понимали объём работ:

1. Подготовка: ставим pgBackRest на сервер БД и на бэкап-сервер (NAS с поддержкой SSH или отдельная виртуалка). Создаём пользователя postgres с одинаковым UID на обеих машинах, настраиваем SSH-ключи.
2. Конфигурация: в файле /etc/pgbackrest/pgbackrest.conf описываем стэнзу (логическое имя БД), путь к файлам PostgreSQL, репозиторий хранения, тип сжатия (zstd уровень 3 — оптимум по скорости/степени сжатия).
3. Включаем архивацию WAL: в postgresql.conf прописываем archive_mode = on, archive_command = 'pgbackrest --stanza=main archive-push %p', перезагружаем PostgreSQL.
4. Создаём стэнзу: pgbackrest --stanza=main stanza-create.
5. Первый полный бэкап: pgbackrest --stanza=main --type=full backup. На 200 ГБ занимает 15–20 минут на NVMe.
6. Cron-задания: настраиваем расписание полного, дифференциального и инкрементального бэкапов через системный cron.
7. Облачная копия: настраиваем второй репозиторий типа s3 в Яндекс Object Storage с access-ключами и шифрованием.
8. Тестовое восстановление: пишем bash-скрипт, который раз в неделю поднимает PostgreSQL на тестовом сервере, восстанавливает последний бэкап, запускает pg_isready и набор SQL-проверок, отправляет отчёт в Telegram.
9. Документация: фиксируем всё в Confluence, открываем доступ клиенту, проводим обучение его сотрудника на случай экстренного восстановления.

На стандартный сервер с базой до 500 ГБ полная установка занимает 4–6 часов работы инженера — вместе с первым полным бэкапом и тестовым восстановлением. Разовая настройка стоит от 28 000 руб. Дальнейшее сопровождение входит в нашу абонентку без доплат.

Что мониторить, чтобы спать спокойно

Сделать бэкап — это полдела. Вторая половина — точно знать, что он работает. У нас в Zabbix по каждой базе клиента настроены такие триггеры:

• Возраст последнего полного бэкапа > 8 дней — критическая авария.
• Возраст последнего инкрементального бэкапа > 9 часов — предупреждение.
• Размер последнего бэкапа отличается от среднего более чем на 50 % — предупреждение (часто сигнал, что что-то странное случилось с базой).
• Задержка архивации WAL > 5 минут — предупреждение.
• Свободное место в репозитории бэкапов < 20 % — критическая авария.
• Не прошло еженедельное тестовое восстановление — критическая авария с эскалацией мне на личный мобильный.

Все алерты летят в общий Telegram-канал клиента и дублируются в нашу дежурную смену 24×7. За 2025 год по этой схеме мы поймали и устранили 17 инцидентов с бэкапами у клиентов — все до того, как клиент о них узнал.

Стоимость для разных сценариев

Ниже — типовая стоимость внедрения и сопровождения нашей бэкап-системы для PostgreSQL/1С на апрель 2026 года:

«NAS / S3 в месяц» — это аренда облачного Яндекс Object Storage плюс амортизация локального NAS из расчёта 5 лет службы. А «включено в абонентку» означает, что мониторинг бэкапов, разбор алертов, плановое тестовое восстановление и восстановление при необходимости — всё это входит в стандартный тариф обслуживания и отдельно не тарифицируется.

Когда нужно идти дальше — реплика и кластер

Бэкап решает задачу «потеряли данные — восстановили». Но он не решает другую: «сервер умер — работать надо прямо сейчас». Если час простоя 1С стоит вашему бизнесу больше 100 000 руб., одного бэкапа мало — нужна горячая реплика.

Мы используем встроенную в PostgreSQL потоковую репликацию: поднимаем второй сервер, который непрерывно тянет изменения с главного. При сбое главного ручное переключение на реплику занимает 5–15 минут, автоматическое (через Patroni) — 30 секунд. Но это уже отдельная тема, и автоматизация переключения нужна не всем — большинству офисов хватает бэкапа плюс ручной реплики.

FAQ — частые вопросы про бэкап PostgreSQL для 1С

Достаточно ли выгрузки .dt для бэкапа 1С на PostgreSQL?

Нет, для боевой эксплуатации — категорически нет. .dt блокирует базу, не даёт восстановления на момент времени и часто рвётся на больших базах. Это инструмент для миграции, а не для бэкапа.

Сколько места занимают бэкапы базы 1С на 200 ГБ?

При схеме «полный воскресенье + дифференциальный ежедневно + WAL», глубине 14 дней и сжатии zstd — около 120–150 ГБ. То есть в полтора раза меньше самой базы благодаря сжатию и дедупликации повторяющихся блоков.

Какое RPO и RTO реально для 1С на PostgreSQL?

С грамотной настройкой pgBackRest + архивация WAL: RPO 5–15 минут, RTO 30–90 минут для базы 100–300 ГБ. С горячей репликой RTO падает до 5–10 минут.

Где хранить бэкапы — локально или в облаке?

Правило 3-2-1: три копии, два разных носителя, одна копия вне офиса. На практике для 1С это локальный NAS, второй сервер и холодная копия в Яндекс Object Storage.

Что делать, если база 1С повреждена и не запускается?

Остановить службу 1С и PostgreSQL, не пытаться чинить вручную. Восстановить последний бэкап на тестовый сервер, проверить целостность через тестирование/исправление в конфигураторе. Если всё в порядке — переключить продуктив. Никогда не восстанавливайте поверх живой базы.