BlogVault: скорее всего, ваша система резервного копирования

BlogVault — ещё один случай, похожий на MainWP: если этот UA появляется в логах, чаще всего это означает не постороннего бота, а вашу же (или клиента) систему резервного копирования WordPress. BlogVault — реальный, хорошо известный сервис backup/staging/миграции для WordPress с более чем миллионом заявленных резервных копий сайтов, а не безымянный «прочий сервис».

1. Что такое BlogVault на самом деле

BlogVault — платный SaaS-сервис для WordPress: автоматическое резервное копирование (инкрементальное, включая базу данных, темы, плагины, медиафайлы), staging-окружения для тестирования изменений, миграция сайтов между хостингами и базовая security-функциональность (сканирование малвари, файрвол, аудиты уязвимостей). Владелец сайта или его агентство подключает конкретный WordPress-сайт к своему аккаунту BlogVault — именно после этого на сайте появляется трафик от бота.

Важный технический момент, о котором сообщает сама компания: обработка резервного копирования и staging выполняется на серверах BlogVault, а не на ресурсах сайта — то есть сервис специально спроектирован так, чтобы не создавать заметной нагрузки на origin, а не наоборот.

2. Зачем BlogVault приходит на сайт

• плановое резервное копирование — по расписанию, которое настроил владелец аккаунта (ежедневно/еженедельно/ежемесячно, до 90 дней истории по умолчанию, до 365 дней в расширенных планах);
• создание или обновление staging-окружения для безопасного тестирования изменений перед публикацией на боевом сайте;
• миграция сайта между хостингами — единоразовый, но объёмный процесс переноса;
• malware-сканирование и аудит уязвимостей — часть заявленной security-функциональности сервиса.

Типичный кейс: в логах регулярно появляется BlogVault с определённой периодичностью, соответствующей расписанию бэкапов — это ожидаемое, штатное поведение подключённого сервиса, а не аномалия.

3. Нагрузка и риски

Прямого риска для контента (republishing, скрытый сбор данных для третьих лиц) практически нет — это узкоспециализированный сервис резервного копирования с понятной, официально заявленной целью. Сама компания подчёркивает, что архитектура спроектирована так, чтобы минимизировать нагрузку на сайт во время бэкапа/staging.

Главный практический риск здесь другой: если сайт был передан от одного подрядчика другому, а старое подключение BlogVault осталось активным, владелец может не осознавать, откуда идёт этот трафик — и по ошибке заблокировать собственную (или прежнюю) систему бэкапа, решив, что это посторонний бот.

4. Как найти BlogVault в логах

# Базовый поиск
grep -i "blogvault" /var/log/nginx/access.log

# Топ URL, которые запрашивает сервис
grep -i "blogvault" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Топ IP за этим UA — помните, что диапазон динамический
grep -i "blogvault" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Регулярность — должна соответствовать расписанию бэкапов, если сервис подключён осознанно
grep -i "blogvault" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

# Проверка: установлен ли на сайте активный плагин BlogVault
wp plugin list --status=active | grep -i blogvault

Верификация. BlogVault официально рекомендует связку User-Agent + обратный DNS (rDNS) для подтверждения подлинности запроса — IP-адреса динамические, отдельного фиксированного списка компания не публикует:

IP="1.2.3.4"
dig +short -x "$IP"

Первый и самый быстрый шаг диагностики здесь — не техническая проверка IP, а простой вопрос: подключён ли сайт к чьему-либо аккаунту BlogVault сознательно, и если да — к чьему именно.

5. robots.txt для BlogVault

# Жёсткий запрет — сломает функциональность бэкапа, если сервис используется
User-agent: BlogVault
Disallow: /

# Разрешить всё — необходимо, если сайт реально использует BlogVault для бэкапов
User-agent: BlogVault
Allow: /

Обратите внимание: пример правила из независимых каталогов ботов (полный Disallow: / для BlogVault) — это ровно та конфигурация, которая незаметно сломает резервное копирование, если её применить бездумно на сайте, где сервис реально используется.

6. Блокировка вручную и через TrafficVeil

Nginx:

if ($http_user_agent ~* "blogvault") {
    return 403;
}

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} blogvault [NC]
RewriteRule ^ - [F,L]

TrafficVeil:

• прежде чем блокировать — проверьте, не используется ли BlogVault сознательно для бэкапов, staging или миграции конкретно этого сайта;
• если сервис используется — allow, дополнительно ограничивать не требуется, нагрузка и так минимальна по архитектуре самого сервиса;
• если сайт сменил подрядчика и подключение осталось от прежнего — правильное решение не блокировать техническими средствами, а отвязать сайт от старого аккаунта BlogVault, иначе бэкапы могут продолжать уходить бывшему подрядчику;
• после изменения сверьте логи и, если применимо, убедитесь, что собственные бэкапы продолжают создаваться штатно.

7. Что делать: короткий алгоритм

• Первый шаг всегда один: выяснить, подключён ли сайт к чьему-либо аккаунту BlogVault сознательно;
• Подключён и используется — allow, это ваша (или клиентская) инфраструктура резервного копирования;
• Подключение осталось от прежнего подрядчика — отвязать аккаунт через саму BlogVault, а не просто заблокировать трафик технически;
• Сайт точно не использует BlogVault и подключения никогда не было — Disallow + запрет в TrafficVeil обоснован;
• Не блокируйте по маске User-agent: *, чтобы не задеть Googlebot/YandexBot заодно.

8. С кем не путать BlogVault

9. Стратегия allow/deny для BlogVault