Резервные копии сайта и сервера: что и как часто проверять
Как определить состав копии, частоту, глубину хранения и тест восстановления, чтобы архив действительно помог при удалении данных или аварии.
Зеленый статус задания резервного копирования не гарантирует восстановление. Архив может быть пустым, база — поврежденной, ключ шифрования — потерянным, а единственная копия — лежать на том же сервере. Надежность подтверждает только понятная процедура и контрольный тест.
Определите допустимую потерю данных
Сначала ответьте на два вопроса:
- сколько данных допустимо потерять;
- за какое время сервис должен вернуться в работу.
Для редко обновляемого сайта может быть достаточно суточной копии. Для магазина или кабинета с постоянными операциями потеря суток неприемлема. Частота зависит от скорости изменения данных, а не от размера компании.
Что входит в резервную копию
Для сайта обычно нужны разные компоненты:
- база данных;
- пользовательские файлы;
- исходный код или стабильный репозиторий;
- конфигурация веб-сервера;
- список переменных окружения и место хранения секретов;
- задания расписания;
- сертификаты, если их нельзя быстро выпустить заново;
- правила DNS и внешние зависимости;
- версии runtime и системных пакетов.
Не всегда нужно архивировать весь сервер. Важно иметь достаточно данных и инструкций, чтобы воспроизвести окружение.
Согласованность файлов и базы
Если база копируется в один момент, а загруженные файлы — через несколько часов, восстановленный сайт может ссылаться на отсутствующие изображения или документы. Для активных систем используют согласованный снимок, короткую блокировку записи или журнал изменений.
После копирования база проверяется на читаемость, а архив — на целостность. Размер файла сравнивают с ожидаемым диапазоном: резкое уменьшение часто указывает на ошибку.
Правило независимого хранения
Копия на том же диске защищает от случайного удаления файла, но не от отказа диска, компрометации сервера или ошибки провайдера. Как минимум одна версия должна находиться в независимом хранилище с отдельными учетными данными.
Полезная схема:
- рабочие данные;
- быстрая локальная копия для короткого отката;
- удаленная копия в другом контуре;
- периодическая долгосрочная версия.
Доступ сервера к хранилищу лучше ограничить записью новых копий без возможности незаметно удалить всю историю.
Глубина хранения
Одна последняя копия не помогает, если повреждение обнаружили через неделю. Нужна история: несколько ежедневных, недельных и месячных точек. Конкретная глубина зависит от объема и требований бизнеса.
Также учитывайте тихие ошибки: зараженный файл, некорректный импорт или удаление записей могут попасть в новые архивы. Более старая версия остается единственным чистым источником.
Шифрование и доступы
Резервная копия содержит те же данные, что production, поэтому требует не меньшей защиты. Шифруйте передачу и хранение, ограничивайте пользователей, включайте журнал доступа.
Ключ восстановления нельзя хранить только внутри резервируемого сервера. Но и бесконтрольная пересылка ключа сотрудникам создает риск. Компания должна знать, где он хранится и кто имеет право использовать.
Автоматическая проверка
После каждого задания контролируют:
- факт завершения;
- размер архива;
- контрольную сумму;
- наличие базы и файлов;
- возраст последней успешной копии;
- свободное место;
- доставку в удаленное хранилище.
Уведомление нужно не только об ошибке задания, но и об отсутствии свежей копии. Иногда расписание перестает запускаться, и формальной ошибки нет.
Тест восстановления
Восстановление проводят в изолированном окружении, не поверх production. Фиксируют время и все ручные шаги.
Порядок проверки:
- Подготовить чистое окружение.
- Получить архив и ключи.
- Восстановить базу и файлы.
- Поднять приложение нужной версии.
- Проверить главную и административную часть.
- Выполнить критичный сценарий без отправки реальных уведомлений.
- Сверить дату и ключевые данные.
- Записать найденные пробелы в инструкцию.
После серьезного изменения инфраструктуры тест повторяют, даже если старый сценарий восстановления когда-то работал.
Отдельная копия перед релизом
Плановый архив не заменяет контрольную точку перед обновлением, миграцией или массовым импортом. Перед рискованной операцией создают согласованную копию и проверяют способ возврата.
Для изменения базы важно понимать, совместим ли старый код с новой схемой. Иногда откат приложения без отката данных невозможен.
Кто отвечает за восстановление
В регламенте должны быть владелец решения, технический исполнитель, место доступа к копиям и канал связи. Во время аварии некогда выяснять, на чьей почте зарегистрировано хранилище.
Общий порядок реакции стоит связать с аварийным регламентом сайта и сервера, а инфраструктурные риски — с аудитом Linux-сервера.
Страница поддержки серверов и VPS/VDS включает резервирование в общий контур доменов, SSL, окружения и восстановления.
Частые вопросы
Как часто делать резервную копию?
Не реже, чем допустимая потеря данных. Если за час создается много заказов, суточная копия базы недостаточна. Статичные файлы можно сохранять реже, чем активно меняющуюся базу.
Можно ли доверять копии провайдера?
Она полезна, но нужно знать состав, глубину, условия доступа и срок восстановления. Для критичных данных желательно иметь независимую копию, контролируемую компанией.
Нужно ли копировать код, если есть репозиторий?
Репозиторий должен содержать воспроизводимую рабочую версию. Если на сервере есть ручные изменения, сначала их выявляют. Пользовательские файлы и секреты в репозиторий не помещают.
Как проверить копию без риска для сайта?
Восстановить ее на отдельном сервере или изолированном окружении с отключенными реальными интеграциями и уведомлениями. Production при этом не изменяется.
