Как системы резервного копирования работают с LTO

Сегодня мы логически продолжим и завершим мой небольшой цикл о ленточных библиотеках. Мы уже разобрали наиболее интересные и важные моменты о том, как работают ленты. И на мой взгляд логичным завершением будет посмотреть, как различные СРК работают с лентами. В нашем сегодняшнем списке будут числиться лидеры отрасли (по Gartner) – Commvault и Veeam, Российские СРК — Кибер Бекап и RuBackup (Бересты в списке нет по причине отсутствия публичных данных о работе с лентами) и продукты из поднебесной — AISHU AnyBackup и Vinchin.

Сразу про методологию

Тема лент в документации разных вендоров раскрыта очень неравномерно. Commvault и Veeam имеют многолетнюю глубокую интеграцию с лентой — их документация по этой теме насчитывает сотни страниц. КиберБекап и RuBackup активно развивают поддержку ленточных библиотек прямо сейчас, и некоторые возможности появились буквально в последних версиях 2025–2026 годов. Vinchin и AISHU AnyBackup публично описывают лишь верхний уровень функциональности — детали их внутренней реализации приходится реконструировать по release notes и косвенным данным. Там, где уверенных данных нет — честно об этом скажу.

Commvault

Commvault имеет одну из наиболее зрелых реализаций поддержки лент на рынке — компания работает с лентой с момента своего основания в 1996 году, когда лента была основным носителем для бэкапа.

Архитектура

Commvault поддерживает прямую запись на ленту (D2T) без обязательного промежуточного дискового репозитория. Лента исторически рассматривается как полноправная цель для первичного бэкапа, а не только как архивный носитель.

Управление осуществляется через концепцию Storage Policy с привязкой к Libraries (физические или виртуальные ленточные библиотеки) и Drive Pools (группы приводов). Scratch pool определяет, какие картриджи доступны для использования — их можно назначать автоматически по паттерну штрихкода или вручную.

Управление носителями

Vault Tracker — ключевое отличие Commvault: встроенный модуль управления физическим перемещением картриджей между локациями. Он отслеживает, где физически находится каждая лента (в библиотеке, в сейфе off-site, в транзите), напоминает операторам о необходимости вывоза и возврата, формирует отчёты по истории перемещений. Ничего подобного в других продуктах нет.

Export Media — возможность физически выгрузить картриджи через I/O-порты библиотеки прямо из консоли Commvault.

Штрихкоды поддерживаются, можно задавать кастомные паттерны для автоматического распределения картриджей по scratch pools.

WORM

Поддерживается с автоопределением — если в настройках MediaAgent включена опция Automatically detect WORM Tape Media, система сама распознаёт WORM-картриджи при инвентаризации и переводит их в соответствующий пул. После израсходования WORM-картридж автоматически перемещается в Retired Media pool без возможности переиспользования.

LTFS

Commvault не использует LTFS как основной формат — данные хранятся в собственном формате с каталогом. Поддержка LTFS для обмена данными с внешними системами возможна как дополнительная опция.

NDMP

Commvault поддерживает и прямую потоковую передачу данных с NAS на целевое хранилище, и IntelliSnap NDMP-бэкапы. Дифференциальные NDMP-бэкапы — редкость для продуктов такого класса — здесь работают.

Шифрование

Интеграция с внешними ключевыми серверами по KMIP. Поддерживается как аппаратное шифрование LTO-приводов, так и программное шифрование на уровне самого Commvault.

Auxiliary Copy, DASH Copy и Silo Storage

Auxiliary Copy — базовый механизм вторичных копий в Commvault. Через него организуется запись на ленту в схеме D2D2T: первичная копия хранится на диске, auxiliary copy переносит её на ленту по расписанию. Бывает синхронной (охватывает все задания автоматически) или выборочной (только полные или синтетические полные копии).

DASH Copy (Deduplication Accelerate Streaming Hash) — режим Auxiliary Copy при дедупликации. Вместо того чтобы разворачивать дедуплицированные данные в полный объём, DASH Copy передаёт на ленту только уникальные блоки. Нагрузка на сеть и потребляемая ёмкость ленты снижаются. Оговорка: при восстановлении с такой ленты без дедуп-базы (DDB) на диске Commvault разворачивает данные обратно — это занимает больше времени, чем восстановление из полного недедуплицированного образа.

Silo Storage — функция для долгосрочного архивирования: дедуп-база периодически запечатывается (seal) и архивируется на ленту вместе с данными. Данные хранятся годами без дискового индекса. Ограничения прямо прописаны в документации Commvault: объём от 10 ТБ, срок хранения от года, высокий коэффициент дедупликации противопоказан, частое восстановление невозможно — каждая операция требует обращения к нескольким кассетам. Инструмент для архива, не для оперативной работы.

Мультиплексирование и управление потоками — по умолчанию Commvault мультиплексирует данные нескольких клиентов на одну ленту. Ёмкость кассеты используется эффективно, но данные одного клиента могут оказаться размазаны по нескольким кассетам, что усложняет восстановление. Если важна простота восстановления — отключите мультиплексирование через параметр Device Streams: один поток заполняет одну кассету до конца перед переходом к следующей.

Слабые места

Commvault — сложный продукт с высоким порогом вхождения. Tape-конфигурация здесь требует понимания иерархии Storage Policy → Library → Drive Pool → Scratch Pool, и ошибка на любом уровне может привести к тому, что картриджи не будут правильно распределены.

Veeam Backup & Replication

Архитектура

Ключевое архитектурное ограничение Veeam: прямой бэкап на ленту невозможен. Лента в Veeam всегда выступает вторичной целью — данные сначала записываются на дисковый репозиторий, затем отдельный Backup to Tape job копирует готовые файлы бэкапов на кассеты. Для этого выделяется отдельная роль Tape Server, через которую проходят все операции с библиотекой.

Управление носителями

Вся логика работы с картриджами строится вокруг media pools — логических контейнеров с лентами:

• Служебные пулы (Free, Unrecognized, Imported, Retired) создаются автоматически
• Пользовательские пулы — для конкретных задач
• GFS media pool — готовая схема Grandfather-Father-Son без ручной настройки ротации: пять предопределённых уровней хранения, автоматическое создание полной копии из инкрементов

Несколько практических рекомендаций из Best Practice Guide. GFS-пулы не поддерживают параллельную обработку нескольких заданий — закладывайте это в расчёт окна резервного копирования. Media pool можно растянуть на несколько библиотек: если одна недоступна, задания продолжат работу через другую. При восстановлении это автоматически не сработает: кассету из недоступной библиотеки сначала нужно перенести физически и пересканировать. Под каждый тип данных с разными сроками хранения заводите отдельный пул — Veeam не перезапишет кассету, пока на ней есть хоть одна действующая точка восстановления.

Штрихкоды — обязательное условие нормальной работы. Veeam строго требует уникальности штрихкодов в рамках всей инфраструктуры.

WORM

WORM-картриджи хранятся в отдельном пуле — смешивать их с обычными нельзя.

Несколько нюансов. Veeam определяет WORM-картриджи при инвентаризации, но только если WORM-пул уже создан. Кассета, попавшая в обычный пул до инвентаризации, получит статус Unrecognized и не будет использована корректно. Заполненный WORM-картридж автоматически уходит в пул Retired — переиспользовать его нельзя, закладывайте это в расчёт ёмкости. Изменить срок хранения на уже записанной WORM-ленте невозможно никакими программными средствами — защита аппаратная, на уровне LTO-привода.

LTFS

Не используется нативно. Veeam создаёт собственный формат ленточной сессии с каталогом — читать данные можно только тем же Veeam, а не через монтирование ленты как файловой системы.

Шифрование

Поддерживается — как аппаратное (если привод заявляет поддержку LTO-4+), так и программное AES-256. Важный нюанс: если данные на дисковом репозитории уже зашифрованы — включение шифрования на ленте приведёт к двойному шифрованию, что снижает эффективность сжатия без прироста безопасности.

NDMP

Поддерживается, но с явной оговоркой прямо в Best Practice Guide: описывается как «terribly slow» — принудительный full-бэкап каждые 10 точек восстановления делает схему малопригодной для больших NAS-хранилищ.

Многопоточность и мультиплексирование — Veeam поддерживает оба механизма, но с важными ограничениями. Пул может раздавать несколько приводов разным tape-джобам одновременно — количество параллельных потоков определяется числом доступных приводов в пуле. Однако для GFS-пулов параллельная обработка нескольких заданий недоступна — это архитектурное ограничение, которое нужно закладывать в расчёт окна резервного копирования при использовании GFS. Мультиплексирование данных нескольких источников на один привод также поддерживается, но при этом данные разных заданий могут оказаться перемешаны на одной кассете — что усложняет восстановление конкретного источника в изоляции.

Virtual Full — начиная с Veeam Backup & Replication 10 синтетические операции для Virtual Full получили асинхронный движок чтения, что заметно ускорило их создание. Именно Virtual Full — рекомендованный разработчиками способ формировать полные резервные копии на ленте, а не гонять честный full-бэкап каждый раз через сеть.

Сжатие и дедупликация — если бэкапы Veeam уже сжаты (а это поведение по умолчанию), включение аппаратного сжатия на уровне LTO-привода не даст никакого выигрыша по ёмкости, но создаст лишнюю нагрузку.

Восстановление с ленты

Прямое восстановление VM или файлов с ленты в Veeam невозможно. Instant VM Recovery с ленты недоступен. Сначала данные копируются с ленты на дисковый репозиторий (операция Restore from Tape или Export Backup from Tape), затем — стандартное восстановление любого типа. RTO складывается из двух этапов: чтение с ленты плюс само восстановление.

При инкрементальной схеме Veeam читает с ленты всю цепочку — полный бэкап плюс все инкременты до нужной точки. Одна кассета с несколькими точками восстановления читается целиком, даже если нужен только последний инкремент. GFS с периодическими полными копиями сокращает цепочку и ускоряет восстановление.

Veeam ведёт каталог содержимого лент в своей базе данных. Поиск нужной точки восстановления занимает секунды — система знает, на какой кассете и в каком положении находятся данные. Если каталог утерян, потребуется операция Catalog Tape: она перечитывает метаданные с ленты, время пропорционально объёму данных.

Слабые места

Отсутствие прямого бэкапа на ленту — это принципиальное архитектурное решение, а не упущение. Но оно означает, что для полноценной работы с лентой всегда нужен промежуточный дисковый репозиторий, то есть нельзя построить схему «сервер → лента» минуя диск.

Восстановление с ленты также принципиально отличается от восстановления с диска. Instant VM Recovery с ленты недоступен — данные сначала должны быть полностью перенесены на дисковый репозиторий, и только потом становится возможным любой тип восстановления. При инкрементальной схеме бэкапа Veeam вынужден читать с ленты всю цепочку — полный бэкап плюс все инкременты до нужной точки, — даже если требуется только последний. Это напрямую влияет на RTO в сценариях восстановления именно с ленты.

Кибер Бэкап

Кибер Бэкап работает с лентой со времён, когда компания ещё входила в структуру Acronis.

Архитектура

Поддерживает запись бэкапов по схемам D2T и D2D2T. Управление библиотекой — через раздел Tape Management в консоли: инвентаризация, управление пулами, настройка ротации.

Подтверждена совместимость с российскими библиотеками линейки «ДИАМАНТ» (СЕЛЕНГА 400, 800, 2000 и СЕЛЕНГА.АРХИВ) с LTO-7, LTO-8, LTO-9 и LTO-10. В 2026 году, когда доступность западных библиотек ограничена, это весомый аргумент.

Управление носителями

Пулы лент с ротацией по схеме GFS: недельные, месячные и годовые копии, настраиваемые периоды хранения. Инвентаризация по штрихкодам, управление слотами и картриджами — через веб-консоль.

WORM

Поддерживается через аппаратный механизм LTO WORM-картриджей. Кибер Бэкап упоминает WORM в связке с ленточным air gap как защиту от ransomware.

LTFS

Кибер Бэкап поддерживает LTFS — данные читаются стандартными средствами ОС без самого продукта. Для архивов, которые хранятся 10–15 лет, это страховка: нет зависимости от того, будет ли Кибер Бэкап доступен при восстановлении.

Шифрование

Аппаратное шифрование AES-256 через LTO-привод. Нюанс для российского рынка: встроенное AES-256 LTO-привода не является сертифицированным СКЗИ по требованиям ФСТЭК/ФСБ. Для КИИ и госконтуров нужен отдельный сертифицированный продукт. Сам Кибер Бэкап имеет сертификат ФСТЭК, аппаратное шифрование ленты — нет.

NDMP

Поддерживается, зафиксировано в документации.

Многопоточность, мультиплексирование и управление лентами

Кибер Бэкап поддерживает оба режима:

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

Мультиплексирование — несколько агентов пишут потоки на одно устройство. Работает в средах с множеством одновременных заданий или с быстрыми приводами, которые принимают данные быстрее одного агента.

Если хранилище-источник использует дедупликацию, при репликации на ленту данные разворачиваются из дедуплицированного формата перед записью. Это создаёт повышенную нагрузку и замедляет процесс — при больших объёмах заметно.

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

Слабые места

Мониторинг здоровья носителей и предиктивная аналитика — слабее, чем у Commvault и Veeam.

RuBackup

Архитектура

RuBackup предлагает два типа пула для ленты — выбор делается при конфигурации:

• Tape library, LTFS — лента монтируется как файловая система, данные доступны без RuBackup стандартными средствами ОС. Управление утилизацией ресурсов библиотеки не оптимизировано.
• Tape library, Native — собственный формат, управление ресурсами оптимизировано, данные доступны только через RuBackup.

Управление носителями

В апреле 2026 года вышла версия 2.7 с подтверждённой совместимостью с библиотеками «ДИАМАНТ» серии СЕЛЕНГА (LTO-7–10). Пулы хранения, управление слотами, конфигурация библиотек — через веб-интерфейс.

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

WORM

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

LTFS

LTFS — один из двух нативных типов пула, не дополнительная опция. Выбирается при создании пула в конфигурации.

Шифрование

В публично доступной документации не упоминается.

NDMP

В публично доступной документации не упоминается.

Слабые места

RuBackup моложе Veeam и Commvault, и это отражается на функциональности: нет управления физическим перемещением картриджей, нет мониторинга носителей, нет GFS media pool с автоматической ротацией. Зато поддерживает российские библиотеки (ДИАМАНТ СЕЛЕНГА), входит в реестр российского ПО и нативно работает с LTFS.

AISHU AnyBackup

AISHU — китайский вендор с фокусом на корпоративный сегмент Китая, постепенно выходящий на российский рынок.

Управление носителями

Данные архивируются на ленточные библиотеки по политикам. В версии 7.0.17.1 добавлена прямая запись файловых систем на ленту (D2T). В более ранних версиях — только D2D2T.

WORM

В публично доступной документации не упоминается.

LTFS

В публично доступной документации не упоминается.

Шифрование

В публично доступной документации не упоминается применительно к ленте.

NDMP

В публично доступной документации не упоминается.

Слабые места

Из шести продуктов AnyBackup задокументирован по работе с лентой меньше всего. Release notes показывают развитие функциональности, но оценить реальные возможности по публичным материалам невозможно.

Vinchin Backup & Recovery

Vinchin — китайский продукт, ориентированный прежде всего на резервное копирование виртуальных машин.

Управление носителями

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

WORM

Документации по настройке WORM в Vinchin нет — неясно, реализована ли поддержка на уровне продукта или только на уровне LTO-привода.

LTFS

В публично доступной документации информация отсутствует.

Шифрование

Упоминается аппаратное шифрование AES для LTO-6 и выше, рекомендуются внешние ключевые серверы. Деталей реализации нет.

NDMP

В публично доступной документации не упоминается.

Слабые места

Поддержка ленточных библиотек в Vinchin — базовая. Лента воспринимается как дополнительная возможность, не приоритетный сценарий.

Сводная таблица

Параметр	Commvault	Veeam	Кибер Бэкап	RuBackup	AISHU AnyBackup	Vinchin
Прямой бэкап на ленту (D2T)	Да	Нет	Да	Да	Да	Нет
GFS-ротация	Да, через Storage Policy	Да, нативный GFS media pool	Да	Не подтверждено	Не подтверждено	Не подтверждено
WORM	Да, автоопределение через MediaAgent	Да, отдельный пул; по штрихкоду или при инвентаризации	Да	Не подтверждено	Не подтверждено	Не подтверждено
LTFS	Опционально (для обмена данными)	Нет	Да, нативно (тип пула)	Да, нативно (тип пула)	Не подтверждено	Не подтверждено
Шифрование на ленте	Да, KMIP, аппаратное + программное	Да, аппаратное (LTO-4+) + программное AES-256	Да, AES-256 (аппаратное LTO)	Не подтверждено	Не подтверждено	Да, AES (LTO-6+); внешние ключевые серверы
NDMP	Да	Да, с ограничениями	Да	Не подтверждено	Не подтверждено	Не подтверждено
VTL	Да	Да	Да	Да	Да	Не подтверждено
Управление перемещением картриджей	Да	Нет	Нет	Нет	Нет	Нет
Штрихкоды	Да, с кастомными паттернами	Да, обязательно; тип по суффиксу штрихкода	Да	Да	Не подтверждено	Да
Мультиплексирование	Да	Да	Да	Не подтверждено	Не подтверждено	Не подтверждено
Многопоточность	Да	Да	Да	Не подтверждено	Не подтверждено	Не подтверждено
Поддержка российских библиотек	Нет	Нет	Да (ДИАМАНТ СЕЛЕНГА LTO-7–10)	Да (ДИАМАНТ СЕЛЕНГА LTO-7–10)	Не подтверждено	Не подтверждено
Сертификация ФСТЭК	Нет	Нет	Да	Да	Нет	Нет

Выводы

Veeam и Commvault — наиболее зрелые решения. Vault Tracker в Commvault — уникальная функция управления физическим перемещением носителей, аналогов нет ни у кого из шести. Veeam выигрывает по экосистеме и документации, но проигрывает по отсутствию D2T и слабому NDMP.

Кибер Бэкап закрывает LTFS, WORM, NDMP и GFS, имеет сертификацию ФСТЭК и работает с российскими библиотеками. Для организаций, которым нужны и функциональность, и соответствие регуляторам, — сбалансированный выбор.

RuBackup использует LTFS как нативный тип пула — архитектурно грамотное решение для долгосрочных архивов. Мониторинга носителей и GFS пока нет.

Vinchin и AISHU AnyBackup — базовая поддержка ленты, не более. Перед выбором этих продуктов для сценариев с интенсивным использованием ленты — обязателен пилот под конкретно ваши задачи.