Настройка резервного копирования нужна не для того, чтобы где-то существовал файл backup.zip, а чтобы сайт, база данных и критичные данные действительно можно было восстановить после сбоя, ошибки, повреждения или удаления.
Настраиваем резервное копирование сайтов, баз данных и серверного контура как управляемую систему: определяем, что нужно сохранять, как часто создавать копии, сколько их хранить, где размещать и за какое время проект должен восстанавливаться.
Рабочая схема выглядит так:
Данные -> Backup -> Независимое хранение -> Контроль -> Test Restore -> Восстановление
Когда нужна настройка резервного копирования
- На сайте хранятся заявки, заказы, пользователи или другие бизнес-данные.
- Работает интернет-магазин, личный кабинет или веб-сервис.
- Данные в базе изменяются постоянно.
- Проводятся обновления CMS, приложения или сервера.
- Нужна гарантированная точка отката перед изменениями.
- Хостинг создаёт свои копии, но неизвестны их частота и условия восстановления.
- Резервные копии хранятся на том же сервере, что и production.
- Никто не проверял, можно ли из существующих копий реально восстановить проект.
Что входит в резервное копирование
Состав backup зависит от архитектуры проекта. Копировать только файлы сайта часто недостаточно.
В резервирование могут входить:
- Файлы сайта или приложения.
- Базы данных.
- Пользовательские загрузки.
- Медиаданные.
- Конфигурация приложения.
- Настройки веб-сервера.
- Системные конфигурации.
- cron и другие планировщики.
- Данные объектных хранилищ.
- Необходимая информация для восстановления окружения.
Временные файлы, cache и другие восстанавливаемые данные обычно исключаются, чтобы не увеличивать размер и время создания копий без необходимости.
RPO: сколько данных допустимо потерять
RPO - Recovery Point Objective определяет допустимый интервал между последней рабочей копией и моментом сбоя.
Например:
- 15 минут.
- 1 час.
- 6 часов.
- 24 часа.
Для корпоративного сайта, где контент обновляется несколько раз в месяц, и интернет-магазина, где заказы появляются каждую минуту, требования к резервному копированию будут разными.
Чем меньше допустимая потеря данных, тем чаще должна создаваться или обновляться точка восстановления.
RTO: сколько времени можно восстанавливаться
RTO - Recovery Time Objective определяет допустимое время простоя после аварии.
При расчёте учитываем не только загрузку backup, но весь процесс:
- Подготовку инфраструктуры.
- Восстановление базы данных.
- Восстановление файлов.
- Возврат конфигурации.
- Запуск сервисов.
- Проверку критичных функций.
Backup существует не сам по себе. Его задача - обеспечить требуемое восстановление проекта.
Настройка резервного копирования сайта
Для сайта определяем данные, без которых проект невозможно вернуть в рабочее состояние.
Обычно резервируем:
- Код и файлы проекта, если они не воспроизводятся из репозитория.
- Пользовательские загрузки.
- Медиатеку.
- CMS-конфигурацию.
- Критичные файлы окружения.
- Настройки, необходимые для запуска.
Определяем частоту создания копий, retention и ротацию, чтобы старые backup не заполняли хранилище бесконтрольно.
Резервное копирование базы данных
Резервное копирование базы данных требует отдельной стратегии, особенно если данные постоянно изменяются.
В зависимости от СУБД и требований используем:
- Консистентные дампы.
- Физические копии.
- snapshots.
- Репликацию как дополнительный механизм.
- PITR - Point-in-Time Recovery.
При необходимости резервируем не только пользовательские данные, но и схемы, роли, права и другие параметры, необходимые для полноценного восстановления.
PITR
Point-in-Time Recovery позволяет восстановить базу не только из последнего полного backup, а приблизить состояние к конкретному моменту времени.
Это особенно важно для проектов, где между обычными резервными копиями может появиться значительный объём новых данных.
Настройка резервного копирования серверов
Если сайт работает на VPS, VDS или собственной серверной инфраструктуре, одной копии файлов приложения может быть недостаточно.
В зависимости от задачи резервируем или документируем:
- Конфигурацию веб-сервера.
- Настройки сервисов.
- cron и systemd units.
- Контейнерную конфигурацию.
- Необходимые системные параметры.
- snapshots виртуальных машин или дисков.
При этом snapshot сервера не заменяет отдельное резервное копирование базы данных и критичных пользовательских данных.
Стратегия резервного копирования
Подбираем схему в зависимости от объёма данных, скорости их изменения, стоимости хранения и требований к восстановлению.
Могут использоваться:
- full backup - полная копия данных.
- incremental backup - изменения после предыдущей копии.
- differential backup - изменения после последнего полного backup.
- snapshots - снимки дисков, файловых систем или виртуальных машин.
- database dumps - логические копии базы данных.
Одновременно определяем:
- Частоту запуска.
- retention.
- rotation.
- Максимальное количество копий.
- Срок хранения долгосрочных backup.
Правило 3-2-1
Для критичных данных используем принцип:
- 3 копии данных.
- 2 разных типа или независимых места хранения.
- 1 копия вне основного production-контура.
Сбой основного сервера, потеря доступа к аккаунту или компрометация production не должны автоматически уничтожать все точки восстановления.
Защита резервных копий
Backup также является чувствительным набором данных и требует отдельной защиты.
Контролируем:
- Шифрование при передаче.
- Шифрование хранения, если оно требуется.
- Отдельные учётные данные.
- Минимально необходимые права.
- Изоляцию от production.
- Защиту от случайного или несанкционированного удаления.
Компрометация сайта не должна автоматически давать злоумышленнику возможность удалить резервные копии.
Мониторинг резервного копирования
Наличие настроенного задания ещё не означает, что backup действительно создаётся.
Контролируем:
- Запустилось ли задание.
- Завершилось ли оно успешно.
- Сколько времени заняло.
- Какой получился размер копии.
- Не изменился ли размер аномально.
- Не возникли ли ошибки загрузки или хранения.
При сбоях настраиваются уведомления по согласованному каналу.
Test Restore: проверяем, что backup восстанавливается
Успешный статус задания означает только то, что процесс резервного копирования завершился без известной ошибки.
Он не доказывает, что из этой копии получится восстановить рабочую систему.
Поэтому выполняем тестовое восстановление и проверяем:
- Открывается ли база данных.
- Доступны ли файлы.
- Запускается ли приложение.
- Работает ли авторизация.
- Присутствуют ли необходимые данные.
- Выполняются ли критичные пользовательские сценарии.
Backup без Test Restore - это предположение о возможности восстановления.
Runbook восстановления
После настройки фиксируем порядок действий на случай реального сбоя.
В runbook указываем:
- Где находятся копии.
- Какие доступы необходимы.
- Какую точку восстановления выбирать.
- Что восстанавливать первым.
- Как вернуть базу данных.
- Как вернуть файлы и конфигурацию.
- Как проверить результат.
- Кто принимает решение о возврате проекта в эксплуатацию.
Почему одного backup хостинга недостаточно
Резервное копирование хостинг-провайдера может быть полезной дополнительной защитой, но его параметры должны быть известны.
Нужно понимать:
- Как часто создаются копии.
- Сколько они хранятся.
- Где физически или логически находятся.
- Можно ли скачать их независимо.
- Что именно включено в backup.
- Сколько занимает восстановление.
- Проводилось ли тестовое восстановление.
Если копия сайта находится в том же аккаунте и зависит от тех же доступов, она не закрывает все сценарии отказа.
Когда настройка считается завершённой
- Определены RPO и RTO.
- Зафиксирован состав резервируемых данных.
- Настроена необходимая частота backup.
- Определены retention и rotation.
- Копии размещены в согласованной схеме хранения.
- Ограничены права доступа.
- Подключён мониторинг заданий.
- Настроены уведомления об ошибках.
- Проведён Test Restore.
- Подготовлен runbook восстановления.
Резервное копирование и аварийное восстановление - разные задачи
Эта услуга предназначена прежде всего для создания системы резервирования до аварии и регулярной проверки её работоспособности.
Если сайт уже недоступен, повреждён или взломан и требуется срочно вернуть его в эксплуатацию, используется услуга аварийного восстановления сайта.
Что нужно для настройки
Для первичной оценки нужны сведения о сайте или сервисе, используемой базе данных, размещении, объёме данных, существующих backup и допустимом времени простоя.
Если требования к RPO и RTO ещё не определены, формируем их вместе исходя из того, как часто изменяются данные и какие последствия вызывает их потеря.
Часто задаваемые вопросы (FAQ)
Сайт обслуживает другой разработчик. Вы можете отдельно настроить только резервное копирование?
Да. Настройку резервного копирования можно выделить в отдельную задачу. Главное - получить необходимые технические доступы и понять, какие данные и конфигурации участвуют в работе проекта. Менять текущего разработчика для этого не требуется.
Для настройки резервных копий нужно переносить сайт на другой хостинг?
Не обязательно. Система резервирования может быть настроена для существующего размещения. При этом сами копии желательно организовать так, чтобы отказ основного сервера или потеря доступа к нему не лишили проект одновременно и рабочих данных, и всех точек восстановления.
Настройка резервного копирования потребует остановки сайта?
Обычно длительная остановка не нужна. Конкретный способ зависит от базы данных, объёма информации и инфраструктуры. Если для первоначальной настройки или тестового восстановления потребуется отдельное техническое окно, это можно определить заранее.
Можно использовать наше существующее облачное хранилище для резервных копий?
Можно рассмотреть уже используемое хранилище, если оно подходит по доступам, объёму, надёжности и позволяет отделить резервные копии от основного production-контура. Создавать новый сервис только ради backup требуется не во всех случаях.
Копии будут находиться в нашем аккаунте или у вас?
Схему хранения лучше определить до настройки. Для бизнеса обычно важно сохранить собственный контроль над резервными данными и доступами к ним, независимо от того, кто в дальнейшем обслуживает сайт. Конкретное место хранения зависит от выбранной инфраструктуры.
Если мы потом сменим хостинг, резервное копирование придётся полностью настраивать заново?
Не обязательно полностью, но схему потребуется пересмотреть. После переезда могут измениться сервер, пути к данным, база, права доступа и способы запуска заданий. Саму стратегию хранения и требования к восстановлению при этом часто можно сохранить.
Можно восстановить только один случайно удалённый файл, не откатывая весь сайт?
Это зависит от того, как организованы резервные копии и что именно нужно вернуть. Для некоторых типов данных возможно точечное восстановление, а в других случаях безопаснее сначала развернуть копию отдельно и извлечь из неё нужную информацию, не затрагивая рабочий сайт.
Тестовое восстановление не повредит работающему сайту?
Его не следует выполнять поверх рабочего проекта без необходимости. Проверку обычно организуют так, чтобы восстановленная копия была отделена от production и можно было проверить базу, файлы и основные функции без риска перезаписать актуальные данные.
Можно настроить резервное копирование сразу для нескольких сайтов на одном сервере?
Можно. При этом для каждого проекта нужно определить собственный состав данных и зависимости. Если несколько сайтов используют общий сервер, базу, хранилище или другие компоненты, это также необходимо учитывать в общей схеме восстановления.
После настройки мы сможем передать резервное копирование своему системному администратору?
Да. Система не должна зависеть от одного исполнителя. Понятная схема хранения, доступы, настройки заданий и инструкция по восстановлению позволяют вашей технической команде дальше контролировать резервирование и использовать копии при необходимости.
