В панели хостинга появилась отметка «копия создана». Но получится ли вернуть из неё статьи, изображения и последние заявки? Резервное копирование сайта имеет смысл, когда восстановление проверено. Команда Гуси-Лебеди объясняет, что сохранять, где хранить копии и как убедиться, что сайт вернётся к работе.
Числа ниже относятся к учебным примерам. Они помогают разобрать требования и расчёты, но не задают универсальную частоту копирования или срок восстановления.
Как часто делать копии: сначала определите RPO и RTO
RPO описывает допустимую потерю изменений во времени: насколько старой может оказаться пригодная точка восстановления. RTO задаёт целевое время возвращения сервиса к согласованной работе. Эти требования нужно подтвердить устройством системы и испытанием, а не только записать в регламенте.
Для сайта с редкими публикациями потеря правок и для магазина потеря оплаченных заказов имеют разные последствия. Разделите данные: код, тексты, загрузки, обращения, заказы. Уточните, что можно вернуть из другого подтверждённого источника и что пришлось бы собирать вручную.
| Учебное требование | Что означает | Чем проверять |
|---|---|---|
| RPO один час | Потеря более часа изменений неприемлема | Возраст пригодной точки |
| RTO два часа | Работа должна вернуться за два часа | Замер полного восстановления |
| История за несколько периодов | Нужен возврат до поздно найденной ошибки | Пригодность старых комплектов |
Расписание не равно результату. Если ежечасные задания завершались ошибкой, последняя пригодная копия может оказаться старше допустимого срока. Контролируйте создание, доставку и возможность прочитать комплект.
Частота зависит от скорости появления важных данных и требований к их потере. Копия перед обновлением полезна, но не заменяет регулярное резервирование. Для часто меняющихся данных может понадобиться механизм восстановления, предусмотренный используемой системой.
Что должно входить в резервную копию сайта
Типичный сайт с CMS хранит тексты и настройки в базе данных, изображения и документы в файлах. Копирование только каталога сайта обычно не сохраняет базу. Дамп базы без загрузок оставит ссылки на отсутствующие файлы.
Для WordPress обе части описаны в официальном руководстве по резервным копиям. Учитывайте установленную CMS, плагины, темы, загрузки и конфигурацию. Состав своего проекта проверяйте отдельно.
Для запуска могут потребоваться версии среды, зависимости, правила маршрутизации, настройки сервера и перечень внешних сервисов. Репозиторий кода не обязательно содержит текущую базу, загрузки и секреты. Сохраняйте инструкцию развёртывания и сведения о версиях.
Ключи расшифрования и аварийный доступ должны быть доступны уполномоченным людям. Архив, который невозможно открыть после отказа основной инфраструктуры, не решает задачу. Секреты храните защищённо, а не в общедоступной инструкции.
Отдельно определите, что можно воссоздать: кэш, поисковый индекс, временные файлы. Их повторная генерация тоже требует времени. Если индекс строится долго, учитывайте это в сроке возвращения поиска.
Как получить согласованный комплект базы и файлов
Во время копирования сайт продолжает меняться. В базе может появиться ссылка на файл, который ещё не попал в архив. Части, собранные в разное время без согласованного процесса, не всегда образуют пригодную точку восстановления.
Используйте штатный механизм базы и хранилища с понятными гарантиями. В зависимости от архитектуры это может быть логический дамп, согласованный снимок, журналирование изменений или ограничение записи. Обычному копированию каталога нельзя приписывать свойства транзакционного снимка.
Например, документация PostgreSQL разделяет SQL-дамп, резервирование файловой системы и непрерывное архивирование. Это разные подходы с собственными условиями. Для другой базы выбирайте её документированный способ.
Сохраняйте описание комплекта: ID точки, время, версии компонентов, список частей и контрольные суммы. Так можно понять, какие архивы относятся друг к другу. Контрольная сумма обнаруживает изменение файла, но не доказывает правильность данных внутри базы.
Не смешивайте несвязанные версии приложения и схемы данных. Если новый код ожидает новую структуру базы, старый дамп может не запуститься с ним. В сопровождении инфраструктуры и развёртывания важно закрепить воспроизводимый комплект и порядок запуска.
Где хранить копии и чем они отличаются от репликации
Копия на том же сервере удобна для отката, но может исчезнуть вместе с ним или стать недоступной при потере аккаунта. Продумайте независимость хранения, доступы и получение архива во время аварии. Не ограничивайтесь второй папкой рядом с первой.
Репликация поддерживает актуальную копию данных, но способна передать случайное удаление или повреждение. Репозиторий сохраняет код. Снимок виртуальной машины может зависеть от исходной платформы. Ни один механизм автоматически не заменяет проверяемую историю восстановления.
Выберите глубину хранения с учётом поздно обнаруженных проблем. Свежая копия может уже содержать ошибку. Если план предусматривает старую точку, проверяйте её пригодность, а не только последний архив.
Ограничьте полномочия на удаление и изменение копий. Где это требуется и поддерживается инструментом, используйте защищённое от изменения хранение или изоляцию. Проверяйте выбранную защиту и порядок обслуживания архива. Название функции не подтверждает настройку.
В руководстве AWS по аварийному восстановлению сравниваются разные стратегии. Выбирайте подход под требования и ресурсы. Не переносите чужие сроки как гарантию своего проекта.
Как проверить восстановление на отдельной среде
Получите выбранную копию и доступ, подготовьте отдельное окружение, восстановите файлы и базу, настройте зависимости и пройдите критичные действия. Измеряйте весь путь, включая ожидание доступа и проверку результата.
Изолируйте копию от производственных действий. Тестовый сайт не должен отправлять реальные письма, создавать платежи, заказы и webhook. Согласуйте адрес, доступ, замену интеграций и обработку тестовых данных.
| Проверка | Что подтверждает |
|---|---|
| Страницы и изображения | База и файлы согласованы |
| Вход и роли | Доступ и конфигурация работают |
| Поиск и каталог | Нужные данные и индексы доступны |
| Тестовое сохранение | Приложение записывает данные |
| Внешние действия отключены | Копия не запускает реальные операции |
| Последний восстановленный объект | Известна фактическая глубина данных |
Учебный разбор: пригодный комплект создан в 12:00, инцидент произошёл в 14:20. Возможное окно потери изменений составляет два часа двадцать минут. Требование RPO один час не выполнено, даже если расписание было ежечасным.
Доступ занял 20 минут, загрузка 35, импорт 25, подготовка окружения 30, проверка 20. Всего 130 минут. Целевой срок два часа превышен на десять минут. Это условный расчёт: окончание импорта нельзя считать окончанием восстановления.
Запишите ручные действия и неизвестные зависимости в инструкцию. Исправьте причины задержки и повторите упражнение. Если успех зависит от памяти одного специалиста, процесс трудно воспроизвести при его отсутствии.
Как действовать при сбое и принять резервирование
Определите область повреждения и сохраните сведения для расследования. Не перезаписывайте единственную текущую версию поспешным восстановлением. Выберите точку до появления проблемы, особенно если ошибка обнаружена с задержкой.
Решите, что делать с изменениями после этой точки: заявками, оплатами и документами. При наличии независимых подтверждённых источников потребуется сверка. Возврат старой базы может потерять новые операции, а повторная загрузка без правил создаст дубли.
Перед возвратом трафика проверьте критичные сценарии и данные. После переключения наблюдайте ошибки и интеграции. Связанные проверки описаны в статье о мониторинге сайта. При переносе на другую площадку учитывайте порядок миграции сайта.
- Определены допустимая потеря данных и время восстановления.
- Известны состав комплекта и глубина хранения.
- Проверены доступ к архиву и ключи.
- Выполнено восстановление на отдельной среде.
- Прочитан результат и измерено полное время.
- Назначены ответственные и подготовлена инструкция.
При техническом сопровождении сайта закрепите, что делает хостинг, что команда проекта и что владелец внешнего сервиса. Бэкап сайта не обязательно содержит CRM, почту и данные платёжной системы.
Инструкцию храните доступной вне инфраструктуры, которую придётся восстанавливать. В ней нужны расположение копий, порядок доступа, версии окружения, последовательность и проверки. Резервирование принято, когда команда смогла вернуть согласованный результат и повторить процесс по инструкции.