Резервная копия сайта: правило 3-2-1 и проверка

Резервная копия сайта кажется скучным делом, пока сайт не исчезнет. Достаточно приостановленного аккаунта хостинга, взлома, неудачного обновления или ошибки при удалении файлов. Тогда выясняется, есть ли копия, где она лежит и можно ли из неё хоть что-то восстановить.

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

Почему копии у того же хостинга недостаточно

Большинство хостингов делают копии автоматически, и это хорошо. Проблема в том, что они лежат у того же провайдера, часто на том же аккаунте или в том же дата-центре. Один сбой может забрать и сайт, и копию одновременно.

Типичные ситуации, в которых такая копия не поможет:

• потеря доступа к аккаунту (перехваченный пароль, неоплаченный хостинг, приостановка услуги),
• программа-вымогатель или взлом, которые шифруют или удаляют файлы, а иногда и доступные из аккаунта копии,
• ошибка провайдера, который удаляет данные или восстанавливает их с задержкой,
• собственная ошибка, замеченная через недели, когда копии того времени давно исчезли.

Копия хостинга — хорошая защита, но лишь одна из нескольких. Сколько дней копий хранит Ваш тариф, проверьте в описании предложения у своего провайдера (OVHcloud, home.pl, nazwa.pl и другие описывают это по-разному), потому что срок бывает коротким. Пример: согласно документации веб-хостинга OVHcloud на 25 октября 2026 г. файлы можно восстановить не дальше, чем с воскресенья двухнедельной давности, а сам провайдер рекомендует регулярно делать собственные копии.

Правило 3-2-1 простыми словами

Это старая, проверенная схема из информатики. Запомнить её можно одним предложением: 3 копии данных, на 2 разных носителях, из них 1 вне сервера.

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

Что должно быть в копии

Сайт — это не только файлы. Хорошая копия состоит из двух частей, и обе нужно сохранять вместе:

1. Файлы: тема, плагины, загруженные фотографии и документы, конфигурационные файлы.
2. База данных: содержимое страниц, настройки, заказы, аккаунты клиентов, сообщения из форм.

В магазине база важнее внешнего вида. Фотографии и шаблон Вы восстановите, а заказы последних недель уже нет. Поэтому в магазине базу стоит копировать часто, не реже одного раза в сутки, лучше каждую ночь.

Помните и о том, о чём обычно забывают:

• конфигурационный файл с настройками подключения к базе,
• ключи и пароли к сервисам (платежи, почта, API), которые хранятся отдельно в менеджере паролей,
• настройки домена и почты (записи DNS), которые стоит сохранить в виде снимка экрана или списка.

Как выглядит хорошая схема на практике: пример robimyweb.pl

На собственном сайте robimyweb.pl я применяю именно такую схему. Данные копируются каждую ночь на сервере, а система хранит 14 последних копий. Копия скачивается и за пределы сервера, на компьютер, который стоит у меня.

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

Ваш вариант может быть проще. Ключевых вещей три: автоматическое расписание, копия в другом месте и сигнал, когда что-то перестаёт работать.

Шаг за шагом: настройте собственную схему 3-2-1

Приведённый ниже план можно внедрить за полдня, если у Вас есть доступ к панели хостинга.

1. Проверьте, что делает хостинг. В панели найдите раздел резервных копий. Запишите, как часто они создаются и сколько их остаётся.
2. Включите автоматическую копию, если её нет. Для редко меняющегося сайта компании достаточно раза в неделю, для магазина не реже одного раза в сутки, лучше каждую ночь.
3. Добавьте копию вне сервера. Скачивайте файл с копией вручную раз в неделю или настройте автоматическую отправку в другое место (другой провайдер, сетевой диск, облако с отдельным аккаунтом).
4. Защитите доступ. Аккаунт с копиями защищайте надёжным паролем и дополнительным подтверждением входа. Копия с данными клиентов — это те же данные, что и на сайте.
5. Запишите, кто за это отвечает. Один человек и одна заметка: где лежат копии и как их восстановить.

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

Проверка восстановления: раз в квартал

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

Раз в квартал проведите пробу. Лучше всего занести её в календарь: первая неделя января, апреля, июля и октября.

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

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

Самые частые ошибки с копиями

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

При персональных данных клиентов помните, что копия тоже их содержит. GDPR (RODO) в ст. 32 называет среди мер безопасности, в частности, способность быстро восстановить доступность данных после инцидента и регулярное тестирование мер защиты. Это не юридическая консультация: правила хранения и защиты данных определите с юристом или инспектором по защите данных. Данные клиентов я могу хранить на сервере в ЕС в рамках услуги Данные клиентов в ЕС.

Что делать, если сбой уже произошёл

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

1. Смените пароли от панели хостинга, базы, почты и панели сайта.
2. Найдите последнюю чистую копию, сделанную до возникновения проблемы.
3. Восстановите её в тестовом месте и проверьте, всё ли работает.
4. Обновите программное обеспечение (систему, плагины, тему) до публикации.
5. Только после этого переключите сайт на восстановленную версию.

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

Итог

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

Если Вы хотите, чтобы я настроил копии, проверку восстановления и предупреждения, напишите мне. Техническую поддержку я оцениваю от 149 зл/мес. без НДС, а домен и хостинг с сервером в Польше или ЕС — от 390 зл/год без НДС. Можно также сначала проверить основы своего сайта в бесплатном инструменте Проверить сайт. Состояние, описанное в статье, актуально на 27 октября 2026 г.