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

Что: b10b27905edfce6ad8054172f508ada4e3ebc09f

Когда: 2022-02-03 10:39:40+03:00

Темы: hard

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

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


  записи чего-то большого, что не умещается разом на LTO4, использовал

  tar-ом. Он не поддерживает multi-volume архивы, когда если стример
  сообщает о том что место кончилось, то он позволил бы вставить
  следующую ленту и продолжить на ней. Заранее просто через split
  команду создают .tar00, .tar01 архивы

  что стример очень любит и работает на максимальной скорости без проблем
  при этом

  сделанным zstd например?

  показывать, в случае попадания лент в чужие руки. Да, это всё означает
  что если файл будет бит, то я ничего из него не восстановлю. И я не
  использую никаких par2. Я просто слепо верю в то, что на ленте и так,
  как пишут, своей избыточности достаточно много

  алгоритма шифрования. Для шифрования лент у меня отдельный offline
  ключ, который по умолчанию тоже стал иметь это предпочтение. Он, как и
  не ускоренный AES -- медленный и я всегда упираюсь в CPU. Теперь стал
  использовать AES, но без OCB режима, так как лень обновлять GnuPG на
  сервере к которому подключён стример. Всё же считывание данных с лент
  это очень редкое действие у меня на практике, поэтому не так к спеху

  Вторая копия относится в географически другое место

  одного человека, которые были списаны по причине upgrade-а их
  библиотеки, только две были неисправны. Они видятся, даже немного
  пишутся, но возникают ошибки. Но при этом мне две ленты он давал
  просто так в подарок как постоянному оптовому покупателю

  не проходит так много времени чтобы убедиться в действительно их
  долговечной надёжности

  помещаю в теплоизолированные сумки, не оставляя например в холодной
  машине

  между ними. Но для этого надо вести какой-то учёт, индекс того, что
  где размещено. Мне лень. Поэтому все они записываются в виде одного
  tar-а одной записью

  с ней. Поэтому любое чтение это всегда tar xf /dev/esa0 -- полное
  чтение всей ленты. Так проще

  дисках. Когда их объём становился достаточно большим, то скидывал на
  очередную свободную пару лент. Сейчас забил. По сути мне ни разу не
  требовались старые резервные копии. Или то что имеется в пределах
  snapshot-а ZFS недельного, или то, что вообще отсутствует на диске но
  выгружено отдельным файлом на ленты (типа "резервная копия какой-то
  там CentOS на которой я проверял такую-то софтину, где остался
  исходный код, сборочная система и я не знаю вообще нужно ли это мне
  ещё когда-нибудь будет, но мало ли")

  200 GB свободных? Ещё одну копию фотографий туда забацать! Сейчас
  перестал. Во-первых это не уменьшает износ: наполовину заполненная
  лента служит в два раза дольше. То есть, износ делает не загрузка
  ленты, а её проматывание. Во-вторых, просто удобнее иметь более
  "короткие" ленты с чётко заданными данными, чем постоянную мешанину
  которую дольше считывать

  срезов), но сейчас от них избавился. Или нужно иметь свежий срез, но
  на него у меня нет места или нафиг. Если отключат Интернет, то
  какие-то БД и сборники всякой всячины у меня конечно есть, но они не
  существенно помогут. Есть срезы wikipedia в виде ZIM файлов -- просто
  лучше чем ничего

  или какого-нибудь scimag -- нет. Но и покупать новые я уже как-то и не
  горю желанием из-за цены. Стоимость самого стримера такова, что он
  окупается только при объёмах в сотни терабайт. Даже для scimag или
  wikipedia... дешевле купить современные очень ёмкие жёсткие диски и
  держать в массивах регулярно делая scrub. Если не дешевле, то конечно
  и удобнее. Ленты это всё же для очень больших данных (чтобы окупалось)
  и для архивов

  файлик под Vim-ом. Каждый параграф в нём состоит из пары строчек с
  серийными номерами лент (оно наклеено на сам картридж и сбоку видно),
  а дальше просто из "ls -1" вывода файлов на них содержащихся, которых
  не много как правило: если мне надо записать архив со всеми моими
  подкастами, то я создаю podcast-DATE.tar и его помещаю в архив на
  самой ленте: tar cf /dev/*sa0 podcast-DATE.tar

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

  хозяйства просто смехотворен и зелен. Наверняка. Но меня не сильно это
  парит, ибо это just-for-fun главным образом. Ибо это всё не отменяет
  что фотографии, музыка (а это две самых ценных вещи что у меня есть,
  ибо моё собрание музыки хрен откуда скачаешь и добудешь) всё равно
  находятся на ZFS массиве тоже

  имеет кой какой но overhead и скорость последовательного чтения чуть
  пониже чем максимальная что может выдать сам диск. Речь про диски не
  самые свежие и современные, но всё равно 2-3-х терабайтные. Они сами
  по себе могут выдать 140MiB/sec зачастую, что требуется и при записи
  ленты, но чуть проседающий overhead от ZFS уже недостаточен для
  "насыщения" канала стримера и он вынужден время от времени
  останавливаться, чуть отматывать ленту назад, продолжать запись, что и
  изнашивает её и сильно замедляет весь процесс записи. Чтение с ленты
  на ZFS на один диск делается без проблем, overhead тут не мешает

  меня есть отдельная не всегда включённая SAS корзина с 4-мя 450GiB
  дисками в RAIDZ1, которую я часто и использую для работы с лентами.
  Ибо держать её постоянно включённой тоже не охота для раздачи торрентов

  должно быть достаточно. А вот LTO7 уже имеет скорость в 300MiB/sec и
  там без массивов не обойтись. Ну или без SSD, но я в живую SSD на 6TB
  не видел, чтобы можно было бы разом записать на ленту всё что хочется

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

  Ctrl-T, который покажет нечто типа:
    In: 7 files, 356068175872 bytes; Out: 356068175872 bytes, compression 0%
    Current: photoes.tar (75536662528/139850764800 bytes)

  об охлаждении. У меня сейчас внешний с собственным вентилятором --
  проблем нет, лента при вынимании не горячая

  останавливаясь каждые несколько десятков секунд, меняя направление
  головки (серпантинная дорожка), далее снова разгоняясь до визга. Спать
  рядом с таким не выйдет без берушей. У меня он в другой комнате, в
  которую приходится закрывать дверь или две двери

  прекращении чтения/записи из/в 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 контроллер просто встроен в сам стример,
  но и цена у них будет ещё выше

  принуждает. Я делал и zfs send запись прямо на ленту. Единственное о
  чём нужно помнить -- размер блока для записи, к которому стример
  чувствителен. Детали уже не помню, но вроде это 10240 байт. На других
  он то ли откажется работать, то ли будет на ещё каком-то одном
  работать, но в два раза меньшей скоростью. Лень искать в блоге, но об
  опыте этом всём писал. То есть, просто не забывать делать не
  "> /dev/esaX", а через "dd bs=XXX" соответствующий

оставить комментарий

Сгенерирован: SGBlog 0.34.0