Бэкап апокалипсис: ищем альтернативные решения для БД размером в 100+ терабайт, когда стандартные решения бессильны!

Базы данных и системы хранения

MongoDB

Базы данных / другое

Администрирование баз данных

Хранилища

Программный комитет ещё не принял решения по этому докладу

Целевая аудитория

Разработчики, архитекторы, devops, dba, инженеры эксплуатации

Тезисы

Проблема: почему стандартные инструменты не работают
- время бэкапа для 100–500 ТБ — от суток и более;
- критическая нагрузка на CPU/IO, риск деградации продуктива;
- проблемы консистентности при длительных операциях.
- срыв RTO (время восстановления);
- потеря данных при сбоях в процессе бэкапа;
- вынужденный downtime.
Ключевые требования к альтернативным решениям
- Минимальное воздействие на рабочую систему (near zero downtime).
- Предсказуемое время выполнения (часы вместо дней).
- Гарантия консистентности данных.
- Масштабируемость под огромные объёмы (сотни террабайт).
- Автоматизация и мониторинг.
DB-agnostic решение: LVM снэпшоты. Принцип: мгновенное «фото» файловой системы через механизм Copy on Write. Плюсы:
- создание снэпшота — секунды независимо от объёма;
- нулевая блокировка записи;
- полная файловая консистентность.
Решение для Cassandra/Scylla: бэкап по token ranges с параллельной обработкой данных по диапазонам токенов. Плюсы:
- линейное масштабирование скорости (больше узлов = быстрее);
- равномерное распределение нагрузки;
- поддержка инкрементальных бэкапов.
Альтернативные подходы (кратко)
- Репликация в отдельный кластер + бэкап с реплики:
- Облачные снапшоты (AWS EBS, GCP Persistent Disks): Выводы и заключение: Бэкап огромных БД – сложная техническая задача, так как стандартные подходы и инструменты не работают. Без применения нестандартных подходов риск потери данных становится неприемлемым.