Надёжность и эксплуатация: backup, мониторинг, роли, восстановление

Система автоматизации — не сайт, который можно перезагрузить. Она работает в момент операции: рабочий закрывает наряд, кладовщик сканирует ячейку, водитель получает маршрут. Если система недоступна — производство или склад останавливаются. Поэтому надёжность закладывается в архитектуру, а не добавляется «потом».

PostgreSQL backup

Полные резервные копии PostgreSQL (pg_basebackup) + архивирование WAL для Point-in-Time Recovery. pg_dump — для логических копий и миграций.

Point-in-time recovery

WAL-архивирование PostgreSQL позволяет восстановить состояние БД на любую минуту. Не только на момент последнего бэкапа.

Тест восстановления

Backup, который никогда не восстанавливали — это не backup. Регулярная проверка восстановления на тестовом сервере.

Схема базы данных меняется по мере развития системы. Миграции управляются через Alembic — каждая миграция версияна, можно откатить назад. Обновление схемы не требует остановки системы: для production-миграций отдельно анализируется влияние блокировок, опасные изменения выполняются по стратегии zero/minimal downtime.

Перед каждым обновлением — backup. Если миграция не прошла — откат к предыдущей версии. Production никогда не обновляется «вслепую».

Логи приложения

Каждый запрос, ошибка, операция логируется. Уровни: DEBUG, INFO, WARNING, ERROR. Ротация логов по размеру и времени.

Аудит действий

Кто и когда изменил остатки, закрыл операцию, отгрузил товар. Аудит-лог хранится отдельно от основных данных.

Анализ ошибок

Ошибки собираются с контекстом: пользователь, операция, стек. Не «что-то упало», а «кладовщик Иванов отгрузил партию X, ошибка в строке Y».

Доступность

Health-check эндпоинты. Если система не отвечает — алерт ответственному за эксплуатацию.

Метрики

CPU, память, место на диске, количество активных сессий, время ответа API. Аномалии видны до того, как станут проблемой.

Бизнес-метрики

Количество операций за смену, ошибок отгрузки, инвентаризаций. Не только технические метрики — но и показатели процесса.

Ролевая модель доступа (RBAC). Каждый пользователь — роль: рабочий, мастер, кладовщик, ОТК, руководитель, администратор. Роль определяет, какие экраны и операции доступны.

Рабочий видит свои операции и закрывает наряды. Мастер видит весь цех. Руководитель видит отчёты и аналитику. Администратор управляет пользователями и ролями.

Доступ к API — через JWT-токены с ограниченным сроком жизни. LDAP/AD-интеграция — по требованию, для корпоративных систем с единой учёткой.

Сервер упал. Docker Compose поднимает все сервисы одной командой. База восстанавливается из последнего backup + WAL.
Диск повреждён. Backup хранится на отдельном сервере или в облаке. Время восстановления на новый сервер зависит от объёма БД, инфраструктуры и схемы резервного копирования.
Ошибка в данных. Point-in-time recovery возвращает состояние на момент до ошибки. Аудит-лог показывает, кто и что изменил.
Обновление сломало систему. Откат миграции Alembic + восстановление из backup перед обновлением.

Шифрование

HTTPS/TLS для передачи данных. Шифрование БД на уровне диска — при поддержке инфраструктуры. Пароли — хеширование с солью (bcrypt/argon2).

Ролевой доступ

RBAC — ролевая модель доступа. Каждый пользователь видит только свои экраны и данные. JWT-токены с ограниченным сроком действия.

On-premise периметр

При on-premise развёртывании данные не покидают периметр предприятия. Система внутри сети, доступ через VPN или внутренний адрес.

Аудит-лог

Журнал действий пользователей: кто, когда, что изменил. Критичные операции — с фиксацией в отдельной таблице, не удаляются.

Важно

Конкретные меры безопасности определяются требованиями заказчика и инфраструктурой. Сертификация ФСТЭК, ФС-250 и импортозамещение — отдельным проектом, если требуется. LDAP/AD, SSO, 2FA — по требованию.

Нужны конкретные SLA под вашу эксплуатацию?

Обсудим на аудите — backup, мониторинг, роли, восстановление под ваши требования

Записаться на аудит

TL;DR

Для резервного копирования PostgreSQL в production используем pg_basebackup (полные бинарные копии) + WAL-архивирование (Point-in-Time Recovery). pg_dump — только для логических копий и миграций.

Проблема

Заказчики требуют надёжного восстановления после сбоя. pg_dump создаёт логический дамп — медленный для больших БД и не даёт Point-in-Time Recovery. Восстановление из pg_dump БД на десятки ГБ занимает часы.

Контекст

Production-системы работают on-premise на PostgreSQL. Объёмы БД — от единиц до десятков ГБ. Требуется RPO до минуты и восстановление на произвольный момент времени (случайное удаление, сбой).

Решение

Базовая стратегия: (1) pg_basebackup — полные бинарные копии по расписанию; (2) WAL-архивирование — непрерывная отправка WAL-файлов в архив; (3) Point-in-Time Recovery — восстановление на любой момент. pg_dump используется дополнительно для логических копий перед миграциями (Alembic).

Компромиссы

Плюс: RPO до минуты — потери данных минимальны при сбое.
Плюс: Point-in-Time Recovery — можно откатиться на момент до ошибочной операции.
Плюс: pg_basebackup быстрее pg_dump для больших БД — бинарный формат.
Минус: требует настройки archive_command и места под WAL-архив.
Минус: восстановление требует тестирования — процедура не тривиальна.
Минус: pg_basebackup не заменяет pg_dump для логических копий и миграций.

Результат

RPO до минуты (WAL). RTO зависит от объёма БД и инфраструктуры — не обещаем фиксированного RTO без тестирования на конкретной конфигурации.

Ограничения

RTO не указываем как фиксированное число — оно зависит от объёма БД, дисковой подсистемы и процедуры восстановления.
Процедура восстановления должна тестироваться на конкретной инфраструктуре заказчика.
WAL-архивирование требует мониторинга — если архивирование останавливается, RPO растёт.

Источники

Документация PostgreSQL: pg_basebackup, WAL, Point-in-Time Recovery
Страница /security — схема backup → WAL → восстановление → проверка
Опыт эксплуатации 80+ систем on-premise

Надёжность и эксплуатация

Резервное копирование