Бэкап бэкапов: дашборд нашёл 97%

Как было

В моём кластере Velero каждые 6 часов делает бэкап в MinIO, а скрипт на Mac копирует бакет за пределы кластера. Всё «работало» — бэкапы создавались, ошибок не было.

Что показал дашборд

Я собрала в Grafana дашборд по бэкапам — и он сразу показал: MinIO заполнен на 96.7%, а каждый новый бэкап больше предыдущего: 1.8 → 5.4 → 8.7 GiB.

По таблице бэкапов нашлась причина: расписание сохраняло все namespace’ы, включая minio-system — том, где лежат сами бэкапы. Каждый бэкап копировал в себя все предыдущие. Вторая причина: расписание когда-то создали руками с хранением 30 дней, а исправление на 7 дней попало только в README.

Что я сделала

• Срочно расширила том MinIO, чтобы не потерять текущие бэкапы.
• Перенесла расписание в Git — теперь им управляет ArgoCD: хранение 7 дней, без minio-system и monitoring.
• Удалила старые бэкапы и неиспользуемые репозитории kopia — сначала записи в кластере, потом данные.

Результат

Бэкап — 427 MiB вместо 8.65 GiB, MinIO — 2.1% вместо 96.7%.

Потом — бэкапы базы

Снимок тома — это ещё не бэкап базы. Поэтому для PostgreSQL я добавила второй уровень:

• CronJob с pg_dump каждый день кладёт дамп в S3 (MinIO) и удаляет дампы старше 14 дней;
• restore-тест: Job скачивает свежий дамп, восстанавливает его во временную базу и сверяет число строк в каждой таблице с боевой;
• оба Job’а пушат метрики в Pushgateway, и дашборд показывает возраст последнего бэкапа и последнего restore-теста.

На работе тот же принцип: бэкапы PostgreSQL уходили сразу в два места — в S3 DigitalOcean и на локальный NAS в офисе.

Чему я научилась

• Не бэкапить хранилище бэкапов в само себя.
• Всё, что создаёт бэкапы, должно жить в Git, а не в ручных командах.
• Мониторинг показывает то, чего не видно в терминале.
• Бэкап, который ни разу не восстанавливали, — это надежда, а не бэкап.