Бэкапы сайта: почему копия на том же хостинге не спасает

бэкапы интернет-магазин хостинг 03 ноя 16:38 13

Бэкап — это копия, которую можно достать без чужого разрешения

У интернет-магазина две категории данных. Заказы, клиенты и история продаж не восстанавливаются ничем: повторным парсингом их не собрать. Каталог восстановить можно, если есть снимок товаров, характеристик и фотографий.

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

Почему копия на том же хостинге не считается резервной

Схема «сайт на хостинге, там же в панели включены ежедневные бэкапы» выглядит надёжной до первой аварии. Ломается она по одной из трёх причин.

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

Вторая причина — площадка. Пожар, затопление, отключение питания, авария на сети: если датацентр недоступен целиком, недоступны и сайт, и копии, лежащие в нём же. Запасной сервер в том же датацентре падает вместе с основным.

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

Три копии, два носителя, другая площадка

Правило 3-2-1: три копии данных, минимум два разных носителя или технологии хранения, одна копия вне основной площадки. Для магазина на хостинге это рабочая база на сайте, ежедневный дамп на втором сервере у другого провайдера и недельная копия на диске вне серверов.

К правилу стоит добавить ещё две вещи.

Права только на запись. Аккаунт, которым сайт кладёт копии в хранилище, не должен уметь их удалять: в S3-совместимых хранилищах это версионирование и защита объекта от удаления, на своём сервере — отдельный пользователь без права delete.

Разные точки управления. Второй провайдер, второй аккаунт, отдельные ключи. Копии, которые достаются одной панелью, аварию переживут вместе с ней.

Иногда к трём цифрам добавляют ещё две: копия должна быть неизменяемой (офлайн-диск, лента, object lock), а восстановление должно быть проверено заранее. Проверке посвящён отдельный раздел ниже.

Что именно бэкапить интернет-магазину

Список зависит от магазина, но базовый набор такой.

База данных: товары, категории, заказы, клиенты, остатки. Заказы и историю продаж не восстановит ничто.
Файлы сайта: движок, шаблоны, модули, файлы конфигурации с доступами к базе.
Изображения товаров. Обычно это самая тяжёлая часть каталога. У части поставщиков фото уже не достать, а ссылки на чужие картинки к моменту восстановления успевают умереть.
Домен и DNS. Домен держите у регистратора, не связанного с хостингом, а записи A, MX и TXT сохраните текстовым файлом: при переезде это минуты вместо часов.
Доступы: пароли, API-ключи, сертификаты. Хранить их только на сервере, который бэкапите, нельзя.

Где держать вторую копию

Варианты различаются ценой и тем, насколько копия независима от основной площадки.

Куда	Что даёт	Что учесть
Второй аккаунт у того же провайдера	Быстро и дёшево	Общий датацентр и общий контур управления: авария или взлом затрагивает и копии
VPS у другого провайдера, синхронизация по SSH	Полный контроль, с копии можно поднять сайт сразу	Нужен скрипт, мониторинг и обслуживание второго сервера
S3-совместимое хранилище у другого провайдера	Дёшево, версионирование, защита от удаления	Права настраиваются один раз, но аккуратно: ключ не должен уметь удалять
NAS или внешний диск в офисе	Не зависит от сети и хостера	Пропадёт при пожаре или краже, диск нужно хранить отдельно от сервера
Офлайн-архив (лента, диск в сейфе)	Переживает шифровальщиков и удаление через панель	Восстановление медленнее, нужен регламент

Практичный минимум выглядит так: S3-бакет у провайдера, у которого не лежит сайт, и раз в месяц копия на диск, который хранится не в том же помещении, что сервер.

Свежий пример: что бывает, когда копия одна

В ночь с 1 на 2 ноября 2026 года в инфраструктуре Beget злоумышленники получили доступ к управляющему контуру и запустили скрипты, обнуляющие данные. 3 ноября провайдер признал потери: в облачной части (VPS, S3, Kubernetes) утрачены все данные, бинарные копии виртуальных серверов потеряны полностью, настройки CDN и IP-адресов тоже. Файловые копии сохранились, но клиентам их не выдали: больше тысячи серверов проверяют вручную, сроков не называют, объявлен форс-мажор. На виртуальном хостинге файловые бэкапы есть, и по оценке провайдера восстановлению подлежат почти 100% сайтов, только когда — неизвестно.

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

Как настроить бэкапы, чтобы они пережили взлом

Соберите инвентарь: что бэкапите, где лежит, сколько весит и как часто меняется. Без списка половина данных остаётся без копии, обычно это изображения и файлы конфигурации.
Заведите вторую площадку у другого провайдера и уточните, что она не в том же датацентре, что сайт: «резервный» сервер в той же площадке ничего не даёт.
Автоматизируйте: дамп базы, архив файлов, отправка на вторую площадку. Как часто — зависит от числа заказов. Магазину с ежедневными продажами нужен как минимум ежедневный дамп, лучше каждые несколько часов. Храните 7–30 версий, а не одну, которую затрёт следующая.
Разделите права: отдельный пользователь хранилища только на запись, версионирование включено, удаление старых копий — по расписанию на стороне хранилища, а не скриптом на боевом сервере.
Уберите секреты с сервера. Ключи к хранилищу — в менеджере паролей, на панель и на хранилище — двухфакторная аутентификация. После любой аварии у провайдера меняйте пароли и ключи.
Опишите восстановление: где лежит последняя копия, какими командами разворачивается, кто это делает и кого будить, если он в отпуске. Инструкция на две страницы обычно экономит сутки простоя.

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

Копию, которую ни разу не разворачивали, рано считать рабочей. Раз в квартал, а также после крупных обновлений движка:

Возьмите последнюю копию и разверните её на тестовом поддомене или локально.
Сверьте цифры: количество товаров, категорий и заказов за последнюю неделю. Откройте 5–10 карточек и проверьте, что фото на месте.
Замерьте время от «есть копия» до «сайт отвечает». Это и есть реальный срок простоя магазина в аварии.
Найденные дыры закрывайте сразу: обычно выясняется, что не бэкапились изображения или настройки, без которых сайт не поднимается.

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

Парсер не заменяет бэкап

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