«Бэкап есть, хостинг делает» — а при взломе оказывается, что последний снимок заражён и лежит в том же аккаунте. В практике бэкап — это не zip на диске, а проверенное восстановление на тестовом поддомене. Сравниваем четыре способа для визитки и магазина.
Почему «бэкап раз в месяц на хостинге» — это не бэкап
На вопрос «есть ли у вас резервная копия сайта?» владельцы WordPress отвечают примерно одинаково: «да, хостинг делает». На практике в момент проблемы выясняется одно из:
- Бэкап есть, но он недельной или месячной давности — за это время в магазине прошли заказы, в блоге вышли статьи, в каталоге обновились цены. Восстановишь — потеряешь свежие данные.
- Бэкап лежит в том же аккаунте хостинга, что и сайт. Аккаунт заблокировали из-за вируса или жалобы — доступ к бэкапу пропал вместе с сайтом.
- Бэкап есть, но это «снимок диска» — без отдельной выгрузки БД. Развернуть его на другом хостинге невозможно.
- Бэкап есть, но никто никогда не пробовал из него восстанавливаться. В критический момент оказывается, что архив битый или БД не разворачивается.
Бэкап — это не файл на диске, это проверенная процедура восстановления. Если вы ни разу не разворачивали свой бэкап на тестовом поддомене — у вас нет бэкапа, у вас есть надежда.
В этой статье разберём 4 рабочих подхода: их сильные и слабые стороны, кому какой подходит, и как организовать так, чтобы при сбое вы потеряли максимум час работы, а не неделю.
Что вообще нужно бэкапить в WordPress

WordPress состоит из двух независимых частей, и обе нужны для восстановления:
- Файлы — ядро WordPress, темы, плагины, загрузки (картинки, документы в
wp-content/uploads/),wp-config.php,.htaccess. - База данных MySQL/MariaDB — все статьи, страницы, настройки, пользователи, заказы WooCommerce, комментарии. БЕЗ БД сайт развернуть невозможно — это самая важная часть.
Минимальный размер архива среднего сайта — 200–500 МБ. Для магазина с большим каталогом и медиабиблиотекой — 2–10 ГБ. БД обычно занимает 20–500 МБ. Это влияет на выбор способа: то, что подходит для сайта-визитки, не годится для магазина на 50 000 товаров.
Способ 1. Бэкапы хостинга

Все крупные российские хостинги — Beget, Timeweb, Reg.ru, SpaceWeb, ihc, Sprinthost — делают автоматические бэкапы из коробки. Глубина и частота отличаются: где-то 30 дней с ежедневным снимком, где-то 7 дней через день.
Когда подходит
- Это базовый уровень, который должен быть у любого сайта. Даже если используете другие способы — бэкапы хостинга не выключайте.
- Удобно для быстрого отката: если на сайте сломалась тема — за 5 минут восстановили вчерашнее состояние.
- Хорошо для сайтов-визиток и небольших блогов, где контент меняется редко.
Когда НЕ подходит как единственный способ
- Хранятся в том же аккаунте. Хостинг заблокирован, аккаунт удалён за неоплату, диск-узел упал — бэкап пропал вместе с сайтом. Бывали случаи, когда из-за жалобы на спам аккаунт блокировали без права восстановления.
- Глубина может быть маленькой. На бесплатном тарифе Beget — 30 дней, на тарифах попроще у других хостингов — 7 дней. Заражение часто замечают через 2–3 недели, к этому моменту все бэкапы уже заражены.
- Не всегда «гранулярные». Откатываете весь аккаунт целиком — теряются изменения за день, включая заказы магазина.
Что сделать прямо сейчас
- Зайти в панель хостинга, найти раздел «Резервные копии» / «Бэкапы».
- Убедиться, что бэкапы реально создаются (последний — не старше 24 часов).
- Узнать глубину хранения. Если меньше 14 дней — добавить второй способ из списка ниже.
- Раз в месяц вручную скачать один бэкап к себе на компьютер (в облако, на внешний диск) — это «семейная фотография» сайта, последний рубеж обороны.
Способ 2. UpdraftPlus + облако

UpdraftPlus — самый популярный плагин бэкапов для WordPress, более 3 миллионов установок. Бесплатная версия покрывает 90% потребностей.
Что умеет
- Резервирует файлы и БД по расписанию (раз в час / день / неделю — отдельно для файлов и БД).
- Заливает архивы во внешнее облако: Google Drive, Dropbox, FTP/SFTP, Microsoft OneDrive, S3-совместимые хранилища (включая Яндекс Object Storage), WebDAV.
- Хранит на сайте N последних копий, старые удаляет.
- Восстановление — через интерфейс плагина в один клик (если плагин ещё работает).
Куда сохранять (под Россию)
- Яндекс.Диск через WebDAV. Бесплатно 10 ГБ, докупается дёшево. Адрес WebDAV:
https://webdav.yandex.ru, логин/пароль — отдельный пароль приложения, не основной. В UpdraftPlus → Settings → Remote Storage → WebDAV. Самый удобный вариант для большинства сайтов. - Яндекс Object Storage (S3-совместимый). Платно по объёму (копейки за гигабайт), для больших сайтов и магазинов. Настраивается в разделе S3 — указываете endpoint
storage.yandexcloud.net, ключи доступа из консоли Yandex Cloud. - FTP/SFTP на другой хостинг. Если у вас два хостинг-аккаунта (например, основной + дешёвый «склад»), можно сливать бэкапы туда. Минус — оба аккаунта могут пострадать одновременно, если одна и та же утечка пароля.
- Google Drive / Dropbox. Технически работает, но у российских пользователей сейчас бывают сложности с доступом, плюс оплата подписки усложнилась. Запасной вариант, не основной.
Минимальная разумная настройка
- Расписание файлов: раз в неделю.
- Расписание БД: раз в сутки (для блогов) или раз в 6 часов (для магазинов).
- Хранить: 4 копии файлов + 14 копий БД.
- Удалить локальную копию после загрузки в облако: включить, иначе диск хостинга забьётся.
- В Advanced Tools → Email reports включить уведомления — будете знать, если бэкап перестал создаваться.
Слабые стороны
- Если плагин конфликтует с тяжёлым WooCommerce — бэкап может «зависнуть» на середине. Решается переходом на cron-задачи на стороне сервера вместо WP-Cron.
- Бесплатная версия не умеет инкрементальные бэкапы — каждый раз льёт всё заново. Для сайтов 5+ ГБ это болезненно.
- Восстановление через интерфейс работает, только если сам сайт работает. Если сайт лежит — нужно разворачивать руками (тоже возможно, но сложнее).

Способ 3. BackWPup или Duplicator
Альтернативы UpdraftPlus с похожей логикой, но другими акцентами.
BackWPup
- Бесплатный, активно поддерживается.
- Гибкое создание «задач» — можно отдельно бэкапить только БД каждые 6 часов, отдельно файлы раз в неделю, и каждую задачу отправлять в своё место.
- Хорошо умеет S3, FTP, Dropbox. WebDAV для Яндекс.Диска тоже есть.
- Логи и оповещения на email из коробки.
Подходит, если хочется тонкой настройки или если UpdraftPlus конфликтует с темой/хостингом.
Duplicator
- По сути это инструмент для миграции сайта, но идеально подходит как разовый «снапшот» перед рискованной операцией: обновлением мажорной версии WP, заменой темы, миграцией на новый хостинг.
- Создаёт один
.zipсо всем сайтом + установщикinstaller.php. Развернуть можно на любом другом хостинге за 10 минут. - Не подходит как основной инструмент регулярных бэкапов — нет расписания в бесплатной версии. Но обязательный «второй пилот» к UpdraftPlus.
Способ 4. Бэкап вручную через SSH / panel
Самый надёжный, но и самый трудоёмкий способ. Подходит, если у вас один сайт, и вы не хотите ставить лишний плагин.
Как делается
Подключаетесь по SSH (или открываете «Терминал» в панели хостинга, если есть). Из корня сайта:
# 1. Архив файлов
tar -czf ~/backup-files-$(date +%Y-%m-%d).tar.gz ./
# 2. Дамп базы данных
mysqldump -u DB_USER -p DB_NAME > ~/backup-db-$(date +%Y-%m-%d).sql
# 3. Скачать оба файла на компьютер через SFTP / SCP
# Например, на локальной машине:
scp user@host:~/backup-* ./bekapy/
Где DB_USER и DB_NAME возьмите из wp-config.php (строки DB_USER и DB_NAME). Пароль БД система спросит интерактивно.
Когда подходит
- Перед любой рискованной операцией: обновлением, миграцией, чисткой вируса.
- Раз в квартал — как «эталонный» бэкап на свой жёсткий диск, отдельно от любых облаков и плагинов.
- Для разработчиков и тех, кто привык к терминалу.
Когда НЕ подходит
- Как замена ежедневному бэкапу — про ручную процедуру забывают через 2 недели.
- Если нет SSH (на дешёвом виртуальном хостинге доступа в терминал может не быть). Альтернатива — экспорт БД через phpMyAdmin и архив файлов через файловый менеджер панели.
Какой способ выбрать: короткая таблица решений
- Сайт-визитка, контент меняется раз в месяц. Хостинг-бэкапы + раз в квартал ручная выгрузка к себе на диск. Этого хватит.
- Блог, статьи 1–4 раза в неделю. Хостинг-бэкапы + UpdraftPlus в Яндекс.Диск (БД раз в день, файлы раз в неделю).
- Корпоративный сайт с лидами через формы. Хостинг-бэкапы + UpdraftPlus или BackWPup, БД раз в 6–12 часов в Яндекс.Диск или Object Storage.
- Интернет-магазин WooCommerce с регулярными заказами. Хостинг-бэкапы + UpdraftPlus БД раз в 1–3 часа в Object Storage. Дополнительно — экспорт заказов раз в день в отдельный CSV через плагин Order Export & Order Import for WooCommerce. Заказы — самая дорогая для потери информация.
- Магазин с большим каталогом (5+ ГБ файлов). Хостинг-бэкапы + платная версия UpdraftPlus с инкрементальными бэкапами, либо профессиональное решение типа Jetpack Backup (Rewind) — если есть бюджет.
Главное: проверка восстановления

Эту часть пропускают 95% владельцев сайтов — и зря. Раз в квартал делайте следующее:
- Создайте на хостинге тестовый поддомен, например
test.вашдомен.ру, с отдельной БД. - Возьмите самый свежий бэкап и разверните его на тестовом поддомене:
- Через UpdraftPlus — «Migrate / Clone» или «Restore on another site».
- Через Duplicator — выгрузите архив +
installer.phpна поддомен, запустите installer. - Вручную — распаковать архив файлов, импортировать SQL-дамп через phpMyAdmin, поправить
siteurlиhomeвwp_optionsна адрес поддомена.
- Проверьте: открывается ли главная, работает ли админка, видны ли последние записи и заказы.
- Зафиксируйте время восстановления. Это ваш реальный RTO (recovery time objective) — то, через сколько часов сайт реально поднимется при сбое.
- Удалите тестовый поддомен.
Если на третьем шаге выяснилось, что бэкап битый или не разворачивается — у вас есть время спокойно разобраться, а не в момент пожара.
Типовые ошибки, которые ломают бэкапы
- Хранят бэкапы рядом с сайтом. В папке
wp-content/backups/или/home/user/backups/— то же место, что и сайт. Падает хостинг — падает всё. - Не бэкапят БД, только файлы. Развернёте файлы — получите «голый» WordPress без контента.
- Бэкап БД через мини-плагин «WP-DB-Backup» без файлов. Обратная ситуация — БД есть, но загрузки и темы потеряны.
- Полагаются только на одно облако. Google Drive отключил Россию, Dropbox не открывается без VPN — бэкапы есть, доступа нет. Лучше два места: Яндекс.Диск + локальная копия.
- Используют WP-Cron для расписания на тихом сайте. WP-Cron срабатывает только при заходе посетителей. Если сайт малопосещаемый — бэкап не запускается неделями. Решение: настроить системный cron на стороне хостинга (есть в большинстве панелей: «Планировщик заданий» или «Cron Jobs»).
- Шифруют бэкап и забывают пароль. Шифрование — полезно для бэкапов в публичных облаках. Но пароль нужно хранить отдельно от самих бэкапов, иначе восстанавливать нечем.
- Не следят за уведомлениями. Бэкап-плагин шлёт «Ошибка: недостаточно места» на email, который не читают. Через месяц выясняется, что свежих копий нет.
Чек-лист «правильного бэкапа»
- Включены бэкапы хостинга, глубина минимум 14 дней.
- Настроен второй независимый способ: плагин + внешнее облако (Яндекс.Диск / Object Storage / FTP на другой хостинг).
- БД бэкапится чаще файлов: для блога — раз в день, для магазина — раз в 1–6 часов.
- Раз в месяц одна копия скачивается к вам на компьютер (последний рубеж).
- Включены уведомления на email об ошибках бэкапа.
- Раз в квартал — тестовое восстановление на поддомене.
- Перед любой рискованной операцией (обновление мажорной версии, чистка вируса, миграция) — отдельный ручной бэкап через Duplicator или SSH.
Если кажется, что это сложно
На небольшом сайте всю описанную схему можно собрать за час: бэкапы хостинга включены по умолчанию, UpdraftPlus настраивается за 15 минут, тестовое восстановление раз в квартал — ещё час. Это малая цена за спокойный сон, если что-то пойдёт не так.
На крупном магазине схема сложнее, и тут уже имеет смысл настроить один раз профессионально и забыть. Если хочется, чтобы всё было настроено правильно, протестировано и подкреплено мониторингом — посмотрите услугу «Поддержка WordPress» (включает регулярные бэкапы и тестовые восстановления) или напишите в Контактах. Если уже случилось то самое — пошаговый план в статье «Сайт на WordPress взломали — план восстановления за один вечер», а как не допустить — в «Защите WordPress от взлома».



