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

Меня зовут Семёнов Евгений Сергеевич, я уже 15 лет занимаюсь обслуживанием корпоративных IT-инфраструктур в Москве и Подмосковье. За это время через мои руки прошло несколько сотен баз 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

За последние три года мы внедрили бэкап-схему для 47 клиентов на PostgreSQL — от маленьких офисов с базой 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 дней локально и 90 дней в Яндекс.Облаке.

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

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

То есть для базы 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, не пытаться чинить вручную. Восстановить последний бэкап на тестовый сервер, проверить целостность через тестирование/исправление в конфигураторе. Если всё в порядке — переключить продуктив. Никогда не восстанавливайте поверх живой базы.