Оптимизация производительности баз

<b>Бэкап без автопроверки — это не защита, а очень дорогой ритуал</b>

<b>Бэкап без автопроверки — это не защита, а очень дорогой ритуал</b>

Коллеги, давайте разберем план выполнения. Резервное копирование имеет смысл только если оно автоматизировано, проверяемо и регулярно восстанавливается. Иначе вы просто копите файлы, которые в момент аварии могут оказаться битым мусором.

Минимальный набор:
— расписание бэкапов для full и incremental;
— контроль успешности задачи, размера и времени выполнения;
— отдельное хранение копий от боевой БД и от учётки, которая их создает;
— шифрование и ротация;
— проверка restore в тестовый контур, а не по молитве в пятницу вечером.

Посмотрим, что тут с I/O в реальности: бэкап может убить прод, если запустить его без учета нагрузки. Для больших баз лучше ограничивать скорость, делать снимки на уровне хранилища только при понятной консистентности и следить, чтобы окно резервного копирования не пересекалось с тяжелыми batch-задачами. И отдельно логировать ошибки: «успешно завершилось» без артефактов восстановления — бесполезная строка.

На практике полезно хранить рядом с копией манифест: дата, источник, контрольная сумма, тип бэкапа, точка восстановления. Тогда автоматический restore-check можно запускать как обычную джобу: поднять копию, прогнать короткий smoke-тест, удалить результат. В продакшене так лучше не делать руками — человек забудет, скрипт нет.
Этот пост опубликован в Telegram-канале Оптимизация производительности баз. Подписаться можно по ссылке: @database_performance_tuning_arb.
tech

Свежие посты в категории «Tech Infrastructure»

Все каналы категории →

start

Готовы запустить рекламу через сеть public.tg?

Новый оффер, продукт, GEO, кейс, событие или партнёрский запуск — соберём маршрут под задачу и отдадим медиаплан.

Telegram для медиаплана: @dumay. Быстрый тест: $20 за канал, $1000 за пакет по сети.