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

Существует только два типа компаний: те, кто проверяет свои резервные копии, и те, кто узнаёт об их неработоспособности в день аварии. Наличие галочки «бэкап включён» в панели хостинга не означает наличия бэкапа — это означает наличие галочки. Разберём, как построить схему, которая действительно спасёт.

Правило 3-2-1 и почему оно всё ещё актуально

Три копии данных, на двух разных носителях, одна — вне основной площадки. Логика простая: одна копия защищает от случайного удаления файла, вторая — от отказа диска, третья — от пожара, изъятия оборудования или компрометации всей учётной записи хостинга. Самый частый провал — все три копии живут в одном аккаунте у одного провайдера. При блокировке аккаунта за неоплату или взломе панели вы теряете сразу всё.

Что именно нужно копировать

• База данных — полный дамп, а не только пользовательские таблицы.
• Пользовательские загрузки: изображения, документы, вложения. Именно они занимают основной объём и не восстанавливаются из репозитория.
• Конфигурационные файлы веб-сервера, окружения, cron-задания.
• SSL-сертификаты и ключи, если они не выпускаются автоматически.
• Зона DNS в текстовом виде — восстановление вручную по памяти занимает часы.
• Список установленных пакетов и версий — без него «такой же сервер» собирается неделю.

Глубина хранения: почему одной копии мало

Ежедневная копия с перезаписью бесполезна против двух самых частых сценариев. Первый — шифровальщик: он работает тихо, вы замечаете проблему через несколько дней, а все копии уже перезаписаны зашифрованными данными. Второй — тихое повреждение данных из-за ошибки в коде: сбойная выгрузка испортила поле в базе, обнаружили через две недели. Рабочая схема ретенции: 7 ежедневных копий, 4 еженедельных, 12 ежемесячных. Для большинства проектов это укладывается в десятки гигабайт и стоит несколько сотен рублей в месяц.

Две цифры, которые определяют схему

RPO — сколько данных вы готовы потерять, измеряется временем между копиями. RTO — за сколько вы обязаны восстановиться. Для сайта-визитки RPO в сутки и RTO в 4 часа приемлемы. Для интернет-магазина или ERP потеря суток заказов недопустима: там нужен непрерывный архив журналов транзакций и RPO в минуты. Эти два числа определяют бюджет — не наоборот. Сначала посчитайте стоимость часа простоя, потом выбирайте решение.

Шифрование и доступ

Резервная копия базы данных — это ваша клиентская база в максимально удобном для злоумышленника виде. Она должна быть зашифрована до отправки в хранилище, а ключ храниться отдельно от самих копий. Отдельное требование: учётная запись, которая пишет бэкапы, не должна иметь права их удалять. Иначе получивший доступ к серверу злоумышленник первым делом сотрёт архивы. По 152-ФЗ резервные копии с персональными данными подчиняются тем же правилам локализации, что и основная база — подробнее об этом в разделе безопасности.

Главное: тестовое восстановление

Копия, из которой ни разу не восстанавливались, — это не копия, а надежда. Раз в квартал разворачивайте архив на тестовом окружении полностью, с секундомером. Вы узнаете реальный RTO вместо предполагаемого, обнаружите, что дамп базы бьётся на середине или что забыли включить в бэкап каталог с договорами. Час работы раз в три месяца против дня паники — размен очевидный.

Минимальная схема на старте

• Ежедневный автоматический дамп базы и файлов по расписанию.
• Выгрузка в объектное хранилище другого провайдера с ключом только на запись.
• Ретенция 7/4/12 и шифрование архива.
• Уведомление на почту при неуспешном выполнении задания — молчание не означает успех.
• Календарное напоминание на тестовое восстановление раз в квартал.

Если настраивать это некому или хочется передать под контроль команды — такие контуры мы ведём в рамках сопровождения. Обсудить параметры под ваш проект можно через форму.