Вернуться к статьям Посчитайте, сколько записей придётся сверить
Представим магазин, база которого копируется в 08:00 и 20:00. Сбой произошёл в 18:00. Если последняя пригодная копия содержит данные на 08:00, все изменения за следующие десять часов придётся искать отдельно. Платежи можно сверить с платёжным сервисом. Заказы ищите в учётной системе, если обмен успел их передать. Проверьте, остаются ли где-то ещё заявки и изменения, которые вводились только на сайте.
Запишите два значения. RPO задаёт допустимый разрыв между моментом сбоя и временем данных, которые можно вернуть. RTO задаёт допустимую длительность простоя. Пригодная копия трёхчасовой давности позволяет вернуть состояние магазина на три часа раньше сбоя. Сколько займут скачивание, импорт и запуск магазина, покажет пробное восстановление. Разбор целей RPO и RTO в AWS Architecture Blog
Проверьте, что расписание выполняется
Смотрите на время данных в последней пригодной копии в хранилище. Например, при графике каждые три часа копия на 12:00 может оказаться последней доступной, если задача на 15:00 завершилась ошибкой или выгрузка ещё идёт. При сбое в 17:00 разрыв составит пять часов.
Настройте уведомление о пропуске или задержке копии. На пробном восстановлении проверьте, что выбранная версия базы подходит к версии кода и схемы данных. После обновления магазина сохраните точку восстановления, для которой известны версии файлов и базы.
Какой график предусмотрен на обслуживании
| Тариф S-WEBS24 | График резервного копирования базы |
|---|---|
| Старт | Раз в сутки |
| Профи | Дважды в сутки |
| Бизнес | Каждые три часа |
Файлы сайта резервируем отдельно. На тарифах «Профи» и «Бизнес» график копирования файлов согласуем с клиентом. До подключения имеет смысл назвать часы наибольшего потока заказов и системы, с которыми придётся сверять данные после сбоя. Тарифы и состав обслуживания серверов
История клиента, с которой началась эта серия. Как мы восстановили проект после атаки на Beget