Всё о моём опыте с лентами и стримером

Пять лет ещё не прошло с начала игр с ними, но скоро будет.

* Использую я LTO4, которые на 800GB или ~745GiB (то что показала бы ОС)
* Есть 1 LTO5, шедшая в комплекте со стримером, которую я для временной
  записи чего-то большого, что не умещается разом на LTO4, использовал
* LTFS не пробовал, хотя видел FUSE драйвер. Пишу я простым обычным BSD
  tar-ом. Он не поддерживает multi-volume архивы, когда если стример
  сообщает о том что место кончилось, то он позволил бы вставить
  следующую ленту и продолжить на ней. Заранее просто через split
  команду создают .tar00, .tar01 архивы
* Пишу я tar-ом ещё и потому, что он блюдёт размер блока фиксированного,
  что стример очень любит и работает на максимальной скорости без проблем
  при этом
* Сжатие (mt comp on) не использую. Разве оно может сравнится с offline
  сделанным zstd например?
* Сжимаю я всё что сжимается. Шифрую (GnuPG) всё что не стоит всем
  показывать, в случае попадания лент в чужие руки. Да, это всё означает
  что если файл будет бит, то я ничего из него не восстановлю. И я не
  использую никаких par2. Я просто слепо верю в то, что на ленте и так,
  как пишут, своей избыточности достаточно много
* По умолчанию у меня в настройках было выставлено использование Twofish
  алгоритма шифрования. Для шифрования лент у меня отдельный offline
  ключ, который по умолчанию тоже стал иметь это предпочтение. Он, как и
  не ускоренный AES -- медленный и я всегда упираюсь в CPU. Теперь стал
  использовать AES, но без OCB режима, так как лень обновлять GnuPG на
  сервере к которому подключён стример. Всё же считывание данных с лент
  это очень редкое действие у меня на практике, поэтому не так к спеху
* Практически все ленты пишутся в двух экземплярах, идентичных копиях.
  Вторая копия относится в географически другое место
* Из всех лент, которых более 80 штук, которые почти все я купил у
  одного человека, которые были списаны по причине upgrade-а их
  библиотеки, только две были неисправны. Они видятся, даже немного
  пишутся, но возникают ошибки. Но при этом мне две ленты он давал
  просто так в подарок как постоянному оптовому покупателю
* Ни разу не было чтобы я что-то не смог прочитать с них, хотя конечно и
  не проходит так много времени чтобы убедиться в действительно их
  долговечной надёжности
* Но я стараюсь их хранить вне сквозняков. При перетаскивании на холоде,
  помещаю в теплоизолированные сумки, не оставляя например в холодной
  машине
* Даже без LTFS на них можно дозаписывать данные и прыгать по меткам
  между ними. Но для этого надо вести какой-то учёт, индекс того, что
  где размещено. Мне лень. Поэтому все они записываются в виде одного
  tar-а одной записью
* Из-за этого нельзя с произвольного места, произвольный файл прочитать
  с ней. Поэтому любое чтение это всегда tar xf /dev/esa0 -- полное
  чтение всей ленты. Так проще
* Прежде я агрегировал недельные бэкапы всех своих систем на жёстких
  дисках. Когда их объём становился достаточно большим, то скидывал на
  очередную свободную пару лент. Сейчас забил. По сути мне ни разу не
  требовались старые резервные копии. Или то что имеется в пределах
  snapshot-а ZFS недельного, или то, что вообще отсутствует на диске но
  выгружено отдельным файлом на ленты (типа "резервная копия какой-то
  там CentOS на которой я проверял такую-то софтину, где остался
  исходный код, сборочная система и я не знаю вообще нужно ли это мне
  ещё когда-нибудь будет, но мало ли")
* Прежде я старался по полной забивать каждую ленту до отказа. Осталось
  200 GB свободных? Ещё одну копию фотографий туда забацать! Сейчас
  перестал. Во-первых это не уменьшает износ: наполовину заполненная
  лента служит в два раза дольше. То есть, износ делает не загрузка
  ленты, а её проматывание. Во-вторых, просто удобнее иметь более
  "короткие" ленты с чётко заданными данными, чем постоянную мешанину
  которую дольше считывать
* Когда-то у меня были всякие копии wikipedia (очень правда старых
  срезов), но сейчас от них избавился. Или нужно иметь свежий срез, но
  на него у меня нет места или нафиг. Если отключат Интернет, то
  какие-то БД и сборники всякой всячины у меня конечно есть, но они не
  существенно помогут. Есть срезы wikipedia в виде ZIM файлов -- просто
  лучше чем ничего
* Кол-во лент для моих нужд небольших мне хватает. Для wikipedia полной
  или какого-нибудь scimag -- нет. Но и покупать новые я уже как-то и не
  горю желанием из-за цены. Стоимость самого стримера такова, что он
  окупается только при объёмах в сотни терабайт. Даже для scimag или
  wikipedia... дешевле купить современные очень ёмкие жёсткие диски и
  держать в массивах регулярно делая scrub. Если не дешевле, то конечно
  и удобнее. Ленты это всё же для очень больших данных (чтобы окупалось)
  и для архивов
* Единственный софт для ведения базы данных этих лент это... tapes.txt
  файлик под Vim-ом. Каждый параграф в нём состоит из пары строчек с
  серийными номерами лент (оно наклеено на сам картридж и сбоку видно),
  а дальше просто из "ls -1" вывода файлов на них содержащихся, которых
  не много как правило: если мне надо записать архив со всеми моими
  подкастами, то я создаю podcast-DATE.tar и его помещаю в архив на
  самой ленте: tar cf /dev/*sa0 podcast-DATE.tar
* Раз в полтора года я перезаписывал многие ленты оставляя только самые
  свежие и актуальные архивы, снова освобождая много из них. В этом году
  решил просто перезаписывать поверх старых, учитывая что "мешанины" у
  меня будет меньше. Не должно быть лент с "музыка+фильмики+фотографии",
  а должно быть три со всеми этими архивами отдельно, позволяя просто
  обновить только нужную коллекцию
* У меня сильные подозрения что мой опыт по ведению всего этого
  хозяйства просто смехотворен и зелен. Наверняка. Но меня не сильно это
  парит, ибо это just-for-fun главным образом. Ибо это всё не отменяет
  что фотографии, музыка (а это две самых ценных вещи что у меня есть,
  ибо моё собрание музыки хрен откуда скачаешь и добудешь) всё равно
  находятся на ZFS массиве тоже
* Один жёсткий диск с ZFS не пригоден для работы с лентами. ZFS всё же
  имеет кой какой но overhead и скорость последовательного чтения чуть
  пониже чем максимальная что может выдать сам диск. Речь про диски не
  самые свежие и современные, но всё равно 2-3-х терабайтные. Они сами
  по себе могут выдать 140MiB/sec зачастую, что требуется и при записи
  ленты, но чуть проседающий overhead от ZFS уже недостаточен для
  "насыщения" канала стримера и он вынужден время от времени
  останавливаться, чуть отматывать ленту назад, продолжать запись, что и
  изнашивает её и сильно замедляет весь процесс записи. Чтение с ленты
  на ZFS на один диск делается без проблем, overhead тут не мешает
* Поэтому приходится или с массива читать или с UFS2 файловой системы. У
  меня есть отдельная не всегда включённая SAS корзина с 4-мя 450GiB
  дисками в RAIDZ1, которую я часто и использую для работы с лентами.
  Ибо держать её постоянно включённой тоже не охота для раздачи торрентов
* Скорость LTO5/LTO6 чуть повыше, но одного современного диска всё же
  должно быть достаточно. А вот LTO7 уже имеет скорость в 300MiB/sec и
  там без массивов не обойтись. Ну или без SSD, но я в живую SSD на 6TB
  не видел, чтобы можно было бы разом записать на ленту всё что хочется
* Упоминал про LTFS, но только сейчас вспомнил что его можно
  использовать только начиная с LTO5, которых у меня одна штука. Так что
  можно не переживать по поводу того, что возможно с ним тьма проблем бы
  в плане удобства решалась сразу
* Безумно удобна возможность отправки SIGINFO сигнала в BSD tar через
  Ctrl-T, который покажет нечто типа:
    In: 7 files, 356068175872 bytes; Out: 356068175872 bytes, compression 0%
    Current: photoes.tar (75536662528/139850764800 bytes)
* Стример жрёт под 90W энергии. Если внутренний, то нужно реально думать
  об охлаждении. У меня сейчас внешний с собственным вентилятором --
  проблем нет, лента при вынимании не горячая
* Он громкий. Он буквально визжит. При этом не монотонно, а
  останавливаясь каждые несколько десятков секунд, меняя направление
  головки (серпантинная дорожка), далее снова разгоняясь до визга. Спать
  рядом с таким не выйдет без берушей. У меня он в другой комнате, в
  которую приходится закрывать дверь или две двери
* Идея с тремя разными device node-ами просто гениальна по удобству! При
  прекращении чтения/записи из/в nsaX -- он оставит головку на том же
  самом месте где и остановились.
    tar cf /dev/nsa0 file1 ; tar cf /dev/nsa0 file2
  создаст две записи на ленте. В первой будет архив с file1, во второй с
  file2. mt fsf позволяет прыгнуть на следующие записи. saX перемотает в
  начало ленты после закрытия файла devnode-ы. Равносильно использованию
  nsaX с mt rewind после. esaX используется мною чаще всего -- оно eject
  ленту после обработки. Так как прочитать с ленты и сразу же на неё
  что-то записать требуется редко, то это удобно. Вынутая лента видна
  визуально -- сигнал о том что процесс завершился. Плюс я часто же
  оставляю писаться/читать на ночь и не хотел бы чтобы оставшиеся кучу
  часов оно в раскрытом состоянии находилось внутри стримера
* Хоть лента и по последовательным скоростям сравнима с жёстким диском,
  но из-за объёма весь процесс чтения/записи занимает часы! Как и с
  жёстким диском конечно же. Но если на последнем, при наличии файловой
  системы, мы можем один из тысяч произвольных файлов прочитать, то на
  ленте (без LTFS, без индекса и файлов побитых по записям) доставание
  нужного файла стоит оценивать как полное её чтение на жёсткий диск, а
  дальше уже вынимание нужного с его файловой системы
* С совместимостью у стримеров, насколько понимаю, проблем нет никаких.
  SAS/SCSI tape drive -- везде должен без проблем работать. Но нужен SAS
  контроллер. Знаю что есть home-grade решения подключаемые по
  Thunderbolt, где наверное SAS контроллер просто встроен в сам стример,
  но и цена у них будет ещё выше
* Пользоваться tar-ом совершенно не обязательно! Ничто к этому не
  принуждает. Я делал и zfs send запись прямо на ленту. Единственное о
  чём нужно помнить -- размер блока для записи, к которому стример
  чувствителен. Детали уже не помню, но вроде это 10240 байт. На других
  он то ли откажется работать, то ли будет на ещё каком-то одном
  работать, но в два раза меньшей скоростью. Лень искать в блоге, но об
  опыте этом всём писал. То есть, просто не забывать делать не
  "> /dev/esaX", а через "dd bs=XXX" соответствующий