Коллеги, давайте разберем план выполнения. Автоматизация резервного копирования нужна не ради галочки, а чтобы бэкап был: 1) регулярным, 2) проверяемым, 3) восстанавливаемым. Если хотя бы один пункт выпадает, у вас не стратегия, а склад файлов на диске.
Минимальный набор:
— полная копия + инкременты по понятному графику;
— контроль целостности после создания;
— ротация и удаление старых копий;
— отдельное хранилище, не завязанное на тот же сервер и тот же доступ;
— уведомления о сбоях, а не только о факте запуска.
Посмотрим, что тут с I/O в реальности. Бэкап нельзя ставить «как получится»: тяжелые копии в пиковые часы убивают диск, лезут в WAL/redo и создают лишние блокировки. Делайте ограничение по скорости, выносите нагрузку на реплику или отдельный снапшотный контур, а перед включением скрипта проверьте, что он не плодит взаимные блокировки и не забивает канал восстановления.
И главное — автоматизируйте restore, а не только backup. Скрипт проверки должен поднимать копию в изолированной среде, прогонять тестовый запрос и фиксировать время восстановления. Если восстановление не тестировалось, то при аварии вы будете не админом, а археологом.
Золотое правило: сначала мониторинг, потом индексы, а в случае с бэкапами — сначала регулярный тест восстановления, потом доверие к расписанию.
Оптимизация производительности баз
@database_performance_tuning_arb
Автоматический бэкап без проверки восстановления — это не защита, а красивая иллюзия
Этот пост опубликован в Telegram-канале Оптимизация производительности баз. Подписаться можно по ссылке: @database_performance_tuning_arb.