Как проверить, что бэкап сайта действительно поднимается

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

Что значит «бэкап поднимается»

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

Поэтому «бэкап есть» и «бэкап поднимается» — разные утверждения. Первое проверяется по списку файлов в панели. Второе — только восстановлением. Удобно разделить проверку на уровни: каждый следующий доказывает больше предыдущего.

Только последние две строки отвечают на вопрос из заголовка. Всё выше — подготовка к ним.

Сначала проверьте возраст копии и где она лежит

Самая частая причина, по которой бэкап не пригождается, — он перестал создаваться, а никто не заметил. У нас так и было. На момент аварии хостинга 2 ноября 2026 года последние копии вне сервера были от 28 июля — 97 дней. Запись «бэкап ежедневно» три месяца заменяла проверку: сама проверка жила внутри того же скрипта и молчала вместе с ним.

Что смотреть:

• Дата и время самой свежей копии. Не дата настройки задачи, а дата последнего файла в хранилище. Сравните её с тем, сколько данных вы готовы потерять: для сайта с заявками это часы, а не месяцы.
• Место хранения. Копия в той же панели хостинга, на том же сервере или в том же аккаунте падает вместе с сайтом. Минимум — два места вне хостинга; одно из них может быть диском в вашем офисе.
• Размер. Если размер копии резко упал или не меняется неделями, что-то отключилось.

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

Пусть свежесть проверяет другая машина

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

Важная деталь: проверять нужно настоящим путём копии. У нас с 04–05.11 копии сервера уезжают в два места вне провайдера по расписанию раз в 45–55 минут (одно место — раз в 55 минут, другое — раз в 45 минут). Сторож проверяет свежесть меткой, которая едет тем же путём, что и сама копия, и возвращается. Если путь сломан, метка не вернётся.

Первая настоящая тревога сторожа пришла вечером 04.11: копия картинок сайта 29 часов не уезжала на диск из-за ошибки доступа. Внутри сервера всё выглядело нормально. 9 828 картинок висели в очереди загрузки, и никакая внутренняя проверка этого бы не показала.

Пробное восстановление на чистом сервере

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

1. Запишите время начала. Время — один из результатов проверки.
2. Возьмите копию из хранилища вне хостинга, а не из панели основного хостинга. Так вы проверяете тот путь, которым будете пользоваться в аварию.
3. Разверните файлы и базу на чистом сервере. Отмечайте всё, чего не хватило: ключ, пароль, версия программы, настройка, о которой знал только человек, настраивавший сервер.
4. Откройте сайт по временному адресу или через файл hosts на своём компьютере, не меняя DNS рабочего сайта.
5. Пройдите путь клиента: главная, каталог, форма заявки, оплата в тестовом режиме, письмо-подтверждение.
6. Проверьте дату последней заявки и последней записи в базе: она должна совпасть с возрастом копии.
7. Запишите время окончания и список того, что пришлось доделывать руками.

Эта запись — ваш первый настоящий замер. До него любое время восстановления — только предположение.

Что чаще всего не попадает в копию

Пробное восстановление почти всегда находит дыры. Типичные места:

• Код, которого нет в репозитории. Доработки, лежавшие только на сервере. На ревизии 06.11 из 159 модулей и служб агентства 81 работает, 47 ждут ключей и решений, 31 придётся собирать заново — их кода не было ни в одной копии.
• Ключи и доступы. Копия сайта без ключей платёжной системы и почтового сервиса поднимется и не примет оплату.
• Картинки и документы. Копируется база, а загруженные файлы лежат отдельно и в расписание не попали.
• DNS и почта. Если домен, DNS и почта администратора живут у того же провайдера, восстановленный сайт не откроется по адресу, а письмо для смены доступа не дойдёт. Об этом отдельно: переносить DNS нужно заранее, а не в аварию. Ложное «можно» на перенос DNS мы поймали на прогоне: 19 % ответов SERVFAIL.
• Заявки между копиями. Всё, что пришло после последней копии, потеряно. В нашем случае 12 485 старых заявок вернули из дампа от 28 июля — более поздних не было.

Какой тип копии вы проверяете

Копии бывают разные: файлы и база отдельно, образ всего сервера, снимок диска. Восстановление из каждого идёт по-своему, и «у нас есть бэкап» может относиться к типу, из которого вы не собираетесь восстанавливаться.

Это видно и из сообщений провайдера об аварии. По сообщению провайдера (пост № 573 от 03.11.2026): «Сохранены файловые бэкапы VPS» и «бинарные бэкапы VPS полностью утеряны». Мы не делаем из этого выводов о провайдере. Практический вывод для владельца сайта один: заранее знайте, какого типа ваши копии, из каких вы реально сможете развернуть сайт и где они хранятся. Свежие данные по любому провайдеру смотрите только в его собственных сообщениях и с датой.

Как это делаем мы и что у нас не готово

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

Про себя скажем честно. Резервный сервер и переключение одной командой мы ещё собираем по плану. Учений у нас не было. Расчётное время переключения при падении хостера — 70–80 минут; это оценка, а не замер. Час — цель для контура, который построен и проверен учением, и обещанием он не является. Простой нашего сайта в аварию составил около 2,5 суток, около 63 часов: с ночи 02.11 до 17:53 04.11.

Что сделать на этой неделе

Порядок, который не требует программиста:

• Найдите дату самой свежей копии вне хостинга. Если её нет, это уже результат.
• Настройте копии не реже раза в час минимум в два места вне хостинга.
• Подключите проверку возраста копий с другой машины другой компании, чтобы тревога приходила вам сама.
• Назначьте дату пробного восстановления на чистом сервере и засеките время.
• Распечатайте лист «первые 15 минут»: кому звонить, что выключить, что написать клиентам.

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

Вопросы и ответы

Цену разбора называем после короткого звонка: она зависит от того, где живут сайт, домен и почта. Мы не обещаем, что авария не случится, и не продаём защиту информации.