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

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