Развитие твердотельных накопителей идет невероятными темпами, а использование лент для хранения данных может показаться архаизмом. Но только не тем людям, которые работают с архивированием и резервным копированием огромных массивов данных. В нашей практике ленточные накопители продолжают использоваться, они остаются лучшим решением для целого ряда задач заказчиков. И в этом посте я расскажу о том, как используются современные ленточные накопители и чем они отличаются друг от друга.
Если говорить об основных законах, в мире ничего не меняется кардинально. Информации как становилось больше с каждым годом, так и становится. А в дополнение к этому в растет количество угроз для информации. Одни только атаки Ransomware, приводящие к блокировке данных, по прогнозам аналитиков останутся одной из основных угроз для компаний в ближайшем времени. Наверное поэтому мы, как системный интегратор, продолжаем получать запросы на организацию больших и надежных хранилищ данных. Они могут использоваться как для архивирования, так и для резервного копирования по схеме “3-2-1”. Например, оперативная информация может бэкапироваться на быстрые диски по протоколу SAN или на NAS-устройство, вторая копия данных уходит на сетевые ресурсы, а наименее востребованная информация — как раз на ленты.
Но почему ленты?
Аргументов в пользу ленточных накопителей сегодня все еще достаточно много:
Это надолго. Ведь ленточные накопители считаются самыми надежными из распространенных накопителей (срок хранения от 15 до 30 лет).
Большой объём. Ленточные накопители обладают наибольшим объемом: картриджи стандарта LTO-9 имеют физический объем 18ТБ и могут вмещать до 45ТБ при сжатии информации.
Низкая стоимость. Стоимость хранения данных ($ за гигабайт) для ленточных накопителей значительно ниже, чем для любых других типов накопителей.
LTO - универсальный стандарт
Сегодня самым распространенным (и практически единственным) стандартом ленточных накопителей стал стандарт LTO (Linear Tape-Open). Он появился в 2000 году, и изначально разрабатывался компаниями IBM, Hewlett-Packard и Quantum. Позже к этому стандарту присоединились другие производители. Поэтому картриджи и приводы (накопители) LTO разных производителей полностью совместимы.
За прошедшее время сменилось несколько поколений LTO. Сейчас (2022 год) последним является девятое поколение – LTO-9.
Стандарт |
LTO-5 |
LTO-6 |
LTO-7 |
LTO-8 |
LTO-9 |
LTO-10 |
Год появления |
2010 |
2012 |
2015 |
2017 |
2021 |
план 2022 |
Физическая ёмкость |
1.5TB |
2.5TB |
6TB |
12.8TB |
18TB |
36TB |
Максимальная скорость (МБ/с) |
140 |
160 |
300 |
900-920 |
1000 |
2750 |
Картриджи девятого поколения имеют 18TB физической ёмкости. Информация может записываться на картриджи со сжатием (упаковкой). Считается, что в коэффициент сжатия общем случае составляет 2,5:1, поэтому иногда для картриджей указывается их ёмкость с учетом сжатия, например – 45ТБ для картриджей LTO-9.
Стандарт LTO регламентирует для приводов поддержку чтения на 2 поколения назад и записи на 1 поколение назад. Поэтому привод LTO-9, например, умеет читать картриджи LTO-9, LTO-8 и LTO-7, а писать на картриджи стандартов LTO-9 и LTO-8.
Картриджи
В устройствах LTO используются картриджи (кассеты) следующих типов:
RW (англ. ReWritable) — лента для многократной записи.
WORM (англ. Write Once, Read Many) — картриджи со специальной электронной схемой, допускающей только однократную запись и многократное чтение.
UCC (англ. Universal Cleaning Cartridge — чистящие картриджи), совместимые со всеми устройствами, для проведения технического обслуживания привода (чистка головок чтения/записи привода).
Магнитная лента картриджа содержит по своей ширине несколько сотен (и даже тысяч) дорожек. За один проход головки привода захватывают несколько десятков дорожек. Таким образом, чтобы полностью пройти всю ленту (весь картридж), требуется несколько десятков или даже сотен проходов. На торце картриджа может быть наклеена метка (label) - штрих-код, который маркирует картридж и используется в библиотеках для выбора картриджа (о библиотеках см. ниже). Наработка на отказ одного картриджа – около 250 циклов (полных проходов чтения/записи всей ленты). Наработка на отказ чистящих картриджей – 50 циклов.
Приводы
Приводы LTO состоят из лентопротяжного механизма и головок чтения/записи. Приводы различаются по:
стандарту LTO. Стандарт LTO требует от приводов читать картриджи на 2 поколения назад и записывать на 1 поколение назад. Поэтому привод LTO-9, например, умеет читать картриджи LTO-9, LTO-8 и LTO-7, и писать на картриджи стандартов LTO-9 и LTO-8.
интерфейсу подключения. Приводы LTO имеют один из двух интерфейсов подключения: SAS 6Gb или FC 8Gb. Более быстрых стандартов не бывает, т,к. привод не может писать быстрее, и использование быстрого интерфейса не требуется.
форм-фактору. Приводы бывают двух форм-факторов: FH и HH. Привод форм-фактора FH (Full-Height) занимает два стандартных отсека 5,25”. Привод HH (Half-Height) занимает только один такой отсек. Раньше приводы FH были более производительными, но сейчас разницы в производительности уже нет.
Типы устройств
Все устройства хранения на магнитной ленте можно разделить на несколько типов:
внутренние;
внешние одиночные приводы;
автозагрузчики;
библиотеки.
Внутренние приводы
Внутренние приводы (Internal tape drive) устанавливаются непосредственно в корпус сервера или компьютера. Последнее время они почти не используются, так как в стоечных серверах перестали делать отсеки 5.25”, а в случае напольных серверов конечные пользователи предпочитают использовать другие носители: внешние диски или USB-накопители.
Внешние одиночные приводы
Внешние одиночные приводы (Standalone tape drive) выполнены в виде отдельного выносного корпуса. Они бывают только с подключением SAS, и подключаются с помощью SAS-кабеля к SAS HBA, установленному в сервере. По необходимости картридж заменяется вручную. Устройство не устанавливается в стойку и существует только настольном варианте.
Автозагрузчики
Внутренние и внешние одиночные приводы не имеют автоматизации. Каждый раз пользователь должен вставлять и вынимать картриджи самостоятельно. Автозагрузчик (autoloader) – это устройство с одним приводом и автоматизированной системой хранения картриджей. Система может хранить несколько картриджей в магазинах. Внутри устройства робот-автомат выбирает картриджи из магазинов и вставляет в привод для чтения или записи.
Обычно на картриджи наклеиваются штрих-коды (label) – метки. По этим штрих-кодам робот-автомат различает картриджи (считывает фотоэлементом), а управляющее программное обеспечение ведет по этим штрих-кодам каталог (какая информация хранится на каждом картридже) и отдаёт соответствующие команды роботу.
Автолоадеры обеспечивают автоматизацию процессов резервного копирования, и поэтому применяются в тех случаях, когда объём информации не очень высок (для больших объёмов используются библиотеки), но требуется частое резервное копирование.
Приводы, которые устанавливаются в автолоадеры, могут иметь интерфейс SAS либо FC 8Gb.
HPE StoreEver 1/8 Autoloader Tape Library
Это видео наглядно показывает устройство автозагрузчика HPE StoreEver 1/8 Autoloader Tape Library: в стоечном корпусе 1U по бокам расположены магазины на 4 картриджа каждый, а в середине - дорожка, по которой передвигается робот. С помощью фотоэлемента он считывает метки на картриджах, выбирает нужный, и доставляет его в привод, который расположен в задней части автозагрузчика. Так как приводы могут быть разных стандартов LTO и с разным типом подключения (FC или SAS), устройство продаётся без привода. Привод нужно покупать отдельно.
Библиотеки
Если автозагрузчик всегда имеет только один привод чтения/записи, то библиотека рассчитана на использование нескольких приводов. Кроме того, они обычно рассчитаны на большее количество картриджей и имеют возможности расширения путём подключения модулей расширения с картриджами и дополнительными приводами.
Например, головной блок библиотеки начального уровня HPE MSL 3040 (на фото) имеет 40 слотов под картриджи, а с помощью шести модулей расширения количество картриджей можно увеличить до 280 штук. Кроме того, каждый модуль расширения может также содержать приводы, и их количество может быть увеличено до 21 штуки (3 штуки в головном блоке библиотеки и по 3 штуки в каждом из 6 модулей расширения). Приводы, которые устанавливаются в библиотеку, могут иметь интерфейс SAS либо FC 8Gb – причем в одной библиотеке могут использоваться приводы с разными интерфейсами.
HPE StoreEver MSL3040 Tape Library
Это видео наглядно показывает устройство и принцип работы библиотеки HPE StoreEver MSL3040 Tape Library: в стоечном корпусе 3U по бокам расположены магазины общей вместимостью 40 картриджей. Посередине корпуса, как и в автозагрузчике - дорожка, по которой передвигается робот. С помощью фотоэлемента он считывает метки на картриджах, выбирает нужный, и доставляет его в один из приводов, установленных в задней части библиотеки. Так как приводы могут быть разных стандартов LTO и с разным типом подключения (FC или SAS), устройство продаётся без привода. Привод нужно покупать отдельно. Библиотека может расширяться дополнительными корпусами (до 6 штук), каждый из которых может содержать как картриджи, так и приводы.
Производители
Все основные производители серверного оборудования предлагают ленточные накопители начального уровня стандарта LTO. Однако эти накопители не являются их собственными разработками, а производятся для них одним-двумя производителями по OEM-соглашениям. Это хорошо заметно по одинаковой конструкции и даже внешнему облику устройств:
Автозагрузчики:
HPE MSL 1/8 Tape Autoloader
IBM TS2900 Tape Autoloader
Dell TL1000 Tape Autoloader
Lenovo IBM TS2900 Autoloader*
Fujitsu ETERNUS LT20 S2 Tape System
*Lenovo продаёт ленточные накопители под брендом IBM.
Библиотеки:
HPE MSL 3040 Tape Library
IBM TS4300 Tape System
Dell ML3 Tape Library
Lenovo IBM TS4300 Tape System*
Fujitsu ETERNUS LT140
*Lenovo продаёт ленточные накопители под брендом IBM.
Типовые схемы подключения
Вариант 1
Серверы связаны по сети Ethernet. Один из серверов выполняет роль сервера резервного копирования (back-up server): к нему напрямую подключен ленточный накопитель, и на нём работает соответствующее программное обеспечение. Резервное копирование информации с любого сервера на ленточный накопитель идёт только через этот back-up сервер.
Использование внешнего одиночного привода оправдано, когда требуется копировать небольшие объёмы информации, и заменять картриджи нужно не очень часто. При больших объемах информации лучше использовать автозагрузчики или библиотеки.
Вариант 2
На рисунке ниже у заказчика есть сеть хранения (SAN, Storage Area Network) на технологии FibreChannel, в которой присутствует система хранения MSA 2060 (где у заказчика лежат важные для ведения бизнеса данные) и ленточный автозагрузчик (для резервного копирования). Сохранность данных и бесперебойный доступ к ним имеют решающее значение для бизнеса: любая поломка ведёт к простою бизнеса и следовательно - к убыткам. Поэтому серверы осуществляют доступ к данным на СХД через два дублирующих друг друга коммутатора. В случае поломки одного из них серверы сохранят доступ к данным.
Для резервного копирования используется автозагрузчик (ленточная система с одним приводом) с подключением по FС. Так как привод только один, отказоустойчивость отсутствует: в случае выхода из строя правого коммутатора доступ к автозагрузчику будет потерян. Кроме того, серверы потеряют доступ к данным на автозагрузчику в случае выходя из строя его привода. Насколько это критично - решает для себя сам заказчик.
Вариант 3.
Следующая схема - с полным дублированием. Вместо автозагрузчика на этой схеме присутствует библиотека с двумя приводами. Один из приводов подключён к левому коммутатору, второй - к правому. В случае выхода из строя одного из приводов или коммутаторов серверы сохранят доступ к данным на ленточном накопителе.
Заключение
Как вы видите, современный мир ленточных накопителей весьма разнообразен и продолжает развиваться. А опробованные схемы подключения позволяют предложить пользователям интересную альтернативу резервированию данных на жесткие диски. Конечно, ленты обычно используются в комплекте с другими видами накопителей, но о таких, более сложных методах организации создания резервных копий с использованием ленточного сегмента, мы поговорим в одном из следующих постов.
Комментарии (138)
b01d
24.05.2022 16:07А расскажите про софт. Как происходит процесс резервного копирования и восстановления? Что делать если из бэкапа надо восстановить "один файлик"?
hullaballoo
24.05.2022 17:43+1Я не работал с современными, но в 2008 году это было так:
найти кассету за нужный день
сунуть в привод
в софте (Symantec BackUp Exec) сначала нажать кнопку "Прочесть кассету" - софт строит дерево, занимало минут 15 на LTO-2
выбрать нужный файл, указать место куда восстанавливать, жмакнуть "восстановить"
софт крутил ленту быстро на нужное место и заметно медленне считывал файл. Если файлов много и в разных местах ленты, то процесс восстановления мог затянуться.
Если это был большой бэкап, который не влезал на одну кассету, софт просил вторую (третью, четвёртую) и их стоило внимательно помечать для экономии времени в случае восстановления - дерево строилось после полного чтения всех томов бэкапа, а смотка кассеты перед извлечением занимает какое-то время.
С инкрементами так же - сначала из условной пятничной кассеты достаётся по процедуре выше файл, а затем с понедельника и вторника накатываются инкременты.
Сейчас, думаю, принцип тот же, но скорости повыше.
EDIT: особое веселье было когда надо было кассету из архива заказывать. Они туда уезжали в понедельник, после полного пятничного бэкапа. Заказать-дождаться - сутки-двое легко могло занять, особо больно когда неделя кассет только уехала, а через час-два просят что-то восстановить...
screwer
24.05.2022 23:27У симантека такой же формат, как у NTBackup, только расширенный собственными стримами и блоками. TAR им родственник. Чтобы составить каталог надо промотать всю ленту. Если лента пишется "за раз" более грамотным решением было бы иметь единый каталог в начале
ЛТО-5 (2010 год) поддерживает технологию LTFS. Лента партиционируется на два раздела. Один под каталог, второй пол данные. После чего ее можно примонтировать как обычный диск. Правда, для быстрого чтения лучше использовать спец.утилиту, которая (в отличие от ОС) "знает" положение файлов на ленте, и способна читать их оптимально, за один проход.
ЛТО-2 должен был устареть к 2008 году и быть списан. Также непонятно зачем по много раз дописывать на картридж, там всего 200гб. Какая-то нищая организация ?
Логистика носителей в архив неспецифична для лент. Тут вы сами рисуете процесс, как умеете. С условными хдд было бы точно также. Плюс риск уронить его где-то в процессе, и лишиться всех данных.
hddscan
25.05.2022 07:50У симантека такой же формат, как у NTBackup, только расширенный собственными стримами и блоками.
это фактически одно и тоже, потому что все вышло из Maynard, которую купил Archive, которую купил Conner, который купил Seagate, который купил Microsoft, который купил Veritas и продал лицензию Symantec
TAR им родственник.
Это вы NTBackup с NetBackup перепутали, вот в нем TAR.
screwer
25.05.2022 11:21Это вы NTBackup с NetBackup перепутали, вот в нем TATAR
Нет, не перепутал. "Родственник" - в ключе отсутствия выделенного каталога. А подобное решение с описателем, перед каждым блоком с данными. И необходимостью полной перемотки ленты чтобы построить каталог.
hddscan
26.05.2022 18:59Нет, не перепутал
NetBackup использует tar структуры для хранения данных.
NTBackup aka BackupExec использует свою уникальную систему дескрипторов и потоков для хранения данных.
А подобное решение с описателем, перед каждым блоком с данными.
это используют большинство решений для бэкапа на ленту (их сотни). Я знаю только один тип бэкапа, которые не используют такую структуру, это LTFS - хранит каталог на отдельной partition, но принципиальной разницы между partition и отдельной сессией для каталога нет.
И необходимостью полной перемотки ленты чтобы построить каталог.
И BackupExec и NetBackup имеют отдельную ленточную сессию с выделенным каталогом. Так как это отдельная сессия, то ее поиск на ЛТО ленте занимает меньше минуты.
screwer
26.05.2022 21:30NetBackup использует
NTBackup aka BackupExec использует
Да не важно что за структуры там, важно что они перед каждым блоком с данными. Я писал и парсер TAR и парсер "расширенного" MTF. Для последнего - с эвристической машиной определения неизвестных тегов (стрим ли это, блок, либо ещё один неизвестный тип обьекта. Кстати, собственных, недокументированных стримов и блоков там несколько десятков, встреченных в реальных бекапах.)
но принципиальной разницы между partition и отдельной сессией для каталога нет.
Вот не видел я у Symantec (aka NTBackup) отдельной сессии с каталогом. В котором, полагаю, должны быть записаны... кстати что ? Положение остальных сессии ? Плюс полный индекс их содержимого ? И в доке по MTF не виделю Там тупо набор SSET-ов, и погнали в каждом: VOLB-DIRB-FILE-CSUM-SPAD, как базовый скелет. Узнать за "меньше минуты" что же именно записано на всей ленте - нет ни малейшей возможности. Бекапы реальные, от одного авиаперевозчика.
hddscan
27.05.2022 00:24И в доке по MTF не виделю Там тупо набор SSET-ов, и погнали в каждом: VOLB-DIRB-FILE-CSUM-SPAD, как базовый скелет. Узнать за "меньше минуты" что же именно записано на всей ленте - нет ни малейшей возможности.
каталог живет не там где SSET, а в следующей сессии - ESET, в ней просто список файлов. Это кстати описано в доке на MTF.
screwer
27.05.2022 00:41ESET - это всего лишь окончание сессии. Пустой датаблок. В следующей сессии список файлов может быть, а может не быть. Только проблема в том, что этот список файлов - это не каталог. А натурально блоки и стримы как я выше написал. Перемежающиеся выравниваниями, данными этих самых файлов, расширенных атрибутов, именами директорий и разделов. И чтобы вычитать весь каталог - надо прочитать и весь датасет. Отдельного каталога НЕТ.
Вот пример начала датасета на 931гб:
{00000} [0x000000000000] 54455353 'SSET'<34> DBLK -(1b8)---------> 0x1b8 44415053 'SPAD'
{00001} [0x0000000001b8] 44415053 'SPAD'<16> STRM -(248)---------> 0x400 424c4f56 'VOLB'
{00002} [0x000000000400] 424c4f56 'VOLB'<34> DBLK -(194)---------> 0x594 44415053 'SPAD'
{00003} [0x000000000594] 44415053 'SPAD'<16> STRM -(fa6c)--------> 0x10000 42524944 'DIRB'
{00004} [0x000000010000] 42524944 'DIRB'<34> DBLK -(94)----------> 0x10094 5051544e 'NTQP'
{00005} [0x000000010094] 5051544e 'NTQP'<16> STRM -(30)----------> 0x100c4 4d555343 'CSUM'
{00006} [0x0000000100c4] 4d555343 'CSUM'<16> STRM -(1c)----------> 0x100e0 5551544e 'NTQU'
{00007} [0x0000000100e0] 5551544e 'NTQU'<16> STRM -(50)----------> 0x10130 4d555343 'CSUM'
{00008} [0x000000010130] 4d555343 'CSUM'<16> STRM -(1c)----------> 0x1014c 4c43414e 'NACL'
{00009} [0x00000001014c] 4c43414e 'NACL'<16> STRM -(e8)----------> 0x10234 4d555343 'CSUM'
{00010} [0x000000010234] 4d555343 'CSUM'<16> STRM -(1c)----------> 0x10250 44415053 'SPAD'
{00011} [0x000000010250] 44415053 'SPAD'<16> STRM -(1b0)---------> 0x10400 42524944 'DIRB'
{00012} [0x000000010400] 42524944 'DIRB'<34> DBLK -(ac)----------> 0x104ac 4c43414e 'NACL'
{00013} [0x0000000104ac] 4c43414e 'NACL'<16> STRM -(c0)----------> 0x1056c 4d555343 'CSUM'
{00014} [0x00000001056c] 4d555343 'CSUM'<16> STRM -(1c)----------> 0x10588 44415053 'SPAD'
{00015} [0x000000010588] 44415053 'SPAD'<16> STRM -(278)---------> 0x10800 42524944 'DIRB'
{00016} [0x000000010800] 42524944 'DIRB'<34> DBLK -(114)---------> 0x10914 4c43414e 'NACL'
{00017} [0x000000010914] 4c43414e 'NACL'<16> STRM -(cc)----------> 0x109e0 4d555343 'CSUM'
{00018} [0x0000000109e0] 4d555343 'CSUM'<16> STRM -(1c)----------> 0x109fc 44415053 'SPAD'
{00019} [0x0000000109fc] 44415053 'SPAD'<16> STRM -(204)---------> 0x10c00 454c4946 'FILE'
{00020} [0x000000010c00] 454c4946 'FILE'<34> DBLK -(b8)----------> 0x10cb8 4c43414e 'NACL'
{00021} [0x000000010cb8] 4c43414e 'NACL'<16> STRM -(b8)----------> 0x10d70 4d555343 'CSUM'
{00022} [0x000000010d70] 4d555343 'CSUM'<16> STRM -(1c)----------> 0x10d8c 4e415453 'STAN'
{00023} [0x000000010d8c] 4e415453 'STAN'<16> STRM -(98)----------> 0x10e24 4d555343 'CSUM'Cтатистика содержимого:
Total count=10177648, size=1059972 MB
NTEA<16> count=1792, size=0 MB
VOLB<34> count=1, size=0 MB
ESPB<34> count=1, size=0 MB
DIRB<34> count=145367, size=43 MB
SPAD<16> count=1681623, size=822 MB
FILE<34> count=1536253, size=255 MB
NTOI<16> count=60284, size=3 MB
NACL<16> count=1681620, size=403 MB
CSUM<16> count=3407201, size=19 MB
STAN<16> count=1534015, size=1058415 MB
NTQP<16> count=1, size=0 MB
ADAT<16> count=129488, size=8 MB
SSET<34> count=1, size=0 MB
NTQU<16> count=1, size=0 MBПосле которого идёт ESET, размером 0x58 (из которых 0x34 это стандартный заголовок DATABLOCK).
hddscan
27.05.2022 01:25ESET - это всего лишь окончание сессии. Пустой датаблок. В следующей сессии список файлов может быть, а может не быть.
ESET и есть в следующей сессии (после File Mark-а)
Только проблема в том, что этот список файлов - это не каталог. А натурально блоки и стримы как я выше написал.
вы упорно не хотите принимать реальность.
картинка из доки
Media Based Catalog - он хоть и optional, но мне пока ни одна лента не попадалась, где его нет.
screwer
27.05.2022 01:41Media Based Catalog - он хоть и optional, но мне пока ни одна лента не попадалась, где его нет.
Ну вот на картриджах, доставшихся мне от авиаперевозчика, его нет. Все ESET пустые.
hullaballoo
25.05.2022 09:06Также непонятно зачем по много раз дописывать на картридж, там всего 200гб.
Я вроде бы не писал про "много раз дописывать".
ЛТО-2 должен был устареть к 2008 году и быть списан. ... Какая-то нищая организация?
Да, была. Закрылась недавно после четверти века страданий на дотациях из HQ.
FlashHaos
25.05.2022 10:06+1Сейчас все то же самое, только кассету каждый раз перечитывать не обязательно. Если эта же СРК делала бекап, то она помнит структуру данных на ленте и сразу мотает куда надо.
little-brother
24.05.2022 16:32Кто же все таки оригинальный OEM-производитель? Может они не ушли из России и их можно закупить (хоть какая-то поддержка/гарантия лучше чем полное их отсутствие)?
Sadler
24.05.2022 16:36+3Штука, конечно, неплохая, но огрехи реализации легко могут похоронить базовые преимущества. Приходилось юзать одну из таких LTO-систем на протяжении 5 лет. Не могу сказать, что там была какая-то дикая надёжность, за это время перестало читаться несколько кассет, причём, часть данных не удалось восстановить даже с помощью хвалёной проприетарной системы частичных бэкапов на разных кассетах. При этом RAID5 за то же время никаких данных не потерял при регулярной замене вышедших из строя дисков.
maxitop
24.05.2022 21:55-1Использую библиотеку стандарта LTO-4 уже 12 лет, в части кассет полет нормальный.
tas
24.05.2022 17:26+6У нас был проект, где мы с подачи специалистов IBM использовали ленточное хранилище от IBM для уровня отложенного доступа - от него требовалась загрузка по требованию (это когда данные уехали на ленту и были стерты из БД, но вдруг понадобились опять и их нужно восстановить с ленточного хранилища в БД) - ну и намучились же мы с ним!
Нигде не написано, но лента имеет очень ограниченный ресурс по количеству перемоток, который по факту выбирается за считанные месяцы. А потом ленты нужно менять или начинать оплакивать погибшие данные...
Ds02006
24.05.2022 19:47Про ресурс ленты могу рассказать вот такой пример: в начале десятых годов бэкап базы данных по платёжным карточкам Казкоммерцбанка выполнялся еженочно на три разных совершенно новых картриджа. Потом два картриджа на двух разных автомобилях отвозили в два разнесённых на десяток километров хранилища Казкоммерцбанка в Алма-Ате. Третий картридж оставался в хранилище при серверной, на случай оперативного восстановления данных. Во второй раз ленты не использовали в этом банке никогда.
screwer
24.05.2022 23:33И что нам говорит этот пример ? Если есть много лишних денег - можно и на винты по одному разу писать.
Мой пример - купил 96 лто5 лент из-под одного авиаперевозчика. Остаточный ресурс картриджей 80-96%, по оценке hpetool. Использовал полтора десятка. Только полные перезаписи. От 5 до 30 раз. Пока не было ни одной проблемы ни с одним картриджем.
svpcom
26.05.2022 11:56В начале 2000-х мы купили в университет LTO одного их первых поколений и наступили на эти грабли - кассеты дохли после десятка перезаписей. После этого я перестал верить во все мифы о надежности лент. Да, если один раз записать и положить в шкаф (как делают в банке), то будет надежно. Но если бюджет ограничен и ленту нужно перезаписывать, то ничего хорошего не получится
Dmitrii_kld
24.05.2022 17:45+2Коллеги, а вы уверены в том, что привод LTO9 сможет прочитать картридж LTO7? Правило "чтение на 2 поколения назад" перестало действовать с поколения LTO8.
XCom1994
25.05.2022 09:55прочитать сможет, а записать - вопрос)
Dmitrii_kld
25.05.2022 10:51+4не сможет даже прочитать https://www.lto.org/lto-generation-compatibility/
RStarun
24.05.2022 18:55Надежность под вопросом. Много в интернете случаев когда считать записи не получалось. Но есть вероятность что это ошибки эксплуатации и хранения. Пыль критична для этих устройств и для носителей. И хранить ленты производитель рекомендует не абы как. Для понимания достаточно представить что это просто жесткий диск, только без всей защитной оболочки и без двигателей. Двигатель встроен в привод. (кстати, такие аналоги-конкуренты были у LTO).
Производителей собственно драйвов было вроде два, а сейчас вообще один остался. Поэтому и дорого. Кровавый энтерпрайз.
Низя использовать одну библиотеку для нескольких систем (серверов копирования). Привод считай как DAS устройство.
Подходит только для бэкапов. Фоточки туда складывать для архива не получится - слишком высокое время доступа. Пока пленку нужную найдешь, пока пленка перемотается на нужное место...
Но штука нужная. Иначе сложно обеспечить нормальные архивы бэкапов.
screwer
24.05.2022 23:37Площадь хранения бита отличается от хдд в миллионы раз. Соответственно также отличаются требования к чистоте и точности позиционирования. Также в тысячи раз отличается надёжность его хранения (перемагничивание, чувствительность головок).
RStarun
25.05.2022 13:59Не утверждал полного сходства технологий. Говорил что для понимания достаточно представить диски без корпуса - это понятная аналогия для айтишников которые часто пользуются дисками и не видели пленок. Пыль очень негативно влияет на то и на другое.
FlashHaos
25.05.2022 09:47Низя использовать одну библиотеку для нескольких систем (серверов копирования). Привод считай как DAS устройство.
Если нет SAN - то нельзя, но если нет SAN, то это и называется DAS и никак иначе. Если есть SAN, то никаких проблем (ну кроме одновременного доступа к приводу, но это физически невозможно, головка то одна).
RStarun
25.05.2022 12:41В случае с FC я не понял как раздавать одну голову нескольким сервисам. То есть нужно в шедулах разного софта так задать все параметры чтобы точно не пересекалось. И еще как-то хитро распределить пленки между разными софтами. В общем, мои хотелки были явно не заложены архитектурно.
lab412
24.05.2022 23:50Поясните зачем всегда указывается объем со сжатием если на сегодня это не имеет смысла?
во первых такие объемы данных чаще всего это видео, а видео не сжимается и при попытке сжать файл часто становится больше размером
базы данных так же часто сжимаются сами при экспорте, а значит опять таки сжатие данных не случиться, а то и станет больше размер.
серьезно, никто не хранит на сегодня терабайты данных в виде RAW TXT который поддаётся сжатию. даже офисные файлы вроде внутри имеют ZIP сжатие. но я бы посмотрел на текстовые данные в терабайт размером. серьёзно - вся мировая литература в терабайт влезет, а видео и фоточки не сжать уже.
и так мой вопрос - может перестанем пи**теть и будем указывать просто объем ДО сжатия?
и еще один вопрос на засыпку - а почему не хранить на жестких дисках? почему все сравнения идут с форматами не используемыми сегодня? вы серьезно считаете что имеет смысл с CD дисками сравнивать и указывать что 100500 CD дисков на одну кассету влезет? ну так давайте лучше с флопариками на 1.44 сравнивать - еще больше выйдет и так же никто уже не помнит этого формата и куда его вставлять. так же как и DVD/BD и всё такое. да я лет 10 уже BD приводов нигде не вижу... ну только в консолях и там уже вымирает потихоньку... я даже вот не сразу вспомнил щас какой размер у этих дисков был чтобы как то посчитать количество...
с учетом цены магнитофона - жесткие диски выигрывают довольно долго пока количество данных не накопится такое которое уже и не надо вообще хранить. никому не нужны бэкапы 15ми летней давности. даже месяц назад часто уже не нужны. а если хранить видео, то... вы серьезно храните видео с камер наблюдения 15 лет??
я понимаю что для большого корабля большая торпеда, но тут то зачем про это тогда писать? или как в анекдоте про доктора: - Лечиться? - Нет, хвастаться! это как рекламу ролсройса в метро вешать, в целом то это реклама - но покупатели RR в метро никогда не входили даже в самые худшие моменты своей жизни...
RaphZak
25.05.2022 01:19+1Вот буквально недавно видел новость, как королева Великобритании спустилась в метро. Открыла новую линию названную в её честь.
И насчет бекапов 15 летней давности вы ошибаетесь. Например тут уже упомянули геофизические данные. Да, методы исследования улучшаются, однако для первичного анализа используют базовые методы, которые не меняются с давних времен. Причем некоторые данные хранятся в простом текстовом виде, с заголовком - описанием LAS формат. Хотя согласен с вами, что лучше все же указывать емкость в чистом виде, без сжатия.
DarthPadla
25.05.2022 02:53Мне кажется, имеется в виду под сжатием не сжатие информации, а сжатие ячейки для ее хранения в долях метра
DaemonGloom
25.05.2022 13:08Рекламируется именно сжатие информации. Условные LTO-7 — это 6TB сырых и "до" 15TB сжатых данных. Соответственно, вторая цифра вам не гарантирована для определенных типов данных.
FlashHaos
25.05.2022 09:55+1Откуда столько злобы?
базы данных так же часто сжимаются сами при экспорте
А часто - не сжимаются. Учитывая то, что сжатие при записи на ленту реализуется на аппаратном уровне и сжималка встроена в привод, часто имеет смысл отключить сжатие на стороне базы, чтобы сэкономить вычислительные ресурсы хоста бд.
никому не нужны бэкапы 15ми летней давности. даже месяц назад часто уже не нужны. а если хранить видео, то... вы серьезно храните видео с камер наблюдения 15 лет??
Вы, видимо, работаете в динамичном стартапе, где старые данные не имеют большого значения. Но в крупном бизнесе вполне может возникнуть потребность получить доступ к старым данным. Например, при расследовании. Или при исследовании.
Есть ещё требования регулятора - некоторые данные надо хранить 75 лет, особенно в финансовых организациях. Больше того, некоторые данные надо по закону хранить именно на отчуждаемых носителях. Используют ленты или оптические диски/оптические кассеты.
edo1h
25.05.2022 23:33Учитывая то, что сжатие при записи на ленту реализуется на аппаратном уровне и сжималка встроена в привод
зато и сжатие обычно получается не в 2.5 раза.
screwer
25.05.2022 11:31Аппаратное сжатие - условно-бесплатное. Да, оно уступает программному. Но зато освобождает время. Пожмите террабайт тех же текстовых файлов. Или дисков виртуальных машин. Которые могут быть заполнены на малую часть обьема. Сколько ваш сервер потратит времени ? Полчаса ? Час ? Вот это время вам сэкономит привод. Лента же лто5 способна писать до 500мб-сек несжатых данных (которые хорошо сжимаются, впрочем. Типа гигабайтов нулей. Видел цифру >500 в ходе ИбМовских тестов. Иначе меньше.), дожимая их до нативных 140мб-сек в ходе записи. А современные ЛТО ещё быстрее.
svpcom
26.05.2022 11:58gzip на соверменных процессорах уже давно работает быстрее, чем скорость записи на механический диск
kolu4iy
27.05.2022 12:47Хех... Бекап 2,5 Тб базы на быстрый жёсткий диск (raid 10, 4 SSD) по 10 ГБит сети со сжатием - 1:09, без сжатия - 3 часа. А вы говорите "потратит"... А ядра - условно-бесплатны, т.к. на сервере БД их 24, и занятие пары из них в ненагруженное время не беспокоит вообще никого.
13werwolf13
26.05.2022 07:45+1согласен с почти всем. кроме:
икому не нужны бэкапы 15ми летней давности
не работали вы коллега на телевидении. там бывает "срочно принеси мне то видео про того чувака, ну всего-то 100500 лет назад снимали". и хочешь не хочешь а добыть надо, если не сохранилось в архиве копай интернет. но надо и срочно.
ну и вспомним историю как коммюнити фанатов одного сериала потратило хрен знает сколько денег на поиски одной серии первого сезона потому что у BBC сгорел архив. и не нашли.. а если бы кто-то сохранил у себя он бы мог им просто продать.
aborouhin
25.05.2022 03:31+2Вот эту мантру про "низкую стоимость на гигабайт" для лент так и не понял ни разу, хотя считал неоднократно, т.к. потребность архивирования нескольких десятков Тб (сейчас около 40) есть. Да, Гб на картридже, может, и дешевле, чем Гб на HDD. Но библиотека с автоподатчиком стóит настолько дороже простенького сервера, который можно набить этими HDD и сделать в нём RAID с hot spare дисками, - что эта разница напрочь съедается. Ну разве если повезёт урвать б/у на Авито по особо выгодной цене от недалёкого админа, который сам не понял, что за вундервафлю он спёр из офиса :)
При этом тот самый сервер с RAID, если в нём вовремя заменять вылетающие диски, вряд ли обеспечит качественно худшую надёжность. Ну и HDD со SMART, да ещё и стоя́щий в RAID, которому регулярно делается scrub, как минимум вовремя просигнализирует о своей неисправности, - в отличие от ленты, на которую что-то записали N лет назад и всё.
Необходимости бекапа ещё и в облако опять же, ни один из вариантов не отменяет, т.к. сгореть / быть украденными / изъятыми хоть ленточный накопитель, хоть сервер имеют шанс.
Так что для моего варианта (личные нужды плюс мелкий бизнес) пока что серверная стойка с тем самым набитым HDD сервером под лестницей дома + облачный бэкап в Backblaze (через свою приватную инсталляцию Seafile) выигрывает у ленты, как ни считай...
n2dt4qd2wg9b
25.05.2022 04:07Выключите сервер на 5-7 лет, потом включите и удивитесь :)
А кассета с нулевым потреблением отлежит 7 лет улыбнувшись. Даже в банковской ячейке, куда сервер не влезетъ :)
Мантра проста. Предложите на дисках что-то приближающееся по цене к Amazon Glacier и очень неплохо заработаете :)
aborouhin
25.05.2022 04:23А зачем его выключать?.. :)
Ну и да, Backblaze B2, который отнюдь не на лентах, дешевле Glacier, если хоть иногда что-то оттуда скачивать (у B2 скачивание 0,01$ / Gb и всё, у Glacier плюс стоимость data transfer и за запросы), и несущественно дороже (0,005$ / Gb против 0,0036-0,00405$ / Gb), если вообще только отправлять туда данные, как в чёрную дыру, и никогда не скачивать их обратно. При этом оно ещё и работает как обычное объектное хранилище (и довольно шустрое), в отличие от. Но в любом случае, экономика публичного сервиса и экономика бизнеса, который использует железо для своих нужд, изрядно отличаются.
Нет, наверняка есть сценарии, когда именно лента выигрывает. Но это какая-то экзотика, IMHO. Типа хранения огромного количества версий бекапов, которые существенно превышают по объёму одиночный бекап. Ну, например, для каких-то регуляторных требований. Тогда ленты действительно можно регулярно вынимать из привода и складировать на полку. Но в основном содержание архива бекапов всё же регулярно обновляется полностью (зачем нам ежемесячные архивы за позапрошлый год?) - т.е. ленты должны постоянно находиться в библиотеке (а такая библиотека дорога) и регулярно перезаписываться (а это снижает срок их службы).
n2dt4qd2wg9b
25.05.2022 04:29Выключать, чтобы хранить оффсайт. Чтобы по почте отправить, чтобы в сейфе сохранить, много что-бы.
Ну для трех копий вам нужно три сервера, три рейда, три набора дисков, а ленточнику - три ленты. Вот зачем еще выключать. А тут уже другая экономика за один ТБ, ведь так?
aborouhin
25.05.2022 04:36Я вот о чём.
Сегодня я сохранил бекап за сегодня. Завтра у меня появляется бекап за завтра, и без него, записанного рядом с бекапом за сегодня (если он инкрементальный) или вместо него (если полный), бекап за сегодня резко теряет свою ценность (ну разве что что-то с дуру удалённое в нём искать, восстановить систему из него уже повлечёт неприемлемую потерю данных).
Чтобы все мои три копии не теряли актуальность - эти три ленты должны не на полке лежать, а крутиться каждая в своём приводе. А когда объём данных больше объёма ленты - то и в библиотеке. А неактуальные копии мне не сильно помогут, хоть их десять будь. Ну и вообще хорошо, когда бекап не раз в день, а в режиме онлайн...
Это, конечно, про мой конкретный кейс - бекапы именно с целью обеспечить возможность восстановления. Если бекап делается для других целей (ну, например, те самые регуляторные требования) - тут да, варианты есть. Но мне как-то казалось, что большинству нужны всё же не шашечки, а ехать :)
n2dt4qd2wg9b
25.05.2022 04:45+2Вам звонили в 6 утра со словами приезжай сюда, тут пожар? Мне - да :)
Вас просили сделать так, когда спецслужбы накроют офис - работать нужно продолжить немедленно(1-2часа) с полным набором данных с 12 рабочих станций на консп. квартире? Меня - да :)
Писать на ленты каждый день - согласен - нужна веская причина, но она бывает и у не североамериканских компаний :)
aborouhin
25.05.2022 04:57И первый, и второй кейс я как раз по мере сил и решаю :) От пожара пока Бог миловал, но в расчёт такая возможность принимается. А страховка от маски-шоу - так это вообще базовый сценарий, и вот такое как раз бывало не раз. Плюс более актуальные риски того, что от зарубежного облака могут неожиданно отключить, причём как с этой стороны, так и с той... При этом у меня бизнес-то ещё и свой, так что все эти вводные я сам себе и формулирую, сам и реализую.
Только как мне поможет что от пожара, что от маски-шоу лента месячной давности? Типа, а давайте сейчас повторим последний месяц работы заново?.. Нет, ну в случае совсем уж полного апокалипсиса лучше, чем вообще ничего. Но так себе решение.
edo1h
26.05.2022 00:25Вас просили сделать так, когда спецслужбы накроют офис — работать нужно продолжить немедленно(1-2часа) с полным набором данных с 12 рабочих станций на консп. квартире?
сходу вижу проблемы:
- нужно иметь запасной привод, это не так уж и дёшево;
- актуальность данных. да, несложно перевозить ленту в безопасное место раз в сутки, но данные суточной давности уже не так интересны.
ежечасный же вывоз лент — тот ещё геморрой.
MaksimMadCat2539
26.05.2022 15:27Выключать, чтобы хранить оффсайт.
По почте можно отправить другой диск.
Ну для трех копий вам нужно три сервера
Вообще-то три пары дисков. Если же, три сервера нужны для защиты от выхода из строя самого сервера, то и ленточных привода тоже надо три.
А тут уже другая экономика за один ТБ, ведь так?
У ленты сильно ниже число циклов чтения/перезаписи. Это тоже надо учитывать в расчётах.
tlv
25.05.2022 09:16Кого-то регулятор заставляет сырые данные хранить много лет.
Кто-то сам делает снапшоты ИС регулярно и складывает в архив - чтобы если через месяц выяснится что была какая-то неприятность, а логи давно перезаписались, восстановить снапшот и внимательно его рассмотреть.
Конечно, если данных не очень много (а 20-40 Тб это относительно немного на наши дни) то можно и на дисках, но если в разы больше...
Вот я знаю плотный сервер в который в 2 юнита 46 дисков входит кажется? Это 2700 Тб в шести юнитах + шуметь и греться будет как в аду - а вышеупомянутая HPE MSL 3040 в 6 юнитов вместит в 2 раза больше, 5000 Тб - и будет тихой и холодной.
DaemonGloom
25.05.2022 13:211440TB сырых данных будет в двух MSL 3040 на 6U занятого места… И им нужен сервер, который эти бэкапы делает.
1440TB сырых данных будет в какой-нибудь SuperStorage 6048R-E1CR90L, набитой 16TB дисками на 4U занятого места. И это уже сам по себе сервер, делающий бэкапы.Не рассказывайте про сжатые данные, когда говорите про ленты — сервер будет жать данные однозначно не хуже. Большую часть времени он и не будет особо шуметь и греться — ведь это же холодные данные, к которым регулярных обращений новых нет (помимо периодической проверки).
RStarun
25.05.2022 13:53Смысл хранить все пленки в библиотеке? Пленка она на то и пленка чтобы вынимать ее и хранить отдельно (в другом здании, не подключенную никуда). Так что 4U на обычную библиотеку на 2 привода.
Сжатие всё-таки разное бывает. Не в плане степени сжатия. Например SQL может при бэкапе сжимать данные и записывать уже в сжатом виде. Получается это у него хорошо, но есть проблема. Он при этом сжирает свои ресурсы, которые ему не для этих целей давались. Хотя в основном я согласен - сжимать и даже дедупить часто лучше сразу на месте и передавать уже в сжатом виде, полоса пропускания экономится.
FlashHaos
25.05.2022 09:58+1А Вы электричество и холод считали? Ленты сильно эффективнее схд по этим показателям.
Ну и тут действительно вопрос в эффекте масштаба. Для домашнего офиса действительно ленты не очень нужны, кроме специфических случаев. Но есть другие случаи и другие масштабы.
SergeyMax
25.05.2022 10:35+1Вот эту мантру про "низкую стоимость на гигабайт" для лент так и не понял ни разу, хотя считал неоднократно
Ленты становятся выгодными в районе петабайт по сравнению с хранилками высокого уровня, но вы правы, разница весьма эфемерна, а геморроя добавляется настолько много, что игра обычно не стоит свеч.
screwer
25.05.2022 11:44В бу варианте, для домашнего использования, в котором остаточного ресурса хватит до конца жизни, и если не "здесь и сейчас", а помониторить Авито неспеша - то граница где-то в районе 50тб. Выше нее холодные бекапы на лентах заметно выгоднее.
ЗЫ: хотя с текущими ценами на винты, когда негелиевый 10тб стоит 50+, а стоил в 2020ом ~23, наверное планка упала где-то до 30тб.
saga111a
25.05.2022 11:20Наработка на отказ одного картриджа – около 250 циклов (полных проходов чтения/записи всей ленты).
Меня еще смутило что наработка на отказ всего 250 циклов чтения. Т.е. это все не более чем юэкапы без возможности перезаписи(при таком ресурсе это совершенно глупо). Получается весь этот огромный объем не сравним с обычным hdd, поскольку идет огромное дублирование информации которую вообще говоря можно подтереть через несколько лет, "проредить" частоту старых слепков.
В общем я тоже не понял в чем смысл если только это не архивные денные.
edo1h
25.05.2022 23:59Так что для моего варианта (личные нужды плюс мелкий бизнес) пока что серверная стойка с тем самым набитым HDD сервером под лестницей дома + облачный бэкап в Backblaze (через свою приватную инсталляцию Seafile) выигрывает у ленты, как ни считай...
вы неправильно ставите вопрос, не «лента против сервера с hdd», а «лента в дополнение к серверу с hdd» (против того же backblaze в вашем варианте).
вот смотрите, пусть у нас сотня терабайт и год.
backblaze будет нам стоить0.005*100*1000*12=6к$
привод lto-8 и 10 лент на амазоне стоят около4к$, уже дешевле.притом с ленты будет читаться со скоростью больше 300 мегабайт в секунду и в случае, если интернета нет вовсе.
aborouhin
26.05.2022 00:05Не-не, Backblaze или Glacier или хоть какое удалённое хранилище (по возможности в иностранной юрисдикции) никуда не денутся, хоть я поставь три сервера и пять ленточных накопителей на разных площадках. Потому что если по всем этим локациям пройдется товарищ майор с ордером - только на это удалённое хранилище и надежда.
edo1h
26.05.2022 00:21гхм, а зачем ленты хранить там же, где и приводы?
aborouhin
26.05.2022 00:28Ну наверное затем, чтобы на них писать. См. другие мои комментарии в этой ветке - ценность ленты, которая месяц лежала на полке, для меня стремится к нулю, из неё актуальный бекап не восстановишь. Нет, можно, наверное, какую-то редко изменяемую часть данных так хранить, а более динамичную - иначе, но это уже усложнение.
Ну и в целом, где эти ленты ни храни, сценарии, завязанныме на возможность доступа конкретных людей к конкретной физической локации, объединены общими рисками, которыми надо управлять. Тут опять же, у всех ситуация разная, и по рискам, и по возможностям. Для меня всё же настроить бекап в Backblaze/Glacier куда как проще, чем найти новое место для физического хранения чего бы то ни было, озаботиться системой доступа к этому месту и т.п.
edo1h
26.05.2022 00:38ценность ленты, которая месяц лежала на полке, для меня стремится к нулю
какой месяц, зачем вдаваться в крайности? ежедневную ротацию лент обеспечить совсем несложно.
например:
ночью делается бэкап на сервер, утром он копируется на ленту.
днём в него дописываются инкременты.
вечером ответственный уходит сотрудник с работы, забирает записанную ленту, вставляет вместо неё следующую.Сегодня я сохранил бекап за сегодня. Завтра у меня появляется бекап за завтра, и без него, записанного рядом с бекапом за сегодня (если он инкрементальный)
хм, и в чём тут проблема с лентами? берём ленту с основным бэкапом, ленту (ленты) с инкрементом — готово.
А когда объём данных больше объёма ленты
гхм, у доступных lto-8 объём 12 терабайт. вы правда бэкапите за сутки бо́льшие объёмы на backblaze?
aborouhin
26.05.2022 00:49Я о том, что ленты с более старыми бекапами имеют ценность только в комплекте с лентой с актуальным бекапом. Т.е. если я раз в месяц буду уносить ленту на хранение на условную конспиративную квартиру, а последняя лента будет оставаться в приводе - это мне вообще не поможет решить мои задачи. Каждый день таскать ленты куда-то - помилуйте, у меня личные нужды и малый бизнес, откуда у меня столько человекочасов на это? Поэтому если тот самый привод с актуальной лентой сгорит / украдут / изымут / мало ли что - я останусь с неактуальным бекапом. Так что проще уж все ленты и оставлять по месту их записи в библиотеке постоянно, результат тот же, телодвижений меньше.
romxx
25.05.2022 14:12+5Я в IT так давно, что помню еще картриджи QIC40 ;) И первый свой архив я потерял именно на лентах. Просто перестал читаться. Нипочему. General Read Error. Все.
Потом раз в несколько лет жизнь меня сталкивала с разными форматами: DDS, Sony D8...
В 2004-м я пришел в сервисную компанию, которая по всему российскому энтерпрайзу чинила стримеры, вот там я нагляделся и на оторванные лидеры, после чего кассета с бэкапом в ведро, и на намотанные "бороды" спутанной ленты внутри драйвов.
Там уже были первые DLT и LTO. В общем, вся история лент прошла, фактически, у меня перед глазами.
И зарекомендовали они себя как крайне ненадежные устройства с очень узким функционалом и областью применения. Это подходит только для архива, причем "отчуждаемого", с каким-то внешним хранилищем.
Но раз в несколько лет я посматриваю на ленты после очередной статьи или восторженного неофита, или сейла, которому поставили задачу "продавать ленты". Потому что ну вдруг это заработало наконец, 30 лет спустя?
Последняя моя попытка была домашняя, с внешним SAS-стриммером LTO-5, полгода назад. Как раз была задача записать на архивное долговременное хранение несколько десятков терабайт с домашнего NAS, отвезти в хранилище и надолго забыть, до крупной аварии.
Покупаю LTO-5, покупаю SAS контроллер, покупаю кабель (все за весьма конские деньги, но ОК, надо - значит надо, "если я чего решил, то выпью обязательно"), покупаю пару коробок картриджей HP, новых, запечатанных. Заливаю первую партию. Все хорошо. Ну, не считая того, что стример вынул всю душу своим "взззз - бжжжж - вззз - вззз" на примерно 10 часов.
Спустя месяц решаю дописать на некоторые картриджи нужные добавления.
А они, хоба, не дописываются. Пытаюсь писать на новые ленты. А они уже не пишутся. General Error code 00x0. Утилита диагностики: "Что-то вот у вас не так, не могу завершить тест".
Все, так окончился очередной эксперимент с использованием лент.
В общем, коллеги, которые не имели опыта использования лент, и которым в очередной раз очередной сэйл ленточек морочит голову про "энтерпрайзное решение, выбор банков" - не нужно вам это, потому что говно. Извините за прямоту.
rionnagel
25.05.2022 19:24Тут вопрос целевого использования и масштабов. В вашем примере вы покупаете и эксплуатируете "для себя" дома по современным меркам уже устаревшее оборудование, а сопоставляете с банками и энтерпрайзом, где выход из строя одного стриммера вообще не будет считаться проблемой. Я не думаю, что корректно делать так выводы о том, что технология "не очень". Чем больше надо хранить - тем привлекательней становятся ленты, когда цена за сами стриммеры с библиотеками и тех обслуживание уже нивелируется объёмом лент. Тем более, для архива реальных альтернатив нет.
Ну и о вопросе эксплуатации я предполагаю, что нужна высокая стерильность помещения для высокой сохранности стриммеров (как кстати и всего остального оборудования). Там например датацентр, куда пускают в машинный зал строго в бахилах, наличие разделения горячий/холодный коридор и температурного контроля, запрет на пронос картона и прочего. Ну и отдельное хранилище с нужной температурой и влажностью для лент. В реальности к сожалению если денег мало - такого не будет (.Пытаюсь писать на новые ленты. А они уже не пишутся.
Cleaning tape покупали? Прогнать пробовали? Знаю, вопрос глупый, но... Просто по вашему рассказу создаётся впечатление, что получив подобную ошибку вы со злостью всё оборудование кидаете в мусор с матерным вариантом "да пошли к чёрту эти грёбаные ленты".
romxx
26.05.2022 12:11Cleaning tape покупали? Прогнать пробовали? Знаю, вопрос глупый, но...
Мне казалось, что я достаточно развернуто показал свой уровень знаний темы, чтобы не отвечать на вопрос "а вы пробовали выключить и включить"? ;)
Что же касается первого абзаца: я не отрицаю, что ленты имеют свою область применения. Видел многое. Речь про то, что их упорно пытаются впарить пользователям для непригодных или неподходящих кейсов и условий, аккуратно, до продажи, умалчивая о многочисленных недостатках, рассказывая только о "феноменальной надежности", "долговечности" и "беспрецедентной емкости и дешевизне хранения".
rionnagel
26.05.2022 14:05Ну вариант был бы нормальный, если бы стримеры стоили дешевле этак раз в 20).
screwer
26.05.2022 13:54Я никакой не сейлз. Первые ленты с приводом купил больше года назад. ЛТО5. Причем БУ (потом и новых лент докупил тоже). Все пишется, все читается. ЧЯДНТ ?
romxx
26.05.2022 16:23Возможно
вретеошибаетесь. Возможно неосознанно.
Знаете как это бывает у фанатов. На каком-нибудь LOR очень заметно. Выступает человек, у которого на линуксе "все работает". Но неловко получается, если кто-то, знающий его, пишет в ответ "Лех, так у тебя и то не работало, и се, и настройки при апгрейде слетали, и три месяца ждали пока на видеокарту блоб перепишут, и networkmanager, помнишь, в том релизе официально не работал с полгода".
Но так-то - да, "все работает". Извечная проблема фан-комьюнити :)screwer
26.05.2022 21:42Скорее вы врете. Потому что история про LTO5 вообще никак на реальность не натягивается. Повторю - у меня приводов много. Лент ещё больше. Пишутся они постоянно. И ни один картридж пока не сдох. (Хотя я к этому готов и это не станет для меня катастрофой).
А у вас как-то всё волшебно - первые ленты сразу сдохли. Все. Причём новые. И оставшиеся, новые, тоже дохлыми оказались вдруг. Прям чудеса. А чудес, как известно, на свете не бывает. Возможно увлеклись да. Переборщили с придумыванием ужасов.
И ещё "очень дорого, конский ценник, полгода назад" когда средняя цена бу стримера была 30тр на авито, куча предложений. А если поискать/подождать - то 20 и менее. Короче - "фантазёр".
Tarakanator
25.05.2022 15:47Это надолго. Ведь ленточные накопители считаются самыми надежными из распространенных накопителей (срок хранения от 15 до 30 лет).
Неправда. Распечатка хранится дольше 30 лет.
YMA
25.05.2022 16:58Угумс, пол-мегабайта на лист А4. Сурово и долговечно... ;)
И считывающий привод не нужен, главное - информация о кодировании и любое устройство для создания изображений.
romxx
26.05.2022 13:14А была же такая древняя шутка про загрузочный лист для Windows 95 (полез искать, но уже все, не находится). Причем шутка почти реальная, при необходимости можно было бы пропатчить биос SCSI-сканера, чтобы он как диск, при включении считывал бы область страницы, и заливал ее в бинарном виде в память, куда и отдавать исполнение.
azatfr
25.05.2022 20:38+2Ну если так, то записи на стенах пещеры сделанный охрой хранятся более 3 тысяч лет
Tarakanator
26.05.2022 08:13Я бы не сказал что на данный момент записи на стенах пешеры являются распространённым методом хранения информации.
А рачь шла именно про распространённые методы.Мне к примеру известен реально применяющийся способ хранения информации с помощью керна и металлической пластины. Как раз из-за бешенной надёжности. Данные даже в пожаре не страдают. Но это не распространённый метод хранения.
MaxMxMz
25.05.2022 18:16Для длительного хранения лент (30 лет) - только 1 кратная запись и ЖЕСТКО регламентированы влажность и температура. Я уже забыл сколько гардусов 18 и влажность 50%, но допуски на них были примерно +-1 градус и не более +-5% влажности. Так что покупаем климатконтроль. Да, производитель лент Fuji, утверждает что у него есть устройства для считывания запорченных лент. Но можно ли реально этим сервисом в настоящее время - большой вопрос
SergeyMax
25.05.2022 20:01устройства для считывания запорченных лент
Считывать-то оно считывает, но не получится ли как в анекдоте про 1200 знаков в минуту?
romxx
26.05.2022 13:07Еще энтузиасты архивного хранения на лентах часто плавно обходят тему стандартов и форматов.
Вот смотрите, первый современный интерфейс "бытового" жесткого диска (я специально сейчас оставлю в стороне SCSI и FC, которые бытовыми никогда не становились), IDE (AKA ATA/PATA) появился в 1986 году. С этого времени он в какой-то момент поменялся на SATA.
И... все.
То есть за последних 35 лет я могу прочитать любой бытовой жесткий диск при наличии двух этих интерфейсов в компе.
Ну, SATA есть у всех, а для PATA у меня дома, например, лежит USB-бокс с PATA (последний раз использовал лет 5 назад для 300GB диска со старой MP3-музыкой). Все.
При этом за те же 35 лет я могу даже без википедии наверное перечислить десяток стандартов и форматов картриджей с лентой, либо совсем несовместимых, либо ну очень примерно совместимых (как соседние форматы LTO, например). И вот чем я должен читать какой-нибудь TRAVAN или DLT в 2022-м году? Искать на ебэе чудом работающий драйв, чтобы вычитать нужный мне файлик с, возможно, еще читающегося картриджа?
Иллюзии.
ЗЫ. А, во, нашел, любуйтесь
Magnetic Tape for Data | Museum of Obsolete Mediascrewer
26.05.2022 13:53-1Нещитово, вы к диску и устройство чтения приложили (Неотъемлемое). А к лентам - нет. Приложите пару стримеров к лентам, и ВНЕЗАПНО окажется что там такой же scsi для общения.
DaemonGloom
26.05.2022 14:25+2Одно устройство для чтения всех дисков возможно положить на полку, один стример для всех лент — нет. Тем более, что usb адаптер можно и для других целей использовать, а стример для лент — только для архивирования на ленты. Бонусом — его ещё и воткнуть можно хоть в комп, хоть в ноут, хоть в телефон. А с usb-scsi адаптерами всё плохо, судя по гуглу. Т.е. в накладных расходах — стримеры за все эти года, адаптер scsi и комп, куда этот адаптер можно сунуть.
screwer
26.05.2022 14:37-1Одно устройство для чтения всех дисков возможно положить на полку,
Ещё раз - у вас к каждому диску (пачке блинов) приложено неотьемлемое устройство чтения. Это плата электроники, двигатель, блок головок, сам корпус. Для каждого хдд оно своё собственное. За него вы платите производителю, каждый раз. (И, кстати, без возможности переиспользования - отказ "устройства чтения" повлечёт потерю всех данных, даже если на блинах с ними всё прекрасно. Я, например, случайно сжёг два харда. Взяв пигтейлы питания от одного модульного БП и воткнув в другой. С механикой всё хорошо, а вот супрессоры спасли только древний 1тб диск, на втором отгорели головки и 3тб "отъехали" в мир иной навечно.). С лентами же отказ устройства чтения не означает потерю данных! Откуда взялось "одно устройство для чтения всех дисков", о чём вы вообще ?
один стример для всех лент — нет
Это ещё почему ? У меня 3 запасных стримера. Четвертый в компе. Если надо подключаю один-два из запасных, и пишу на несколько картриджей одновременно.
Тем более, что usb адаптер можно и для других целей использовать
Откуда вдруг взялся USB адаптер ? Что за цели ?
А с usb-scsi адаптерами всё плохо, судя по гуглу.
А с USB-SAS ?
Т.е. в накладных расходах — стримеры за все эти года, адаптер scsi и комп, куда этот адаптер можно сунуть.
И сколько стримеров нужно ? У меня второй год ленты, и пока ни один стример не сдох. Адаптер FC для PCIe стоит 500 рублей. Ну а комп у меня и так есть, и не один. Не люблю убогие ноуты. Не возражаю чтобы их владельцы немножко пострадали, раз они выбирают "мобильность" (или, по крайней мере, думают так).
DaemonGloom
26.05.2022 14:44+1Откуда взялся, устройство для чтения всех дисков, что за usb адаптер, сколько стримеров нужно за два года…
Пожалуйста, прочитайте первое сообщение в этой ветке ещё раз. Там указаны и года, и адаптеры.И да, сжечь можно вообще что угодно, было бы желание. Тот же стример тоже может умереть разнообразными способами, в том числе и убив ленту. Примеры от человека из сервис-центра были где-то выше.
screwer
26.05.2022 22:24Пожалуйста, прочитайте первое сообщение в этой ветке ещё раз. Там указаны и года, и адаптеры.
Причем тут первое сообщение, если у нас диалог уже совсем про другое - про устройство чтения, которое от хдд не отделить.
И да, сжечь можно вообще что угодно, было бы желание. Тот же стример тоже может умереть разнообразными способами, в том числе и убив ленту.
Может умереть. Может умереть убив ленту. А может и не убив. И уж всяко не убив ВСЕ ленты (а хдд убьёт все данные, т.е. десятки лент сразу. И убьёт надёжно).
romxx
26.05.2022 15:40У меня 3 запасных стримера. Четвертый в компе. Если надо подключаю один-два из запасных, и пишу на несколько картриджей одновременно.
romxx
26.05.2022 15:32Щитово-щитово. Диски SATA появились примерно с середины 2000-х, где-то с 2005, допустим.
И для того, чтобы их прочитать, мне не нужно никаких интерфейсов или отдельных устройств, потому что SATA есть всюду.
Сколько бы мне пришлось держать (причем еще и время от времени убеждаясь в их работоспособности) "интерфейсов" для чтения лент?
Только LTO сменилось СЕМЬ поколений, а были всякие DLT, SDLT, DDS, IBM 3890, Storagetek, AIT, VXA (это вот все я так или иначе вживую видел в России).
Для дисков ДО 2005 и эпохи SATA нужен тоже ровно ОДИН интерфейс, причем найти его сравнительно элементарно. А вот насколько элементарно будет найти како-нибудь драйв для QIC80 или IOmega Ditto?screwer
26.05.2022 22:20Только LTO сменилось СЕМЬ поколений
Девять уже. И все эти LTO это старый добрый SCSI. Который завёрнут в два физ.интерфейса, используемых во всех 9ти поколениях - SAS и FC.
а были всякие DLT, SDLT, DDS, IBM 3890, Storagetek, AIT, VXA (это вот все я так или иначе вживую видел в России).
В которых также старый добрый SCSI. И наверняка физических интерфейсов было тоже немного, если не единственный.
Для дисков ДО 2005 и эпохи SATA нужен тоже ровно ОДИН интерфейс
Уже нет. Твердотельные диски внесли свою лепту. Есть SATA. Есть NVMe. Есть SATA но в M.2 формате.
romxx
27.05.2022 11:08Вы совершенно напрасно глупо упорствуете в своем видении. Это вас вообще не красит.
SCSI (кторых тоже было примерно 4 или 5) он "старый добрый" только в том случае, если у вас к картриджу есть еще и устройство чтения. Для HDD мне не нужно устройство чтения, оно всегда уже находится внутри диска. А для картриджа с лентой мне еще где-то надо найти это устройство. И вот тогда уже "SCSI".
Давайте, найдите мне драйв на SDLT сейчас.screwer
27.05.2022 12:00+1Для HDD мне не нужно устройство чтения, оно всегда уже находится внутри диска.
Не понимаю, почему вы считаете это плюсом. Производители делают так от безысходности. Первые диски вполне имели раздельными устройство чтения и пластины с данными. В современных же, даже просто плату электроники не поменять, без переноса адаптаций.
А для картриджа с лентой мне еще где-то надо найти это устройство.
Зато для картриджа оно может быть одно, на весь парк картриджей соотв. поколения. С вытекающими отсюда достоинствами.
Давайте, найдите мне драйв на SDLT сейчас.
Их полно на ebay.
Но как вы не поймёте, устройства имеют естественное устаревание. Даже LTO-4 не выглядят особо интересными сегодня. А всё более древнее тем более, включая хдд. Данные с этих динозавров давно перенесены. А если даже ВДРУГ нет - ebay в помощь.
Вы, кстати, тоже просто так не подключите IDE диск к современному PC. К ноуту вообще ничего не подключите, кроме USB. Нужны будут переходники. Да, их сейчас много и они дешёвые, ибо массовые. Но суть это не меняет.
Следующий уровень это SAS HDD. Ещё труднее будет подключить старый SCSI HDD (хотя устройство чтения внутри, всё как вам нравится).
Интересно будет посмотреть на попытку поработать с MFM HDD, ровесником вашего DLT. И как "встроенное устройство чтения" вам поможет.
Mart
Может кто-нибудь пояснить мне, почему ленточные системы всё еще очень дорогие и для простого пользователя никак не доберутся?
Спасибо!
DMGarikk
ну наверное потому что спроса нет в этом сегменте
а общедоступные облака окончательно похоронили эту идею (если об этом ктото и мечтал)
а иметь дома минисерверную — удел немногих
Mart
с usb 3 интерфейсом сделали бы и нормально пошло бы
YMA
Есть такое, но оно вам нужно за такие деньги? 3600-5900 у.е.
Mart
Так вопрос и стоит, почему оно стоит таких денег? Суперпередовые технологии?
vorphalack
дорогая прецизионная механика с термостабилизацией + объемы производства.
13werwolf13
могу дать контакты человека у которого пара таких (с usb3) валяются без дела, он может их продать за недорого. правда я не знаю какое это поколение, да и самих картриджей как я понимаю у него уже не осталось.
Mart
я могу и SAS подключить себе, тут был скорее вопрос про массовое распространение такого типа продукта, а в массе USB 3.0 более ходовой интерфейс, нежели SAS или external SAS.
но спасибо за предложение!
YMA
"Простому пользователю" это не нужно. Бэкапить ежедневно терабайты данных и хранить их годами - уже специфично...
Простому хватит внешнего винчестера. Чуть менее простому - учетку в облаке. Еще менее простой заведет оптический привод. Продвинутый поставит NAS и объединит всё это в систему.
Mart
Я бы сохранил пару террабайт фото в raw и видео на кассетку и кинул бы у родителей на чердаке.
Облака и горят иногда, да и стоимость хранения пару терабайт кусается, особенно если это холодные данные. Amazon glacier не так уж и дешёв.
Оптический привод может предложить только 50GB и цены на эти болванки какие-то неадекватные.
YMA
2 терабайта - это 40 BD-DL, небольшая коробочка. Стоить будет 12000 руб. на диски и около 10000 руб. на привод (меньше 300 долларов).
Ленточный привод и 1 кассета (новые, не б/у) обойдутся куда дороже.
Mart
Согласитесь, архивировать переодически 2TB на 1 кассету проще, чем на 40 дисков.
Вопрос изначально ставился, почему ленточные накопители, не смотря на кажущуюся простоту привода и кассеты, и потенциальную выгоду хранения из расчёта на TБ, всё еще дорогие для простого пользователя.
vp7
Потому, что это кровавый энтерпрайз (а он может позволить себе быть безумно дорогим с точки зрения обычного пользователя), нет серьёзного рынка обычных пользователей, а также по той причине, что если уронить цены для обычных пользователей, то резко упадёт прибыль с кровавого энтерпрайза.
В результате, для обычных пользователей остаётся только покупка довольно древних б/у LTO-5/LTO-6, которые энтерпрайз меняет на более современные версии. Вот только оценить перед покупкой состояние приводов достаточно проблематично (профессионалы-то, наверное, знают, а вот как это сделать обычным пользователям...).
goletsa
Дианостический и обслуживабщий софт относительно легко доступен - HPE L&TT например.
Прогнать базовые тесты привода дело на полчаса.
Обычный пользователь с LTO4/5 приводам и библиотекой :-)
yerbabuena
Интересно, почему такого не происходит с интеренетом? ТАм тоже цена для физиков и цена для юриов отличатся на порядки.
DaemonGloom
Потому что провайдеры не любят хитрых типов и офисную нагрузку вполне отслеживают. После чего клиент отправляется на другой тариф. Да и при подключении тоже могут возникнуть вопросы.
Ну и во всяких БЦ физиков нет изначально, так что там в любом случае придётся брать тариф юр.лиц.
amarao
$69
Sergey_datex
через несколько месяцев привет данным. срок сохранности данных на TLC флешах 3 месяца гарантируемый. мы в практике видим реальные проблемы после полугода
YMA
Не уверен, что современные тонкие флешки с TLC/QLC продержатся лет 10, ибо диффузия, утечки и прочие матерные слова... Плюс в случае проблемы с контроллером в ней есть риск потерять всё и разом.
А в том, что оптика может прожить 12 (DVD) или 23 (CD) года, я уже убедился лично. :-Р
blind_oracle
Про сохранность данных уже сказали, но на чердаке её потом точно не найдёшь :) Я эти карточки вдохнуть иногда боюсь случайно...
Mart
что-то мне кажется это "китайские" 2TB за таку цену...
Zundapp
Сколько раз удастся ее прочитать, никто не знает...
VBKesha
Авито вам в помощь LTO-5 можно отыскать за вполне приемлемые деньги. Там же и картриджи бывают по очень вкусным ценам.
AlexanderS
Четырёхслойные BDXL дадут вам 128 Gb. Но цена будет ещё менее гуманная, чем болванки BD DL.
PeterZha
Здесь есть специфическая проблема, о которой вендоры предпочитают умалчивать - да, срок жизни ленты, особенно ленты с не очень высокой плотностью, типа старых лент DDS-2..DDS-4 действительно исчисляется десятилетиями. Но вот срок жизни привода по мере роста плотности записи такими числами точно не измеряется, в особенности при хранении/эксплуатации в неидеальных условиях - при наличии пыли, например.
Для устройств начиная уже с DDS-4 соседство в одном помещении с картриджами для лазерных принтеров ведёт к ускоренному выходу из строя магнитных головок из-за наличия в воздухе пыли тонера и на эту тему были даже какие-то исследования в середине нулевых.
Механика современного LTO-привода по навороченности превосходит таковую у жёстких дисков. Наличие обязательного чтения на два поколения назад, конечно, спасает в каком-то смысле, но фактически это означает необходимость менять дорогостоящее читало раз в пять-семь лет и перегонять весь архив на новые картриджи для сохранения уверенности в том, что архив будет чем прочитать..
goletsa
Проверять целостность копии это хорошая практика.
Потому часто приводы покупают через 1 поколение, чтобы вычитать старое и записать в кратно большие картриджи
edo1h
глядя на стоимость ленточных накопителей, я сомневаюсь, что их будут ставить в чулане для картриджей.
Grommy
Я стоял перед таким же выбором недавно. Данные личные, в смысле фотовидео - хранятся на винтах, лежащих на полке, плюс NAS домашний. Но по правилам трёх точек хранения ... мучительно хотелось мне ещё одно, совсем архивное место.
Присматривался к стримерам (ленточным) на Авито. Парочка вариантов была соблазнительной..но выбрал блюрей. Сейчас в доступе у нас близко лишь 25 Гб болванки. Есть как раз с однократной записью. М-Диск я не нашел, пока так погоняю :)
Пару Тб упакую, и буду иногда тестировать :)
AlexanderS
Полно на авито дисков в 50 и 100 Gb. Откуда этот миф, что с доступностью дисков проблемы? Я ещё понимал если бы жаловались с доступностью по ценам… потому что вроде как 1-2 диска купить ещё ничего, а забекапить терабайты уже порядок сумм другой получается.
Grommy
Есть такие диски и продавцы. Но мне в магазине удобнее брать, в тот же день, когда захотелось. Речь шла о М-дисках, с ними проблема.
blu ray 50gb m-disc поиск по такой строке даёт совсем иной результат. Я об этом. Говорят, что на практике обычные хорошие диски BD-R годятся вполне для архивирования, я это буду как раз изучать.
Теперь по объему.
Фотолюбители, и тем более фото-профи начали охотиться за флешками большого , когда они появились. А затем...передумали :)
Многие, по крайней мере.
Почему? Вопрос в надёжности. Поломаться может и 32 Гб и 128 Гб флешка. Но в первом случае повреждены или утеряны данные за полдня съёмок, условно. А во втором - за весь отпуск или большую работу..
Поэтому многие стали класть яйца в разные корзины, а фотки/данные - на несколько носителей. У меня в фотике две флешки стоят, на одну идут RAW, на другую jpeg. Удобно и надёжно.
С архивированием на оптические диски, я решил, будет то же самое. 25 Гб на диск пока для меня оптимум, чтобы помнить и ориентироваться в этом. Для видео лучше будет другой объем, возможно, но до этого этапа я ещё не добрался :)
AlexanderS
Я по своему опыту могу сказать, что трёхслойные болванки (100Gb) 5 лет пролежали и прочитались. Но тут проблема в том, что непонятно как оценить деградацию носителей. Некоторые CD/DVD умели отдавать низкоуровневые ошибки и используя Opti Drive Control на базе сделанной карты ошибок чтения как эталон сразу после записи можно было воочию видеть как носители деградируют со временем. А тут-то такого не завезли. Прочитаться-то оно прочиталось, а там может значение BLER сильно подскочило и стоит задуматься о замене носителя, пока он ещё читается нормально.
Grommy
Как я понял - ODC включается не на всех приводах...что-то перешивают даже, чтобы иметь возможность контроля за ошибками..
AlexanderS
Opti Drive Control это программа, которая просто умеет обращаться к служебным данным накопителя. А вот будет он их отдавать или нет зависело от производителя и, да, его прошивки.
Zundapp
Есть еще древняя вещь, но исключительно надежная, это магнитооптика. 30 лет обещают без проблем. На Авито можно найти, до 1,3Gb диски вполне себе рабочие.
NAI
Small Office, человек так на 30-50-100 вполне могло бы и зайти.
Те юз.кейсы с которыми я сталкивался работая инженером-администраторм в такой фирме:
Разработали проект, сдали. Срок хранения документации 30 лет. Окей, с бумагой все понятно - в архив, а с цифровыми данными? Записал кассету, положил в тот же архив. Сейчас пишут на CD\DVD, но вангую что лет через 5 найти привод будет проблемой. Плюс уже есть диски которые не читаются. Найти качественные CD\DVD нынче проблематично. План Б - писать на USB-HDD, но чет такое себе.
У нас было в 2016 около ~500 Гб активной информации, т.е. та информация с которой работают люди, еще ~500 Гб архивной и запрет заливать образы отгружаемых систем. Вроде не много НО! 90% инфы бинарный формат всяких САПР, офисов и прочих PLC-image'ов. Как итог на рейд в 2 Тб влезало 1 полная копия и пучек инкрементальных (штук 10-15). Плюс надо было держать второй, удаленный сервер, в другом здании, плюс синкать его по расписанию а не держать on-line (это чтобы если кто-то вдруг, что-то зашифрует, то чтобы шифрованная копия не улетела в хранилку) Плюс рейды.... Кароче, на 1 Гб полезной инфы, приходилось порядка 5 Гб сырой.
И лента решила бы массу проблем если бы не была такой дорогой. Записал, отнес в архив, все. Не надо организовывать отдельную серверную на удаленной площадке, 2-26 Тб на одной кассете, хочешь дописывай, хочешь разделяй. Сразу оффлайн копия которой не страшны шифровальщики. Не надо всех отгонять от сервака - "че он пустой стоит? Давайте на него <service name> повесим"
P.s. напоминаю что речь идет о небольшой организации.
blind_oracle
Жесткие диски нынче по 20Тб и вроде больше уже - хоть обархивируйся :)
Диск тоже можно сделать рид-онли и прочие волшебства со снапшотами и версиями на случай шифровальщиков. Ну и просто отмонтировать пока не нужен.
Mart
системы ленточных накопителей рекламируются как "дёшево" и "надёжно".
20TB винчестер стоит 400+ USD/EUR, что никак нельзя назвать "дёшево" в расчёте на TB.
DaemonGloom
По факту — купить NAS на четыре диска и диски к нему окажется проще, надежнее и дешевле. И при проблемах — диски всегда можно воткнуть куда угодно, не будет зависимости от приводов по негуманным ценам. Бонусом — регулярная проверка сохранности данных на дисках. Достаточно питания и локальной сети (если хочется онлайн доступ) или только питания (если данные копируются с USB дисков кнопкой на NAS).
screwer
БУ лто5 привод можно купить за цену такого диска. За цену второго - 40тб лент, новых. Итого паритет по цене. Зато даже если один картридж (или сам привод) сдохнет - потери будут куда меньше чем при сдыхании хдд.
NickViz
хм, на второй сервер деньги нашлись, а на ленту нет?
NAI
Конечно же все считали, выходило что-то около 100к-150к (напоминаю, речь идет о 16 годе) за ленту, 60-100к за тауэр-сервер и 40-60 за synology DS418+5х2Тб дисков.
Radisto
Арвид был вроде дешевый и добрался. Но он кажется никому не понравился
Grommy
Мне Арвид нравился, я пользовался активно. Сейчас кассеты уже маловаты будут, а тогда ого-го!:)
buldo
В этом году купил LTO-4 привод для домашнего бэкапа за 15тр. Правда он scsi :(
И 5 новых касет удалось урвать за 4тр. Вполне норм.
Плюс оказалось, что купить proliant 4го поколения стоит столько же, сколько и scsi карту - 3тр.
AlexanderS
Они никогда уже похоже не доберутся. Технологии становятся всё тоньше (лента, дорожки, головки), повышается точность механики — всё удорожается. Энтерпрайз = х3 к цене.
Пару лет назад передо мной подобную задачу ставили. Я тоже искал, читал, смотрел на авито. В результате сделали бекап на блюрей. Писались эти терабайты на болванки 100 Gb, причём два комплекта, так как потеря одной болванки… а это 100 Gb… в общем больно. Но оптика тоже не так надёжна как хочется. Есть, конечно разрекламированный M-DISC, но там стоимость… Но это всё хорошо для редкого бекапа раз в десятилетку. И то червячок точит: «А вдруг не прочитается?»
А если надо куда-то девать терабайты раз в полгода или год, то для дома NAS это просто безальтернатива ибо диски лежащие на полке всё равно ненадёжны, имеется личный печальный опыт. Два диска по 10 Tb + TrueNAS со своей ZFS. Собираем всё в какой-нибудь маленький корпус и куда-нибудь ставим — оно дублировано, отказоустойчиво при сбое при записи, периодически скраббинг делает «чиня» данные если потребуется. А если железо некультурно накроется, например блок питания за собой всё утащит, то третий диск лет на полке.
Блюрей и NAS — это более менее домашние бюджетные решения. Дальше начинается всё сильно дороже. И сделаю уточнение: кому кажется это всё избыточным — тому свои данные надёжно хранить всего скорее и не требуется.
screwer
Тут надо быть внимательным. Атмосферные 10Тб диски греются как скоты при работе. Я ухитрился разогреть один до 84 градусов(!!!), удалённо. При этом он лежал на столе. И обдувался напольным вентилятором. Но вентилятор почему-то отключился. Благо я мониторил температуры, перегрев длился не более десятка минут. Была сразу же снята нагрузка, а охлаждение восстановлено. Прошёл почти год, диск работает, но ситуация была довольно неприятной.
rPman
Мое мнение — это 'заговор' :)
Рядового потребителя и бизнес выгоднее (в глобальном плане) загнать в облако — это генерирует больше добавочной стоимости, больше компаний участвуют в процессе и занято делом, деньги перетекают туда сюда и экономика процветает… это я еще не говорю про то что потребитель и его данные становятся заложником, кто откажется от такой власти?
Ну и вопрос на засыпку, почему китайцы не занялись этим?
XCom1994
Ну тут как смотреть. Да, они дороже остальных накопителей, но если смотреть соотношение стоимости хранения данных 1 ТБ/1$, то ленточные однозначно выигрывают. Их приобретения можно рассматривать как инвестиция в ИТ, тк окупаемость их выше и растягивается на длительный период.
azatfr
Всё дело в экономии. Соотношение Объем/цена у лент выше чем у дисков, что при больших объемах позволяет существенно экономить, а там где сэкономил там получил доход. Оценивая какой «доход» принесет использование оборудования производители назначают цену.