Резервная копия нужна не для отчёта и не для галочки в договоре поддержки. Она нужна в тот момент, когда база повреждена, сервер удалён, а магазин принимает заказы.
Проблема в том, что бэкап проверяют только тогда, когда он уже нужен. Хорошая практика — регулярно восстанавливать копию на тестовом контуре и смотреть, что получилось.
Чем бэкап отличается от реплики
Реплика копирует данные почти мгновенно и помогает пережить отказ сервера. Но если ошибка пришла из приложения, она попадёт и в реплику. Бэкап — это точка восстановления на прошлое состояние.
Для интернет-магазина нужны оба инструмента. Реплика даёт отказоустойчивость, бэкап — защиту от логических ошибок, удаления и атаки.
Что именно копировать
- Базу данных: товары, заказы, клиенты, цены, остатки.
- Файлы приложения и конфигурацию окружения.
- Изображения и документы, загруженные пользователями.
- Настройки веб-сервера, PHP и очередей.
- Ключи и секреты в защищённом хранилище.
- Конфигурацию CDN и правил безопасности.
- Логи за период, достаточный для разбора инцидента.
- Дампы внешних интеграций, если они не восстанавливаются.
- Схему базы и миграции отдельно от данных.
- Резервные копии перед каждым релизом.
RPO и RTO: сколько данных можно потерять
RPO показывает, на какой момент времени вы готовы вернуться. RTO — сколько времени допустимо потратить на восстановление. Для магазина с потоком заказов даже 15 минут простоя могут стоить денег.
Допустима потеря заказов за сутки. Подходит для небольших проектов.
Нужны частые инкременты и журнал транзакций.
Требует автоматизации и заранее подготовленного контура.
Реалистично для большинства средних магазинов.
Как часто делать бэкапы
Частота зависит от интенсивности заказов. Если магазин продаёт несколько позиций в день, ежедневной копии может хватить. Если поток идёт круглосуточно, нужны более частые точки восстановления.
- Полная копия — раз в сутки или раз в неделю.
- Инкрементальная копия — каждые 1–6 часов.
- Копия перед релизом и миграцией — обязательно.
- Копия перед массовым импортом товаров.
- Копия после крупных изменений цен.
- Копия перед изменением прав доступа.
Правило 3-2-1
Классическая схема: три копии, на двух разных носителях, одна из них вне офиса или дата-центра. Для магазина это означает, что копия не должна лежать на том же сервере, который она защищает.
- Рабочая база.
- Локальная или сетевая копия.
- Внешнее хранилище в другом регионе.
- Разные учётные записи и ключи.
- Проверка доступа к внешнему хранилищу.
Куда складывать копии
Лучше использовать объектное хранилище с версионированием и защитой от удаления. Оно дешевле дисков сервера и не исчезнет вместе с ним.
- S3-совместимое хранилище.
- Отдельный сервер резервных копий.
- Холодное хранилище для месячных копий.
- Шифрование перед отправкой.
- Ограничение срока жизни копий.
- Проверка целостности после загрузки.
Консистентность базы
Копия «на горячую» может оказаться несогласованной. Для PostgreSQL используют pg_dump или физический бэкап с архивом журналов, для MySQL — mysqldump с транзакциями или Percona XtraBackup.
- Фиксируйте момент снимка.
- Проверяйте кодировку и последовательности.
- Не копируйте файлы базы без остановки записи.
- Для больших баз используйте физический бэкап.
- Храните журналы транзакций отдельно.
- Проверяйте восстановление на тестовой базе.
Шифрование и доступы
Бэкап содержит персональные данные и заказы. Если копия утечёт, последствия будут не меньше, чем от взлома сайта.
- Шифруйте копии до отправки в хранилище.
- Храните ключи отдельно от копий.
- Ограничьте круг лиц с доступом.
- Включите аудит скачивания.
- Удаляйте копии по истечении срока.
- Не храните пароли в открытом виде.
Сроки хранения
Слишком короткий срок не даст откатиться к состоянию до незаметной ошибки. Слишком длинный увеличивает стоимость и риски.
- 7 ежедневных копий.
- 4 недельных копии.
- 12 месячных копий.
- Копии перед релизами — 30 дней.
- Копии перед миграцией — до завершения проекта.
Как проверить восстановление
Непроверенный бэкап — это не бэкап, а надежда. Восстановление нужно репетировать, пока нет аварии.
Отдельная база и отдельный домен, чтобы не задеть продакшен.
Из того же хранилища и тем же способом, что при аварии.
Количество заказов, товаров, пользователей и последние транзакции.
Каталог, корзина, checkout и оплата в тестовом режиме.
Сколько заняли шаги и что пришлось делать вручную.
Проверку стоит проводить раз в квартал и после крупных изменений инфраструктуры. Результат фиксируйте в регламенте.
Регламент на одну страницу
Типичные ошибки
- Копия лежит на том же сервере, что и сайт.
- Бэкап делается, но никогда не проверяется.
- В копию не попадают загруженные файлы.
- Секреты хранятся вместе с дампом.
- Нет копии перед релизом.
- Срок хранения слишком короткий.
- Нет ответственного за восстановление.
- Копии не шифруются.
- Восстановление не укладывается в RTO.
- Регламент существует только в голове администратора.
Что делать при потере данных
Переведите магазин в режим обслуживания, чтобы не усугубить повреждение.
Что именно сломалось и когда это заметили.
До последней корректной копии, а не всегда до последней.
Сначала проверьте, потом переключайте продакшен.
Ошибка приложения, действие человека или атака.
После восстановления проверьте не только доступность сайта, но и целостность заказов, остатков и интеграций. Часть данных могла обновиться после выбранной точки.
Итог
Бэкап — это процесс, а не файл. Он включает частоту, хранение, шифрование, доступы и регулярную проверку. Если восстановление ни разу не репетировали, считайте, что его нет.
Бэкапы при миграции
Перед переносом магазина нужна отдельная точка восстановления. Если миграция пойдёт не так, вы должны вернуться к рабочему состоянию, а не собирать его по частям.
- Копия до начала работ.
- Копия после переноса данных.
- Копия перед переключением DNS.
- Копия файлов и изображений.
- План отката на старую платформу.
- Проверка восстановления на тестовом домене.
Бэкапы файлов и изображений
База данных — не весь магазин. Изображения товаров, документы, PDF и видео могут занимать больше места и теряться отдельно от дампа.
- Загруженные изображения.
- Документы и сертификаты.
- Файлы конфигурации.
- Шаблоны писем.
- Экспортёры и отчёты.
- Пользовательские файлы.
Стоимость и ресурсы
Бэкапы стоят денег, но дешевле простоя и восстановления. Оцените объём, частоту и срок хранения, чтобы не платить за лишнее.
- Объём базы и файлов.
- Частота копирования.
- Срок хранения.
- Хранилище и трафик.
- Время восстановления.
Проверка перед высоким сезоном
Перед распродажей или сезоном проверьте не только бэкапы, но и весь план восстановления. Нагрузка выше, цена ошибки тоже.
Как автоматизировать бэкапы
Ручной бэкап рано или поздно забудут. Автоматизация должна запускаться по расписанию, проверять результат и сообщать об ошибке.
- Планировщик на сервере или во внешнем сервисе.
- Скрипт с проверкой кода возврата.
- Отправка копии в хранилище.
- Проверка размера и целостности.
- Уведомление об успехе и ошибке.
- Ротация старых копий.
- Логирование каждого запуска.
- Тестовое восстановление по расписанию.
Если бэкап упал ночью, утром кто-то должен узнать об этом раньше, чем начнётся рабочий день. Настройте алерт в мессенджер или на почту.
Разберём регламент, хранение и восстановление. Покажем, где риск потерять заказы.
Обсудить поддержку →
