Копии лежат на том же сервере
Архивы складываются в каталог рядом с приложением. Ошибка в скрипте удаления, шифровальщик или отказ диска уничтожают и данные, и их копии одновременно.
Выберите тему — соберём контекст
Настраиваем копирование базы, файлов и конфигураций с выгрузкой за пределы площадки и шифрованием. Ключевая часть работы — регулярная проверка того, что из этих копий действительно поднимается рабочий сервис.
Или сразу: +7 (962) 368-39-51 Telegram
Копии, которые делаются без проверки, создают ложное чувство защищённости — и обнаруживают свою бесполезность в самый неудачный момент.
Архивы складываются в каталог рядом с приложением. Ошибка в скрипте удаления, шифровальщик или отказ диска уничтожают и данные, и их копии одновременно.
Скрипт отрабатывает без ошибок, файлы растут, но архив обрывается на середине или повреждён. Никто этого не замечал, потому что восстановление никогда не пробовали.
Копия есть, но её размер и способ хранения таковы, что загрузка и разворачивание тянутся больше суток — а простой в это время стоит денег и репутации.
База копируется, а загруженные документы, изображения, пользовательские вложения и переменные окружения — нет. После восстановления сервис поднимается, но без половины данных.
Архивы с персональными данными клиентов лежат на диске в открытом виде, доступны всем администраторам и выгружаются в общедоступное хранилище.
Процедуры нет, доступы к хранилищу у одного человека, команда не знает последовательности шагов. Каждая минута аварии уходит на выяснение ролей.
Схему подбираем под требования к сохранности данных: для интернет-магазина и для системы документооборота приоритеты разные.
Полный состав данных, без которого сервис не поднимется в рабочем виде.
Схема 3-2-1: три копии данных, на двух разных носителях, одна из них — за пределами основной площадки.
Главный блок работ: без регулярной проверки нельзя утверждать, что копия рабочая.
Процедура восстановления должна работать без человека, который её придумал.
Работы идут от аудита текущей схемы до регулярной проверки, которую можно предъявить при разборе инцидента.
Смотрим, что копируется сейчас, куда выгружается, как хранится и кто имеет доступ. Определяем целевые RPO и RTO для каждого типа данных.
Настраиваем расписания, шифрование и выгрузку за пределы площадки. Добавляем то, что раньше не копировалось: файлы, конфигурации, секреты.
Разворачиваем сервис из копии на отдельном стенде, замеряем время и фиксируем расхождения. Уточняем инструкцию по фактическим шагам.
Ежедневный автоматический контроль целостности, ежемесячное тестовое восстановление и отчёт с фактическим временем развёртывания.
RPO — это допустимый объём потерянных данных, выраженный во времени. Если база копируется раз в сутки, RPO равен суткам: при аварии в конце дня вы потеряете все заказы и заявки за этот день. RTO — допустимое время простоя, то есть срок, за который сервис должен снова работать.
Для интернет-магазина с постоянным потоком заказов разумный ориентир — RPO не более 15 минут и RTO в пределах одного-двух часов. Для внутренней системы документооборота часто достаточно RPO в один час и RTO в рабочий день. Значения определяются бизнесом, а не техническими соображениями, и именно от них зависит схема копирования и её стоимость.
Архив, из которого никто не восстанавливался, — это обещание, а не гарантия. За годы практики мы регулярно встречаем копии, которые формально создаются и имеют ненулевой размер, но не разворачиваются: обрыв выгрузки, несовпадение версии базы, отсутствие нужных файлов, забытые ключи шифрования.
Поэтому мы включаем в работу регулярное тестовое восстановление на отдельный стенд с замером времени каждого этапа. Это позволяет не только убедиться в работоспособности копий, но и уточнить фактический RTO: например, выясняется, что развёртывание базы занимает 20 минут, а загрузка файлов из холодного хранилища — два часа. Без такого замера оценка времени восстановления остаётся догадкой.
Резервные копии содержат те же персональные данные, что и продакшен, но часто без тех же мер защиты. Мы шифруем архивы до выгрузки за пределы площадки и храним ключи отдельно от самих копий: тогда утечка носителя или ошибка в настройках доступа к хранилищу не приводит к компрометации данных.
Дополнительно ограничиваем круг лиц с доступом к копиям, ведём журнал скачиваний и устанавливаем срок хранения. Данные, которые больше не нужны, удаляются из архивов по регламенту — это снижает и риск, и стоимость хранения, и объём обязательств перед клиентами.
Зависит от того, сколько данных вы готовы потерять. Для баз данных активных сервисов мы обычно настраиваем ежедневную полную копию и инкрементальные копии или журнал транзакций каждые 15 минут — это даёт RPO в пределах четверти часа. Файлы копируются ежедневно, а конфигурации и секреты — при каждом изменении. Частота напрямую влияет на объём хранилища и стоимость.
Единственный надёжный способ — развернуть из него сервис. Мы настраиваем ежедневную автоматическую проверку целостности архивов, а раз в месяц восстанавливаем копию на отдельный стенд: поднимаем базу, разворачиваем файлы, запускаем приложение и проверяем ключевые сценарии. После этого сверяем количество записей и фиксируем фактическое время восстановления в отчёте.
Да, и для территориально распределённого хранения это удобный вариант. Обязательные условия: шифрование до выгрузки, отдельные ключи доступа, ограниченные права на запись и удаление, а также проверка того, что хранилище не открыто публично. Мы предпочитаем схему, при которой копия лежит вне площадки продакшена, но при этом доступна для восстановления без участия сторонних людей.
Обычно в три-пять раз больше объёма самих данных, если хранить ежедневные копии за месяц и недельные за квартал. Сжатие и инкрементальные схемы заметно уменьшают объём: часто хватает удвоения. Мы рассчитываем размер хранилища заранее, исходя из темпа роста базы, и настраиваем политику хранения так, чтобы старые копии удалялись автоматически и предсказуемо.
Смежные задачи, которые обычно решаются в одном проекте с этой.
Расскажите, что и как копируется сейчас, — предложим схему хранения и проведём пробное восстановление.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.