Backup Pipeline — Итоги и план развития

Документ описывает текущее состояние инфраструктуры резервного копирования, архитектуру конвейера и план расширения на все сервисы компании.

Текущая архитектура

Железо и хранилище

Компонент	Описание
NAS	Synology DS925+
RAID	SHR-2 (аналог RAID 6 с гибким расширением)
Диски	4 × 2 ТБ → 4 ТБ полезного пространства
Защита	Выдерживает одновременный выход из строя 2 дисков
Расположение	Холодная серверная, антивибрационные диски
Питание	UPS с подключением к DSM для корректного автовыключения

Конвейер (активный сервис: anketa)

Продовый сервер
  └── pg_dump → .dump файл
        └── rsync (retry до 5 раз, --partial, --timeout=3600)
              └── pg-validator (processing-server)
                    ├── pg_restore в изолированный PG контейнер
                    ├── COUNT(*) по каждой таблице
                    ├── md5 схемы
                    └── verified/ или failed/
                          └── synology-shipper
                                ├── очередь (shipper.queue)
                                ├── rsync --checksum --partial
                                ├── SSH-верификация: size + md5
                                └── /volume1/backups/anketa/

Компоненты конвейера

pg-backup.sh (продовый сервер)

Запуск по cron в 21:00 UTC (02:00 по Ташкенту)
Дамп в формате custom (pg_dump -F custom)
rsync с retry-логикой: до 5 попыток, пауза 60 сек между попытками
--partial сохраняет прогресс при обрыве соединения

pg-validator (processing-server `10.8.0.4`)

inotify следит за incoming/
Поднимает изолированный PostgreSQL контейнер
Проверяет: успешность pg_restore, количество строк в таблицах, целостность схемы
Результат: файл уходит в verified/ или failed/
Webhook-сервер на socat для триггера от watcher-а

synology-shipper.sh (processing-server)

inotify следит за verified/
Персистентная очередь в shipper.queue — переживает рестарты
rsync с --checksum --partial-dir и таймаутом 7200 сек (для файлов 30+ ГБ)
После rsync: SSH на Synology → сравнение stat размера и md5sum
При расхождении: удаляет битый файл на NAS, повторяет попытку
До 10 попыток с паузой 60 сек, Telegram-алерт при исчерпании

retention.sh (Synology DSM)

Task Scheduler: ежедневно в 14:00
Политика 3W7D: последние 7 дней (все файлы) + 3 недельных снэпшота
Дата определяется из имени файла с учётом TZ offset +5h от UTC
Если нет файла за нужную неделю — ищет ближайший в пределах ±3 дней
При отсутствии недельного бэкапа — Telegram-алерт
Dry-run режим: DRY_RUN=1 bash /volume1/backups/retention.sh

Retention политика

Сегодня: Ср 29 апреля 2026

Зона D (7 дней):
  22 апр, 23 апр, 24 апр, 25 апр, 26 апр, 27 апр, 28 апр, 29 апр
  → хранятся ВСЕ файлы за эти дни

Зона W (3 воскресенья):
  19 апр (нед. 3) → ближайший файл за ту неделю
  12 апр (нед. 2) → ближайший файл за ту неделю
   5 апр (нед. 1) → ближайший файл за ту неделю

Всё остальное — удаляется автоматически

Параметры задаются в retention.conf на сервис:

# SERVICE|W|D|DOW|SUBDIR
merchant_1anketa|3|7|0|anketa

Структура файлов на NAS

/volume1/backups/
├── retention.sh
├── retention.conf
└── anketa/
    ├── merchant_1anketa_20260427_210001.dump
    ├── merchant_1anketa_20260428_210001.dump
    └── merchant_1anketa_20260429_210001.dump

Известные проблемы и решения

Проблема	Причина	Решение
rsync timeout (код 30)	Файл 33+ ГБ, канал 100 Мбит/с	`RSYNC_TIMEOUT=7200` в config.env
Бэкапы за 24–25 апреля не отправились	rsync упал без retry	Добавлена retry-логика в pg-backup.sh
`inotifywait` не ловил события	Симлинк `verified/` → `/mnt/backup-storage/verified`	inotify корректно следует по симлинкам
SSH Permission denied на Synology	Shell пользователя `/sbin/nologin`	Заменён на `/bin/sh` через `sed -i` в `/etc/passwd`

План расширения — новые сервисы

Принцип добавления сервиса

Каждый новый сервис проходит тот же конвейер:

Сервис → дамп/архив → rsync → валидатор → verified/ → NAS → retention

Для добавления нового сервиса нужно:

На продовом сервере: настроить скрипт бэкапа (аналог pg-backup.sh)
На processing-server: добавить обработку нового типа файлов в validator.sh если нужно
На Synology: создать папку в /volume1/backups/<service>/
В retention.conf: добавить одну строку с параметрами retention
В config.env: обновить SYNOLOGY_DIR для нового сервиса или создать отдельный экземпляр shipper-а

Целевые сервисы

Бухгалтерия / 1С

Тип бэкапа: файловый архив базы данных 1С (.dt или директория ib)
Валидация: проверка целостности архива + тест открытия через ibcmd
Особенность: 1С может быть заблокирована во время бэкапа — нужна договорённость с бухгалтерией по расписанию
Retention: рекомендуется 4W30D (месяц ежедневных + 4 недельных)

Сайт

Тип бэкапа: дамп БД (MySQL/PostgreSQL) + архив файлов (tar.gz)
Валидация БД: аналогично текущей схеме через restore в контейнер
Валидация файлов: проверка целостности tar -tzf, размер архива
Retention: 2W7D (сайт меняется реже)

Прочие сервисы

Добавляются по той же схеме
Каждый сервис — отдельная папка на NAS и строка в retention.conf

Целевая структура NAS

/volume1/backups/
├── retention.sh
├── retention.conf          ← добавляем строку на каждый сервис
├── anketa/                 ← уже работает
├── accounting/             ← бухгалтерия / 1С
├── website/                ← сайт
│   ├── db/
│   └── files/
└── <other-service>/

Мониторинг (планируется)

SNMP → Telegraf → InfluxDB → Grafana

Доступные метрики через SNMP на DS925+:

Статус RAID массива и каждого диска
Температура дисков и системы
Load average, RAM, CPU
Сетевой трафик
Статус вентиляторов

Метрики бэкапов в InfluxDB

После успешной отправки synology-shipper пишет в InfluxDB:

backup_shipped,service=merchant_1anketa size=35000000000,attempts=1,transfer_seconds=2640

Grafana panels:

Table — последние N бэкапов: сервис, размер, время, попытки
Stat — когда последний раз приходил бэкап от каждого сервиса
Time series — динамика размера бэкапов, аномалии роста
Alert — если от сервиса нет бэкапа более 25 часов

Незакрытые риски

Риск	Критичность	Решение
Нет мониторинга дисков	Средняя	SNMP + Telegraf + Grafana
1С не валидируется автоматически	Средняя	`ibcmd` интеграция в validator

Бизнес-ценность

Главное отличие от "просто папки с файлами" — каждый бэкап подтверждён как восстанавливаемый до того как попал на хранение. Большинство компаний узнают что бэкап нерабочий только в момент когда он срочно нужен.

Аспект	До	После
Проверка бэкапов	Вручную или никак	Автоматически через `pg_restore`
Уведомления о сбоях	Нет	Telegram-алерт в реальном времени
Ротация	Вручную	Автоматически по политике
Доставка	Ненадёжная	Очередь с retry и checksum-верификацией
Покрытие сервисов	1	Расширяется на все ключевые системы

Последнее обновление: апрель 2026

Текущая архитектура​

Железо и хранилище​

Конвейер (активный сервис: anketa)​

Компоненты конвейера​

pg-backup.sh (продовый сервер)​

pg-validator (processing-server 10.8.0.4)​

synology-shipper.sh (processing-server)​

retention.sh (Synology DSM)​

Retention политика​

Структура файлов на NAS​

Известные проблемы и решения​

План расширения — новые сервисы​

Принцип добавления сервиса​

Целевые сервисы​

Бухгалтерия / 1С​

Сайт​

Прочие сервисы​

Целевая структура NAS​

Мониторинг (планируется)​

SNMP → Telegraf → InfluxDB → Grafana​

Метрики бэкапов в InfluxDB​

Незакрытые риски​

Бизнес-ценность​