Перейти к основному содержанию
Разработка3 мин чтения

Резервное копирование: бэкап, который действительно восстановится

Копии есть почти у всех. Проблемы начинаются в момент восстановления. Разбираем схему хранения, целевые сроки простоя и проверку, которая ловит неработающий бэкап заранее.

Схема резервного копирования базы данных с точками восстановления

Про резервные копии все знают, и почти у всех они настроены. А потом случается авария, копию разворачивают — и выясняется, что дампы последние четыре месяца писались с ошибкой, что в архиве нет загруженных пользователями файлов или что развернуть базу можно только на той версии, которой больше нет ни на одном сервере.

Резервная копия — это не файл, это процедура восстановления. Пока процедуру не проверяли, вы не знаете, есть ли у вас бэкап.

Два числа, с которых начинается схема

Прежде чем выбирать инструменты, договоритесь о двух величинах. Первая — сколько данных допустимо потерять: полчаса заказов, сутки, неделя. Вторая — сколько времени бизнес готов лежать при восстановлении. Эти числа определяют всю схему и её стоимость.

Схемы под разные требования
Допустимая потеряПростойЧто нужноПорядок затрат
СуткиДо 8 часовНочной дамп в объектное хранилищеМинимальный
1 часДо 2 часовДамп + журнал транзакций, отработанная процедураУмеренный
5 минутДо 15 минутПотоковая репликация на резервный серверЗаметный
Близко к нулюМинутыГорячий резерв с автопереключениемВысокий

Разница между первой и последней строкой — десятки раз по стоимости. Поэтому вопрос «нужна ли отказоустойчивость» решается не на техническом совещании, а через цену часа простоя для конкретного бизнеса.

Что попадает в копию

  • База данных — согласованный дамп, а не копирование файлов на живой базе
  • Загруженные файлы: изображения, документы, вложения — их часто забывают
  • Переменные окружения и секреты — отдельно и в защищённом хранилище
  • Конфигурация инфраструктуры — в репозитории, а не только в панели провайдера
  • Схема миграций, чтобы дамп можно было развернуть на чистом окружении

Сроки хранения

Ротация: свежие копии часто, старые редко
type RetentionPolicy = {
  hourly: number  // последние сутки — почасовые
  daily: number   // последние две недели — суточные
  weekly: number  // последние два месяца — недельные
  monthly: number // год — месячные
}

export const defaultRetention: RetentionPolicy = {
  hourly: 24,
  daily: 14,
  weekly: 8,
  monthly: 12,
}

// Ошибку в данных часто замечают не сразу: повреждение,
// внесённое месяц назад, к этому времени успевает попасть
// во все суточные копии. Месячные точки — единственный
// способ откатиться до момента, когда данные были целы

Схема «храним копии за последние семь дней» защищает только от аварий. От тихого повреждения данных — например, скрипта, который два месяца назад начал портить записи, — спасают только длинные точки хранения.

Проверка восстановления

  1. Раз в месяц развернуть последнюю копию на отдельном окружении
  2. Проверить, что приложение поднимается и открывает основные страницы
  3. Сверить контрольные цифры: число заказов, пользователей, сумму за период
  4. Замерить время восстановления и сравнить с тем, что обещано в договоре
  5. Записать результат — включая то, что пришлось делать руками

Последний пункт важнее остальных. Восстановление всегда содержит шаги, которые не описаны: поднять расширение базы, поправить права, подставить ключи. В аварийной ситуации в три часа ночи эти шаги вспоминаются плохо, поэтому они должны быть в инструкции.

Проверка восстановления занимает час в месяц. Отсутствие проверки однажды займёт неделю и часть клиентской базы.

Частые вопросы

Достаточно ли бэкапов, которые делает хостинг
Как основа — да, как единственная защита — нет. Копии провайдера хранятся в том же аккаунте и обычно с коротким сроком, а восстановление идёт целым сервером. Отдельный дамп базы в независимое хранилище закрывает оба ограничения.
Как часто делать копии базы
По допустимой потере данных. Магазину с десятками заказов в час нужен журнал транзакций и почасовые точки, корпоративному сайту с редкими правками достаточно суточных. Ориентир — потеря не больше того объёма работы, который реально восстановить руками.
Нужно ли шифровать резервные копии
Да, если в них есть персональные данные. Копия — это полная выгрузка базы, и утечка архива равносильна утечке продакшена. Шифрование на стороне хранилища плюс отдельные ключи доступа к бакету с копиями.
поддержканадёжностьэксплуатацияданные

Похожая задача в вашем проекте?

Разберём вашу ситуацию и пришлём оценку по этапам — без обязательств и общих слов.

Обсудить задачу

Вопрос по статье
или по своему проекту

Отвечаем на заявки в течение одного рабочего дня. Если задача не наша — скажем прямо и подскажем, к кому обратиться.

Написать нам

Поля со звёздочкой обязательны для заполнения.