UpdraftPlus: почему бэкап WordPress не восстанавливается
АйТи Фреш
Информационная безопасность

Как проверить резервную копию WordPress в UpdraftPlus

Автор: , директор ООО «АйТи-Фреш» · · ~10 мин чтения
Проверка резервной копии WordPress перед восстановлением
Копия ценна, когда сайт восстановлен

Если копия WordPress не восстанавливается, проверьте не только сообщение UpdraftPlus об успехе: нужны и файлы, и база данных, целые архивы и испытанное восстановление. Я разберу пять мест, где ломается цепочка, и покажу, как проверить её до аварии.

1. В копии есть файлы, но нет базы данных

У типового сайта WordPress две части: файлы и база данных. В файлах лежат ядро, темы, плагины и загрузки; в базе — записи, страницы, настройки и другие данные сайта. Одно не заменяет другое. Поэтому для защиты и резервного копирования сайта я сначала сверяю состав копии, а уже потом обсуждаю расписание. Это подтверждает и руководство WordPress: полный комплект включает файлы и базу данных.

В условном сценарии компании «Медея-Мед» администратор сохранял только файлы. Такой архив может пригодиться, чтобы вернуть картинки или тему, но он не вернёт записи и настройки базы. Обратная ошибка тоже встречается: выгрузили базу, забыли каталог с изображениями и плагинами. На экране зелёная отметка, а сайта в комплекте нет. Удивляться тут нечему.

В UpdraftPlus проверьте, что резервируются и база данных, и нужные группы файлов. В списке копий плагин показывает набор отдельных архивов; не сводите проверку к одному имени файла или общему статусу задания. Убедитесь, что все части присутствуют и относятся к одному запуску. У базы может быть отдельный сжатый архив, поэтому не требуйте от каждого файла расширение .sql.

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

Статус «успешно» не доказывает полноту копии.
Схема состава резервной копии WordPress
Файлы и база нужны вместе

2. Архив создан, но не дошёл до хранилища

Сбой может случиться между сервером сайта и удалённым хранилищем: соединение оборвалось, авторизация устарела, квота закончилась или задача была остановлена. Называть конкретный предел размера файла без проверки условий аккаунта и текущих правил провайдера — гадание. История про универсальный лимит в 100 МБ не годится: такой цифры для всех хранилищ и всех сценариев нет.

В условном кейсе «Медея-Мед» проверка начинается с простого: сохранились ли все архивы в удалённом хранилище и совпадают ли их размеры с локальными файлами того же запуска. Если размер различается или объект отсутствует, сначала смотрю журнал задания и состояние подключения, затем повторяю передачу. Само наличие папки с резервными копиями не означает, что в ней лежит полный комплект.

Если провайдер или соединение не принимает большой файл, настройте предусмотренное плагином разделение архива на части либо выберите подходящее хранилище. Название настройки и доступность могут различаться по версии и выбранному направлению хранения — сверяйтесь с актуальным интерфейсом UpdraftPlus. Не переключайтесь на FTP вслепую: сначала проверьте, кто имеет доступ к учётной записи, как защищён канал и где физически окажется копия.

Проверка после загрузки должна быть независимой от процесса, который эту загрузку выполнил. Скачайте копию обратно и проверьте, что архив читается, а все ожидаемые части на месте. При сбое сохраните журнал, время запуска и имена отсутствующих компонентов. Так у хостера будет конкретная задача для диагностики, а у вас — понятный ответ, какой участок цепочки отказал.

3. В резерв попали следы взлома

UpdraftPlus сохраняет выбранное состояние сайта, а не выносит экспертное заключение о его чистоте. Если в базе уже появились чужие записи или в каталогах лежат изменённые файлы, обычная копия может сохранить и их. Это не дефект плагина: резервная копия честно фиксирует то, что получил сервер. После восстановления такого набора подозрительное содержимое вернётся вместе с сайтом.

При признаках взлома не затирайте единственную копию и не объявляйте её чистой. Сохраните исходные материалы отдельно для разбора, ограничьте доступ к сайту и выясните, когда началось изменение. Для возврата выбирайте точку до инцидента, если её можно обоснованно определить, а после восстановления обновите уязвимые компоненты и смените затронутые секреты. Подробный порядок действий при инциденте разобран в статье сайт взломали и нужен откат.

Совет «удалите неизвестный плагин и перезапишите ядро через FTP» слишком короткий для реального инцидента. Заражение может затрагивать тему, расширения, базу, учётные записи и конфигурацию хостинга. Чистая копия ядра не очищает базу и не устраняет уязвимость, через которую сайт взломали. Если источник заражения остался, вредоносные изменения появятся снова. Сначала установите границы инцидента, затем решайте, что восстанавливать.

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

Резерв заражённого сайта может сохранить заражение.
Если резерв уже не проходит тест, мы проверим хранилище и восстановим процедуру копирования на отдельной площадке. Обсудить задачу
Дерево действий при заражении WordPress
Сначала сохраните исходные данные

4. PHP или хостинг прерывает длительное задание

Большой сайт требует времени и ресурсов на архивирование. На результат влияют ограничения PHP, дисковое место, нагрузка, тайм-ауты веб-запроса и правила самого хостинга. В условном случае «Медея-Мед» индикатор останавливался примерно на одном этапе; это симптом для диагностики, а не диагноз и не измерение объёма готового архива. Процент на экране нельзя трактовать как гарантию, что именно 80 % данных уже сохранено.

Директивы PHP memory_limit и max_execution_time существуют, но значения 512M и 300 секунд не являются универсальным рецептом. Лимит памяти задаёт предел для одного скрипта, а максимальное время ограничивает его выполнение в соответствующей среде; изменить их можно не на каждом тарифе и не каждым способом. Сверьте фактические значения для PHP, которое обслуживает WordPress, и правила хостера. Увеличивать их стоит по журналам и замерам, а не наугад.

Посмотрите журнал UpdraftPlus и серверные журналы рядом со временем неудачного запуска. Проверьте свободное место, размер временных файлов и сообщения о завершении процесса. Если процесс обрывает веб-сервер или планировщик, простое повышение лимита PHP может ничего не изменить. Когда доступны части архивов, проверьте, все ли созданы; неполный набор удаляйте только после того, как сохранили нужные журналы и решили, как повторить задачу.

Разделение больших файлов на части может помочь при передаче и работе с ограничениями конкретного хранилища, но не отменяет нехватку диска или остановку самого PHP-процесса. Меняйте по одному условию, повторяйте копирование и сравнивайте журнал. Отключать плагины подряд тоже не нужно: делайте это только при воспроизводимом конфликте и сначала на безопасной копии сайта. Иначе вы добавите новую переменную туда, где и без неё мало ясности.

5. Архив ни разу не проходил восстановление

Скачиваемый архив, который открывается, — хороший признак, но не полное доказательство восстановления. Нужны файлы и база, подходящее окружение и понятная последовательность действий. Отдельно проверьте, что у вас есть доступ к панели хостинга и базе данных, а пароль администратора не хранится только на самом сайте. В день сбоя искать доступы — занятие с плохим таймингом.

Я проверяю резерв на отдельной тестовой площадке: загружаю файлы, импортирую базу, открываю сайт и прохожу ключевые сценарии — вход в админку, страницы, формы и загрузки. Тестовая копия должна быть закрыта от поисковиков и посторонних; иначе проверка восстановления сама создаст проблему с данными. После испытания фиксирую дату, состав архива, результат и обнаруженные ограничения. Такой протокол полезнее зелёной галочки в расписании.

Ещё одна обязательная привычка — держать копии не только на том же сервере, где работает сайт. Поломка диска, ошибочное удаление или захват панели могут одновременно лишить и сайт, и локальный архив. WordPress рекомендует хранить несколько свежих копий в разных местах; в своей базе я отдельно отмечаю правило выносить резерв за пределы рабочей машины. Для практики по политике хранения есть материал резервное копирование WordPress с отдельной копией.

Частота копирования определяется допустимой потерей данных. Если сотрудники ежедневно меняют каталог или публикуют материалы, недельный архив оставит слишком большой разрыв; если сайт почти статичен, ежедневная копия может быть лишней. Запишите, сколько изменений можно потерять, и проверьте, что расписание действительно это покрывает. Перед крупным обновлением делайте отдельную точку возврата: стандартная ежедневная задача может ещё не успеть отработать.

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

Расписание выбирайте по тому, сколько новых данных бизнес готов потерять между копиями, а не по привычке «раз в неделю». Перед обновлением WordPress или важных расширений сделайте отдельную копию. Затем периодически повторяйте тест восстановления: проверка должна охватывать не один удачный день, а рабочую процедуру целиком. Я предпочитаю сначала доказать, что комплект поднимается, и лишь потом называть его резервом. Остальное — файлы в хранилище.

Бэкап проверен только после успешного восстановления.
Чек-лист проверки восстановления бэкапа WordPress
Тест восстановления снимает сомнения

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

Что обязательно включать в копию WordPress?

Для полного восстановления типового сайта нужны база данных и файлы: ядро, темы, плагины, загрузки и другие используемые каталоги.

Почему зелёный статус UpdraftPlus не гарантирует восстановление?

Статус задания не доказывает, что все архивы дошли до хранилища и что сайт можно поднять. Проверьте состав, скачайте архивы и испытайте восстановление на отдельной площадке.

Нужно ли выставлять memory_limit 512M и тайм-аут 300 секунд?

Нет универсальных значений. Сначала проверьте ограничения PHP и журналы хостинга; меняйте лимиты только если они действительно вызывают сбой и тариф это допускает.

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

Он может содержать изменённые файлы или данные. Сохраните его отдельно для разбора и восстанавливайтесь из проверенной точки до инцидента, если такая есть.

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

Проверяйте после настройки резервного копирования, затем регулярно и после существенных изменений сайта или хранилища. Интервал зависит от риска и допустимой потери данных.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи