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

Про резервные копии все знают, и почти у всех они настроены. А потом случается авария, копию разворачивают — и выясняется, что дампы последние четыре месяца писались с ошибкой, что в архиве нет загруженных пользователями файлов или что развернуть базу можно только на той версии, которой больше нет ни на одном сервере.
Резервная копия — это не файл, это процедура восстановления. Пока процедуру не проверяли, вы не знаете, есть ли у вас бэкап.
Два числа, с которых начинается схема
Прежде чем выбирать инструменты, договоритесь о двух величинах. Первая — сколько данных допустимо потерять: полчаса заказов, сутки, неделя. Вторая — сколько времени бизнес готов лежать при восстановлении. Эти числа определяют всю схему и её стоимость.
| Допустимая потеря | Простой | Что нужно | Порядок затрат |
|---|---|---|---|
| Сутки | До 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,
}
// Ошибку в данных часто замечают не сразу: повреждение,
// внесённое месяц назад, к этому времени успевает попасть
// во все суточные копии. Месячные точки — единственный
// способ откатиться до момента, когда данные были целыСхема «храним копии за последние семь дней» защищает только от аварий. От тихого повреждения данных — например, скрипта, который два месяца назад начал портить записи, — спасают только длинные точки хранения.
Проверка восстановления
- Раз в месяц развернуть последнюю копию на отдельном окружении
- Проверить, что приложение поднимается и открывает основные страницы
- Сверить контрольные цифры: число заказов, пользователей, сумму за период
- Замерить время восстановления и сравнить с тем, что обещано в договоре
- Записать результат — включая то, что пришлось делать руками
Последний пункт важнее остальных. Восстановление всегда содержит шаги, которые не описаны: поднять расширение базы, поправить права, подставить ключи. В аварийной ситуации в три часа ночи эти шаги вспоминаются плохо, поэтому они должны быть в инструкции.
Проверка восстановления занимает час в месяц. Отсутствие проверки однажды займёт неделю и часть клиентской базы.
Частые вопросы
- Достаточно ли бэкапов, которые делает хостинг
- Как основа — да, как единственная защита — нет. Копии провайдера хранятся в том же аккаунте и обычно с коротким сроком, а восстановление идёт целым сервером. Отдельный дамп базы в независимое хранилище закрывает оба ограничения.
- Как часто делать копии базы
- По допустимой потере данных. Магазину с десятками заказов в час нужен журнал транзакций и почасовые точки, корпоративному сайту с редкими правками достаточно суточных. Ориентир — потеря не больше того объёма работы, который реально восстановить руками.
- Нужно ли шифровать резервные копии
- Да, если в них есть персональные данные. Копия — это полная выгрузка базы, и утечка архива равносильна утечке продакшена. Шифрование на стороне хранилища плюс отдельные ключи доступа к бакету с копиями.
Похожая задача в вашем проекте?
Разберём вашу ситуацию и пришлём оценку по этапам — без обязательств и общих слов.
Обсудить задачу

