Утром сайт перестал открываться. Панель хостинга тоже недоступна, поддержка сообщает об аварии в дата-центре. Реклама продолжает приводить людей на неработающую страницу, а вы не знаете, где последняя копия сайта и можно ли запустить её на другом сервере.
Отключение площадки не обязательно означает потерю данных. Но если сайт, резервные копии и доступы находятся в одном месте, восстановление полностью зависит от провайдера. Ниже — практический план для владельцев сайтов на WordPress: что сохранять, где хранить копии и как подготовить переезд заранее.
Главный вопрос: сможете ли вы восстановить сайт, если старый хостинг, его панель и поддержка недоступны? Если ответ неизвестен, резервное копирование ещё не решает вашу задачу.
1. Сохраняйте весь сайт, а не только папку с файлами
Для полного восстановления WordPress нужны и файлы, и база данных. Встроенный экспорт записей через «Инструменты → Экспорт» полезен для переноса контента, но не заменяет полноценный бэкап.
- База данных. Страницы, записи, пользователи, настройки, заказы и таблицы плагинов. Сохраняйте все относящиеся к сайту таблицы, включая таблицы с нестандартными префиксами.
- Файлы. Медиа из
wp-content/uploads, темы, плагины,mu-plugins, пользовательские скрипты и файлы вне стандартных каталогов. Для простого восстановления удобно иметь полный комплект файлов сайта. - Конфигурация.
wp-config.php, правила.htaccessили Nginx, редиректы, задания cron, параметры PHP и подключения к внешним сервисам. - Окружение. Версии PHP, MySQL/MariaDB, WordPress, темы и плагинов, расширения PHP, ограничения памяти и загрузки файлов.
- Внешние данные. Если изображения вынесены в объектное хранилище, а заявки — в CRM, их сохранность нужно организовать отдельно. Бэкап WordPress не копирует автоматически весь ваш бизнес.
Файлы и база должны соответствовать друг другу. Для активно меняющегося сайта используйте согласованное копирование: например, короткое окно без новых записей либо инструмент, который обеспечивает согласованность. Простое копирование работающего каталога базы данных может дать непригодную копию.
2. Храните копии за пределами основного хостинга
Архив в соседней папке сервера исчезнет вместе с доступом к этому серверу. Второй VPS у того же провайдера тоже может зависеть от общей площадки, сети или панели управления. Проверяйте независимость хранения, а не только название тарифа.
Практический ориентир — правило 3–2–1: рабочие данные и ещё две копии, два разных типа носителей или систем хранения, одна копия вне основной площадки. Например: сайт на хостинге, версионные архивы у другого провайдера и периодическая копия на отключаемом внешнем диске.
- Отправляйте бэкапы в отдельное хранилище с независимым аккаунтом. Убедитесь, что его можно открыть без почты и панели аварийного хостинга.
- Шифруйте архивы. Они могут содержать персональные данные, настройки и ключи сервисов. Ключ расшифровки храните отдельно и проверяйте, что он доступен при аварии.
- Держите несколько поколений копий. Обычная синхронизация может перенести удаление или повреждение на резервную сторону.
- По возможности используйте неизменяемое хранение с периодом защиты от удаления и отдельные права доступа. Компрометация сайта не должна позволять стереть всю историю копий.
- Не размещайте SQL-дампы и архивы в публично доступной папке сайта.
3. Подбирайте частоту бэкапов под цену потерянных данных
Сначала определите два значения: RPO — сколько последних данных вы готовы потерять, и RTO — за какое время нужно вернуть сайт в работу. Ночной бэкап может означать потерю почти суток заказов, если авария случится следующим вечером.
Ниже — отправная точка для настройки, а не универсальная гарантия. Реальная частота зависит от активности сайта, объёма данных и допустимых потерь.
| Тип сайта | База данных | Файлы | Дополнительно |
|---|---|---|---|
| Лендинг или сайт услуг | Ежедневно и после важных правок | После изменений, полный бэкап еженедельно | Перед обновлениями и переносом |
| Блог с частыми публикациями | Ежедневно; чаще при активной работе | Новые медиа ежедневно | Сохранять историю версий |
| Интернет-магазин | Каждые 15–60 минут, если такие потери допустимы | После изменений и загрузки медиа | При строгом RPO — журналы БД и восстановление на момент времени |
Пример политики хранения: ежедневные копии за последние 14 дней, еженедельные за 8 недель и ежемесячные за 6 месяцев. Сроки подбирайте под свой проект: повреждение иногда обнаруживается только через несколько недель. При инкрементальных бэкапах сохраняйте базовую копию и всю необходимую цепочку изменений.
Проверяйте не только запуск задания, но и успешную доставку архива во внешнее хранилище. Уведомления о сбоях должны приходить на канал, который не зависит от основного сервера. Если задача запускается через WP-Cron, учитывайте его зависимость от посещений сайта; для предсказуемого расписания настройте системный cron или внешний планировщик.
4. Кодовая база: Git нужен, но бэкап он не заменяет
Самописную тему, плагины и скрипты развёртывания храните в приватном Git-репозитории вне основного сервера. Отмечайте стабильные релизы и сохраняйте версии зависимостей. Это позволит вернуть рабочий код даже после неудачного изменения или потери диска.
- В репозиторий: исходники темы и плагинов, инструкции сборки, файлы зависимостей, конфигурационные шаблоны без секретов.
- В отдельный защищённый архив: база данных, пользовательские загрузки, приватные настройки и необходимые для развёртывания секреты.
- Для платных компонентов: дистрибутивы нужных версий, сведения о лицензиях и доступ к аккаунтам поставщиков. Повторное скачивание старой версии бывает недоступно.
- Для VPS и Docker: описание сервисов, Dockerfile/Compose, версии образов, настройки сети и список томов с данными. Сохранение образа контейнера не сохраняет автоматически базу в томе.
Не коммитьте пароли, токены и рабочий .env. Пример .env.example должен содержать только названия параметров и безопасные значения. Сам репозиторий тоже нуждается в независимой копии или зеркале.
5. Подготовьте домен, DNS, почту и доступы
Рабочий архив бесполезен, если вы не можете изменить DNS-запись домена. Учётные записи регистратора, DNS-провайдера и хранилища должны принадлежать владельцу сайта. У ответственного специалиста должен быть согласованный доступ для восстановления.
- Сохраните экспорт DNS-зоны: A/AAAA, CNAME, MX, TXT, записи SPF, DKIM и DMARC. При переносе сайта не удаляйте случайно настройки почты.
- Проверьте адрес восстановления аккаунтов. Если он обслуживается в том же дата-центре, во время аварии вход может оказаться невозможным.
- Храните резервные коды двухфакторной аутентификации в защищённом месте, доступном ответственным лицам.
- Подготовьте способ выпуска TLS-сертификата на новой площадке, доступы к SMTP, CRM, платёжным шлюзам и сведения об ограничениях по IP.
- Запишите контакты провайдеров и порядок действий в отдельном документе, доступном без рабочего сайта.
Заранее уменьшенный TTL может ускорить переключение DNS, но не даёт мгновенного перехода всех посетителей. Изменение TTL уже во время аварии не сокращает срок жизни ранее закэшированных записей. Если переносите авторитетные DNS, отдельно проверьте DNSSEC и DS-записи у регистратора.
6. Проверяйте восстановление на отдельной площадке
Статус «бэкап успешно создан» означает лишь завершение операции. Он не доказывает, что архив полный, ключ расшифровки доступен, а сайт запустится на другом сервере.
Хотя бы раз в месяц и после значимых изменений разворачивайте свежую копию в изолированном тестовом окружении. Закройте его от посторонних и индексации, отключите реальные платежи, рассылки, вебхуки и фоновые задания, которые могут отправить данные клиентам.
- Скачайте копию из внешнего хранилища и проверьте расшифровку и целостность.
- Восстановите файлы и базу, настройте окружение и проверьте вход в админку.
- Откройте ключевые страницы, изображения, поиск и формы; для магазина — корзину и оформление заказа в тестовом режиме.
- Проверьте необходимые интеграции безопасным тестом, не вызывающим реальных списаний или повторных уведомлений.
- Измерьте время от начала работ до готовности сайта и запишите найденные проблемы.
Контрольная сумма поможет обнаружить повреждение файла при хранении или передаче. Проверка работоспособности требует полноценного восстановления. Именно тест показывает, укладываетесь ли вы в выбранный RTO.
7. Решите, нужен ли резервный сервер
Для сайта услуг может быть достаточно независимых копий, инструкции и заранее выбранного нового хостинга. Если час простоя стоит дорого, имеет смысл подготовить резервную площадку с совместимым окружением и регулярно обновляемыми данными.
Резервирование сокращает простой, но требует контроля синхронизации и переключения. Репликация может перенести ошибку или удаление на второй сервер, поэтому исторические бэкапы всё равно нужны. В магазине два одновременно принимающих заказы экземпляра без согласованной архитектуры могут привести к расхождению данных.
CDN способен продолжить отдавать часть закэшированных страниц и изображений, если это настроено. Он не заменяет сервер, базу данных, оформление заказов и некэшируемые формы. Для аварии полезно иметь независимую страницу со статусом и альтернативным способом связи.
8. Что делать, если дата-центр уже отключился
- Уточните масштаб сбоя. Проверьте сайт из другой сети, DNS и сообщения провайдера. Проблема может быть в домене, приложении или сети, а не во всём дата-центре.
- Сохраните имеющиеся копии. Защитите последнюю проверенную версию от перезаписи и удаления ротацией. Зафиксируйте время, до которого в ней есть данные.
- Ограничьте потери бизнеса. Приостановите рекламу на неработающие страницы, сообщите клиентам альтернативный контакт через доступные каналы.
- Разверните сайт на независимой площадке. Проверьте совместимость окружения, восстановите файлы, импортируйте базу и настройте подключения.
- Проверьте новый сайт до переключения. Используйте локальный hosts или другой безопасный способ проверки. При смене URL WordPress применяйте инструмент, учитывающий сериализованные данные, а не слепую SQL-замену.
- Переключите трафик. Подготовьте HTTPS, измените нужные DNS-записи, проверьте A и AAAA, почту, формы, интеграции и мониторинг.
- Контролируйте возврат старого сервера. Не допускайте параллельного приёма заказов и повторных фоновых задач. Сначала согласуйте источник актуальных данных и отдельно сверяйте заказы и статусы платежей.
Если копии нет, а сервер недоступен, создать полноценный бэкап задним числом нельзя. Запросите у провайдера независимые резервные копии и проверьте, что осталось у разработчика. Веб-архивы и сохранённые копии страниц иногда помогают вернуть отдельные тексты, но не базу пользователей, заказы и работающий сайт целиком.
9. Короткий чек-лист владельца сайта
- Есть свежая копия файлов и базы, доступная без основного хостинга.
- Есть история копий и отдельный защищённый или отключаемый экземпляр.
- Сохранены собственный код, зависимости, конфигурация и список версий.
- Работают доступы к регистратору, DNS и резервному хранилищу.
- Ключи расшифровки и резервные коды не потеряются вместе с сервером.
- Назначен ответственный, определены допустимые потери данных и время простоя.
- Восстановление на другой площадке уже проверено, результат и время записаны.
Самая полезная проверка: попросите ответственного восстановить сайт, не используя старый сервер и панель хостинга. Если это получилось, у вас есть реальный план на случай аварии.
Нужна помощь с резервными копиями WordPress?
Мы занимаемся разработкой и обслуживанием сайтов на WordPress. Поможем проверить текущую схему резервирования, настроить внешнее хранение, провести тестовое восстановление и подготовить план переноса на другую площадку.
Можно начать с вашего сайта и конкретной задачи: бэкапы, перенос, восстановление или регулярная техническая поддержка. После обсуждения определим объём работ и стоимость.
Согласуем резервные копии, проверку восстановления и порядок действий при сбое.
Разработка и поддержка WordPress — wp.uweam.ru.
Полезные материалы: руководство WordPress по резервному копированию, рекомендации CISA по защите резервных копий, варианты аварийного восстановления AWS. Предложенное расписание копирования и сроки хранения — примеры для планирования; их нужно адаптировать к вашему сайту.