dm-timemachine: Device Mapper для CDP

Обзор

dm-timemachine - это низкоуровневый CDP-движок для Linux-стека хранения. Он встраивается в путь записи на уровне Device Mapper, журналирует каждую значимую операцию записи и тем самым превращает обычный блочный том в источник восстановления на момент времени, технического разбора инцидентов и репликации по журналу изменений.

С инженерной точки зрения это решение про управление компромиссом между надежностью, накладными задержками и стоимостью восстановления. Вместо грубых снимков "раз в N минут" система сохраняет непрерывный журнал изменений между контрольными точками. За счет этого можно откатить том к нужному моменту времени, расследовать инцидент на уровне блоков и строить процедуры восстановления с предсказуемым RPO.

Это уже не просто прототип модуля ядра, а платформенная возможность для систем хранения: низкоуровневый путь данных, семантика восстановления, наблюдаемость и инструменты пользовательского пространства сведены в одну архитектуру, из которой можно вырастить коммерческую функцию резервного копирования и аварийного восстановления.

Ключевые возможности

• Ядерный модуль: перехват записей на уровне Device Mapper
• Кольцевой буфер: журнал изменений с фиксированным потреблением памяти
• Два режима хранения: в RAM для быстрого стенда и на отдельном блочном устройстве для персистентности
• Политики захвата: ограничения по размеру записи, списки разрешенных и запрещенных устройств и ограничение по числу записей в секунду
• Read API: символьное устройство для чтения журнала из пользовательского пространства
• Экспортер в Prometheus (Python): метрики в реальном времени
• Дашборды в Grafana: нагрузка и объёмы
• Скрипты воспроизведения: безопасная проверка без записи, откат состояния и восстановление до заданной временной отметки
• Дымовые и интеграционные проверки: проверка жизненного цикла dmsetup, воспроизведения и персистентности

Зачем он нужен

Проект решает практическую проблему, с которой регулярно сталкиваются инфраструктурные команды: снимки слишком редки, классическое резервное копирование слишком медленное для оперативного восстановления, а после ошибки оператора или логической порчи данных нужно вернуть состояние не "примерно", а максимально близко к моменту сбоя.

Проект помогает:

• сократить RPO, потому что между контрольными точками остается журнал изменений;
• расследовать инциденты, потому что видно, какие блоки и когда были перезаписаны;
• тестировать механики восстановления, не дожидаясь настоящей аварии;
• измерять накладные расходы и качество защиты через метрики captured, dropped, log_used и задержки;
• строить поверх него более крупные функции хранения и резервного копирования.

Как помогает в коммерческом проекте

В коммерческом продукте это не просто прототип модуля ядра, а платформенная возможность. Такой движок можно положить в основу классов функций вроде "непрерывное резервное копирование", "восстановление на момент времени", "откат после ошибки оператора", "отслеживание изменений" или технического аудита операций хранения.

Продуктовая ценность здесь вполне измерима: ниже RPO, быстрее реакция на инциденты, понятнее процедуры восстановления и сильнее корпоративная история вокруг надежности хранения.

Он может приносить пользу в нескольких сценариях:

• Storage appliance / SDS: как старшая возможность для СХД, где нужно восстановление до точного момента, а не до последнего снимка.
• Backup и DR-платформа: как источник журнала изменений для инкрементальной защиты, ускоренной репликации и быстрого восстановления.
• Инфраструктура виртуализации: как слой под виртуальными дисками VM для безопасного отката после обновлений, ошибок пользователей и сценариев с шифрованием данных.
• Средства корпоративной поддержки: как диагностическая подсистема для расследования инцидентов и подтверждения причин деградации у клиента.
• Внутренняя платформенная разработка: как базовый строительный блок, на котором затем собираются политики хранения, репликация и автоматизация восстановления.

Как такой проект зарабатывает деньги

Сам модуль не является конечным продуктом, но является базовой технологией, вокруг которой строится коммерчески значимая функциональность для хранения и защиты данных.

Типовые модели монетизации:

• Корпоративная продуктовая линейка: CDP, точечное восстановление и откат на уровне блоков продаются как старшие функции в платформе хранения и резервного копирования.
• Лицензирование по емкости или количеству защищаемых томов: естественная модель монетизации инфраструктурного ПО.
• Платная интеграция и консалтинг: встраивание в конкретный стек хранения клиента, настройка политик и адаптация процедур восстановления.
• Сервис сопровождения защиты данных: мониторинг, регулярные тренировки восстановления, сопровождение и разбор инцидентов как платная услуга.
• OEM / appliance: встраивание в специализированные решения для защиты критичных данных.

Бизнес-ценность здесь в снижении ущерба от потери данных, сокращении времени восстановления и появлении измеримого SLA на защиту данных. Именно это превращает низкоуровневую инженерную работу в коммерчески значимую платформенную функцию.

Как устроен проект

Архитектура намеренно разделена на изолированные слои, чтобы минимизировать связность, упростить тестирование и оставить пространство для развития режима хранения, политик и API восстановления без переписывания всего пути данных.

• core.c регистрирует модуль и Device Mapper target.
• target.c создает экземпляр цели, разбирает аргументы, подключает нижележащее устройство, считает задержки и экспортирует статус через dmsetup status.
• io_engine.c решает, что именно писать в журнал, сериализует запись и передает ее в хранилище.
• metadata.c формирует заголовок записи: временную метку, сектор, размер полезной нагрузки, версию и флаги операции.
• policy.c применяет правила захвата: размер, список устройств, ограничение частоты и причины отказа.
• log_store.c реализует кольцевой буфер и режим хранения.
• read_api.c отдает снимок журнала в пользовательское пространство через символьное устройство /dev/dm_timemachine_log.
• scripts/dm_timemachine_replay.py читает журнал и воспроизводит полезную нагрузку обратно на целевое блочное устройство.
• scripts/dm_timemachine_exporter.py превращает статус DM-цели в метрики Prometheus.

Во время работы путь данных выглядит так:

1. Приложение или файловая система пишет в устройство Device Mapper.
2. target.c получает bio и передает запись в io_engine.c.
3. policy.c решает, можно ли захватывать эту операцию или ее нужно отбросить.
4. metadata.c собирает заголовок записи, а log_store.c пишет заголовок и полезную нагрузку в кольцевой буфер.
5. Исходный bio перенаправляется на нижележащее устройство, поэтому рабочая запись все равно доходит до диска.
6. Пользовательское пространство читает журнал через read API, экспортирует метрики или воспроизводит данные через скрипт восстановления.

Ключевое архитектурное решение - логирование как параллельный канал рядом с основным вводом-выводом, а не вместо него. Это важный производственный компромисс: основная запись продолжает идти на нижележащее устройство, а слой защиты данных развивается как отдельная контролируемая подсистема с понятными метриками, контролем перегрузки и политиками деградации.

Почему это зрелый инженерный кейс

Для портфолио проект силен не только тем, что это код в ядре Linux. Более важен здесь уровень ответственности за решение:

• работа в пути данных ядра, где цена ошибки высока;
• проектирование семантики восстановления и журнала изменений на уровне блоков;
• разделение ответственности между ядром и пользовательским пространством без размывания границ;
• наблюдаемость через Prometheus/Grafana для низкоуровневого компонента хранения;
• воспроизводимая среда разработки и тестирования, дымовые и интеграционные проверки и сценарии воспроизведения;
• прямая связь между низкоуровневой механикой и коммерчески значимой корпоративной функцией.

То есть это не просто модуль ядра, а инженерная работа на стыке Linux kernel, архитектуры хранения и проектирования продукта: как встроить непрерывную защиту данных в реальный путь записи так, чтобы решение оставалось измеримым, тестируемым и пригодным для коммерческого продукта хранения.

Технический стек

• Ядерный модуль: C (Linux kernel API)
• Инструменты пользовательского пространства: Python
• Мониторинг: Prometheus, Grafana, Docker Compose
• Тестирование: KUnit, дымовые и интеграционные проверки, проверки воспроизведения и персистентности
• Окружение: devcontainer, работа через виртуальную машину, Docker