Резервное копирование сайта: как настроить резервное копирование и восстановление в 2026 году

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

Короткий ответ

Для большинства бизнес-сайтов стоит настроить автоматические ежедневные копии файлов и базы, хранить одну копию вне основного сервера и отслеживать ошибки. Для интернет-магазина или сервиса с частыми заказами база может копироваться каждые 15–60 минут. Частоту определяет не CMS, а объём новых данных, который бизнес готов потерять.

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

Что именно нужно копировать

• Файлы сайта: код, тема, плагины, изображения, документы и другие медиафайлы.
• База данных: страницы, товары, заказы, пользователи, настройки CMS и часть данных интеграций.
• Конфигурация: версия PHP, переменные окружения, правила веб-сервера, cron и кеширование.
• DNS и SSL: актуальные записи домена, порядок выпуска сертификата и доступ к регистратору.
• Почта: ящики и письма, если они работают в том же хостинг-аккаунте.
• Интеграции: ключевые настройки CRM, оплаты, доставки, аналитики и вебхуков без открытого хранения секретов.

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

RPO и RTO: две цифры до выбора сервиса

Google Cloud объясняет, что RPO — максимально допустимый период потери данных, а RTO — максимально допустимое время недоступности системы.

Если RPO магазина составляет 30 минут, ежедневной копии базы недостаточно: после сбоя можно потерять почти сутки заказов. Если RTO равно двум часам, загрузка большого архива из медленного хранилища и ручная настройка сервера могут не уложиться в цель.

Это стартовые ориентиры. Чем меньше RPO и RTO, тем сложнее и дороже инфраструктура.

Как работает правило 3-2-1 для сайта

Первая копия — рабочий сайт. Вторая — автоматический бэкап в хранилище хостинга. Третья — зашифрованная копия в независимом облачном хранилище или на другом сервере.

Внешняя копия не должна зависеть от того же аккаунта и диска. Если сайт и все архивы лежат на одном сервере, один сбой, удаление аккаунта или компрометация доступа могут затронуть всё. CISA также советует иметь защищённые офлайн-копии и регулярно проверять восстановление в руководстве по противодействию ransomware.

Политика хранения

Один последний архив не защищает от ошибки, замеченной через неделю. Базовая ротация:

• 7 ежедневных копий;
• 4–5 еженедельных;
• 6–12 ежемесячных для важных проектов;
• отдельная копия перед обновлением CMS, модуля, дизайна или крупным импортом.

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

Тестовое восстановление проверяет не только архив, но и работу сайта и интеграций.

Что нужно автоматизировать

1. Создание копий файлов и базы с заданной частотой.
2. Шифрование при хранении и передаче.
3. Отправку копии в независимое хранилище.
4. Проверку завершения, размера архива и контрольной суммы.
5. Удаление устаревших копий по политике ротации.
6. Уведомление ответственного об ошибке.

Нужен также контроль отсутствия результата: если задание вообще не запустилось, система должна подать сигнал.

Почему бэкап хостинга не снимает ответственность с владельца

У провайдера нужно письменно уточнить:

• что копируется: файлы, база, почта или весь аккаунт;
• какова частота и срок хранения;
• находится ли копия на другой площадке;
• кто запускает восстановление и сколько оно занимает;
• есть ли дополнительная плата;
• что происходит после блокировки или закрытия аккаунта.

При выборе хостинга проверяйте всю политику, а не только слово backup. Независимая копия сохраняет возможность восстановиться после конфликта доступов или переноса сайта на другой хостинг.

Как правильно тестировать восстановление

Архив считается рабочим только после успешного восстановления. NIST включает тестирование в полный цикл планирования непрерывности, а Google Cloud рекомендует проверять данные и весь стек приложения.

Проводите тест на изолированном техническом домене или staging-среде.

1. Выберите копию и зафиксируйте время начала.
2. Разверните файлы, базу и конфигурацию.
3. Проверьте страницы, вход, поиск и мобильную версию.
4. Для магазина оформите тестовый заказ, проверьте корзину, оплату, письма, склад и CRM.
5. Проверьте формы, вебхуки, cron и аналитику.
6. Просмотрите журналы ошибок и измерьте время восстановления.
7. Запишите результат, проблемы, ответственного и изменения инструкции.

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

Типичные ошибки

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

План настройки за один рабочий день

Шаг 1. Инвентаризация

Зафиксируйте CMS, объём файлов и базы, частоту заказов, интеграции, ответственных и существующие копии.

Шаг 2. Цели восстановления

Согласуйте RPO и RTO. Не требуйте «ноль потерь и ноль минут» без оценки стоимости.

Шаг 3. Два независимых маршрута

Оставьте копии хостинга и добавьте внешнее хранилище с отдельным доступом. Включите шифрование и MFA.

Шаг 4. Мониторинг и ответственность

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

Шаг 5. Контрольное восстановление

Разверните копию на staging, пройдите чек-лист и сравните фактическое время с RTO.

Чек-лист владельца сайта

• Копируются ли файлы, база и конфигурация?
• Есть ли копия вне основного сервера и аккаунта?
• Какие RPO и RTO установлены?
• Сколько версий хранится?
• Кто получает уведомления об ошибках?
• Когда проводилось полное тестовое восстановление?
• Проверялись ли формы, корзина, оплата, почта, CRM и cron?
• Защищено ли хранилище шифрованием, уникальным паролем и MFA?
• Есть ли актуальная инструкция и резервный ответственный?

Вывод

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

BB STUDIO может проверить текущую схему, настроить независимые копии и провести контрольное восстановление. Узнайте больше о хостинге с ежедневными бэкапами или напишите нам.