Бэкапа на хостинге недостаточно: внешняя копия, схема 3-2-1 и живой кейс
Почему копии на хостинге — это не полноценная защита
Резервная копия на том же хостинге полезна. Она позволяет откатить неудачное обновление, восстановить удалённый файл или вернуть базу к предыдущему состоянию. Проблема не в самой такой копии, а в том, что она не защищает от всех сценариев отказа.
Хотя бы одна резервная копия должна находиться на другой физической площадке: например, в другом дата-центре, желательно у независимого провайдера. Само слово «облако» ничего не гарантирует — важно понимать, где физически хранятся данные и насколько независимо устроено хранилище.
Повреждение инфраструктуры может нарушить работу облачных сервисов
В октябре 2026 года Яндекс сообщил о повреждениях дата-центров в Сасово и Калуге. В опубликованном компанией материале также говорится, что после атаки в ночь на 11 октября работа дата-центра во Владимире была остановлена. Компания описала последствия для инфраструктуры и восстановление сервисов.
Источники: официальный разбор Яндекса о состоянии дата-центров и сообщение Яндекс 360 от 13 октября.
Эти события наглядно показывают, почему даже крупная технологическая компания не может полностью исключить физические риски для собственной инфраструктуры. Для владельца небольшого сайта вывод практический: если важные данные существуют только в одном месте, последствия аварии могут оказаться значительно серьёзнее временной недоступности сайта.
Независимая резервная копия не предотвращает аварию и не гарантирует бесперебойную работу. Она даёт возможность восстановить данные, когда основной контур недоступен или повреждён.
Хостер может потерять связь с интернетом
2 июня 2026 года произошёл случай из моей практики. У крупного российского хостера, по сообщениям самого провайдера в день аварии, одновременно возникли проблемы с двумя магистральными операторами связи.
Сайты, включая интернет-магазин одного из моих клиентов, были недоступны около получаса. По данным моего мониторинга Netdata, трафик упал в 4–5 раз. Сам сервер работал штатно: проблема находилась за пределами сайта, и восстановить доступность собственными действиями на сервере было невозможно.
Публичного подробного разбора инцидента от провайдера я не нашёл, поэтому привожу этот эпизод как собственное наблюдение, а не как независимо подтверждённое расследование.
В этом случае внешняя копия не сделала бы сайт доступным во время аварии. Но если бы инфраструктура оказалась повреждена и потребовался перенос, независимый бэкап дал бы возможность развернуть сайт на другой площадке.
Аккаунт могут заблокировать
Типичный сценарий: злоумышленник взламывает WordPress через уязвимый плагин, заражённый сайт начинает рассылать спам или выполнять подозрительные команды, после чего хостинг блокирует аккаунт.
В зависимости от правил провайдера блокировка может ограничить доступ не только к сайту, но и к панели управления, где хранятся резервные копии.
Владелец оказывается в неприятной ситуации: для восстановления нужны данные, а получить их привычным способом не удаётся. Приходится обращаться в поддержку, разбираться с причинами блокировки и искать способ выгрузить файлы.
Внешняя копия позволяет перенести сайт на другой хостинг, если вместе с ней сохранены необходимые конфигурации, доступы и сведения об окружении. В некоторых случаях это занимает несколько часов, но точный срок можно оценить только после проверки процедуры восстановления.
Человеческий фактор и шифровальщики
База удалена одной командой. Обновление повредило сайт. Подрядчик случайно удалил нужный каталог. Вирус-шифровальщик добрался до сетевой папки с резервными копиями.
Во всех этих случаях оригинал и копии могут пострадать одновременно, если они находятся рядом и доступны тем же людям, скриптам или учётным записям.
Особенно опасно, когда сервер сайта имеет права не только создавать резервные копии, но и без ограничений удалять всю историю. Компрометация такого сервера может привести к потере и сайта, и его резервов.
Вывод
Хостинговый бэкап — полезная первая линия защиты от собственных ошибок. Но он не заменяет независимую резервную копию, которая переживёт потерю основной площадки, блокировку аккаунта или компрометацию сервера.
Идеальная схема: 3-2-1-1-0
Один из распространённых принципов резервного копирования — правило 3-2-1. Это практическая модель организации защиты данных, а не единый обязательный стандарт для каждого сайта.
Смысл правила тот же, что закреплён и в российских требованиях к защите данных: копии должны существовать, переживать потерю основной площадки и проверяться восстановлением.
Расширенная формула выглядит так.
3 копии данных. Оригинал плюс две резервные копии. Одна резервная копия уже лучше, чем отсутствие копий, но оставляет мало запаса на случай повреждения или потери самого носителя.
2 разных типа носителей или технологии хранения. Например, локальный накопитель и отдельное объектное хранилище. Два сервера с одинаковой конфигурацией хранения не обязательно соответствуют этому требованию: важно учитывать типы носителей и общие точки отказа.
1 копия вне основной площадки — offsite. Другой дата-центр, независимый провайдер или отдельное физическое место хранения. Такая копия помогает пережить потерю основного здания или инфраструктуры.
1 копия офлайн или неизменяемая — immutable. Её нельзя удалить или перезаписать обычными учётными данными, даже если злоумышленник получил контроль над сервером сайта. Примеры — отключённый накопитель, WORM-хранилище или объектное хранилище с настроенной политикой неизменяемости.
0 ошибок при проверке. Резервная копия может существовать, но её пригодность для восстановления не подтверждена, пока не проверены целостность данных и сама процедура восстановления.
Для небольшого сайта не обязательно сразу строить сложную инфраструктуру. Можно начать с хостинговой копии, автоматического резервирования на независимое хранилище и регулярных проверок. Затем добавить изолированный слой, защищённый от удаления.
Важно различать два понятия: внешняя копия и неизменяемая копия — не одно и то же. Резерв на другом сервере защищает от некоторых аварий основной площадки, но если сервер сайта может удалить его через доступные учётные данные, он остаётся уязвимым для шифровальщика.
Живой кейс: подписка на бэкапы интернет-магазина
Один из моих клиентов — интернет-магазин на OpenCart примерно с 50 тысячами заказов. База данных занимает около 45 МБ, общий объём файлов сайта — около 4 ГБ.
Во время разработки и доработок я делал локальные копии перед изменениями. Они хранились у исполнителя, а не на рабочем сервере. Осенью 2026 года разовые резервные копии заменили постоянно работающей системой.
Как устроено резервное копирование
База данных — каждые три дня по расписанию cron. Задание запускается в 02:00 в дни 1, 4, 7 и далее. Дамп передаётся непосредственно во внешнее хранилище, без необходимости сохранять промежуточный файл на рабочем сервере. Хранятся 10 копий.
Файлы сайта без изображений, включая конфигурации, — каждое воскресенье. Хранятся 5 копий.
Ежемесячный L3-отчёт — сверка версии MySQL, количества таблиц и заказов, а также контрольных сумм файлов. Это помогает обнаруживать изменения и потенциальные проблемы.
Ежедневный log-scan — сравнение логов с предыдущим днём и отправка уведомлений в Telegram при появлении записей, соответствующих настроенным правилам обнаружения.
Доступ клиента — ссылка на файловое хранилище с паролем. Клиент может самостоятельно посмотреть доступные резервные копии, не полагаясь только на отчёт исполнителя.
Как прошёл первый запуск
Первый прогон дал следующие результаты:
- База данных: 44 МБ, 19 секунд, 198 таблиц.
- Файлы без изображений: около 756 МБ из примерно 4 ГБ общего объёма сайта.
- Количество файлов в выбранном наборе: 19 199.
Это результаты конкретного запуска, а не гарантия того, что каждый последующий бэкап будет выполняться столько же времени. Важно другое: резервирование должно подтверждаться измеримыми результатами — размером, количеством объектов, временем выполнения и проверками.
Что эта подписка защищает, а что нет
Подписка обеспечивает хранение копий вне основного хостинга, ротацию, контроль выполнения задач и регулярную сверку данных.
Но это не полная реализация 3-2-1-1-0. В текущей конфигурации нет отдельного неизменяемого или офлайн-слоя. Кроме того, соответствие требованию о двух разных типах носителей зависит от конкретной инфраструктуры хранения.
Это осознанный компромисс по стоимости для малого бизнеса. Ротация помогает вернуться к более ранней копии, если проблема обнаружена не сразу. Мониторинг позволяет заметить сбои резервирования. Но ни ротация, ни уведомления не защищают от злоумышленника, который получил права на удаление всех копий.
Для более высокой устойчивости к шифровальщикам и компрометации сервера нужен отдельный изолированный слой — например, хранилище с неизменяемостью объектов или офлайн-копия.
Сколько стоит день без сайта
Резервное копирование — это расходы на снижение риска. Чтобы понять, оправданы ли они для бизнеса, нужно оценить последствия простоя.
Ущерб может складываться из трёх частей:
- Недополученная маржа за время простоя — не вся выручка, а доход за вычетом переменных расходов.
- Стоимость аварийных работ: срочное восстановление, время сотрудников, обработка обращений клиентов.
- Репутационные потери: часть покупателей может не вернуться после неудачной попытки оформить заказ.
Условный пример
Предположим, дневная маржа интернет-магазина составляет 100 000 рублей. Сайт не работает сутки. Аварийные работы стоят ещё 20 000–50 000 рублей.
В таком сценарии прямой потенциальный ущерб составит примерно 120 000–150 000 рублей. В спокойном случае восстановление может обойтись дешевле, а некоторые последствия вообще не возникнут. Репутационные потери в расчёт не включены.
Для сравнения: ориентир по описанной подписке — настройка от 10 000 рублей разово и ведение от 2 000 рублей в месяц.
Это не обещание окупаемости, а способ оценить масштаб риска. Подписка не исключает простоя и не гарантирует, что восстановление всегда пройдёт без потерь. Решение зависит от стоимости данных, допустимого времени простоя и бюджета.
Как рассчитать собственный лимит
Возьмите среднюю дневную маржу за последние 90 дней, умножьте её на реалистичное количество дней простоя и добавьте стоимость одного-двух дней работы специалиста.
Посчитайте несколько сценариев: оптимистичный, реалистичный и тяжёлый. Необязательно угадывать вероятность аварии с точностью до процента. Уже сравнение потенциального ущерба с годовыми расходами на резервирование помогает принять обоснованное решение.
Соберите такую схему за 5 шагов
Шаг 1. Проведите аудит: что нельзя потерять
Составьте список данных и настроек, необходимых для восстановления сайта:
- база данных;
- пользовательские файлы, загрузки и изображения;
- конфигурации nginx, PHP-FPM, MySQL и других используемых сервисов;
- список заданий cron и их конфигурации;
- SSL-сертификаты и необходимые приватные ключи;
- инструкции по восстановлению и перечень необходимых доступов.
Конфигурации и секреты тоже могут быть нужны для восстановления, но хранить их следует с ограничением доступа. Приватные ключи, пароли и токены не должны попадать в открытый архив или общедоступный каталог.
Отдельно зафиксируйте, кто имеет доступ к хостингу, домену, базе данных и резервному хранилищу. Если после аварии невозможно получить доступ к домену или расшифровать копию, наличие файлов само по себе проблему не решит.
Шаг 2. Разделите базу данных и файлы
У разных данных разная частота изменений.
База данных обычно небольшая, но может постоянно пополняться заказами, пользователями и другими записями. Частоту резервирования выбирайте исходя из того, сколько изменений бизнес готов потерять: для небольшого магазина отправной точкой могут быть интервалы от одного до трёх дней.
Файлы сайта часто занимают больше места и меняются реже. Их можно копировать еженедельно, если это соответствует реальной частоте изменений.
Изображения и статика могут занимать большую часть дискового пространства. При редких изменениях их допустимо копировать реже, но частоту нужно согласовать с допустимой потерей новых загрузок.
Конфигурации следует резервировать при каждом изменении и хранить эталонную копию.
Шаг 3. Настройте расписание и ротацию
Пример расписания для типового интернет-магазина:
0 2 */3 * * /opt/backups/db-stream.sh 0 3 * * 0 /opt/backups/files-stream.sh 0 4 16 * * /opt/backups/l3-report.sh 0 6 * * * /opt/backups/log-scan.sh
Здесь:
- база данных копируется в 02:00 в дни 1, 4, 7 и далее;
- файлы копируются по воскресеньям в 03:00;
- L3-отчёт формируется 16-го числа каждого месяца;
- проверка логов запускается ежедневно в 06:00.
Это пример расписания, а не готовый комплект скриптов: сами задания необходимо реализовать, настроить права доступа и проверить обработку ошибок.
| Что копировать | Рекомендуемая частота | Пример хранения | Для чего |
|---|---|---|---|
| База данных | Каждые 1–3 дня | 10 копий | Откат к более раннему состоянию |
| Файлы без изображений и конфигурации | Раз в неделю | 5 копий | Восстановление кода и настроек |
| Изображения и статика | Раз в 2–4 недели, если изменения редкие | 2–3 копии | Снижение объёма хранения |
| L3-отчёт | Раз в месяц | 12 месяцев | Анализ изменений во времени |
Это стартовые ориентиры, а не универсальные значения. Частота резервирования зависит от RPO — максимально допустимой потери данных. Скорость восстановления и срок возвращения сайта в работу связаны с RTO.
Десять копий сами по себе не означают месяц истории. Реальная глубина хранения зависит от частоты резервирования, ротации и успешности заданий.
Важный нюанс cron. Запись */3 в поле дня месяца даёт запуски 1, 4, 7 и далее. Это не строгий интервал в 72 часа: на границе месяцев интервал может оказаться короче. Пропущенный запуск cron автоматически не воспроизводится.
Если нужен периодический запуск с интервалом относительно предыдущего срабатывания, можно использовать systemd-таймер с OnUnitActiveSec=. Но механизм восстановления после пропуска необходимо проектировать отдельно: Persistent=true предназначен для календарных таймеров OnCalendar= и не обеспечивает догон пропущенных запусков монотонного таймера. Даже у календарного таймера после простоя речь идёт о запуске для обработки пропуска, а не о последовательном воспроизведении каждого пропущенного интервала.
Независимо от расписания полезно проверять время последнего успешного резервирования и отдельно сигнализировать, если ожидаемая копия не появилась.
Ключевой приём — передача без промежуточного файла на рабочем сервере. Дамп можно направлять непосредственно в удалённое хранилище. Это снижает потребность в свободном месте на сервере и исключает необходимость оставлять временный архив в каталоге сайта.
Однако есть три важных условия.
- Согласованность дампа. Потоковая передача сама по себе её не гарантирует. Результат зависит от движков таблиц и параметров дампа. Для InnoDB обычно используют согласованный снимок, например --single-transaction, если ограничения схемы это позволяют. Для MyISAM и других нетранзакционных таблиц могут потребоваться блокировки.
- Проверка результата. Нужно контролировать коды завершения и самого дампа, и передачи. Успешно созданный удалённый файл ещё не доказывает, что в нём содержатся все необходимые данные.
- Безопасная ротация. Старые копии удаляют только после того, как новая копия успешно передана и прошла предусмотренные проверки. Частичный дамп не должен заменять последнюю проверенную резервную копию.
Шаг 4. Вынесите копии наружу
Для внешнего хранения подойдёт отдельный сервер, независимое объектное хранилище, NAS в другом здании или внешний накопитель с продуманной ротацией.
Главное — не хранить единственные резервные копии на том же сервере или в той же физической площадке, что и оригинал.
Используйте отдельную учётную запись для резервирования с минимально необходимыми правами. По возможности запретите ей удалять старые копии или настройте политику хранения на стороне хранилища. Учётные данные, позволяющие управлять всей историей резервов, не должны быть доступны серверу сайта без ограничений.
Пароли храните в менеджере паролей, а не в переписке или открытых конфигурациях. Если копии содержат персональные данные или другие конфиденциальные сведения, предусмотрите шифрование при передаче и хранении.
Внешнее хранилище не обязательно должно быть дорогим. Важно не столько название сервиса, сколько его независимость от основного контура и возможность восстановить данные при потере доступа к сайту.
Шаг 5. Добавьте мониторинг
Резервное копирование, которое молча перестало работать, может создать ложное чувство безопасности. Об ошибке нельзя узнавать только в день аварии.
Минимальный набор мониторинга:
- уведомление об успехе или ошибке каждого задания;
- размер созданной копии и время выполнения;
- проверка, что копия действительно появилась во внешнем хранилище;
- оповещение, если резервирование не выполнялось дольше установленного срока;
- периодическая сверка данных;
- регулярное пробное восстановление.
В описанной подписке используются ежедневный анализ логов и Telegram-уведомления по заданиям. Но уведомление о завершении скрипта не заменяет проверку пригодности копии для восстановления.
Как проверить, что бэкап рабочий
1. Проверяйте количество объектов и размер
В отчёте должны быть указаны размер базы, количество таблиц, число файлов и время выполнения.
Если обычно дамп занимает 45 МБ, а сегодня получился файл на 300 КБ, это повод проверить результат. Причиной может быть ошибка подключения, пустая база или некорректное выполнение скрипта.
Сами по себе размер и количество объектов не доказывают корректность данных, но помогают быстро обнаружить очевидные отклонения.
2. Проверяйте контрольные суммы
Контрольные суммы помогают убедиться, что файл не изменился при передаче или хранении.
MD5 может использоваться для обнаружения случайного повреждения, но для новых систем разумнее применять SHA-256. При этом совпадение хешей подтверждает совпадение содержимого файлов, а не корректность самой базы данных или пригодность сайта к запуску.
Если нужно защититься от умышленной подмены, эталонная контрольная сумма должна быть защищена отдельно. Хранить её рядом с копией под теми же правами недостаточно: злоумышленник может заменить и файл, и его хеш.
3. Проводите пробное восстановление
Для критичных сайтов полезно ориентироваться на квартальный тест восстановления. В зависимости от требований бизнеса тестировать процедуру можно чаще.
Базовая последовательность:
- Подготовить отдельный стенд.
- Получить резервную копию и проверить её целостность.
- Развернуть необходимые файлы сайта.
- Восстановить базу данных.
- Настроить окружение и конфигурации.
- Проверить вход в административную панель, открытие страниц, работу форм и оформление тестового заказа.
- Зафиксировать результат, время восстановления и найденные проблемы.
Не проверяйте процедуру впервые на рабочем сайте во время аварии. Контрольные суммы не заменяют пробное восстановление: файл может быть целым, но содержать неполные данные или не подходить для используемой версии приложения.
4. Сверяйте копию с рабочими данными с учётом времени
L3-отчёт может сравнивать количество заказов, товаров, пользователей и другие показатели.
Но сравнение должно учитывать время создания копии. Если база была сохранена вчера, а сверка выполняется сегодня, новые заказы на рабочем сайте закономерно не попадут в резервную копию.
Расхождение становится поводом для расследования, когда оно превышает ожидаемую разницу между моментом резервирования и моментом проверки либо не объясняется нормальной работой сайта.
Когда схема не сработает
Даже организованное резервирование не устраняет все риски.
Все копии находятся на одной площадке. Пожар или крупная авария могут сделать недоступными и оригинал, и резервы.
Копии никогда не восстанавливали. Файлы могут быть повреждены, дамп — неполным, а процедура развёртывания — зависеть от неизвестных настроек.
Нет мониторинга. Скрипт мог перестать работать месяц назад, а владелец узнает об этом только при аварии.
Потеряны доступы и ключи. Зашифрованная копия без ключа или рабочая база без необходимых доступов могут оказаться бесполезными.
Есть ротация, но нет неизменяемости. Десять копий не спасут, если злоумышленник может удалить все десять. Для этого нужен отдельный изолированный или неизменяемый слой.
На сервере остались открытые дампы. Временный файл в публичном каталоге может раскрыть данные посетителям сайта. Временные файлы нужно создавать вне webroot, защищать правами доступа и удалять после завершения операции.
Итог
Резервное копирование — это не просто файл, который иногда появляется на сервере. Это система, которая должна создавать копии, сохранять их независимо от оригинала, обнаруживать ошибки и позволять восстановить рабочий сайт.
Для начала достаточно трёх действий: вынести копию за пределы основного хостинга, настроить контроль успешности резервирования и хотя бы периодически проверять восстановление. Затем можно добавить неизменяемый слой и автоматизировать дополнительные проверки.
Не обязательно сразу строить сложную инфраструктуру. Важно понимать, какие сценарии уже закрыты, какие остаются риском и сколько времени займёт восстановление, когда оно действительно понадобится.
Настрою бэкапы, которые переживут и пожар, и хостера
Аудит текущих копий, схема 3-2-1 под ваш сайт, автоматика с уведомлениями и проверкой восстановления. Веду подписки как в кейсе из статьи — копии видите вы, а не только я.
