В панели хостинга есть снимок VPS, плагин присылает архив WordPress, а администратор сохраняет дамп базы. Кажется, что сайт защищён трижды. Но после сбоя может выясниться: снимок включает не все диски, архив не содержит загрузок, а дамп нельзя восстановить доступной версией программы.

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

Снимок VPS сохраняет состояние инфраструктуры

Снимок обычно удобен перед изменениями системы: в нём могут находиться ОС, установленное ПО, настройки и данные дисков. Конкретный состав зависит от провайдера. Подключённое сетевое хранилище, отдельный том и внешняя база могут в него не входить. Это нужно выяснить до аварии, по описанию услуги и пробному восстановлению.

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

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

Дамп базы сохраняет структуру и записи

В базе находятся заказы, тексты, настройки и другие данные приложения. Логический дамп представляет их в формате, который затем загружают в СУБД. Он не включает фотографии из каталога загрузок, конфигурацию веб-сервера и код плагинов. Даже исправный дамп сам по себе ещё не является готовым сайтом.

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

Загрузка большого дампа может идти заметно дольше его создания. Кроме того, понадобятся свободный диск, правильные пользователи и настройки приложения. Время восстановления стоит измерить на тестовой площадке. Подробный порядок описан в статье о проверке резервных копий.

Архив файлов возвращает то, чего нет в базе

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

Перед упаковкой нужно решить, какие файлы меняются во время операции. Архив и дамп, снятые далеко друг от друга, способны описывать разные состояния. Например, запись о документе уже попала в базу, а сам документ ещё не вошёл в архив. Для активно работающего магазина нужна согласованная процедура, а не два независимых задания с произвольным расписанием.

Сопоставьте копию с задачей

Для начала полезно составить короткую карту восстановления:

  • Неудачная настройка ОС: пригодятся снимок и сохранённая конфигурация.
  • Удалённые записи: понадобится база нужного момента и безопасное извлечение данных.
  • Потерянные вложения: нужна файловая копия или история объектов в хранилище.
  • Уход от провайдера: важны переносимые данные, доступные ключи и инструкция запуска.

Это ориентиры, а не универсальные команды. Возврат всей старой базы ради одной записи может уничтожить новые заказы. Иногда копию сначала разворачивают отдельно, извлекают нужные сведения и только после проверки переносят их в рабочую систему. Решение зависит от связей между данными.

Проверьте восстановление целиком

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

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

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

Уточните, можно ли получить копию при недоступной панели провайдера. Альтернативный путь доступа стоит проверить заранее, пока основной работает и доступен ответственный специалист.

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