Как проверить резервную копию интернет-магазина: RPO, RTO и тестовое восстановление
Как превратить наличие архивов в проверяемый план восстановления магазина: определить допустимую потерю данных, измерить время и провести изолированный тест.
В этой статье
Письмо «резервная копия создана» подтверждает только запуск задания. Оно не доказывает, что в архив попали база, файлы заказов, конфигурация, ключи и загрузки; что копия не повреждена; что команда знает порядок восстановления. Для интернет-магазина проверкой считается восстановленная в изоляции система и зафиксированный результат.
До теста задают две бизнес-границы. RPO определяет, сколько данных допустимо потерять по времени, а RTO — сколько может длиться восстановление сервиса. Эти цели нельзя выбрать только по размеру диска: час потери заказов и час простоя имеют разную цену для разных магазинов.
Разложите магазин на данные с разной скоростью изменения
Компонент | Как меняется | Что проверить |
|---|---|---|
База заказов и оплат | Постоянно | Точка во времени, согласованность транзакций |
Каталог и цены | Пакетно или через обмен | Связь с версией импорта и источником |
Файлы товаров | Неравномерно | Полнота объектов и права доступа |
Код и шаблоны | По релизам | Точный коммит или пакет развертывания |
Конфигурация и секреты | Редко, но критично | Безопасное отдельное хранение и способ выдачи |
Очереди и сессии | Быстро и временно | Нужно ли восстанавливать или можно пересоздать |
Один ночной архив может соответствовать RPO для изображений, но не для оплаченных заказов. Для базы понадобится более частое копирование или журнал изменений. При этом копии файлов и базы должны относиться к согласованной точке, иначе в базе останутся ссылки на объекты, которых ещё нет в архиве.
Выберите сценарий отказа, а не абстрактный «бэкап»
Тест удаления одного файла отличается от восстановления после потери виртуальной машины, ошибки обновления или компрометации учётной записи. Сценарий определяет, какие уровни независимости нужны.
Ошибка пользователя требует версий и удобного возврата отдельного объекта.
Повреждение базы требует согласованной копии, журналов и проверки целостности.
Потеря VPS требует инфраструктуры, конфигурации, сетевых настроек и данных вне самого VPS.
Компрометация требует копии, недоступной той же учётной записи на запись и удаление.
Сбой региона или площадки требует независимого места хранения и заранее описанной точки запуска.
Правило нескольких копий на разных носителях полезно как направление, но не заменяет модель угроз. Если все копии удаляются одним токеном автоматизации или шифруются тем же вредоносным процессом, географическое расстояние не спасает.
Составьте паспорт восстановления
Паспорт — короткий документ, по которому другой подготовленный специалист может начать работу. В нём указаны ответственный, расположение копий, порядок получения доступа, зависимости, контрольные суммы, последовательность запуска, ожидаемое время этапов и критерии остановки.
Секреты и реальные пароли в такой документ не вставляют. Он описывает, где и по какой процедуре получить их. Отдельно фиксируют контакт владельца платёжной интеграции, DNS и внешних сервисов: восстановленный сайт не готов, если уведомления об оплате уходят на старый адрес или повторно создают операции.
Как провести тест без риска для боевого магазина
Выберите изолированную сеть и ресурсы, не принимающие реальный трафик.
Зафиксируйте выбранную точку восстановления, время начала и состав копий.
Разверните инфраструктуру по документированной процедуре, не копируя работающие секреты без необходимости.
Восстановите базу и файлы, затем примените журналы только до выбранной точки.
Запустите магазин с отключёнными реальными платежами, рассылками, доставкой, CRM и обменом с 1С.
Проверьте целостность данных и контрольные пользовательские сценарии.
Измерьте фактическое время каждого этапа и сравните с RTO.
Удалите тестовые данные по правилам компании и оформите найденные проблемы.
Изоляция обязательна: копия сайта может начать отправлять письма, списывать остатки, подтверждать старые задания и обращаться к боевым API. Отключение только доменного имени недостаточно, если фоновые процессы имеют исходящий доступ.
Что проверять в восстановленном магазине
Область | Контрольный вопрос | Признак проблемы |
|---|---|---|
Заказы | Есть ли записи до выбранной точки и нет ли более поздних | Разрыв последовательности или дубли |
Оплаты | Совпадают ли статусы и суммы с журналом событий | Оплата есть, заказ не знает о ней |
Каталог | Открываются ли карточки и варианты товара | Ссылки на отсутствующие файлы |
Права | Работают ли роли без избыточного доступа | Все пользователи стали администраторами |
Фоновые задания | Не ушли ли реальные уведомления | Повторная отправка или внешний вызов |
Конфигурация | Соответствует ли окружение нужной версии | Код и схема базы несовместимы |
Хеш архива подтверждает неизменность конкретного файла, но не логическую пригодность данных. Успешное открытие главной страницы тоже недостаточно. Нужны выборочные заказы, авторизация, корзина, поиск, административные операции и сверка критичных счётчиков.
Посчитайте RPO и RTO по факту
Если последняя пригодная точка была в 10:00, а сбой произошёл в 10:23, фактический возможный разрыв составляет 23 минуты. Если восстановление началось в 10:40, а приёмка завершилась в 12:10, операционное время восстановления — полтора часа. В отчёте отдельно отмечают задержку обнаружения и принятия решения: она тоже влияет на реальный простой.
После теста корректируют не только расписание копирования. Возможно, больше времени занял поиск доступа, установка нужной версии или ручная проверка интеграций. Иногда самый дешёвый способ улучшить RTO — автоматизировать окружение и держать инструкцию актуальной, а не покупать более быстрое хранилище.
Копию можно считать проверенной только для конкретного сценария и даты. Изменение CMS, версии базы, состава интеграций или схемы хранения требует нового теста. Регулярное восстановление превращает резервное копирование из надежды в измеряемую способность вернуть магазин к работе.
A "backup created" email confirms only that the job started. It does not prove that the database, order files, configuration, keys, and uploads are in the archive; that the copy is intact; or that the team knows the recovery sequence. For an e-commerce store, verification requires a system restored in isolation and a recorded result.
Before the test, define two business boundaries. RPO determines how much data loss by time is acceptable, while RTO defines how long service recovery may take. These goals cannot be chosen based solely on disk size: an hour of lost orders and an hour of downtime carry different costs for different stores.
Break down the store into data with different change frequencies
Component | How it changes | What to check |
|---|---|---|
Order and payment database | Continuous | Point in time, transaction consistency |
Catalog and prices | Batch or via exchange | Link to import version and source |
Product files | Irregular | Object completeness and access rights |
Code and templates | By releases | Exact commit or deployment package |
Configuration and secrets | Rare but critical | Secure separate storage and distribution method |
Queues and sessions | Fast and temporary | Should it be recovered or recreated? |
A single nightly archive may meet the RPO for images but not for paid orders. The database will require more frequent copying or change logging. However, file and database copies must correspond to a consistent point in time; otherwise, the database will retain references to objects that do not yet exist in the archive.
Select a failure scenario, not an abstract "backup"
Testing the deletion of a single file differs from recovery after a virtual machine loss, an update error, or account compromise. The scenario determines the required levels of independence.
A user error requires versioning and a convenient way to restore a single object.
Database corruption requires a verified copy, logs, and integrity checks.
VPS loss requires infrastructure, configuration, network settings, and data outside the VPS itself.
A compromise requires a copy inaccessible to the same account for writing and deletion.
A region or platform failure requires independent storage and a pre-defined recovery point.
The rule of multiple copies on different media is useful as a guideline, but it does not replace a threat model. If all copies are deleted by a single automation token or encrypted by the same malicious process, geographic distance offers no protection.
Create a recovery passport
A passport is a short document that allows another qualified specialist to begin work. It lists the responsible person, copy locations, access procedures, dependencies, checksums, startup sequence, expected stage durations, and stop criteria.
Secrets and actual passwords are not included in such a document. Instead, it describes where and by which procedure to obtain them. Contact information for the owners of payment integrations, DNS, and external services is recorded separately: a restored site is not ready if payment notifications go to an old address or if operations are recreated.
How to run a test without risking the live store
Select an isolated network and resources that do not receive live traffic.
Record the selected recovery point, start time, and copy composition.
Deploy the infrastructure according to the documented procedure without copying active secrets unless necessary.
Restore the database and files, then apply logs only up to the selected point.
Launch the store with real payments, email campaigns, delivery, CRM, and 1C exchange disabled.
Verify data integrity and run key user scenarios.
Measure the actual duration of each stage and compare it against the RTO.
Remove test data according to company rules and document any issues found.
Isolation is mandatory: a site copy may start sending emails, deducting stock, confirming old orders, or calling live APIs. Disabling only the domain name is insufficient if background processes have outbound access.
What to check in the restored store
Area | Control question | Problem indicator |
|---|---|---|
Orders | Are there records before the selected point and none after? | Sequence break or duplicates |
Payments | Do statuses and amounts match the event log? | Payment exists, but the order is unaware of it |
Catalog | Do product cards and variants open? | Links to missing files |
Permissions | Do roles work without excessive access? | All users became administrators |
Background jobs | Did real notifications disappear? | Resend or external call |
Configuration | Does the environment match the required version | Code and database schema are incompatible |
An archive hash confirms the immutability of a specific file, but not the logical usability of the data. Successfully opening the main page is also insufficient. Select orders, authorization, the shopping cart, search, administrative operations, and verification of critical counters are required.
Calculate RPO and RTO based on actuals
If the last usable point was at 10:00 and the failure occurred at 10:23, the actual potential data gap is 23 minutes. If recovery started at 10:40 and acceptance testing concluded at 12:10, the operational recovery time is one and a half hours. The report must separately note the delay in detection and decision-making, as this also affects actual downtime.
After the test, adjust not only the backup schedule. The search for access, installation of the required version, or manual verification of integrations may have taken more time. Sometimes the most cost-effective way to improve RTO is to automate the environment and keep instructions up to date, rather than purchasing faster storage.
A backup can be considered verified only for a specific scenario and date. Changes to the CMS, database version, integration set, or storage schema require a new test. Regular restoration turns backup from a hope into a measurable capability to return the store to operation.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.