Регламент резервного копирования сайта: что сохранять, как часто и как проверять восстановление

Что должен гарантировать регламент резервного копирования сайта

Рабочий регламент отвечает на четыре вопроса: какие данные копируются, с какой частотой создаются резервные копии, где они хранятся и как команда доказывает возможность восстановления. Успешное завершение задания сообщает только о результате конкретного процесса. Оно не подтверждает целостность архива, наличие всех частей набора, согласованность базы данных и запуск приложения после отката.

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

Ниже приведен воспроизводимый шаблон регламента. Он связывает частоту копирования с RPO и RTO, показывает правила хранения резервных копий, объясняет разницу между проверкой архива и запуском восстановленного сайта. В конце есть чек-лист, который можно перенести в эксплуатационную документацию.

Почему созданный файл не равен рабочей резервной копии

Архив может существовать на диске и при этом не подходить для аварийного восстановления. Причины типовые:

• архив поврежден из-за ошибки диска, прерванной передачи или нехватки места;
• в инкрементальной цепочке отсутствует одна из зависимых частей;
• дамп базы завершился с ошибкой или снят в неконсистентном состоянии;
• резервное хранилище недоступно в момент аварии;
• у учетной записи восстановления нет нужных прав;
• в копии отсутствуют секреты, сертификаты, volumes или конфигурации;
• версии CMS, СУБД, runtime и расширений не совместимы с сохраненными данными.

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

RPO и RTO как основа регламента

RPO, Recovery Point Objective, показывает максимально допустимую потерю новых данных. При RPO 1 час сайт должен позволять вернуться к состоянию, которое было создано не более часа назад. RTO, Recovery Time Objective, задает допустимое время восстановления сервиса после сбоя, включая подготовку среды, загрузку данных, проверку и переключение трафика.

Для интернет-магазина с постоянными заказами разумный ориентир может выглядеть так: дамп базы каждые 15 минут, RPO не более 15 минут, RTO 2 часа. Для корпоративного сайта с публикациями раз в день подойдет ежедневная копия базы, RPO 24 часа и RTO 8 часов. Для редко обновляемого проекта можно создавать полный набор раз в неделю, если потеря изменений за неделю приемлема.

Эти значения нужно согласовать с владельцем сервиса. Частое копирование увеличивает нагрузку на CPU, диск, сеть и хранилище. Малое RTO требует заранее подготовленной среды, понятной процедуры и измеренного времени восстановления.

Что сохранять при резервном копировании сайта

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

Файлы приложения и пользовательские загрузки

В файловую копию обычно входят исходный код, темы, плагины, шаблоны, локальные конфигурации и каталоги с пользовательскими материалами. Для CMS отдельно проверьте media, uploads, документы, изображения и файлы, которые пользователи отправляют через личный кабинет.

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

База данных и состояние приложения

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

Логический дамп удобно импортировать в тестовый экземпляр СУБД, просматривать таблицы и переносить между средами. Снапшот быстрее создает точку возврата, но зависит от согласованности файлов и поддержки конкретной СУБД. Для активной базы проверьте, как инструмент фиксирует транзакции и что происходит с записью во время копирования.

Храните бинарные и логические копии раздельно, если это соответствует вашей схеме восстановления. Дамп проверяйте импортом в изолированную СУБД. Одного успешного завершения экспорта мало.

Конфигурация, секреты и инфраструктурные зависимости

В состав регламента включите конфигурации Nginx или Apache, параметры PHP и других runtime, файлы systemd, cron, firewall, reverse proxy, DNS-зоны, TLS-сертификаты, список пакетов, версии образов и переменные окружения. Для контейнеров сохраняйте compose-манифесты, bind mounts, volumes и правила запуска.

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

Как составить расписание резервного копирования для сервера

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

Частота копирования файлов и базы данных

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

Пример для малонагруженного блога: база и uploads ежедневно, полный набор еженедельно, месячный архив 12 месяцев. Пример для корпоративного сайта: база каждые 4 часа, uploads ежедневно, полный набор раз в неделю, месячные точки 12 месяцев. Пример для сайта с постоянными заказами: база каждые 15 минут или через журнал транзакций, uploads каждый час, полный набор еженедельно, отдельная offsite-копия.

Окно backup согласуйте с периодом низкой нагрузки. Контролируйте продолжительность задания, объем прочитанных данных, задержку базы, загрузку диска и скорость отправки в удаленное хранилище. Если копирование пересекается с пиковыми операциями, измените расписание или используйте технологию, которая поддерживает согласованные снимки.

Полные, инкрементальные и дифференциальные копии

Полная копия содержит выбранный набор целиком. Восстановление проще: нужен один комплект. Цена, время создания и объем хранения выше.

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

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

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

Пример расписания для типового сайта

Ниже приведен базовый график для сайта на VPS с CMS, СУБД и пользовательскими файлами. Он требует адаптации под реальный объем, интенсивность изменений и доступный бюджет.

Раз в месяц пересматривайте фактический RPO и RTO. Сравнивайте целевые значения с результатом последнего теста, а не с расчетом на бумаге.

Хранение резервных копий: правила и схема 3-2-1

Правило 3-2-1 означает три экземпляра данных, два разных типа носителей или хранения и одну копию вне основной площадки. Практический вариант для сайта: рабочие данные на сервере, локальная копия на отдельном хранилище, удаленная копия в другой инфраструктуре. Если резервный NAS стоит в той же серверной, пожар, затопление, ошибка электропитания или компрометация сети могут затронуть обе системы.

Локальная, удаленная и облачная копия

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

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

Объектное хранилище или удаленный сервер добавляет независимость от основной площадки. Нужно учесть задержку, стоимость трафика, лимиты API, ключи доступа и процедуру извлечения данных при недоступности панели управления. Облачную инфраструктуру для размещения VPS, базы или отдельного сервера можно подобрать, например, в Timeweb Cloud, но само размещение не заменяет настроенный backup и проверку восстановления.

Ротация и сроки хранения

Retention policy должна отвечать на вопрос, к какой дате команда сможет вернуться. Один из рабочих вариантов: ежедневные точки хранить 14 дней, недельные 12 недель, месячные 12 месяцев. Для аудита, юридических требований или редких повреждений данных сроки меняются после согласования с владельцем информации.

Автоматическое удаление копий запускайте только после проверки возраста, типа, полноты и наличия более свежей независимой точки. Удаление журналируйте. Защитите минимальный набор копий от одновременного удаления ошибочной командой или скомпрометированной учетной записью.

Снапшоты не должны бесконечно заменять резервные копии. Они часто живут в том же пуле хранения и исчезают вместе с ним. Используйте их как быстрый механизм отката, а независимые копии храните отдельно.

Защита backup от удаления и шифровальщика

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

Применяйте шифрование при передаче и хранении. Настройте MFA для панели управления, immutable или WORM-хранение для критичных точек, сетевую сегментацию и отдельный журнал аудита. Регулярно проверяйте, что ключ шифрования доступен уполномоченному сотруднику и что расшифровка проходит в тестовой среде.

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

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

Проверка восстановления резервной копии состоит из двух уровней. Техническая верификация контролирует сам архив: контрольные суммы, структуру, комплектность и возможность извлечения. Практическое восстановление запускает данные в изолированной среде и проверяет работу сайта.

Техническая верификация архива

Встроенная функция validation или integrity check может сравнить контрольные суммы, проверить структуру архива, наличие всех частей и чтение выбранных объектов. Запускайте ее после создания копии и после передачи в удаленное хранилище, если инструмент поддерживает оба этапа.

Результат сохраняйте в журнале с идентификатором набора, датой, объемом, длительностью и кодом завершения. Ошибка проверки должна создавать уведомление ответственному. Успешная верификация подтверждает техническую целостность проверенного набора, но не доказывает работу приложения после запуска.

Проверка базы данных и крупных файлов

Тест охватывает данные, которые критичны для бизнеса. Импортируйте дамп в изолированный экземпляр СУБД, проверьте кодировку, схему, количество ключевых таблиц, роли и чтение последних записей. Для крупной базы сравните контрольные показатели с исходной системой, не публикуя реальные данные наружу.

Распакуйте несколько больших файлов, откройте изображения и документы, проверьте права и имена. Выберите хотя бы один новый объект и один старый объект. Проверка самых маленьких файлов создает слабое покрытие: повреждение может затронуть редкий, крупный или последний загруженный объект.

Почему технической проверки недостаточно

Архив может корректно распаковываться, а восстановленный сайт все равно не работать. Причиной становятся несовместимая версия CMS, отсутствующий модуль PHP, неверная миграция, недоступная очередь, сломанный cron, неправильный TLS, невыданное право на volume или активная интеграция с продуктивными платежами.

Ping подтверждает сетевую доступность узла. HTTP-код подтверждает ответ веб-сервера. Ни один из этих сигналов сам по себе не доказывает подключение к базе, авторизацию, публикацию материалов, обработку загрузок и выполнение фоновых заданий.

Тестовое восстановление backup в безопасной среде

Тестовое восстановление backup выполняйте без риска для продуктивного сайта. Используйте отдельный VPS, виртуальную машину, изолированный Docker Compose-проект или выделенный тестовый сегмент сети. Реальные письма, платежные запросы, webhooks и внешние интеграции должны быть отключены или направлены в заглушки.

Пошаговый сценарий восстановления сайта

1. Выберите конкретную копию по дате и идентификатору. Проверьте ее метаданные, срок хранения, целостность и доступность ключа шифрования.
2. Зафиксируйте исходные значения RPO и целевого RTO, версии ОС, CMS, СУБД, runtime, образов и программы backup.
3. Подготовьте изолированную среду с объемом диска, CPU, памятью и сетевыми правилами, достаточными для восстановления.
4. Разверните зависимости: пакеты, runtime, контейнеры, reverse proxy, локальные сертификаты и системные каталоги.
5. Восстановите базу данных в отдельном экземпляре. Проверьте схему, кодировку, роли, индексы и последние ожидаемые записи.
6. Восстановите код, uploads, документы и volumes. Сверьте права, владельцев, символические ссылки и доступность крупных файлов.
7. Примените конфигурацию веб-сервера, фоновых процессов, cron или systemd timers. Секреты выдайте через защищенный механизм.
8. Запустите приложение без переключения продуктивного DNS. Для проверки используйте локальное имя, hosts или внутренний адрес.
9. Проверьте главную страницу, разделы, поиск, вход, публикацию, загрузку файла, чтение старых материалов и фоновые задания.
10. Измерьте время каждого этапа и общее время до рабочего состояния. Сравните результат с RTO.
11. Проверьте, что восстановленный экземпляр не отправляет реальные письма, платежи и запросы во внешние системы.
12. Удалите тестовую среду после фиксации результата или сохраните ее состояние для разбора найденных ошибок.

Что проверять после запуска восстановленного сайта

• HTTP-коды, логи приложения, веб-сервера и СУБД;
• подключение к базе и выполнение типовых запросов;
• отображение новых и старых материалов;
• загрузку, скачивание и открытие пользовательских файлов;
• вход пользователя, восстановление сессии и права доступа;
• выполнение cron, systemd timers, очередей и фоновых workers;
• работу reverse proxy, TLS и внутренних DNS-имен;
• отключение платежей, писем, webhooks и иных продуктивных интеграций;
• свежесть восстановленного набора относительно заявленного RPO;
• возможность создать backup уже восстановленного экземпляра.

В тестовой среде используйте обезличенные данные, если этого требуют внутренние правила или договоры. Не подменяйте DNS без контроля TTL и заранее подготовленного обратного переключения.

Периодичность и оформление результатов теста

Для критичного сервиса выполняйте выборочную проверку после каждого значимого backup и полный сценарий ежемесячно или с другой частотой, согласованной с RTO. Для небольшого сайта подойдет ежемесячное восстановление базы и uploads с полным тестом после обновления CMS, СУБД, структуры хранения или инструмента backup.

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

Автоматизация и контроль выполнения backup

Автоматический запуск через штатную программу, cron или systemd timer снижает число ручных действий, но сам по себе не гарантирует результат. Контролируйте код завершения, свежесть точки, длительность, объем, свободное место и доступность удаленного хранилища.

Журналы, уведомления и контроль свежести копии

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

• задание не запустилось или завершилось с ненулевым кодом;
• копия старше установленного максимального возраста;
• объем резко уменьшился или стал нулевым;
• задание превысило допустимую длительность;
• на локальном или удаленном хранилище недостаточно места;
• передача прервалась или объектное хранилище недоступно;
• техническая верификация завершилась ошибкой;
• нарушен срок создания отдельной offsite-копии;
• не прошел тест восстановления или контрольный импорт базы.

Полезная метрика свежести выглядит как возраст последней успешной копии, а не как число запусков cron. Проверяйте фактический объект в хранилище, его размер и возможность чтения. Отсутствие сообщения об ошибке не доказывает, что нужный набор данных сохранен.

Проверка регламента после изменений

Запускайте контрольный backup и восстановление после обновления CMS, СУБД, операционной системы, контейнерных образов, путей хранения, прав доступа, сертификатов и сетевой схемы. Документируйте версии компонентов, чтобы отделить повреждение архива от несовместимости среды.

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

Примеры регламента для CMS, Docker и VPS

CMS на VPS

Для классической CMS на VPS сохраняйте логический дамп MySQL или PostgreSQL, каталог uploads, код, настройки Nginx, параметры PHP, cron, TLS и список установленных пакетов. Ежедневно копируйте базу и пользовательские файлы, еженедельно создавайте полный набор, а удаленную копию отправляйте на независимое хранилище.

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

Конкретные команды зависят от ОС, CMS, версии СУБД и используемого инструмента. Зафиксируйте их вместе с версией пакетов и ожидаемым результатом.

Сайт в Docker Compose

Сохраняйте compose-манифесты, версии образов, шаблоны env без открытых секретов, volumes, bind mounts, reverse proxy, дампы базы и правила запуска. Копирование одного YAML-файла не возвращает данные, которые лежат в volume.

Разворачивайте отдельный проект с другим именем сети и отключенными внешними интеграциями. Проверьте миграции, подключение приложения к базе, права на volume, загрузку файлов, healthcheck и корректное завершение контейнеров. После теста удалите временные токены и журналы с чувствительными значениями.

Минимальный регламент для небольшого сайта

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

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

Для расширения схемы можно добавить резервный VPS, объектное хранилище, immutable-политику и автоматическое уведомление о возрасте последней копии. Услуга размещения сайта или сервера не заменяет эти процессы.

Чек-лист проверки восстановления резервной копии

• Определены целевые RPO и RTO.
• Перечислены код, CMS, uploads, документы и пользовательские файлы.
• Настроено резервирование базы с выбранным способом согласованного копирования.
• Сохранены конфигурации веб-сервера, runtime, firewall, reverse proxy и DNS.
• Сохранены cron, systemd timers, контейнерные манифесты и volumes.
• Описаны сертификаты, секреты, ключи шифрования и порядок доступа к ним.
• Назначено расписание для базы, файлов, конфигурации и полного набора.
• Установлены сроки хранения дневных, недельных и месячных точек.
• Есть локальная и удаленная копии на независимых типах хранения.
• Разделены учетные данные создания, чтения, удаления и восстановления.
• Настроены шифрование, MFA, журнал аудита и защита критичных точек от удаления.
• Включена техническая верификация с сохранением результата и ошибок.
• Проверяются база, крупные файлы, uploads, права и последние изменения.
• Выполняется тестовое восстановление в изолированной среде.
• После запуска проверяются приложение, авторизация, фоновые задачи и интеграции.
• Измеряется фактическое время восстановления и сравнивается с RTO.
• Мониторятся код завершения, возраст, размер, длительность и доступность хранилища.
• Назначены ответственный и резервный ответственный.
• Зафиксированы дата последнего теста, использованная копия и найденные проблемы.

Регламент считается рабочим после успешного восстановления в безопасной среде. Файл с датой и размером подтверждает существование объекта, а запись о восстановленном сайте подтверждает пригодность процедуры.

FAQ о резервном копировании и восстановлении сайта

Достаточно ли копировать файлы сайта?

Нет. Файлы не содержат записи базы, роли пользователей, заказы и часть настроек. Сохраняйте каталог приложения вместе с дампом базы, конфигурациями, uploads, volumes и зависимостями.

Как часто делать backup базы данных?

Частота зависит от RPO и скорости изменений. Для редко обновляемого сайта подойдет ежедневный дамп. Для корпоративного сайта с частыми публикациями используйте интервал в несколько часов. Для постоянных заказов может потребоваться копирование каждые 15 минут или каждый час.

Можно ли хранить все копии на одном NAS?

NAS удобен как локальная копия, но один NAS не закрывает отказ площадки, повреждение массива, ошибочное удаление и компрометацию учетных данных. Добавьте удаленную копию, раздельные права и защиту критичных точек от изменения.

Как часто выполнять тестовое восстановление?

Периодичность выбирайте по критичности сервиса. Для критичного сайта проводите регулярные выборочные проверки и полный сценарий ежемесячно либо чаще. Для небольшого проекта выполняйте тест минимум ежемесячно и после изменений CMS, СУБД, архитектуры или программы backup.

Что делать при ошибке проверки контрольной суммы?

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

Подтверждает ли ping или HTTP-ответ работоспособность восстановленного приложения?

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

Нужно ли сохранять секреты и сертификаты?

Да, если они нужны для запуска и доступа к сервису. Храните секреты зашифрованными, ограничьте ACL, раздельно управляйте ключами и заранее проверьте порядок выдачи доступа при аварии. Публичные сертификаты можно восстановить повторно, но закрытые ключи и цепочки нужно включить в защищенный план.

Как проверить совместимость копии с новой версией CMS или СУБД?

Разверните изолированную среду с целевыми версиями, импортируйте дамп, восстановите файлы и выполните миграции по документированному порядку. Проверьте ключевые пользовательские сценарии, логи, права, расширения и фоновые задания. Переключайте продуктивную систему только после отдельного плана отката.

Где найти расширенные схемы для сервера и систем хранения?

Для общей стратегии, локальных и offsite-копий, снэпшотов, репликации и расчета объема полезно изучить руководство по резервному копированию в системах хранения. Практические варианты автоматизации через BorgBackup, Rclone и rsync собраны в гайде по резервному копированию сервера.