В панели хостинга включено резервное копирование, на диске лежат архивы, уведомления об ошибках не приходят. Но после сбоя выясняется: последняя пригодная копия сделана несколько дней назад, базы данных в архиве нет, а восстановленный сайт открывается без новых заказов и загруженных файлов.
Наличие бэкапа ещё не отвечает на главный вопрос: сможете ли вы вернуть проект в рабочее состояние и сколько данных потеряете при этом. Проверить это можно заранее, пока основной сервер работает.
На LowEndTalk клиент OVHcloud описал повторные зависания VPS во время автоматического резервного копирования. По его сообщениям, после отдельных сбоев новые точки восстановления не появлялись. В обновлении от 15 августа 2026 года автор сообщил, что завершает перенос проектов на другую инфраструктуру. Это описание конкретного клиентского случая, по которому нельзя оценивать все услуги провайдера. Но сам сценарий полезно разобрать любому владельцу VPS.
Почему VPS может зависать во время создания бэкапа
Резервное копирование создаёт дополнительную нагрузку: система читает данные с диска, иногда сжимает их и передаёт в хранилище. Если ресурсов не хватает, сайт может отвечать медленнее, а запросы к базе данных — дольше ждать выполнения.
Есть и другой механизм. При некоторых способах создания снимка система через гостевой агент временно приостанавливает запись в файловые системы. Например, в QEMU для этого предусмотрены операции freeze и thaw: приостановка записи и её возобновление. Если процесс застревает, приложения, которым нужна запись на диск, могут перестать отвечать, хотя панель продолжает показывать VPS как включённый.
Совпадение сбоя со временем бэкапа — повод для проверки, но ещё не готовый диагноз. Зафиксируйте время и часовой пояс, статус операции в панели, доступность SSH или RDP, состояние консоли и ошибки мониторинга. Эти данные помогут поддержке отличить перегрузку диска от зависшей операции резервного копирования.
Отключать гостевой агент или регулярно перезагружать VPS вслепую не стоит: это может изменить поведение бэкапов, а причина повторных сбоев останется.
Почему в резервной копии может не оказаться нужных данных
Сначала выясните, что именно сохраняет ваша система резервного копирования. Архив сайта, дамп базы и снимок диска решают разные задачи.
- Архив каталога сайта. Содержит попавшие в него файлы, но обычно не включает базу данных. Для WordPress нужны обе части: файлы и база.
- Дамп базы данных. Сохраняет данные базы, но не фотографии товаров, документы пользователей, темы и плагины на диске.
- Снимок VPS. Нужно проверить, какие диски входят в снимок. Внешняя база, сетевое хранилище и дополнительные тома могут требовать отдельного копирования.
- Сохранённый образ Docker. Не заменяет бэкап данных в подключённых volumes и каталогах хоста. Контейнер можно запустить заново и получить приложение без прежних данных.
Отдельно проверьте настройки, без которых проект не запустится: конфигурацию веб-сервера, переменные окружения, расписание фоновых заданий, версии программ и необходимые ключи. Секреты храните в защищённом виде. Доступ к ним и ключ расшифровки бэкапа должны сохраняться при полной потере VPS.
Даже присутствие всех файлов не гарантирует исправную базу. Простое копирование каталога работающей СУБД может сохранить разные файлы в разные моменты. Используйте поддерживаемый базой способ резервного копирования: согласованный дамп, специализированный инструмент или корректно настроенный снимок. Для проекта с базой и файлами на разных серверах также нужно продумать согласованность их восстановления.
Как часто делать копии и где их хранить
Частота зависит от того, сколько изменений вы готовы потерять. Допустим, последняя исправная копия отражает состояние магазина на 03:00, а сервер выходит из строя в 18:00. При восстановлении только из этой копии в базе не будет изменений за 15 часов.
Для редко обновляемого сайта такой интервал может быть приемлем. Для магазина с постоянными заказами — уже нет. Если допустимо потерять максимум 30 минут данных, одной ночной копии недостаточно. Нужны более частые копии базы либо заранее настроенное восстановление по журналам изменений. В MySQL для этого используют binary logs вместе с исходным бэкапом. Журналы тоже нужно сохранять вне основного сервера.
Проверьте и срок хранения. Если ошибочное удаление обнаружится через неделю, единственная вчерашняя копия может уже содержать ту же проблему. Несколько точек за разные даты позволяют выбрать состояние до сбоя.
Хотя бы одну копию храните независимо от рабочего VPS. Архив на том же диске потеряется вместе с ним. Хранилище в другом дата-центре снижает зависимость от одной площадки, а отдельная учётная запись и защита от удаления — от одного взломанного аккаунта. Само название «снапшот» ничего не говорит о независимости хранения: это нужно уточнять у провайдера.
Контролируйте возраст последней успешно завершённой копии. Сообщение «задание запущено» не означает, что появился новый бэкап, пригодный для восстановления.
Как проверить восстановление, не затронув рабочий сайт
Проверку проводите на отдельном VPS или в изолированной тестовой среде. Для испытания полного восстановления не используйте единственный рабочий сервер: откат может перезаписать текущие данные.
- Выберите конкретную копию. Запишите её дату и время. Убедитесь, что доступны все части архива, ключ расшифровки и, если копия инкрементальная, необходимые предыдущие копии.
- Подготовьте место для восстановления. Проверьте объём диска, включая место для распаковки, совместимость программ и доступность установочных файлов.
- Изолируйте тестовый проект до запуска. Закройте публичный доступ, отключите реальные платежи, письма, SMS и обмен с рабочими внешними системами. Фоновые задания тоже могут повторно отправить уведомления или изменить данные.
- Восстановите проект по инструкции. Используйте содержимое бэкапа и сохранённые настройки. Если недостающий файл приходится брать с рабочего VPS, добавьте его в схему резервного копирования и повторите проверку.
- Проверьте пользовательские действия. Откройте несколько страниц, войдите в личный кабинет, найдите заказ, созданный незадолго до выбранной точки восстановления, и проверьте его вложения. Выполните тестовую запись в базу, загрузку файла и оформление заказа с тестовой оплатой.
- Запишите результат и затраченное время. Считайте весь путь: получение копии, подготовку сервера, распаковку, импорт базы, исправление настроек и проверку приложения.
Если архив распаковался за десять минут, а сайт удалось запустить только через три часа, для планирования простоя ориентируйтесь на три часа. При реальном переключении могут добавиться ожидание поддержки, настройка сети и обновление DNS.
Повторяйте проверку после переноса базы, подключения нового диска, изменения способа копирования и крупных обновлений проекта. Между изменениями установите регулярный график: например, ежемесячно для активно работающего магазина. Частоту выбирайте по последствиям возможного сбоя.
Что делать, если сбой уже произошёл
Сначала сохраните доступные исходные данные. Не переустанавливайте VPS и не запускайте полный откат поверх единственного экземпляра проекта, пока не выяснили, что осталось на сервере и в резервных копиях.
Если сервер доступен, по возможности сохраните текущую базу корректным для неё способом, новые загрузки и журналы. При ошибочном удалении или повреждении данных согласуйте с администратором остановку записи: продолжающие работать приложения могут осложнить восстановление.
Уточните у хостера список фактически доступных точек и возможность подключить копию как отдельный диск либо восстановить её на другой VPS. Если пропала одна папка, извлечение нужных файлов может быть безопаснее полного отката сервера.
Для магазина отдельно проверьте заказы и платежи, появившиеся после выбранной точки восстановления. Откат базы не отменяет уже проведённые платежи. Статусы придётся сверить с платёжной системой, чтобы не повторить обработку и не потерять оплаченные заказы.
Возвращайте посетителей на восстановленный проект после проверки данных и основных операций. До переключения определите, как перенести последние изменения и остановить запись на старом сервере, чтобы два экземпляра магазина не начали принимать разные заказы.
Что заранее уточнить у хостера
Для VPS xHost24 параметры резервного копирования стоит уточнять применительно к своей услуге через тикет в биллинге. Можно отправить такой запрос:
Здравствуйте. Хочу проверить возможность восстановления проекта на VPS [номер услуги]. Подскажите:
— включено ли резервное копирование для этой услуги и что именно в него входит;
— сохраняются ли все подключённые диски и какие есть исключения;
— какова дата последней успешной копии и сколько точек хранится;
— где находятся копии и как получить к ним доступ при недоступности VPS;
— можно ли выгрузить данные, извлечь отдельные файлы или восстановиться на другой VPS;
— перезаписывает ли восстановление текущий диск и требуется ли участие поддержки;
— есть ли плата за восстановление и от чего зависит его срок;
— как безопасно провести тестовое восстановление.
После ответа назначьте первую проверку. Её результат должен быть конкретным: из какой копии восстановлен проект, какие данные в нём найдены, какие действия работают и сколько времени занял запуск.
