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