Резервное копирование сайта: как настроить резервное копирование и восстановление в 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	Практический график
Редко изменяемый лендинг	24 часа	4–8 часов	Ежедневно и перед изменениями
Корпоративный сайт или блог	12–24 часа	2–4 часа	Ежедневно, недельные копии хранятся дольше
Интернет-магазин	15–60 минут для БД	1–2 часа	Частые копии БД, ежедневные файлы, копия перед обновлением
Онлайн-сервис или личный кабинет	По бизнес-требованию, иногда минуты	По SLA	Репликация, журналы транзакций и отдельный DR-план

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зона ответственности	Хостинг-провайдер	Владелец сайта или техническая команда
Серверная платформа	Поддерживает инфраструктуру по условиям тарифа	Проверяет соответствие тарифа RPO/RTO
Копии провайдера	Создаёт и хранит по своей политике	Проверяет частоту, сроки и доступность восстановления
Независимая внешняя копия	Может не предоставлять	Настраивает отдельно и защищает доступ
Сайт после восстановления	Обычно отвечает только за сервер	Проверяет CMS, формы, оплату, CRM и интеграции
План и тест восстановления	Предоставляет инструменты или поддержку	Назначает ответственных, проводит тест и фиксирует результат

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

Архив считается рабочим только после успешного восстановления. 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 может проверить текущую схему, настроить независимые копии и провести контрольное восстановление. Узнайте больше о хостинге с ежедневными бэкапами или напишите нам.

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

Как часто делать резервную копию сайта?

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

Достаточно ли бэкапов хостинга?

Это хороший первый уровень, но не единственная копия. Храните ещё одну версию в независимом хранилище и проверьте условия провайдера.

Нужна ли копия перед обновлением WordPress?

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

Чем backup отличается от snapshot?

Snapshot быстро фиксирует состояние диска или сервера. Если он хранится в той же инфраструктуре, то не заменяет независимый offsite-бэкап.

Как понять, что копия работает?

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

---

Подготовлено командой BB STUDIO. Материал основан на практике хостинга, технической поддержки и восстановления бизнес-сайтов, а также на официальных рекомендациях CISA, NIST, WordPress и Google Cloud