Безопасность

Бэкап WordPress: 4 рабочих способа и как выбрать

МаксимИнженер по WordPress · 10+ лет с WordPress и WooCommerce13 мин чтения46 просмотров

Бэкап — проверенная процедура восстановления, а не zip на диске. Четыре способа под российские хостинги и Яндекс.Диск — почему «бэкапы хостинга» часто недостаточно.

В статье
  • Почему «бэкап раз в месяц на хостинге» — это не бэкап
  • Что вообще нужно бэкапить в WordPress
  • Способ 1. Бэкапы хостинга
  • Способ 2. UpdraftPlus + облако

Нужна помощь — аудит и очистка.

Бэкап WordPress: 4 рабочих способа и как выбрать

«Бэкап есть, хостинг делает» — а при взломе оказывается, что последний снимок заражён и лежит в том же аккаунте. В практике бэкап — это не zip на диске, а проверенное восстановление на тестовом поддомене. Сравниваем четыре способа для визитки и магазина.

Почему «бэкап раз в месяц на хостинге» — это не бэкап

На вопрос «есть ли у вас резервная копия сайта?» владельцы WordPress отвечают примерно одинаково: «да, хостинг делает». На практике в момент проблемы выясняется одно из:

  • Бэкап есть, но он недельной или месячной давности — за это время в магазине прошли заказы, в блоге вышли статьи, в каталоге обновились цены. Восстановишь — потеряешь свежие данные.
  • Бэкап лежит в том же аккаунте хостинга, что и сайт. Аккаунт заблокировали из-за вируса или жалобы — доступ к бэкапу пропал вместе с сайтом.
  • Бэкап есть, но это «снимок диска» — без отдельной выгрузки БД. Развернуть его на другом хостинге невозможно.
  • Бэкап есть, но никто никогда не пробовал из него восстанавливаться. В критический момент оказывается, что архив битый или БД не разворачивается.

Бэкап — это не файл на диске, это проверенная процедура восстановления. Если вы ни разу не разворачивали свой бэкап на тестовом поддомене — у вас нет бэкапа, у вас есть надежда.

В этой статье разберём 4 рабочих подхода: их сильные и слабые стороны, кому какой подходит, и как организовать так, чтобы при сбое вы потеряли максимум час работы, а не неделю.

Что вообще нужно бэкапить в WordPress

Что входит в бэкап WordPress
Файлы + БД — обе части нужны; без дампа MySQL сайт не поднимется.

WordPress состоит из двух независимых частей, и обе нужны для восстановления:

  • Файлы — ядро WordPress, темы, плагины, загрузки (картинки, документы в wp-content/uploads/), wp-config.php, .htaccess.
  • База данных MySQL/MariaDB — все статьи, страницы, настройки, пользователи, заказы WooCommerce, комментарии. БЕЗ БД сайт развернуть невозможно — это самая важная часть.

Минимальный размер архива среднего сайта — 200–500 МБ. Для магазина с большим каталогом и медиабиблиотекой — 2–10 ГБ. БД обычно занимает 20–500 МБ. Это влияет на выбор способа: то, что подходит для сайта-визитки, не годится для магазина на 50 000 товаров.

Способ 1. Бэкапы хостинга

Бэкапы в панели хостинга
Панель Beget/Timeweb — проверьте, что последний снимок не старше суток.

Все крупные российские хостинги — Beget, Timeweb, Reg.ru, SpaceWeb, ihc, Sprinthost — делают автоматические бэкапы из коробки. Глубина и частота отличаются: где-то 30 дней с ежедневным снимком, где-то 7 дней через день.

Когда подходит

  • Это базовый уровень, который должен быть у любого сайта. Даже если используете другие способы — бэкапы хостинга не выключайте.
  • Удобно для быстрого отката: если на сайте сломалась тема — за 5 минут восстановили вчерашнее состояние.
  • Хорошо для сайтов-визиток и небольших блогов, где контент меняется редко.

Когда НЕ подходит как единственный способ

  • Хранятся в том же аккаунте. Хостинг заблокирован, аккаунт удалён за неоплату, диск-узел упал — бэкап пропал вместе с сайтом. Бывали случаи, когда из-за жалобы на спам аккаунт блокировали без права восстановления.
  • Глубина может быть маленькой. На бесплатном тарифе Beget — 30 дней, на тарифах попроще у других хостингов — 7 дней. Заражение часто замечают через 2–3 недели, к этому моменту все бэкапы уже заражены.
  • Не всегда «гранулярные». Откатываете весь аккаунт целиком — теряются изменения за день, включая заказы магазина.

Что сделать прямо сейчас

  1. Зайти в панель хостинга, найти раздел «Резервные копии» / «Бэкапы».
  2. Убедиться, что бэкапы реально создаются (последний — не старше 24 часов).
  3. Узнать глубину хранения. Если меньше 14 дней — добавить второй способ из списка ниже.
  4. Раз в месяц вручную скачать один бэкап к себе на компьютер (в облако, на внешний диск) — это «семейная фотография» сайта, последний рубеж обороны.

Способ 2. UpdraftPlus + облако

UpdraftPlus бэкап в облако
UpdraftPlus в S3/Yandex Object Storage — бэкап вне аккаунта хостинга.

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+ ГБ это болезненно.
  • Восстановление через интерфейс работает, только если сам сайт работает. Если сайт лежит — нужно разворачивать руками (тоже возможно, но сложнее).
Дублирование бэкапов WordPress в облако
Два канала: снимок хостинга + плагин в облако — не полагаться на одно хранилище.

Способ 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) — если есть бюджет.

Главное: проверка восстановления

Тестовое восстановление бэкапа WordPress
Раз в квартал разворачиваем бэкап на staging — иначе при сбое узнаем, что архив битый.

Эту часть пропускают 95% владельцев сайтов — и зря. Раз в квартал делайте следующее:

  1. Создайте на хостинге тестовый поддомен, например test.вашдомен.ру, с отдельной БД.
  2. Возьмите самый свежий бэкап и разверните его на тестовом поддомене:
    • Через UpdraftPlus — «Migrate / Clone» или «Restore on another site».
    • Через Duplicator — выгрузите архив + installer.php на поддомен, запустите installer.
    • Вручную — распаковать архив файлов, импортировать SQL-дамп через phpMyAdmin, поправить siteurl и home в wp_options на адрес поддомена.
  3. Проверьте: открывается ли главная, работает ли админка, видны ли последние записи и заказы.
  4. Зафиксируйте время восстановления. Это ваш реальный RTO (recovery time objective) — то, через сколько часов сайт реально поднимется при сбое.
  5. Удалите тестовый поддомен.

Если на третьем шаге выяснилось, что бэкап битый или не разворачивается — у вас есть время спокойно разобраться, а не в момент пожара.

Типовые ошибки, которые ломают бэкапы

  • Хранят бэкапы рядом с сайтом. В папке 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 от взлома».

Поделиться: Telegram VK
Сложный случай?

Опишите ситуацию — поможем

Только WordPress. Если статья не закрыла вопрос — напишите, посмотрим конкретно ваш сайт.

Если есть — поможет быстрее оценить задачу.
Необязательно · до 10 МБ · PNG, JPG, PDF, ZIP
Удобный канал связи

URL сайта и краткое описание задачи. Чем больше деталей, тем точнее оценка.

Не передаём третьим лицам · Политика