Бэкап сайта: почему надежда на хостинг-провайдера — это риск, а не защита

Резервное копирование сайта у многих владельцев сводится к одной фразе: «Хостинг и так бэкапит». Я слышу её почти каждую неделю. И почти каждый раз она оказывается правдой ровно наполовину — той самой, которая не спасает.

Что на самом деле копирует хостинг

Автоматические копии у провайдеров есть. Вопрос в мелком шрифте, который никто не читает, пока гром не грянет.

Срок хранения. Многие провайдеры держат копии ограниченное время. Взлом нашли не сразу, а через пару-тройку недель? Чистая точка восстановления уже стёрта автоматикой. Ничего личного, просто ротация.

Место хранения. Копии часто живут на той же инфраструктуре, что и сайт. Авария у провайдера, угнанный аккаунт панели, ошибка оператора — и под ударом сразу и сайт, и его «страховка».

Независимая копия устроена иначе. Она лежит на отдельном носителе или в отдельном хранилище, которое не управляется той же учётной записью. Угнали панель хостинга — копия жива.

Правило 3-2-1 без занудства

Отраслевой стандарт звучит просто: три копии данных, два разных типа носителей, одна копия — вне основной инфраструктуры. Это правило рекомендуют и для крупных систем, и для обычных сайтов на CMS. Масштаб значения не имеет.

На языке сайта это выглядит так:

1. Рабочий оригинал на сервере.
2. Копия на другом типе хранилища — например, в облачном объектном хранилище.
3. Ещё одна копия, отделённая от первых двух физически или по доступам.

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

Файлы и база — два разных бэкапа

Классическая ошибка — копировать что-то одно.

Полноценный бэкап сайта на WordPress, Joomla, 1С-Битрикс или Drupal — это всегда пара. Архив файлов: ядро, плагины, темы, загруженные картинки. И дамп базы данных: тексты, настройки, пользователи, заказы.

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

Когда снимать копию

Расписание — база. Скрипт через cron раз в сутки, а для активного магазина и чаще. Частота должна следовать за темпом изменений: магазину с потоком заказов нужно копировать больше, чем визитке, которую правят раз в месяц.

Но есть момент важнее расписания. Перед любым обновлением — CMS, плагинов, темы, версии PHP — нужна отдельная свежая копия. Не вчерашняя ночная. Сегодняшняя, снятая за минуту до нажатия кнопки «Обновить».

Почему? Потому что обновления ломают сайты. Регулярно. С фантазией.

Заражённая копия: тихий кошмар

А вот сценарий, который бесит меня больше всего.

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

Лечение одно: хранить несколько точек восстановления за разные даты. Чтобы откатиться туда, где сайт был заведомо чист, а не туда, где было удобно.

Как понять, что бэкап живой

Самая коварная ошибка — не отсутствие копий. Это слепая вера в их исправность.

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

И делать это не однажды при настройке. Меняется версия CMS, меняется конфигурация сервера, растёт база — и процедура восстановления, работавшая весной, к осени тихо ломается.

Зелёная галочка «Копирование завершено» доказывает только одно: скрипт не упал. Больше ничего.

Автоматизация: убираем человеческий фактор

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

Нормальная схема такая. По расписанию через cron запускается скрипт. Он архивирует файлы, снимает дамп базы и отправляет всё на удалённое хранилище: отдельный сервер, облако или S3-совместимое объектное хранилище. На исходном сервере копия не задерживается.

Чем копировать — встроенным модулем CMS, своим скриптом или сервисом — вопрос вторичный. Принцип первичен: автоматически и за пределы основного сервера.

Уведомления: бэкап, который молча умер

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

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

Без этого администратор месяцами живёт в уверенности, что копии есть. А последняя рабочая лежит полугодовой давности. Сюрприз.

Два вопроса, которые надо задать себе честно

Первый: сколько данных вы готовы потерять? Если копия снимается раз в сутки, то при аварии в шесть вечера пропадает всё, что сделано за день: заказы, заявки, правки каталога. Для визитки это терпимо. Для магазина в сезон — это деньги, которые уже никто не вернёт.

Второй: сколько часов сайт может лежать? Час? День? Неделю? От ответа зависит, где хранить копию и как быстро её поднимать. Копия в холодном архиве, которую надо три дня выкачивать, формально существует. Практически — нет.

Эти два числа владелец бизнеса должен назвать сам. Не админ, не подрядчик. Потому что цену простоя знает только тот, кто платит зарплату и считает выручку.

Что ещё забывают положить в копию

Файлы и база — минимум. Но восстановить сайт на новом сервере только по ним бывает мучительно. Что обычно теряется:

• конфигурация веб-сервера и PHP, под которую сайт годами подгоняли;
• задания cron, без которых не уходят письма и не обновляются цены;
• файлы настроек с доступами к внешним сервисам и платёжным модулям;
• сведения о DNS-записях домена.

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

Как халтурят с бэкапами

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

Это не обслуживание. Это продажа ощущения безопасности. И самое мерзкое здесь то, что вскрывается обман ровно в тот день, когда вам хуже всего: сайт лежит, заказы не идут, поисковик повесил предупреждение. Задавайте подрядчику один вопрос: «Когда вы последний раз восстанавливали наш сайт из копии?» Если ответ начинается с «ну…» — у вас нет бэкапов.

Сценарий: заражение старше всех копий

Интернет-магазин на популярной CMS. У хостинга включено автокопирование с хранением за две недели. Через уязвимый модуль на сайт попадает вредоносный код. Внешне всё нормально. Три недели. Потом поисковик помечает сайт предупреждением об угрозе.

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

Одна внешняя копия месячной давности превратила бы неделю ручной чистки в вечер работы.

Сценарий: обновление «на авось»

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

Ночной бэкап есть. Но утренние публикации и правки каталога в него не попали. При откате они теряются. Отдельная копия перед обновлением дала бы откат за минуты и без потерь.

Таблица: из чего состоит нормальная стратегия

Что делаем мы и чем это отличается

Мы не предлагаем «довериться хостингу». В рамках обслуживания сервера — от 7 000 ₽ в месяц — настраиваем независимое копирование по правилу 3-2-1:

• копии уходят за пределы основного хостинга и под отдельные доступы;
• храним несколько точек восстановления за разные периоды, а не одну «последнюю»;
• каждая задача копирования присылает статус, молчание считается аварией;
• перед обновлениями снимаем отдельную копию;
• и главное — периодически реально восстанавливаем сайт из копии в тестовой среде.

Облачный провайдер включит бэкап как общую услугу для всех и не проверит, поднимется ли из него именно ваш сайт. Мы проверяем. Вы получаете не галочку, а процедуру, которая уже отработала до аварии.

Чек-лист: есть ли у вас защита

• Копии хранятся вне основного хостинга, а не только в его панели.
• Копируются и файлы, и база данных.
• Есть несколько точек восстановления за разные даты.
• Перед обновлением CMS, темы или плагинов делается отдельная копия.
• Восстановление из копии хотя бы раз проверено вживую.
• Вы знаете срок хранения бэкапов у провайдера, и он длиннее, чем вы обычно замечаете проблемы.
• Есть ответственный, который получает уведомления о статусе копирования.

Проверьте до аварии

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

Частые вопросы