Как настроить резервное копирование сайта: гайд для WordPress и Tilda

Резервное копирование сайта - единственное, что спасает бизнес, когда хостинг падает, обновление плагина ломает базу данных или в Tilda случайно стирают блок с ценами за час до старта рекламной кампании. За годы работы с WordPress и Tilda я регулярно вижу одну и ту же историю: владелец сайта теряет недели работы просто потому что бэкап либо не настроен, либо лежит битым архивом, который никто ни разу не открывал. Ниже - как я настраиваю резервные копии на реальных проектах: что копировать, какими инструментами, куда складывать архивы и как убедиться, что в критический момент восстановление действительно сработает.

Что теряют без бэкапов: три случая из практики

Первый случай - интернет-магазин на WooCommerce, где после неудачного обновления плагина эквайринга слетела таблица заказов. Резервной копии базы не было четыре дня, магазин восстанавливали из логов Т‑Банка и переписки с покупателями вручную - часть заказов так и не удалось сопоставить с оплатами.

Второй - сайт на Tilda, где менеджер клиента при редактировании страницы случайно удалил блок с интеграцией СДЭК и калькулятором доставки. Экспорта проекта не было полгода, откатывать пришлось руками по скриншотам из переписки.

Третий - обычный сбой на хостинге: диск с сайтом на WordPress вышел из строя, а автоматические снапшоты хостинг хранил всего 3 дня, тогда как проблему заметили только через неделю. Все три случая объединяет одно: бэкап либо не делали, либо делали нерегулярно и никогда не проверяли, что он открывается.

Резервное копирование WordPress: базы данных и файлов

В WordPress копировать нужно два независимых блока, и терять любой из них одинаково плохо.

• База данных MySQL - тексты страниц, товары и заказы WooCommerce, настройки плагинов, таблица wp_options, пользователи и их роли.
• Файлы - каталог wp-content целиком: темы, плагины, медиатека uploads, а также wp-config.php с ключами доступа (этот файл в публичный архив не кладу, храню отдельно и зашифрованно).

Базу выгружаю через wp db export при наличии WP-CLI на сервере или через mysqldump напрямую - это быстрее и надежнее, чем экспорт через админку на сайтах с базой больше пары гигабайт. Для интернет-магазинов на WooCommerce отдельно слежу, чтобы в дамп попадали таблицы заказов и метаданных платежей - именно там при интеграции с Т‑Банком или ЮKassa хранится история транзакций, без которой бухгалтерии потом нечем сверяться.

Плагины и автоматизация бэкапов на WordPress

Вручную бэкапы никто не делает дольше месяца - либо забывают, либо откладывают. На практике использую связку из плагина и хостинг-снапшотов.

Izвестные варианты для автоматизации: UpdraftPlus (бесплатной версии хватает для сайта на 1-2 ГБ), All-in-One WP Migration - удобен для разового переноса и клонирования, BackWPup - гибче настраивается под расписание и внешние хранилища. Ставлю расписание - полный бэкап раз в сутки для магазина с активными заказами, раз в неделю для статичного корпоративного сайта, плюс отдельное расписание для дампа базы каждые 6 часов, если через сайт идут платежи.

Хостинги вроде Timeweb, Beget или Reg.ru делают собственные ежедневные снапшоты, но хранят их обычно 3-7 дней - этого мало, если проблему заметили не сразу. Снапшоты хостинга рассматриваю как дополнительный, а не основной уровень защиты.

Архивы с базой WooCommerce часто содержат имена, телефоны и email покупателей - это персональные данные, и по 152-ФЗ хранить их нужно на серверах в РФ. Складываю такие бэкапы в S3-совместимое хранилище Selectel или Яндекс Object Storage, а не в зарубежные облака вроде Google Drive. Уведомления о статусе бэкапа - успешно прошел или упал с ошибкой - обычно завожу в Telegram-бота на aiogram, который раз в сутки проверяет наличие свежего архива в хранилище.

Как устроено резервное копирование в Tilda

Tilda - конструктор без доступа к серверу и базе данных, поэтому логика бэкапов там другая. Экспорт проекта из панели Tilda выгружает статический zip-архив со всеми страницами, CSS и картинками - это основной способ сохранить визуальную часть сайта.

Но экспорт не включает несколько важных вещей: настройки форм и их привязку к CRM, вебхуки для интеграции с СДЭК или платежными системами, кастомные Tilda-скрипты, если их не сохранять отдельно вручную. На проектах, где я подключаю кастомный JS для расчета доставки или для передачи заказов в CRM, код скрипта всегда храню в отдельном Git-репозитории с историей версий - панель Tilda версионирования правок не ведет, и откатить скрипт к рабочему состоянию из самой Tilda нельзя.

Экспорт из Tilda делаю перед каждой крупной правкой макета и минимум раз в месяц по расписанию - вручную это легко забыть, поэтому на нескольких проектах я настроил сценарий в n8n, который раз в неделю присылает напоминание в Telegram и фиксирует, когда последний архив был выгружен и загружен в хранилище. Если нужен похожий сценарий под свой проект, можно настроить автоматизацию бэкапов на n8n - обычно на это уходит несколько часов на связку с хранилищем и уведомлениями.

Правило 3-2‑1: куда и как хранить копии сайта

Правило простое: минимум 3 копии данных, на 2 разных типах носителей, 1 из которых - за пределами основного сервера. На практике это выглядит так: рабочая копия на хостинге, автоматическая копия в облачном хранилище, и третья - либо на локальном диске разработчика, либо в отдельном облачном аккаунте, не связанном с первым.

Срок хранения версий тоже стоит планировать заранее: ежедневные копии храню 7-14 дней, еженедельные - месяц, ежемесячные - до полугода. Это позволяет откатиться не только к вчерашнему состоянию, но и найти рабочую версию, если проблема с контентом или заказами обнаружилась не сразу, а через пару недель.

Как проверить, что бэкап реально работает

Архив, который никогда не разворачивали, - это не бэкап, а файл, который создает иллюзию защиты. Проверяю восстановление на тестовом поддомене или локальном окружении хотя бы раз в 1-2 месяца: разворачиваю базу и файлы WordPress через wp db import, открываю сайт, проверяю, что товары, цены и формы работают.

Для Tilda процедура другая - распаковываю экспортированный zip и открываю страницы локально в браузере, чтобы убедиться, что верстка и кастомные скрипты подключаются корректно. Отдельно проверяю, что после восстановления снова работают интеграции: вебхук СДЭК для расчета доставки и прием платежей от Т‑Банка обычно требуют повторного ввода API-ключей и переподключения, потому что эти настройки бэкап не сохраняет.

Если на сайте есть Telegram-бот на aiogram, который принимает заявки или уведомления о заказах, его токен и вебхук тоже стоит внести в чек-лист восстановления отдельно - база сайта его не содержит.

Частые вопросы

Как часто делать резервное копирование сайта?

Для интернет-магазина с активными заказами - дамп базы каждые 6-12 часов и полный бэкап файлов раз в сутки. Для информационного сайта или лендинга без частых правок достаточно резервной копии раз в неделю, плюс обязательно перед любым крупным обновлением плагинов или темы.

Сколько хранить старые бэкапы?

Держу ежедневные копии 1-2 недели, еженедельные - месяц, ежемесячные - до полугода. Этого хватает, чтобы откатиться и к вчерашнему сбою, и к проблеме, которую заметили не сразу.

Можно ли восстановить сайт из бэкапа самостоятельно?

На WordPress - да, если есть доступ к хостингу и базовое понимание работы с базой данных и FTP: большинство плагинов для бэкапа умеют восстанавливать сайт в несколько кликов. С Tilda сложнее: экспорт восстанавливает верстку, но интеграции, формы и вебхуки приходится настраивать заново вручную.

Что делать, если хостинг не поддерживает автоматические снапшоты?

Ставлю плагин для WordPress с расписанием бэкапов и выгрузкой во внешнее S3-хранилище - от хостинга в этом случае ничего, кроме доступа по FTP и SSH, не требуется. Для Tilda снапшоты хостинга неактуальны в принципе, там резервная копия - это регулярный экспорт проекта из панели.