Ленточные библиотеки: разбираемся, как это работает и почему это до сих пор актуально
Итак, сегодня поговорим про ленту. Да-да, ту самую магнитную ленту, про которую половина айтишников младше тридцати знает только «ну это как-то дед бэкапил, наверное». А зря — технология живее всех живых, и буквально в конце 2025 — начале 2026 вышло уже десятое поколение LTO. Так что повод разобраться назрел.
Сразу скажу — моя задача не в том, чтобы уговорить вас бежать и покупать ленточную библиотеку. Я постараюсь объяснить, как это устроено технически, зачем оно вообще нужно в мире SSD и облаков, и на что обратить внимание, если вы всё-таки решите с этим связаться — будь то домашняя лаборатория или реальный проект на работе.
Что вообще такое ленточная библиотека
Если совсем просто — это шкаф с роботом внутри. В шкафу лежат картриджи с лентой (полки называются слотами), есть один или несколько приводов для чтения/записи, и есть механическая рука, которая по команде софта резервного копирования достаёт нужный картридж и суёт его в привод. Всё. Дальше уже дело техники — в прямом смысле слова.
Три компонента, которые стоит запомнить:
— картридж — кассета с лентой внутри, собственно носитель;
— привод (drive) — устройство, которое читает и пишет;
— робот — та самая рука-манипулятор, которая двигает картриджи между слотами и приводом.
Отдельный привод без библиотеки называется стримером — им можно попользоваться, если объёмы небольшие и картриджи меняются не часто, но как только речь заходит о десятках и сотнях кассет, вручную вы уже не набегаетесь, и нужна автоматизация.
Как лента вообще пишет данные — немного физики
Тут я, пожалуй, немного углублюсь, потому что без этого сложно понять, откуда взялись все эти цифры про ёмкость и скорость.
Есть два принципиально разных метода записи на магнитную ленту. Один — наклонно-строчный (helical scan), как в старых видеомагнитофонах: вращающийся барабан пишет данные по диагонали. Второй — линейный (linear serpentine recording), и именно он лёг в основу LTO. Головка неподвижна, лента протягивается мимо неё в одну сторону, дописывает дорожку до конца — и лента едет в обратную сторону, а головка сдвигается на следующий набор дорожек. Получается своего рода «змейка» — отсюда и название. Так повторяется, пока не будут исписаны все дорожки по ширине ленты.
Почему выбрали именно линейный метод? Он проще механически и надёжнее — меньше движущихся частей, меньше что может сломаться, и он лучше масштабируется по плотности дорожек.
Дальше — интересный момент, о котором мало кто задумывается. На ленте, помимо самих дорожек с данными, есть ещё и сервополосы — опорные дорожки, записанные на заводе, по которым головка в реальном времени понимает, где она находится, и корректирует своё положение. Без этого невозможно было бы удержать сотни дорожек на ленте шириной в полдюйма с той плотностью, которая нужна для десятков терабайт на картридж.
В LTO-10 ещё и материалы поменяли: магнитное покрытие теперь на основе барий-феррита (более мелкая и стабильная зернистость, чем у металлического порошка в старых лентах), а головки — с технологией TMR (туннельное магнитосопротивление), которая умеет считывать очень слабые сигналы от плотно упакованных битов. А в расширенной версии LTO-10 на 40 ТБ ещё и подложку ленты сделали из арамидного волокна — она тоньше и глаже, и в тот же самый корпус картриджа влезает больше метров ленты. Причём заметьте — без переделки приводов, то есть уже купленное «железо» продолжает работать.
LTO: краткая история и таблица поколений
LTO (Linear Tape-Open) — открытый стандарт, который в конце 90-х придумали IBM, HP и Seagate специально как альтернативу закрытым форматам вроде DLT. Идея простая: сделать так, чтобы картриджи и приводы разных производителей были взаимозаменяемы, и чтобы заказчик не был привязан к одному вендору намертво.
Вот табличка на wiki, которая, думаю, многим пригодится для ориентира:
Общая динамика проста: примерно раз в 2–3 года ёмкость вырастает в полтора-два раза.
Отдельно стоит сказать про совместимость. Правило простое: привод читает на два поколения назад, пишет — на одно. То есть LTO-8 читает 8, 7 и 6, а пишет только 8 и 7. Логично и предсказуемо — до LTO-10.
А вот тут внимание: приводы LTO-10, не имеют обратной совместимости с картриджами LTO-9. Это разрыв привычной цепочки, и если у вас в архиве лежат горы лент девятого поколения, а вы планируете переезд на десятое — уточняйте это у вендора, прежде чем что-то заказывать.
LTFS — файловая система для тех, кто не хочет писать скрипты под tar
С пятого поколения LTO появилась поддержка партиционирования — лента делится на два логических раздела: маленький под индекс (каталог) и большой под сами данные. На этой базе IBM сделала **LTFS** — файловую систему, которая позволяет монтировать картридж как обычный диск и работать через файловый менеджер, без специализированного бэкап-софта.
Звучит здорово, но есть нюанс: ОС хоть и видит содержимое ленты как папку с файлами, но для реально быстрого последовательного чтения большого объёма лучше не полагаться на штатные средства системы, а использовать специализированную утилиту — она знает физическое расположение файлов на ленте и умеет читать их за один проход, а не скакать туда-сюда по ленте, теряя время.
И ещё момент — классические бэкап-системы обычно не используют LTFS, а создают собственную ленточную сессию с выделенным каталогом. Тоже быстро (поиск занимает меньше минуты), но читать такую ленту сможет только тот же самый софт, которым она писалась — в отличие от LTFS, где содержимое можно прочитать штатными средствами любой ОС.
Из чего состоит библиотека как железка
Теперь про само оборудование. Кроме уже упомянутых слотов, привода и робота, в реальной библиотеке есть:
— слоты импорта/экспорта (mail slots) — специальные ячейки, через которые можно загружать и выгружать картриджи, не открывая основной корпус. Это важно и для микроклимата внутри, и для того, чтобы вывозить ленты за пределы дата-центра без остановки библиотеки;
— штрихкоды и/или RFID-метки — для автоматической инвентаризации без физического извлечения картриджа;
— контроллер — плата, которая принимает команды от бэкап-софта (через протокол SCSI Medium Changer) и командует роботом и приводами.
Масштаб современных корпоративных библиотек, впечатляет. Вот пара примеров для ориентира:
— HPE T950 — в максимальной конфигурации до 738 слотов и 4 привода на фрейм, скорость передачи на LTO-8 до 155,5 ТБ/ч без сжатия;
— IBM TS4500 — с фреймами расширения до 128 приводов и 1536 картриджей одновременно, ёмкость без сжатия до 175 ПБ (со сжатием — до 526 ПБ);
— Quantum Scalar i6000 — конкурент IBM в этом сегменте, архитектура с единым роботом на всю библиотеку и функцией Active Vault, которая позволяет «складировать» редко используемые картриджи прямо внутри библиотеки для более дешёвого и защищённого хранения без физического извлечения.
Подключаются такие махины обычно по SAS (для небольших и средних инсталляций) или по Fibre Channel, если нужно, чтобы к библиотеке одновременно обращалось несколько серверов через SAN.
Зачем всё это, если есть диски и облако
Вопрос закономерный, и у меня на него есть развёрнутый ответ.
Энергопотребление. Картридж в слоте библиотеки не потребляет вообще ничего — в отличие от дискового массива, который должен быть постоянно включён, даже если данные с него читают раз в год. Лента «активна» только когда она в приводе. Это прямо бьёт по совокупной стоимости владения.
Цена за терабайт. На масштабах в петабайты лента заметно дешевле дисков и облака, особенно если считать не только капитальные затраты на закупку, а горизонт в 5-10 лет.
Срок хранения. 15–30 лет по консервативным оценкам, по заявлениям некоторых производителей — до 50 лет. И этот срок можно продлить, если при каждом резервном копировании не забивать ленту под завязку, а использовать не более половины ёмкости — меньше механического износа при каждом проходе.
Плотность. IBM с Fujifilm в экспериментальном образце дожали ленточный накопитель до 580 ТБ на единицу — рекорд среди вообще всех типов носителей. Для сравнения, максимальная ёмкость коммерческих SSD на тот момент не превышала 100 ТБ.
Расплата, разумеется, есть — это скорость произвольного доступа. Перемотка ленты для поиска нужного участка может занять до минуты, тогда как SSD или HDD справляются за миллисекунды. Поэтому лента годится там, где данные пишутся и читаются последовательно большими потоками — что как раз характерно для бэкапов и архивов, а не для случайного доступа к отдельным файлам.
А теперь про самое горячее — защита от шифровальщиков
Вот это, пожалуй, главная причина, почему лента снова на слуху в последние пару лет. Работают тут два независимых механизма, и оба стоит разобрать отдельно, потому что их часто путают.
Air gap («воздушный зазор»). Пока картридж в приводе — он теоретически доступен по сети (в рамках того, что позволяет бэкап-софт). Но как только его вытащили и он лежит в слоте (или тем более физически вывезен из дата-центра) — он полностью отключён от какой-либо сети. Вредонос до него физически не доберётся, потому что ему просто не через что «дотянуться». Это принципиально отличается от дисковых копий: даже изолированный бекап на дисковой системе остаётся на постоянно подключённом к сети оборудовании, и теоретически уязвим, если атакующий получит достаточные привилегии в инфраструктуре. Тут оговорюсь, что есть разработки и для дисковых массивов, позволяющие организовать air gap на дисковых хранилищах, например в решении Cyber Recovery Solution от Dell.
WORM (Write Once Read Many). Данные можно записать один раз, а изменить или удалить программным путём — уже нет. Технология изначально появилась именно на ленте, и лишь потом перекочевала на диски (у NetApp это, например, называется SnapLock). Для библиотек WORM защищает архив даже в сценарии, когда атакующий уже получил админский доступ к самой системе резервного копирования — потому что перезапись физически заблокирована на уровне носителя или контроллера картриджа.
Тут важно не впадать в маркетинговую эйфорию: сама по себе лента — не какое-то волшебное противоядие от вирусов. Она просто дешёвая, ёмкая и может очень долго лежать в полностью автономном режиме. Именно сочетание этих трёх качеств и делает её удобным последним рубежом обороны, а не какая-то особая «противовирусная» магия.
Что нужно знать, если вы всё-таки решите с этим работать
Пара практических моментов:
Ротация по схеме GFS. Классика — Grandfather-Father-Son: ежедневные копии («сын») перезаписываются еженедельно, еженедельные («отец») — ежемесячно, а ежемесячные («дед») хранятся дольше или уходят в постоянный архив. Баланс между стоимостью носителей и глубиной истории восстановления.
Чистка головок. Головки со временем загрязняются частицами с ленты, поэтому в приводах есть механизм автоматической очистки — обычно с помощью специальных чистящих картриджей, которые надо менять по регламенту, а не по факту появления ошибок. Не ждите, пока начнёт сыпаться, — профилактика дешевле разгребания последствий.
Требования к помещению. В отличие от дисков, крупные библиотеки — это тяжёлое оборудование с требованиями к вентиляции, температуре и нагрузке на пол. Заказывая условный IBM TS4500 или HPE T950 в максималке, отдельно планируйте маршрут доставки и место в серверной.
Совместимость с бэкап-софтом. Прежде чем покупать конкретную модель, убедитесь, что ваш бэкап-софт умеет с ней работать и поддерживает нужные вам функции — партиционирование, WORM, шифрование на уровне привода. Это несложно проверить заранее, но очень неприятно выяснять постфактум.
Best practice по работе с лентой в Veeam
Раз уж мы заговорили о практике — у Veeam есть официальный Best Practice Guide именно по tape-модулю, и там собрано довольно много полезного — накидаю здесь то, что считаю важным на старте.
Роль Tape Server. В Veeam за работу с библиотекой отвечает отдельная роль — Tape Server. Она может стоять как на Windows, так и на Linux — при достаточных ресурсах разницы в производительности нет, так что линуксовый tape-сервер даёт вам больше гибкости. Роль можно совместить с ролью Repository на одной машине, чтобы сократить сетевые узкие места при передаче данных — а вот с ролью Hardened Linux Repository совмещать её нельзя, это ограничение прямо прописано в документации.
Библиотека — только для Veeam. Рекомендация звучит строго, но логично: если библиотека используется одновременно Veeam и каким-то сторонним ПО (например, в тестовой лаборатории), это может помешать записи со стороны другого софта. Лучше выделить библиотеку под один продукт.
Media pools — как Veeam организует картриджи. Всё крутится вокруг так называемых media pools — логических контейнеров с лентами. Есть служебные пулы, которые Veeam создаёт и ведёт сам:
— Free — пустые ленты, готовые к использованию;
— Unrecognized — непонятные ленты, которые Veeam не смог опознать (чтобы случайно не затереть);
— Imported — ленты с чужими данными после инвентаризации, вы сами решаете, оставить их как есть или отправить в Free на перезапись;
— Retired — изношенные или сломанные ленты, которые больше не используются.
Поверх этого вы создаёте собственные пользовательские пулы под конкретные задачи, и отдельно — GFS media pools, если хотите вести долгосрочное хранение по схеме Grandfather-Father-Son прямо на уровне Veeam, а не городить это руками через несколько обычных Backup to Tape джобов. GFS-пул сам держит пять предопределённых media set’ов (по сути — уровней хранения) и умеет строить полный бэкап из инкрементов на нужный день по расписанию.
Не мешайте WORM и обычные ленты. Отдельная и важная деталь: если хотите использовать WORM-картриджи, под них нужно завести отдельный WORM-пул. Смешивать обычные перезаписываемые и WORM-ленты в одном пуле нельзя — это прямо не рекомендуется.
Virtual Full — рекомендованный способ класть данные на ленту. Начиная с Veeam Backup & Replication 10, синтетические операции для Virtual Full получили асинхронный движок чтения, что заметно ускорило создание таких копий. Именно Virtual Full — рекомендованный вендором способ формировать полные копии на ленте, а не гонять честный full-бэкап каждый раз через сеть.
Несколько приводов — несколько джобов параллельно. Если в библиотеке несколько приводов, media pool может раздать их разным tape-джобам одновременно: настроили лимит в три привода — значит, до трёх джобов пишут параллельно, а остальные встают в очередь и подхватывают освободившийся привод. Обратите внимание — для GFS-пулов параллельная обработка недоступна, это ограничение архитектуры.
Отказоустойчивость между библиотеками. Кастомный media pool можно растянуть на несколько библиотек — если один tape-сервер или библиотека уходит в офлайн, Veeam продолжит писать через второй. Но для восстановления это работает не так гладко: если лента физически лежит в библиотеке, которая сейчас недоступна, восстановиться напрямую не получится — сначала нужно физически переставить картридж в рабочую библиотеку и пересканировать её, только тогда данные станут видны для восстановления.
Штрихкоды — обязательны. Работайте с лентами только через штрихкоды, проверяйте их целостность перед вводом в эксплуатацию и следите, чтобы в рамках всей инфраструктуры (если у вас несколько библиотек) штрихкоды не повторялись — иначе Veeam будет путать картриджи.
Вывозите ленты регулярно — иначе никакого air gap не будет. Вот это, мне кажется, самый недооценённый пункт из всего гайда. Если картриджи просто лежат в слотах библиотеки постоянно, они всё ещё технически доступны для перезаписи в случае, если атакующий получил контроль над инфраструктурой — то есть настоящего воздушного зазора у вас нет. По-настоящему air-gapped резервной копией можно считать только те ленты, которые физически вывезены и хранятся отдельно, вне досягаемости сети. Экспортируйте и ротируйте ленты регулярно, а для дополнительного слоя защиты используйте WORM.
По железу. Используйте отдельные драйверы для приводов и для самого чейнджера библиотеки, а не общие Windows-драйверы «из коробки» — они не всегда дают такую же производительность, как фирменные драйверы вендора.
Планируйте retention реалистично. Если в пуле не осталось свободных лент, tape-джоб не упадёт сразу — он будет ждать освобождения ленты до 72 часов, и только потом завершится с ошибкой. Это удобный запас времени, чтобы вручную докинуть картриджи, но рассчитывать только на это в проде я бы не стал — лучше держать пул из свободных лент с запасом.
Если резюмировать — большая часть best practice сводится к простому принципу: разделяйте роли и типы данных (отдельный tape-сервер, отдельные пулы для WORM), не экономьте на резервировании (несколько библиотек, штрихкоды без дублей) и не забывайте, что air gap — это не галочка в настройках, а физическое действие: вынуть картридж и увезти его подальше от сети.
Резюме
Ленточные библиотеки — далеко не музейный экспонат. LTO-10 с ёмкостью картриджа до 40 ТБ, аппаратным AES-256, WORM и RFID-инвентаризацией — это живая, развивающаяся технология с прописанной дорожной картой аж до LTO-14. Сила ленты не в скорости произвольного доступа, а в комбинации низкой стоимости хранения, минимального энергопотребления, десятилетий срока службы и физической изоляции от сети — то есть в том самом air gap, который делает её одним из немногих реально надёжных рубежей защиты от шифровальщиков.
Подборка ссылок: вендорская документация по лентам
IBM Redbooks
IBM Tape Library Guide for Open Systems (18-е издание) — обзорная библия по всей линейке: LTO Ultrium, приводы TS11xx, автозагрузчик TS2900, библиотеки TS4300 и TS4500, SCSI/FC подключения
IBM TS4500 R9 Tape Library Guide — детальный разбор конкретно TS4500: компоненты, коды функций, шифрование, управляющая консоль (IMC), CLI и REST API
IBM Diamondback Tape Library Guide — новейшая сверхплотная библиотека IBM (1548 слотов под LTO-9, до 27,8 ПБ без сжатия), отдельно расписан air gap и Safeguarded Tape
IBM Linear Tape File System (LTFS) — Enterprise Edition — если хотите разобраться в LTFS EE на уровне установки и конфигурации, а не только общего принципа
IBM Spectrum Archive SDE и LE — про то, как сделать так, чтобы лента вела себя как обычный съёмный диск, с таблицами поддерживаемых приводов и партиционирования LTFS
HPE
HPE StoreEver MSL2024/4048/8048/8096 — User and Service Guide — если у вас библиотека этой линейки, это ваша настольная книга: от установки до troubleshooting
Data protection of virtual machines with HPE StoreEver Tape Libraries — отдельный вайтпейпер именно про связку HPE StoreEver + Veeam, с разбором автообнаружения библиотеки и архитектуры
HPE StoreEver Tape Libraries with HP Data Protector — Implementation Guide — если у вас в инфраструктуре Data Protector, а не Veeam
Quantum
Scalar Tape Libraries Datasheet — актуальный даташит по всей линейке Scalar (i3/i6/i7), с описанием iLayer, Active Vault и Scalar Security Framework
LTO: The New «Enterprise Tape Drive» — вайтпейпер Quantum с сравнением LTO против проприетарных форматов и разбором TCO
DXi-Series Configuration and Best Practices Guide for Veeam Backup & Replication — если планируете виртуальную ленточную библиотеку (VTL) на дисковом бэкенде Quantum DXi вместо физической
Veeam
Tape | Veeam Backup & Replication Best Practice Guide — тот самый раздел, на основе которого я писал главу про best practice выше: media pools, GFS, сайзинг
Tape Operations | Veeam Backup & Replication Best Practice Guide — операционная часть: как ведут себя разные типы бэкап-цепочек при записи на ленту, параллельная обработка джобов
Tape Server | Veeam Backup & Replication Best Practice Guide — сайзинг самого tape-сервера (ядра, память, сколько потоков на привод)
Tape Job Encryption | Veeam Backup & Replication Best Practice Guide — отдельно про шифрование на ленте: аппаратное vs программное, управление ключами
Backup Tape Storage Best Practices (блог Veeam) — более неформальный разбор от инженера саппорта Veeam, откуда я брал часть рекомендаций по air gap
