Оставить заявку
Менеджер свяжется с вами в ближайшее время и задаст уточняющие вопросы по заявке
Сайт можно потерять за минуты: сбой хостинга, ошибка в базе, неудачное обновление. Восстановление зависит не от того, как быстро вы реагируете, а от того, что было настроено заранее. Разбираем, что теряется при сбое, как устроен рабочий бэкап и как проверить, что сайт действительно восстановится. Если вам нужен системный контроль, посмотрите поддержку сайта.
Бэкап, который ни разу не проверяли, — это не бэкап. Это надежда.
Сбой хостинга редко означает, что исчезает только «сайт целиком». Чаще теряются отдельные слои, и каждый из них восстанавливается по-своему. Если не понимать, что именно пропало, можно восстановить не то и потерять больше.
Файлы
Шаблоны, плагины, изображения, скрипты. Без них сайт ломается или не открывается.
База данных
Статьи, товары, заказы, пользователи. Без неё страницы пустые.
Почта и сервисы
Заявки перестают доходить, и это замечают не сразу.
Доступы и SSL
Браузер показывает предупреждение, интеграции падают.
Что чаще всего упускают. Владелец думает, что «сайт» — это одно целое. На деле файлы и база живут отдельно, и копировать нужно оба слоя. Если сохранить только файлы, после восстановления сайт откроется пустым.
Рабочий бэкап — это не «файл, который где-то лежит». Это цепочка, в которой каждый шаг важен. Если выпадает одно звено, копия перестаёт быть надёжной. Ниже — схема, по которой стоит проверять свою настройку.
Цепочка рабочего бэкапа
Сайт и база
Источник копирования
Копия
Файлы и дамп базы
Внешнее хранилище
Отдельно от хостинга
Проверка
Тест восстановления
Восстановление
За 5 минут
24 ч
частота копий
30 дней
глубина хранения
2 места
минимум копий
Схема показывает главное: бэкап — это не один шаг, а цепочка. Если копия хранится только на хостинге, цепочка рвётся на третьем шаге. Если восстановление не проверяли, оно может не сработать на четвёртом. Рабочий бэкап — тот, где каждый шаг закрыт.
Место хранения — самый частый провал. Копия, которая лежит на том же хостинге, что и сайт, не спасает от сбоя хостинга. Если сервер падает или аккаунт блокируется, вы теряете и сайт, и копию одновременно.
Второе правило — минимум две копии в разных местах. Одна автоматическая в облаке, одна ручная на локальном диске. Если облако недоступно, есть локальная копия. Если диск вышел из строя, есть облако.
Третье — доступ к копиям. Если к ним есть доступ только у подрядчика, а он пропал, копии становятся бесполезными. Доступы должны быть у владельца бизнеса или у команды, а не у одного человека.
Проверьте сейчас. Где лежит ваша последняя копия? Если ответ «на хостинге» или «не знаю», считайте, что копии нет. Это первое, что стоит исправить.
Проверка — это не «посмотреть, что бэкап создался». Это попытка восстановить сайт из копии до того, как случится реальная авария. Если вы ни разу не пробовали восстановление, вы не знаете, сработает ли оно.
Возьмите последнюю копию и разверните её на тестовом домене или локальной среде. Проверьте, что сайт открывается, база подключена, формы работают, изображения на месте. Если что-то не так, копия неполная или повреждена. Тест стоит проводить раз в месяц или после крупных изменений.
Что проверить при тесте восстановления
Отдельно проверьте базу данных. Файлы могут восстановиться, а база — нет, если дамп повреждён или неполный. После теста восстановления убедитесь, что контент и настройки на месте.
Частота зависит от того, как часто меняется сайт. Если контент добавляется каждый день, ежедневный бэкап — минимум. Если сайт статичный, достаточно раза в неделю. Важно, чтобы копия была свежей на момент сбоя.
Глубина хранения — это сколько копий вы храните. Если бэкап делается каждый день и хранится 30 дней, у вас есть 30 точек восстановления. Если хранится только последняя копия, а она повреждена, восстановиться не из чего.
Копии содержат те же данные, что и сайт: заказы, пользователей, персональные данные. Если они хранятся в открытом виде в облаке, доступ к ним может получить кто угодно. Шифрование копий и ограничение доступа — обязательная часть настройки.
Пароли и ключи к хранилищу должны быть у владельца бизнеса, а не только у подрядчика. Если подрядчик уходит, доступ к копиям не должен исчезать вместе с ним.
Как часто нужно делать бэкап сайта?
Зависит от активности. Если контент добавляется ежедневно, нужен ежедневный бэкап. Если сайт статичный, достаточно раза в неделю. Главное — чтобы копия была свежей на момент сбоя и хранилось несколько версий, а не только последняя.
Можно ли обойтись бэкапом на хостинге?
Как единственную копию — нет. Если хостинг падает, копия на нём теряется вместе с сайтом. Бэкап на хостинге может быть дополнением, но основная копия должна лежать в другой среде: в облаке, на другом хостинге или на физическом диске.
Сколько хранить старые копии?
Оптимально — от 7 до 30 дней. Этого хватает, чтобы откатиться после сбоя или неудачного обновления. Если сайт меняется редко, можно хранить копии за 2–3 месяца. Слишком короткий срок хранения опасен: если поломка обнаружена поздно, свежих копий может не остаться.
Как проверить, что бэкап рабочий?
Развернуть копию на тестовом домене и убедиться, что сайт открывается, база подключена, формы работают. Проверку стоит проводить раз в месяц или после крупных изменений. Бэкап, который ни разу не восстанавливали, нельзя считать надёжным.
Кто должен иметь доступ к копиям?
Владелец бизнеса и ответственная команда. Если доступ только у подрядчика, при его уходе копии становятся недоступными. Доступы к хранилищу и пароли должны быть у заказчика, даже если технически копии настраивает студия.
Менеджер свяжется с вами в ближайшее время и задаст уточняющие вопросы по заявке