Вечером алерт по CPU — а это ночной бэкап

Прилетает уведомление: нагрузка выросла. Сайт при этом «вроде жив». Часто это не DDoS и не утечка, а дамп базы / tar по расписанию, который совпал с пиком или стартовал слишком рано. Разбираем, как отличить и что сделать, не отключая бэкапы.

Картина, которую узнаёшь

• Алерт по CPU или нагрузке в одно и то же время каждый день/ночь.
• Диск или I/O скачут, пока пишется .sql.gz / .tar.gz.
• После окончания cron — метрики сами падают.
• Сайт в эти 20–40 минут отвечает медленнее (особенно на маленьком VPS).

Такое допустимо, если окно короткое и не бьёт по пику продаж. Недопустимо — если бэкап стартует в час рекламы или дамп без сжатия/лимита убивает диск.

Пять минут диагностики

# Кто жрёт CPU прямо сейчас
ps aux --sort=-%cpu | head -10

# Есть ли бэкап в cron
crontab -l
sudo crontab -u www-data -l 2>/dev/null
grep -r backup /etc/cron.* 2>/dev/null | head -20

# Когда последний раз писали тяжёлые архивы
ls -lt /var/backups /backup 2>/dev/null | head -10

Если в топ процессов mysqldump, mariadb-dump, tar, gzip, rsync — почти наверняка плановое задание, а не «сервер сломался».

Что сделать

1. Сдвинуть окно — на 03:00–05:00, вне рекламы и пика заказов.
2. Не дублировать два скрипта бэкапа в один час (см. бэкапы на том же диске).
3. Ограничить I/O — nice/ionice, сжатие, дамп по частям (зависит от стека).
4. Алерт оставить — но понимать паттерн: «каждый день в 02:15 на 30 минут» ≠ инцидент. Аномалия вне окна — уже разбор.

Связка с Load Average

Высокий LA во время дампа часто = очередь I/O, не «мало ядер навсегда». Базовый разбор: Load Average на VPS и 7 метрик VDS.

Честно про Mediops

Алерт по CPU и диску на VDS помогает увидеть пик. История метрик покажет, что рост повторяется по ночам — тогда правите cron, а не покупаете тариф «на всякий случай».