Резервная копия нужна не для отчёта и не «на всякий случай». Она нужна, чтобы после ошибки сотрудника, неудачного обновления, взлома, сбоя диска или недоступности площадки вернуть сайт в рабочее состояние за согласованное время. Поэтому правильно организованное резервное копирование — это не один архив на сервере, а понятный процесс: что копируем, как часто, где храним, кто получает уведомления и когда проверяем восстановление.
Главный практический критерий простой: если копию ни разу не пытались развернуть, нельзя считать, что восстановление гарантировано. Архив может оказаться неполным, база — повреждённой, а инструкция — устаревшей.
Содержание:
Что именно нужно копировать
Для восстановления большинства сайтов нужны как минимум две связанные части: файлы проекта и база данных. В файлах находятся код, тема, плагины, загруженные документы и изображения. В базе — страницы, настройки, пользователи, заказы, статусы, связи каталога и другие динамические данные.
Отдельно фиксируют конфигурацию окружения: версию PHP, список расширений, правила веб-сервера, задания cron, параметры очередей, адреса внешних сервисов и способ выпуска SSL-сертификата. Секреты и ключи нельзя бездумно складывать в общий архив: для них нужны ограниченный доступ, шифрование и отдельная инструкция восстановления.
| Объект | Зачем нужен | Типичная ошибка |
|---|---|---|
| Файлы приложения | Код, шаблоны, плагины, загрузки | Копируют только папку с изображениями и теряют конфигурацию |
| База данных | Контент, заказы, пользователи, настройки | Делают дамп реже, чем меняются данные |
| Конфигурация сервера | Позволяет воспроизвести окружение | Никто не помнит версии и нестандартные правила |
| Интеграции и cron | Возвращают обмены и фоновые процессы | Сайт открывается, но заказы и обмены не работают |
| Документация | Сокращает время восстановления | Инструкция хранится только на недоступном сервере |
Как определить допустимую потерю данных и время восстановления
RPO показывает, сколько данных бизнес допускает потерять. Если RPO равен одному часу, копирование и журналы должны позволить вернуться к состоянию не старше часа. RTO показывает, за какое время сайт требуется восстановить после инцидента.
Эти параметры нельзя назначать только технически: их определяет стоимость простоя и потери операций. Для небольшого контентного сайта вчерашняя копия может быть приемлема. Для магазина, который получает заказ каждые несколько минут, суточная копия означает реальную потерю продаж.
| Сценарий | Стартовый ориентир RPO | Как часто копировать | Стартовый ориентир RTO |
|---|---|---|---|
| Корпоративный сайт с редкими изменениями | До 24 часов | Полная копия ежедневно и перед релизом | Несколько часов |
| Сайт с активными рекламными кампаниями | 1–4 часа для заявок | Файлы ежедневно, база и данные форм — чаще | 1–2 часа |
| Интернет-магазин | 15–60 минут для заказов | Ежедневная полная копия плюс частые инкременты или журналы | По согласованному SLA |
| Интегрированный B2B-проект | Минуты или часы по критичности операций | Репликация, журналы и копии по архитектуре | Определяется планом аварийного восстановления |
Это не универсальные нормативы, а отправная точка для обсуждения. Финальные значения зависят от количества операций, договорённостей с клиентами и стоимости инфраструктуры.
Какие виды резервных копий использовать
Полная копия содержит весь выбранный набор данных. Её проще понимать и переносить, но она требует больше времени и места. Инкрементная хранит изменения после предыдущей копии и экономит ресурсы, но цепочка восстановления становится сложнее. Дифференциальная сохраняет изменения после последней полной копии.
Для базы данных дополнительно используют журналы транзакций и восстановление на выбранный момент времени — point-in-time recovery. Это особенно полезно, когда нужно вернуться к минуте перед ошибочным импортом или удалением данных. Конкретная технология зависит от СУБД и схемы репликации.
Снимок виртуальной машины удобен перед обновлением или переносом, однако не должен быть единственной защитой. Снимок может находиться на той же инфраструктуре, что и рабочий сервер, и исчезнуть вместе с ней. Кроме того, без корректной фиксации базы он не всегда гарантирует согласованность данных.
Где хранить резервные копии
Минимальная разумная схема строится по принципу 3–2–1: несколько экземпляров данных, разные типы или независимые места хранения и хотя бы одна копия вне основной площадки. Практический смысл принципа важнее буквального подсчёта: авария рабочего сервера не должна уничтожить и сайт, и его резервные копии.
- оперативная копия для быстрого восстановления рядом с рабочей средой;
- независимая копия в другом аккаунте, облаке или дата-центре;
- архивные версии с более долгим сроком хранения;
- ручная контрольная копия перед крупным обновлением, импортом или релизом.
Доступ к хранилищу резервных копий отделяют от административного доступа к сайту. Если один скомпрометированный аккаунт позволяет удалить рабочий сервер и все архивы, схема не защищает от целевой атаки.
Практическое расписание резервного копирования
| Период | Что сохранять | Пример хранения |
|---|---|---|
| Каждые 15–60 минут | Изменения критичной базы или журналы | От нескольких часов до нескольких суток |
| Ежедневно | База и изменённые файлы | 7–14 дневных версий |
| Еженедельно | Полная согласованная копия | 4–8 недельных версий |
| Ежемесячно | Контрольный архив | 6–12 месячных версий |
| Перед изменениями | Файлы, база и текущая конфигурация | До подтверждения стабильности релиза |
Глубину хранения рассчитывают с учётом «тихих» ошибок. Если повреждение каталога обнаруживается через две недели, семь дневных копий уже не помогут. Одновременно бессмысленно годами хранить каждую почасовую версию: это увеличивает стоимость и объём чувствительных данных.
Как защитить сами резервные копии
Архивы часто содержат персональные данные, сведения о заказах, конфигурацию и другие чувствительные данные. Поэтому их шифруют при передаче и хранении, ограничивают роли, ведут журнал доступа и регулярно меняют ключи согласно внутренней политике.
- использовать отдельную учётную запись с минимальными правами;
- не хранить пароли и ключи рядом с незашифрованным архивом;
- включить защиту от немедленного удаления или неизменяемое хранение, если это оправдано рисками;
- удалять просроченные копии по утверждённому сроку хранения;
- контролировать требования к персональным данным и местам их хранения.
Автоматизация, уведомления и тест восстановления
Задача резервного копирования должна завершаться измеримым результатом. Система мониторинга проверяет статус, длительность, размер архива, наличие базы и факт передачи во внешнее хранилище. Резкое уменьшение дампа или нулевой архив — такой же повод для тревоги, как сообщение об ошибке.
Уведомление «копия создана» ещё не доказывает, что сайт можно вернуть. На тестовом контуре периодически разворачивают выбранную версию, запускают сайт, проверяют авторизацию, несколько страниц, изображения, формы, заказы и фоновые задачи. Время такого упражнения сравнивают с RTO.
Для небольшого корпоративного сайта тест можно проводить, например, ежеквартально и после изменения схемы. Для магазина или B2B-системы с жёстким SLA проверки нужны чаще. Частоту утверждают в плане восстановления, а результат фиксируют.
Какая копия помогает в разных авариях
| Событие | Что потребуется | Что проверить после восстановления |
|---|---|---|
| Ошибочное удаление страницы или товара | Недавняя версия базы | Связи, URL, изображения и индексацию |
| Неудачное обновление CMS | Предрелизная копия файлов и базы | Совместимость, формы, личный кабинет |
| Вредоносное изменение | Чистая копия до заражения и журнал событий | Закрытие уязвимости и смену доступов |
| Сбой хостинга или дата-центра | Копия на независимой площадке и описание окружения | DNS, SSL, почту, cron и интеграции |
| Ошибочный обмен с 1С или CRM | Восстановление базы на момент до обмена | Заказы, остатки, статусы и повторный запуск обмена |
В случае взлома недостаточно просто вернуть архив. Если не найти точку входа, восстановленный сайт снова будет заражён. Сначала изолируют инцидент, сохраняют данные для анализа, закрывают уязвимость и только затем возвращают проверенную версию.
Кто отвечает за резервное копирование
Фраза «хостинг делает бэкапы» не заменяет распределение ответственности. Провайдер отвечает только за заявленный сервис и его срок хранения. Разработчик знает состав проекта. Администратор контролирует задания, хранилище и восстановление. Владелец бизнеса определяет допустимый простой и потерю данных.
В рабочем регламенте фиксируют владельца процесса, расписание, места хранения, получателей уведомлений, порядок запроса копии, инструкцию развёртывания и контакты на случай аварии. Полезно отдельно указать, кто имеет право принять решение об откате, потому что восстановление старой версии само по себе может перезаписать новые данные.
Официальная документация WordPress по резервным копиям также разделяет копирование базы и файлов. Для проектов на MySQL варианты полного, инкрементного и точечного восстановления описаны в документации MySQL.
Частые вопросы
Достаточно ли резервных копий, которые делает хостинг?
Они полезны как первый уровень защиты, но критичному проекту нужна независимая копия вне основной площадки. Нужно заранее проверить периодичность, срок хранения, способ восстановления и то, входит ли база данных в архив.
Что важнее копировать: файлы или базу данных?
Нужны обе части. Без файлов не будет кода и загрузок, без базы — контента, настроек, пользователей и заказов. Для восстановления они должны соответствовать друг другу по времени.
Как часто делать резервную копию сайта?
Частота зависит от допустимой потери данных. Контентному сайту часто достаточно ежедневной копии, а магазину может потребоваться сохранение базы каждые 15–60 минут или восстановление по журналам.
Можно ли хранить копии на том же сервере?
Можно держать там оперативную версию для быстрого отката, но не единственную. Сбой диска, блокировка аккаунта или взлом могут одновременно затронуть и сайт, и локальные архивы.
Сколько времени хранить резервные копии?
Нужна комбинация дневных, недельных и месячных версий. Конкретный срок зависит от того, как быстро обнаруживаются ошибки, сколько места занимают данные и какие требования действуют для проекта.
Как понять, что резервная копия рабочая?
Развернуть её в изолированной среде и пройти контрольный сценарий: открыть страницы, проверить медиа, авторизацию, формы, заказы, cron и интеграции. Только успешное тестовое восстановление подтверждает пригодность копии.
Нужно настроить резервное копирование и проверить восстановление?
German Web может провести техническую диагностику, определить критичные данные, предложить RPO/RTO, настроить расписание и проверить восстановление на тестовой среде. Работа разработчика рассчитывается по ставке 2 300 ₽ в час, а объём и архитектура согласуются после изучения проекта.
