Comments 189
Может кто-нибудь пояснить мне, почему ленточные системы всё еще очень дорогие и для простого пользователя никак не доберутся?
Спасибо!
а общедоступные облака окончательно похоронили эту идею (если об этом ктото и мечтал)
а иметь дома минисерверную — удел немногих
с usb 3 интерфейсом сделали бы и нормально пошло бы
Есть такое, но оно вам нужно за такие деньги? 3600-5900 у.е.
могу дать контакты человека у которого пара таких (с usb3) валяются без дела, он может их продать за недорого. правда я не знаю какое это поколение, да и самих картриджей как я понимаю у него уже не осталось.
"Простому пользователю" это не нужно. Бэкапить ежедневно терабайты данных и хранить их годами - уже специфично...
Простому хватит внешнего винчестера. Чуть менее простому - учетку в облаке. Еще менее простой заведет оптический привод. Продвинутый поставит NAS и объединит всё это в систему.
Я бы сохранил пару террабайт фото в raw и видео на кассетку и кинул бы у родителей на чердаке.
Облака и горят иногда, да и стоимость хранения пару терабайт кусается, особенно если это холодные данные. Amazon glacier не так уж и дешёв.
Оптический привод может предложить только 50GB и цены на эти болванки какие-то неадекватные.
2 терабайта - это 40 BD-DL, небольшая коробочка. Стоить будет 12000 руб. на диски и около 10000 руб. на привод (меньше 300 долларов).
Ленточный привод и 1 кассета (новые, не б/у) обойдутся куда дороже.
Согласитесь, архивировать переодически 2TB на 1 кассету проще, чем на 40 дисков.
Вопрос изначально ставился, почему ленточные накопители, не смотря на кажущуюся простоту привода и кассеты, и потенциальную выгоду хранения из расчёта на TБ, всё еще дорогие для простого пользователя.
Потому, что это кровавый энтерпрайз (а он может позволить себе быть безумно дорогим с точки зрения обычного пользователя), нет серьёзного рынка обычных пользователей, а также по той причине, что если уронить цены для обычных пользователей, то резко упадёт прибыль с кровавого энтерпрайза.
В результате, для обычных пользователей остаётся только покупка довольно древних б/у LTO-5/LTO-6, которые энтерпрайз меняет на более современные версии. Вот только оценить перед покупкой состояние приводов достаточно проблематично (профессионалы-то, наверное, знают, а вот как это сделать обычным пользователям...).
Дианостический и обслуживабщий софт относительно легко доступен - HPE L&TT например.
Прогнать базовые тесты привода дело на полчаса.
Обычный пользователь с LTO4/5 приводам и библиотекой :-)
если уронить цены для обычных пользователей, то резко упадёт прибыль с кровавого энтерпрайза.
Интересно, почему такого не происходит с интеренетом? ТАм тоже цена для физиков и цена для юриов отличатся на порядки.
это 40 BD-DL, небольшая коробочка.
C лотереей random data avialable.
PS (Мои диски записанные 12 лет назад меня спасли, но играть в лотерею не всегда хочется)
$69
через несколько месяцев привет данным. срок сохранности данных на TLC флешах 3 месяца гарантируемый. мы в практике видим реальные проблемы после полугода
Не уверен, что современные тонкие флешки с TLC/QLC продержатся лет 10, ибо диффузия, утечки и прочие матерные слова... Плюс в случае проблемы с контроллером в ней есть риск потерять всё и разом.
А в том, что оптика может прожить 12 (DVD) или 23 (CD) года, я уже убедился лично. :-Р
Про сохранность данных уже сказали, но на чердаке её потом точно не найдёшь :) Я эти карточки вдохнуть иногда боюсь случайно...
что-то мне кажется это "китайские" 2TB за таку цену...
Сколько раз удастся ее прочитать, никто не знает...
Здесь есть специфическая проблема, о которой вендоры предпочитают умалчивать - да, срок жизни ленты, особенно ленты с не очень высокой плотностью, типа старых лент DDS-2..DDS-4 действительно исчисляется десятилетиями. Но вот срок жизни привода по мере роста плотности записи такими числами точно не измеряется, в особенности при хранении/эксплуатации в неидеальных условиях - при наличии пыли, например.
Для устройств начиная уже с DDS-4 соседство в одном помещении с картриджами для лазерных принтеров ведёт к ускоренному выходу из строя магнитных головок из-за наличия в воздухе пыли тонера и на эту тему были даже какие-то исследования в середине нулевых.
Механика современного LTO-привода по навороченности превосходит таковую у жёстких дисков. Наличие обязательного чтения на два поколения назад, конечно, спасает в каком-то смысле, но фактически это означает необходимость менять дорогостоящее читало раз в пять-семь лет и перегонять весь архив на новые картриджи для сохранения уверенности в том, что архив будет чем прочитать..
Проверять целостность копии это хорошая практика.
Потому часто приводы покупают через 1 поколение, чтобы вычитать старое и записать в кратно большие картриджи
Для устройств начиная уже с DDS-4 соседство в одном помещении с картриджами для лазерных принтеров
глядя на стоимость ленточных накопителей, я сомневаюсь, что их будут ставить в чулане для картриджей.
Я стоял перед таким же выбором недавно. Данные личные, в смысле фотовидео - хранятся на винтах, лежащих на полке, плюс NAS домашний. Но по правилам трёх точек хранения ... мучительно хотелось мне ещё одно, совсем архивное место.
Присматривался к стримерам (ленточным) на Авито. Парочка вариантов была соблазнительной..но выбрал блюрей. Сейчас в доступе у нас близко лишь 25 Гб болванки. Есть как раз с однократной записью. М-Диск я не нашел, пока так погоняю :)
Пару Тб упакую, и буду иногда тестировать :)
Есть такие диски и продавцы. Но мне в магазине удобнее брать, в тот же день, когда захотелось. Речь шла о М-дисках, с ними проблема.
blu ray 50gb m-disc поиск по такой строке даёт совсем иной результат. Я об этом. Говорят, что на практике обычные хорошие диски BD-R годятся вполне для архивирования, я это буду как раз изучать.
Теперь по объему.
Фотолюбители, и тем более фото-профи начали охотиться за флешками большого , когда они появились. А затем...передумали :)
Многие, по крайней мере.
Почему? Вопрос в надёжности. Поломаться может и 32 Гб и 128 Гб флешка. Но в первом случае повреждены или утеряны данные за полдня съёмок, условно. А во втором - за весь отпуск или большую работу..
Поэтому многие стали класть яйца в разные корзины, а фотки/данные - на несколько носителей. У меня в фотике две флешки стоят, на одну идут RAW, на другую jpeg. Удобно и надёжно.
С архивированием на оптические диски, я решил, будет то же самое. 25 Гб на диск пока для меня оптимум, чтобы помнить и ориентироваться в этом. Для видео лучше будет другой объем, возможно, но до этого этапа я ещё не добрался :)
Есть еще древняя вещь, но исключительно надежная, это магнитооптика. 30 лет обещают без проблем. На Авито можно найти, до 1,3Gb диски вполне себе рабочие.
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. напоминаю что речь идет о небольшой организации.
Жесткие диски нынче по 20Тб и вроде больше уже - хоть обархивируйся :)
Диск тоже можно сделать рид-онли и прочие волшебства со снапшотами и версиями на случай шифровальщиков. Ну и просто отмонтировать пока не нужен.
системы ленточных накопителей рекламируются как "дёшево" и "надёжно".
20TB винчестер стоит 400+ USD/EUR, что никак нельзя назвать "дёшево" в расчёте на TB.
По факту — купить NAS на четыре диска и диски к нему окажется проще, надежнее и дешевле. И при проблемах — диски всегда можно воткнуть куда угодно, не будет зависимости от приводов по негуманным ценам. Бонусом — регулярная проверка сохранности данных на дисках. Достаточно питания и локальной сети (если хочется онлайн доступ) или только питания (если данные копируются с USB дисков кнопкой на NAS).
И сдохнут они лет через 5-10 (причем независимо от того, крутились или "в чулане лежали". Пленка хороша тем, что достаточно сунуть в пакетик специальный - и быть уверенным, что через 30 лет (требуемые по ГОСТу) эту плёнку вынешь из коробки и прочитаешь.
С картриджами сложнее, но тоже лучше чем с дисками (3 поколения - это меньше 30 лет. Так что придется привод запаивать в среде азота и класть вместе с картриджами).
Есть кривая выгодности того или иного способа в зависимости от стоимости. Даже при многих плюсах ленты сейчас при нынешней стоимости HDD в RAID 1,10 и прочих надежность не меньше. При этом из HDD можно организовать вообще вечный архив, и даже посчитать со временем стоимость хранения (как наберется статистика выходов из строя), и часто эта стоимость ниже стримеров да еще и плюс удобство HDD. На стримерах RAID не воплотили. При этом даже если решать проблему энергоуязвимости HDD (возможность умереть от скачка напряжения) двойным дублированием NAS - все равно оказывается дешевле. То есть мы держим 2 копии NAS и каждый RAID 1,10 и никогда не включаем их одновременно. Еще и закупаем хороший UPS бесперебойник, и все равно дешевле. Не говоря уже о экономии времени при работе с большими объемами данных, и удобного доступа к данным большого количества пользователей. Еще такой момент, что HDD можно по мере отработки ресурса все же продавать по какой то остаточной амортизационной стоимости или использовать далее самим для менее важных задач, чего не седлаешь с лентами. при этом HDD оптом - еще дешевле.
У нас процедура и история жизни НDD в качестве хранителя в массиве информации на 50 Тб примерно такая:
1. Куплен в партии, проверен тестами, если исправен, лежит на складе (неисправен - по гарантии)
2. 1-й NAS постоянно работающий (ну или почти постоянно работающий. Туда идут диски новые. Он хранит полный экземпляр все информации в районе 40 Тб.
Новый HDD в зависимости от модели (есть данные) отрабатывает в нем от недели до нескольких месяцев в RAID при хороших нагрузках. За это время все сбойные, со скрытым браком или просто не живучие HDD проявляют себя и заменяются на новые. Умирающие, или нестабильные, сбойные, уходят назад по гарантии меняются (заметьте на данном этапе мы еще не теряем денег при поломках - только хлопоты по гарантии). Так мы сортируем хорошие экземпляры (порой даже партии), и выводим на обмен сбойные (плохие). Часто этот срок = сроку гарантии. Всю гарантию диск отрабатывает в интенсивном режиме в работе в NAS1
3. Вот эти удачные/хорошие экземпляры обработавшие гарантию идут в NAS 2 (резервный NAS c полной копией/зеркалом). Иногда, когда у нас случается ситуации одновременности что все HDD в массиве NAS 1 одновременно (ну или примерно одновременно) перешли в статус новых удачных с прогоном и с хорошим еще ресурсом, этот NAS1 просто переименовывается в NAS 2, и становится резервным не под питанием, а NAS2 c более старыми дисками, но тоже уже все ранее пропущенные через процедуру прогона, становится NAS1 и пускается в работу на износ как бы (выработку ресурса) до дна.
4. Так диски надежные но послегарантийные отрабатывают ресурс в NAS1. Они либо там начинают умирать (ошибки чтения, позиционирования и прочее) и опять меняются новыми для просеивания новых, либо когда предполагаемый срок ресурса их подходит к концу снимаются и идут в NAS 3 (он тоже полная зеркальная копия). Те что сбоят ошибки идут либо в домашнее применение своим, либо на продажу по остаточной цене как возможные к использованию для некритической информации.
NAS3 служит для промежуточного буфера между NAS 1 и NAS 2. То есть NAS 1 никогда напрямую не зеркалится на NAS 2 (одновременно не включена).
Зеркалирование происходит следующим образом:
К NAS 1 (который в основной работе и на раздаче), подключается NAS 3 с неизвестной надежностью. На него доделывается инкрименентно полная копия NAS 1, проверяется. Потом в самый ненагруженный момент времени (ночью часто), NAS 3 включается в работу, NAS 1 выключается вообще полностью, а NAS 2 включается для зеркалирования с NAS 3. То есть NAS 1 и NAS 2 одновременно не бывают под питанием. (хотя конечно 3 независимых бесперебойника у каждого и выпрямители, стабилизаторы еще перед ними). Когда NAS 3 отзеркалился и равен NAS 1, то NAS 2 выключается, включается NAS 1, сверяется еще раз с NAS 3, и NAS 3 тоже выключается. NAS 1 опять в работе.
Движение HDD идет от NAS 1 к NAS 3 и далее на продажу или в домашние компы или на утилизацию.
Сейчас сложилась такая ситуация, то часто есть как бы HDD которые никак не ломаются, и уже отработали все что можно и в NAS 3 даже, и уже с NAS 1 надо в NAS 3 перекидывать некоторые, а они все не ломаются, тогда как бы появляется NAS 4 (совсем холодный) просто в виде пронумерованных дисков готовых встать в любой момент в RAID. Просто лежат на полке (да там не самое актуальное зеркало). Но когда не лень и есть время, то зеркалируем их в NAS 3 и опять на полку, пока не продадутся. Конечно перед продажей все чистим, хотя с 1 HDD из RAID вряд ли кто то что то выдернет купив только 1. Но бывает и по 3 и более берут, людям часто важно с одной партии.
В целом по статистике с 2002 года, не терялась информация ни разу, и даже не было предкритичной ситуации, когда только 1 полная копия. По стоимости это раза 4-5 дешевле ленты, не говоря уже про удобства и доступности и экономию времени. почти все проблемное выявляется по гарантии, после все текучки, ипостасей и отработки 60-70% дисков даже без ошибок, с хорошим смартом - продаются по довольно высокой остаточной стоимости.
Видимо это лучшее что можно придумать для важной информации, считай вероятность сохранности на большом промежутке времени 100%, при этом ты уверен в этой вероятности постоянно (а не в момент когда решил через 5-10 лет проверить ленту).
Этот способ в принципе использует даже природа и эволюция, она не стала изобретать очень надежный носитель информации, а использует очень хрупкую ДНК, но с многоразовым резервированием и удобством использования (но там свои проблемы с мутацией, что у людей решила математика и проверка ХЕШей).
Этот способ особенно хорош тем, что можно работать с обычным потребительским сегментом HDD, даже самые дешевые и с самыми обычными потребительскими компами в качестве NAS. Мы начинали c 15 ГБ HDD и Пентиума 4 (кстати даже из них есть живые еще), потом уже резко объемы пошли вверх 40 Гб, 80 ГБ, 120, 160, 200, 250, 400, 500, 1000... (почти в 2 раза с каждой новой закупкой, так и у нас потребности примерно в 2 раза в 4-6 лет). Все легко и недорого расширяется, а самое главное что ты всегда можешь купить быстро и большого количества продавцов. Мы никогда, кстати, не брали дорогие модели (типа БЛЭК или полупрофессиональную линейку) - всегда по низу рынка. Все неудачное (порой партии, ну как партии 5-10 шт. просто возвращались по гарантии). при этом надо понимать, что даже те диски которые возвращались по гарантии - все равно какие то диско-часы нарабатывают (то есть выполняют задачу для нас). То есть тестируя производителям их диски, мы и используем их под свои нужды это время. Я думаю в сумме это очень много часов считай бесплатного использования дисков. А гарантии бывали часто и не 1 год (были и 2,3 -5 лет), и некоторые диски отрабатывали большой процент времени гарантии на нас и на NAS))), а потом если не дотянули до гарантии, то менялись на новые или возврат денег. Нормально кстати работают и из разных серий и моделей RAIDы особенно с приходом dRAID, ZFS, NFS .
Такой опыт накоплен уже у многих на промежутке 20-30 летней эксплуатации. Я считаю разработчики систем хранения, могли бы воспользоваться таким опытом и все это автоматизировать/алгоритмизировать в едином устройстве.
Типа большой контейнер для HDD (для лент такие есть и для DVD, типа электромеханические dvd changer). Закидываешь туда к примеру 100 HDD каких угодно, он сам все это дело проверяет, тестирует по алгоритмам, в панели управления вводятся необходимые параметры объема хранилища, надежности, резервируемости и алгоритм сам просчитывает необходимые операции для 100% сохранности вечной. Пишет сколько надо закинуть ему HDD, сам сортирует их, маркирует, прогоняет по гарантии, выплевывает в лоток неисправные с пометкой и те что выработали ресурс (на полку или на продажу). Ну и там внутри себя сам делает что включено, что зеркалируется, что в холодном хранении, что в дублирующем холодном хранении, что на тесте - и сам обеспечивает движение HDD по жизненному циклу. Вся информация в ВЕБ интерфейс и управления. Инфа по каждому диску (наработка, циклов чтения и прочая)
Так кто мешает? :) Возьмите штук 10 дисковых полок, сервер и напишите соответствующий софт - все будет, как вы мечтаете. Ну разве что вставлять новые диски и извлекать старые придется все-таки самому по указаниям этого самого софта.
Механика для выбрасывания дисков в лоток будет излишне дорога и создаст лишнюю точку отказа, ее надо будет обслуживать, менять расходники и т.д.
"Полка 5 диск 8 - неисправен, требуется замена по гарантии"
А остальное - переброска дисков между пулами, диагностика, включение и выключение дисков - вполне реализуемо.
БУ лто5 привод можно купить за цену такого диска. За цену второго - 40тб лент, новых. Итого паритет по цене. Зато даже если один картридж (или сам привод) сдохнет - потери будут куда меньше чем при сдыхании хдд.
Только вот новый диск можно купить всегда, вот Б/У LTO - нет. Особенно если его производитель ушел из РФ из-за санкций. Диск это потребительская электроника и есть в магазине всегда, а вот LTO привод - нет. И если в случае пожара привод погибнет, то может быть проблемой купить второй такой же для того что бы прочитать уцелевший архив
Только вот новый диск можно купить всегда, вот Б/У LTO — нет. Особенно если его производитель ушел из РФ из-за санкций.
заметьте, вам писали про lto-5. lto-6 вышел в 2012 году, то есть речь о приводах, которым больше 10 лет.
как связаны уход производителей, которому несколько месяцев, и покупка антикварного б/у оборудования?
Попробуйте сейчас купить хотя бы Б/У при условии, что amazon и ebay недоступны
а в чём проблема?
ну и слухи о недоступности amazon с ebay сильно преувеличены
А как сейчас заказывать с ebay и amazon? В РФ никто из продавцов доставлять не хочет (но тут можно попробовать через форвардера), но как оплачивать (продавцу или форвардеру), если они только кредитные карты или paypal принимают?
форвардеры, ориентированные на россию, уже принимают рубли (а некоторые принимали и до всех этих событий).
по оплате товара, есть разные варианты: оплата рублями посреднику, оплата криптой (например, amazon gift card купить за крипту не проблема), поездка в соседнюю страну и оформление карты там,…
хайтек завернут на таможне, я пробовал черз сдековских баеров, банально сопло для 3d принтера купить (особенность выбора принтера с проприетраными заморочками), не пустили.
хм, на второй сервер деньги нашлись, а на ленту нет?
Про оптический привод сомнительно (учитывая многочисленные, в том числе на Хабре, статьи на эту тему).
Арвид был вроде дешевый и добрался. Но он кажется никому не понравился
В этом году купил LTO-4 привод для домашнего бэкапа за 15тр. Правда он scsi :(
И 5 новых касет удалось урвать за 4тр. Вполне норм.
Плюс оказалось, что купить proliant 4го поколения стоит столько же, сколько и scsi карту - 3тр.
Пару лет назад передо мной подобную задачу ставили. Я тоже искал, читал, смотрел на авито. В результате сделали бекап на блюрей. Писались эти терабайты на болванки 100 Gb, причём два комплекта, так как потеря одной болванки… а это 100 Gb… в общем больно. Но оптика тоже не так надёжна как хочется. Есть, конечно разрекламированный M-DISC, но там стоимость… Но это всё хорошо для редкого бекапа раз в десятилетку. И то червячок точит: «А вдруг не прочитается?»
А если надо куда-то девать терабайты раз в полгода или год, то для дома NAS это просто безальтернатива ибо диски лежащие на полке всё равно ненадёжны, имеется личный печальный опыт. Два диска по 10 Tb + TrueNAS со своей ZFS. Собираем всё в какой-нибудь маленький корпус и куда-нибудь ставим — оно дублировано, отказоустойчиво при сбое при записи, периодически скраббинг делает «чиня» данные если потребуется. А если железо некультурно накроется, например блок питания за собой всё утащит, то третий диск лет на полке.
Блюрей и NAS — это более менее домашние бюджетные решения. Дальше начинается всё сильно дороже. И сделаю уточнение: кому кажется это всё избыточным — тому свои данные надёжно хранить всего скорее и не требуется.
Два диска по 10 Tb + TrueNAS со своей ZFS. Собираем всё в какой-нибудь маленький корпус
Тут надо быть внимательным. Атмосферные 10Тб диски греются как скоты при работе. Я ухитрился разогреть один до 84 градусов(!!!), удалённо. При этом он лежал на столе. И обдувался напольным вентилятором. Но вентилятор почему-то отключился. Благо я мониторил температуры, перегрев длился не более десятка минут. Была сразу же снята нагрузка, а охлаждение восстановлено. Прошёл почти год, диск работает, но ситуация была довольно неприятной.
все ок. NAS для горячих данных. блюрей для холодных.
вот редко нужно чтобы террабайты архивов двухгодичной давности вдруг прям понадобились ежесекундно.
ну а живучесть любых носителей зависит от условий. держи дубль в холоде и сухости и проживут гораздо дольше.
mart
Может кто-нибудь пояснить мне, почему ленточные системы всё еще очень дорогие и для простого пользователя никак не доберутся?
Мое мнение — это 'заговор' :)
Рядового потребителя и бизнес выгоднее (в глобальном плане) загнать в облако — это генерирует больше добавочной стоимости, больше компаний участвуют в процессе и занято делом, деньги перетекают туда сюда и экономика процветает… это я еще не говорю про то что потребитель и его данные становятся заложником, кто откажется от такой власти?
Ну и вопрос на засыпку, почему китайцы не занялись этим?
Ну тут как смотреть. Да, они дороже остальных накопителей, но если смотреть соотношение стоимости хранения данных 1 ТБ/1$, то ленточные однозначно выигрывают. Их приобретения можно рассматривать как инвестиция в ИТ, тк окупаемость их выше и растягивается на длительный период.
А расскажите про софт. Как происходит процесс резервного копирования и восстановления? Что делать если из бэкапа надо восстановить "один файлик"?
Большинство backup-программ видят LTO-устройства без проблем
Я не работал с современными, но в 2008 году это было так:
найти кассету за нужный день
сунуть в привод
в софте (Symantec BackUp Exec) сначала нажать кнопку "Прочесть кассету" - софт строит дерево, занимало минут 15 на LTO-2
выбрать нужный файл, указать место куда восстанавливать, жмакнуть "восстановить"
софт крутил ленту быстро на нужное место и заметно медленне считывал файл. Если файлов много и в разных местах ленты, то процесс восстановления мог затянуться.
Если это был большой бэкап, который не влезал на одну кассету, софт просил вторую (третью, четвёртую) и их стоило внимательно помечать для экономии времени в случае восстановления - дерево строилось после полного чтения всех томов бэкапа, а смотка кассеты перед извлечением занимает какое-то время.
С инкрементами так же - сначала из условной пятничной кассеты достаётся по процедуре выше файл, а затем с понедельника и вторника накатываются инкременты.
Сейчас, думаю, принцип тот же, но скорости повыше.
EDIT: особое веселье было когда надо было кассету из архива заказывать. Они туда уезжали в понедельник, после полного пятничного бэкапа. Заказать-дождаться - сутки-двое легко могло занять, особо больно когда неделя кассет только уехала, а через час-два просят что-то восстановить...
У симантека такой же формат, как у NTBackup, только расширенный собственными стримами и блоками. TAR им родственник. Чтобы составить каталог надо промотать всю ленту. Если лента пишется "за раз" более грамотным решением было бы иметь единый каталог в начале
ЛТО-5 (2010 год) поддерживает технологию LTFS. Лента партиционируется на два раздела. Один под каталог, второй пол данные. После чего ее можно примонтировать как обычный диск. Правда, для быстрого чтения лучше использовать спец.утилиту, которая (в отличие от ОС) "знает" положение файлов на ленте, и способна читать их оптимально, за один проход.
ЛТО-2 должен был устареть к 2008 году и быть списан. Также непонятно зачем по много раз дописывать на картридж, там всего 200гб. Какая-то нищая организация ?
Логистика носителей в архив неспецифична для лент. Тут вы сами рисуете процесс, как умеете. С условными хдд было бы точно также. Плюс риск уронить его где-то в процессе, и лишиться всех данных.
У симантека такой же формат, как у NTBackup, только расширенный собственными стримами и блоками.
это фактически одно и тоже, потому что все вышло из Maynard, которую купил Archive, которую купил Conner, который купил Seagate, который купил Microsoft, который купил Veritas и продал лицензию Symantec
TAR им родственник.
Это вы NTBackup с NetBackup перепутали, вот в нем TAR.
Это вы NTBackup с NetBackup перепутали, вот в нем TATAR
Нет, не перепутал. "Родственник" - в ключе отсутствия выделенного каталога. А подобное решение с описателем, перед каждым блоком с данными. И необходимостью полной перемотки ленты чтобы построить каталог.
Нет, не перепутал
NetBackup использует tar структуры для хранения данных.
NTBackup aka BackupExec использует свою уникальную систему дескрипторов и потоков для хранения данных.
А подобное решение с описателем, перед каждым блоком с данными.
это используют большинство решений для бэкапа на ленту (их сотни). Я знаю только один тип бэкапа, которые не используют такую структуру, это LTFS - хранит каталог на отдельной partition, но принципиальной разницы между partition и отдельной сессией для каталога нет.
И необходимостью полной перемотки ленты чтобы построить каталог.
И BackupExec и NetBackup имеют отдельную ленточную сессию с выделенным каталогом. Так как это отдельная сессия, то ее поиск на ЛТО ленте занимает меньше минуты.
NetBackup использует
NTBackup aka BackupExec использует
Да не важно что за структуры там, важно что они перед каждым блоком с данными. Я писал и парсер TAR и парсер "расширенного" MTF. Для последнего - с эвристической машиной определения неизвестных тегов (стрим ли это, блок, либо ещё один неизвестный тип обьекта. Кстати, собственных, недокументированных стримов и блоков там несколько десятков, встреченных в реальных бекапах.)
но принципиальной разницы между partition и отдельной сессией для каталога нет.
Вот не видел я у Symantec (aka NTBackup) отдельной сессии с каталогом. В котором, полагаю, должны быть записаны... кстати что ? Положение остальных сессии ? Плюс полный индекс их содержимого ? И в доке по MTF не виделю Там тупо набор SSET-ов, и погнали в каждом: VOLB-DIRB-FILE-CSUM-SPAD, как базовый скелет. Узнать за "меньше минуты" что же именно записано на всей ленте - нет ни малейшей возможности. Бекапы реальные, от одного авиаперевозчика.
И в доке по MTF не виделю Там тупо набор SSET-ов, и погнали в каждом: VOLB-DIRB-FILE-CSUM-SPAD, как базовый скелет. Узнать за "меньше минуты" что же именно записано на всей ленте - нет ни малейшей возможности.
каталог живет не там где SSET, а в следующей сессии - ESET, в ней просто список файлов. Это кстати описано в доке на MTF.
ESET - это всего лишь окончание сессии. Пустой датаблок. В следующей сессии список файлов может быть, а может не быть. Только проблема в том, что этот список файлов - это не каталог. А натурально блоки и стримы как я выше написал. Перемежающиеся выравниваниями, данными этих самых файлов, расширенных атрибутов, именами директорий и разделов. И чтобы вычитать весь каталог - надо прочитать и весь датасет. Отдельного каталога НЕТ.
Вот пример начала датасета на 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).
ESET - это всего лишь окончание сессии. Пустой датаблок. В следующей сессии список файлов может быть, а может не быть.
ESET и есть в следующей сессии (после File Mark-а)
Только проблема в том, что этот список файлов - это не каталог. А натурально блоки и стримы как я выше написал.
вы упорно не хотите принимать реальность.
картинка из доки
Media Based Catalog - он хоть и optional, но мне пока ни одна лента не попадалась, где его нет.
Также непонятно зачем по много раз дописывать на картридж, там всего 200гб.
Я вроде бы не писал про "много раз дописывать".
ЛТО-2 должен был устареть к 2008 году и быть списан. ... Какая-то нищая организация?
Да, была. Закрылась недавно после четверти века страданий на дотациях из HQ.
Сейчас все то же самое, только кассету каждый раз перечитывать не обязательно. Если эта же СРК делала бекап, то она помнит структуру данных на ленте и сразу мотает куда надо.
в софте (Symantec BackUp Exec) сначала нажать кнопку "Прочесть кассету" - софт строит дерево, занимало минут 15 на LTO-2
Чтобы построить дерево, кассету не надо ни читать, ни даже вставлять. Информация о всех версиях забэкапленных файлов хранится в каталоге в базе данных сервера BackUp Exec. Читать каталог с ленты надо только если у вас нет данных в каталоге - например, рухнул сервер и вы сделали свежую установку BackUp Exec.
Кто же все таки оригинальный OEM-производитель? Может они не ушли из России и их можно закупить (хоть какая-то поддержка/гарантия лучше чем полное их отсутствие)?
Штука, конечно, неплохая, но огрехи реализации легко могут похоронить базовые преимущества. Приходилось юзать одну из таких LTO-систем на протяжении 5 лет. Не могу сказать, что там была какая-то дикая надёжность, за это время перестало читаться несколько кассет, причём, часть данных не удалось восстановить даже с помощью хвалёной проприетарной системы частичных бэкапов на разных кассетах. При этом RAID5 за то же время никаких данных не потерял при регулярной замене вышедших из строя дисков.
У нас был проект, где мы с подачи специалистов IBM использовали ленточное хранилище от IBM для уровня отложенного доступа - от него требовалась загрузка по требованию (это когда данные уехали на ленту и были стерты из БД, но вдруг понадобились опять и их нужно восстановить с ленточного хранилища в БД) - ну и намучились же мы с ним!
Нигде не написано, но лента имеет очень ограниченный ресурс по количеству перемоток, который по факту выбирается за считанные месяцы. А потом ленты нужно менять или начинать оплакивать погибшие данные...
Про ресурс ленты могу рассказать вот такой пример: в начале десятых годов бэкап базы данных по платёжным карточкам Казкоммерцбанка выполнялся еженочно на три разных совершенно новых картриджа. Потом два картриджа на двух разных автомобилях отвозили в два разнесённых на десяток километров хранилища Казкоммерцбанка в Алма-Ате. Третий картридж оставался в хранилище при серверной, на случай оперативного восстановления данных. Во второй раз ленты не использовали в этом банке никогда.
И что нам говорит этот пример ? Если есть много лишних денег - можно и на винты по одному разу писать.
Мой пример - купил 96 лто5 лент из-под одного авиаперевозчика. Остаточный ресурс картриджей 80-96%, по оценке hpetool. Использовал полтора десятка. Только полные перезаписи. От 5 до 30 раз. Пока не было ни одной проблемы ни с одним картриджем.
В начале 2000-х мы купили в университет LTO одного их первых поколений и наступили на эти грабли - кассеты дохли после десятка перезаписей. После этого я перестал верить во все мифы о надежности лент. Да, если один раз записать и положить в шкаф (как делают в банке), то будет надежно. Но если бюджет ограничен и ленту нужно перезаписывать, то ничего хорошего не получится
Коллеги, а вы уверены в том, что привод LTO9 сможет прочитать картридж LTO7? Правило "чтение на 2 поколения назад" перестало действовать с поколения LTO8.
прочитать сможет, а записать - вопрос)
не сможет даже прочитать https://www.lto.org/lto-generation-compatibility/
Надежность под вопросом. Много в интернете случаев когда считать записи не получалось. Но есть вероятность что это ошибки эксплуатации и хранения. Пыль критична для этих устройств и для носителей. И хранить ленты производитель рекомендует не абы как. Для понимания достаточно представить что это просто жесткий диск, только без всей защитной оболочки и без двигателей. Двигатель встроен в привод. (кстати, такие аналоги-конкуренты были у LTO).
Производителей собственно драйвов было вроде два, а сейчас вообще один остался. Поэтому и дорого. Кровавый энтерпрайз.
Низя использовать одну библиотеку для нескольких систем (серверов копирования). Привод считай как DAS устройство.
Подходит только для бэкапов. Фоточки туда складывать для архива не получится - слишком высокое время доступа. Пока пленку нужную найдешь, пока пленка перемотается на нужное место...
Но штука нужная. Иначе сложно обеспечить нормальные архивы бэкапов.
Площадь хранения бита отличается от хдд в миллионы раз. Соответственно также отличаются требования к чистоте и точности позиционирования. Также в тысячи раз отличается надёжность его хранения (перемагничивание, чувствительность головок).
Низя использовать одну библиотеку для нескольких систем (серверов копирования). Привод считай как DAS устройство.
Если нет SAN - то нельзя, но если нет SAN, то это и называется DAS и никак иначе. Если есть SAN, то никаких проблем (ну кроме одновременного доступа к приводу, но это физически невозможно, головка то одна).
В случае с FC я не понял как раздавать одну голову нескольким сервисам. То есть нужно в шедулах разного софта так задать все параметры чтобы точно не пересекалось. И еще как-то хитро распределить пленки между разными софтами. В общем, мои хотелки были явно не заложены архитектурно.
Теоретически это сделать, наверное, можно, но не нужно. Основная польза от использования ленточных устройств с полноценной SAN - это виртуализация. Вирутальная машина с софтом резервного копирования может перемещаться между хостами виртуализации, сохраняя подключение к своей библиотеке. Или на одном хосте может работать активная виртуалка, а на другом - её резервная HA-копия (High Availability).
Не только архивирование. Есть другие области. Например, геофизика.
Поясните зачем всегда указывается объем со сжатием если на сегодня это не имеет смысла?
во первых такие объемы данных чаще всего это видео, а видео не сжимается и при попытке сжать файл часто становится больше размером
базы данных так же часто сжимаются сами при экспорте, а значит опять таки сжатие данных не случиться, а то и станет больше размер.
серьезно, никто не хранит на сегодня терабайты данных в виде RAW TXT который поддаётся сжатию. даже офисные файлы вроде внутри имеют ZIP сжатие. но я бы посмотрел на текстовые данные в терабайт размером. серьёзно - вся мировая литература в терабайт влезет, а видео и фоточки не сжать уже.
и так мой вопрос - может перестанем пи**теть и будем указывать просто объем ДО сжатия?
и еще один вопрос на засыпку - а почему не хранить на жестких дисках? почему все сравнения идут с форматами не используемыми сегодня? вы серьезно считаете что имеет смысл с CD дисками сравнивать и указывать что 100500 CD дисков на одну кассету влезет? ну так давайте лучше с флопариками на 1.44 сравнивать - еще больше выйдет и так же никто уже не помнит этого формата и куда его вставлять. так же как и DVD/BD и всё такое. да я лет 10 уже BD приводов нигде не вижу... ну только в консолях и там уже вымирает потихоньку... я даже вот не сразу вспомнил щас какой размер у этих дисков был чтобы как то посчитать количество...
с учетом цены магнитофона - жесткие диски выигрывают довольно долго пока количество данных не накопится такое которое уже и не надо вообще хранить. никому не нужны бэкапы 15ми летней давности. даже месяц назад часто уже не нужны. а если хранить видео, то... вы серьезно храните видео с камер наблюдения 15 лет??
я понимаю что для большого корабля большая торпеда, но тут то зачем про это тогда писать? или как в анекдоте про доктора: - Лечиться? - Нет, хвастаться! это как рекламу ролсройса в метро вешать, в целом то это реклама - но покупатели RR в метро никогда не входили даже в самые худшие моменты своей жизни...
Вот буквально недавно видел новость, как королева Великобритании спустилась в метро. Открыла новую линию названную в её честь.
И насчет бекапов 15 летней давности вы ошибаетесь. Например тут уже упомянули геофизические данные. Да, методы исследования улучшаются, однако для первичного анализа используют базовые методы, которые не меняются с давних времен. Причем некоторые данные хранятся в простом текстовом виде, с заголовком - описанием LAS формат. Хотя согласен с вами, что лучше все же указывать емкость в чистом виде, без сжатия.
Мне кажется, имеется в виду под сжатием не сжатие информации, а сжатие ячейки для ее хранения в долях метра
Откуда столько злобы?
базы данных так же часто сжимаются сами при экспорте
А часто - не сжимаются. Учитывая то, что сжатие при записи на ленту реализуется на аппаратном уровне и сжималка встроена в привод, часто имеет смысл отключить сжатие на стороне базы, чтобы сэкономить вычислительные ресурсы хоста бд.
никому не нужны бэкапы 15ми летней давности. даже месяц назад часто уже не нужны. а если хранить видео, то... вы серьезно храните видео с камер наблюдения 15 лет??
Вы, видимо, работаете в динамичном стартапе, где старые данные не имеют большого значения. Но в крупном бизнесе вполне может возникнуть потребность получить доступ к старым данным. Например, при расследовании. Или при исследовании.
Есть ещё требования регулятора - некоторые данные надо хранить 75 лет, особенно в финансовых организациях. Больше того, некоторые данные надо по закону хранить именно на отчуждаемых носителях. Используют ленты или оптические диски/оптические кассеты.
Аппаратное сжатие - условно-бесплатное. Да, оно уступает программному. Но зато освобождает время. Пожмите террабайт тех же текстовых файлов. Или дисков виртуальных машин. Которые могут быть заполнены на малую часть обьема. Сколько ваш сервер потратит времени ? Полчаса ? Час ? Вот это время вам сэкономит привод. Лента же лто5 способна писать до 500мб-сек несжатых данных (которые хорошо сжимаются, впрочем. Типа гигабайтов нулей. Видел цифру >500 в ходе ИбМовских тестов. Иначе меньше.), дожимая их до нативных 140мб-сек в ходе записи. А современные ЛТО ещё быстрее.
gzip на соверменных процессорах уже давно работает быстрее, чем скорость записи на механический диск
А вы проверяли ?
Сжимаем файл ~1тб штатным gzip с дефолтными настройками:
cat ./lto-BQF643L5.sqfs | gzip > /dev/nullНаблюдаем за прогрессом. Файл плоский, диск легко выдает 200+мб/сек на его чтении.
Every 2,0s: progress -wq
[373579] cat /mnt/lto_1/_tape/lto-BQF643L5.sqfs
0.3% (2.9 GiB / 1.0 TiB) 33.2 MiB/s remaining 9:04:30Процеесоры Xeon 2697 (Haswell), кеши огромные. Нагрузка на процессоры отсустсвует. Наш единственный тред бустится до 3.8ггц.
Полученные 33 мб-сек - это скорость ЧТЕНИЯ, т.е. на выходе может быть в разы ниже. А чтобы "прокормить" древний LTO5 надо выдавать стабильные 140мб-сек.
Добавим ещё ядер ? Но многоядерный буст будет ниже. Плюс по закону Амдалла линейного масштабирования не будет. Плюс хорошо бы иметь запас... Ядер 10 придётся выделить, если не 16.
Вообще-то есть параллельная версия gzip. На современных процессорах с кучей ядер это особенно актуально
Плюс по закону Амдалла линейного масштабирования не будет
совсем линейного не будет, но очень близко к этому — вполне реально.
можно сжимать блоки независимо, при достаточно большом размере блока сброс словаря между блоками практически не оказывает влияния на степень сжатия.
ну и gzip совсем не рекордсмен по скорости сжатия.
Хех... Бекап 2,5 Тб базы на быстрый жёсткий диск (raid 10, 4 SSD) по 10 ГБит сети со сжатием - 1:09, без сжатия - 3 часа. А вы говорите "потратит"... А ядра - условно-бесплатны, т.к. на сервере БД их 24, и занятие пары из них в ненагруженное время не беспокоит вообще никого.
Бекап 2,5 Тб базы ... по 10 ГБит сети со сжатием - 1:09, без сжатия - 3 часа.
10гбит сеть должна обеспечивать 1гбайт-сек. передачу. Или 3.600 Тб в час. Значит не такой уж быстрый у вас raid 4 SSD... Посчитаем: 2,500,000 / 10,800 = 231 мб-сек. Совсем не быстро вообще-то.
А ядра - условно-бесплатны
У вас уровень сжатия получился 1:2.3. Явно тюнили ради скорости ? Древний LTO-6 обещает сжатие 1:2,5 что сопоставимо с вашим. И электричества сожжёт меньше.
и занятие пары из них в ненагруженное время
С хорошим сжатием парой ядер не отделаться, см. мой тест в предыдущем ответе. А с плохим сжатием даже старый LTO будет выдавать сопоставимый результат. И запишет ваши данные часа за полтора-два уже на кассету. А современный LTO запишет минут за 20. Не нагружая ни процессоры, ни сеть.
согласен с почти всем. кроме:
икому не нужны бэкапы 15ми летней давности
не работали вы коллега на телевидении. там бывает "срочно принеси мне то видео про того чувака, ну всего-то 100500 лет назад снимали". и хочешь не хочешь а добыть надо, если не сохранилось в архиве копай интернет. но надо и срочно.
ну и вспомним историю как коммюнити фанатов одного сериала потратило хрен знает сколько денег на поиски одной серии первого сезона потому что у BBC сгорел архив. и не нашли.. а если бы кто-то сохранил у себя он бы мог им просто продать.
Вот эту мантру про "низкую стоимость на гигабайт" для лент так и не понял ни разу, хотя считал неоднократно, т.к. потребность архивирования нескольких десятков Тб (сейчас около 40) есть. Да, Гб на картридже, может, и дешевле, чем Гб на HDD. Но библиотека с автоподатчиком стóит настолько дороже простенького сервера, который можно набить этими HDD и сделать в нём RAID с hot spare дисками, - что эта разница напрочь съедается. Ну разве если повезёт урвать б/у на Авито по особо выгодной цене от недалёкого админа, который сам не понял, что за вундервафлю он спёр из офиса :)
При этом тот самый сервер с RAID, если в нём вовремя заменять вылетающие диски, вряд ли обеспечит качественно худшую надёжность. Ну и HDD со SMART, да ещё и стоя́щий в RAID, которому регулярно делается scrub, как минимум вовремя просигнализирует о своей неисправности, - в отличие от ленты, на которую что-то записали N лет назад и всё.
Необходимости бекапа ещё и в облако опять же, ни один из вариантов не отменяет, т.к. сгореть / быть украденными / изъятыми хоть ленточный накопитель, хоть сервер имеют шанс.
Так что для моего варианта (личные нужды плюс мелкий бизнес) пока что серверная стойка с тем самым набитым HDD сервером под лестницей дома + облачный бэкап в Backblaze (через свою приватную инсталляцию Seafile) выигрывает у ленты, как ни считай...
Выключите сервер на 5-7 лет, потом включите и удивитесь :)
А кассета с нулевым потреблением отлежит 7 лет улыбнувшись. Даже в банковской ячейке, куда сервер не влезетъ :)
Мантра проста. Предложите на дисках что-то приближающееся по цене к Amazon Glacier и очень неплохо заработаете :)
А зачем его выключать?.. :)
Ну и да, Backblaze B2, который отнюдь не на лентах, дешевле Glacier, если хоть иногда что-то оттуда скачивать (у B2 скачивание 0,01$ / Gb и всё, у Glacier плюс стоимость data transfer и за запросы), и несущественно дороже (0,005$ / Gb против 0,0036-0,00405$ / Gb), если вообще только отправлять туда данные, как в чёрную дыру, и никогда не скачивать их обратно. При этом оно ещё и работает как обычное объектное хранилище (и довольно шустрое), в отличие от. Но в любом случае, экономика публичного сервиса и экономика бизнеса, который использует железо для своих нужд, изрядно отличаются.
Нет, наверняка есть сценарии, когда именно лента выигрывает. Но это какая-то экзотика, IMHO. Типа хранения огромного количества версий бекапов, которые существенно превышают по объёму одиночный бекап. Ну, например, для каких-то регуляторных требований. Тогда ленты действительно можно регулярно вынимать из привода и складировать на полку. Но в основном содержание архива бекапов всё же регулярно обновляется полностью (зачем нам ежемесячные архивы за позапрошлый год?) - т.е. ленты должны постоянно находиться в библиотеке (а такая библиотека дорога) и регулярно перезаписываться (а это снижает срок их службы).
Выключать, чтобы хранить оффсайт. Чтобы по почте отправить, чтобы в сейфе сохранить, много что-бы.
Ну для трех копий вам нужно три сервера, три рейда, три набора дисков, а ленточнику - три ленты. Вот зачем еще выключать. А тут уже другая экономика за один ТБ, ведь так?
Я вот о чём.
Сегодня я сохранил бекап за сегодня. Завтра у меня появляется бекап за завтра, и без него, записанного рядом с бекапом за сегодня (если он инкрементальный) или вместо него (если полный), бекап за сегодня резко теряет свою ценность (ну разве что что-то с дуру удалённое в нём искать, восстановить систему из него уже повлечёт неприемлемую потерю данных).
Чтобы все мои три копии не теряли актуальность - эти три ленты должны не на полке лежать, а крутиться каждая в своём приводе. А когда объём данных больше объёма ленты - то и в библиотеке. А неактуальные копии мне не сильно помогут, хоть их десять будь. Ну и вообще хорошо, когда бекап не раз в день, а в режиме онлайн...
Это, конечно, про мой конкретный кейс - бекапы именно с целью обеспечить возможность восстановления. Если бекап делается для других целей (ну, например, те самые регуляторные требования) - тут да, варианты есть. Но мне как-то казалось, что большинству нужны всё же не шашечки, а ехать :)
Вам звонили в 6 утра со словами приезжай сюда, тут пожар? Мне - да :)
Вас просили сделать так, когда спецслужбы накроют офис - работать нужно продолжить немедленно(1-2часа) с полным набором данных с 12 рабочих станций на консп. квартире? Меня - да :)
Писать на ленты каждый день - согласен - нужна веская причина, но она бывает и у не североамериканских компаний :)
И первый, и второй кейс я как раз по мере сил и решаю :) От пожара пока Бог миловал, но в расчёт такая возможность принимается. А страховка от маски-шоу - так это вообще базовый сценарий, и вот такое как раз бывало не раз. Плюс более актуальные риски того, что от зарубежного облака могут неожиданно отключить, причём как с этой стороны, так и с той... При этом у меня бизнес-то ещё и свой, так что все эти вводные я сам себе и формулирую, сам и реализую.
Только как мне поможет что от пожара, что от маски-шоу лента месячной давности? Типа, а давайте сейчас повторим последний месяц работы заново?.. Нет, ну в случае совсем уж полного апокалипсиса лучше, чем вообще ничего. Но так себе решение.
Вас просили сделать так, когда спецслужбы накроют офис — работать нужно продолжить немедленно(1-2часа) с полным набором данных с 12 рабочих станций на консп. квартире?
сходу вижу проблемы:
- нужно иметь запасной привод, это не так уж и дёшево;
- актуальность данных. да, несложно перевозить ленту в безопасное место раз в сутки, но данные суточной давности уже не так интересны.
ежечасный же вывоз лент — тот ещё геморрой.
Выключать, чтобы хранить оффсайт.
По почте можно отправить другой диск.
Ну для трех копий вам нужно три сервера
Вообще-то три пары дисков. Если же, три сервера нужны для защиты от выхода из строя самого сервера, то и ленточных привода тоже надо три.
А тут уже другая экономика за один ТБ, ведь так?
У ленты сильно ниже число циклов чтения/перезаписи. Это тоже надо учитывать в расчётах.
Кого-то регулятор заставляет сырые данные хранить много лет.
Кто-то сам делает снапшоты ИС регулярно и складывает в архив - чтобы если через месяц выяснится что была какая-то неприятность, а логи давно перезаписались, восстановить снапшот и внимательно его рассмотреть.
Конечно, если данных не очень много (а 20-40 Тб это относительно немного на наши дни) то можно и на дисках, но если в разы больше...
Вот я знаю плотный сервер в который в 2 юнита 46 дисков входит кажется? Это 2700 Тб в шести юнитах + шуметь и греться будет как в аду - а вышеупомянутая HPE MSL 3040 в 6 юнитов вместит в 2 раза больше, 5000 Тб - и будет тихой и холодной.
1440TB сырых данных будет в двух MSL 3040 на 6U занятого места… И им нужен сервер, который эти бэкапы делает.
1440TB сырых данных будет в какой-нибудь SuperStorage 6048R-E1CR90L, набитой 16TB дисками на 4U занятого места. И это уже сам по себе сервер, делающий бэкапы.
Не рассказывайте про сжатые данные, когда говорите про ленты — сервер будет жать данные однозначно не хуже. Большую часть времени он и не будет особо шуметь и греться — ведь это же холодные данные, к которым регулярных обращений новых нет (помимо периодической проверки).
Смысл хранить все пленки в библиотеке? Пленка она на то и пленка чтобы вынимать ее и хранить отдельно (в другом здании, не подключенную никуда). Так что 4U на обычную библиотеку на 2 привода.
Сжатие всё-таки разное бывает. Не в плане степени сжатия. Например SQL может при бэкапе сжимать данные и записывать уже в сжатом виде. Получается это у него хорошо, но есть проблема. Он при этом сжирает свои ресурсы, которые ему не для этих целей давались. Хотя в основном я согласен - сжимать и даже дедупить часто лучше сразу на месте и передавать уже в сжатом виде, полоса пропускания экономится.
А Вы электричество и холод считали? Ленты сильно эффективнее схд по этим показателям.
Ну и тут действительно вопрос в эффекте масштаба. Для домашнего офиса действительно ленты не очень нужны, кроме специфических случаев. Но есть другие случаи и другие масштабы.
Вот эту мантру про "низкую стоимость на гигабайт" для лент так и не понял ни разу, хотя считал неоднократно
Ленты становятся выгодными в районе петабайт по сравнению с хранилками высокого уровня, но вы правы, разница весьма эфемерна, а геморроя добавляется настолько много, что игра обычно не стоит свеч.
В бу варианте, для домашнего использования, в котором остаточного ресурса хватит до конца жизни, и если не "здесь и сейчас", а помониторить Авито неспеша - то граница где-то в районе 50тб. Выше нее холодные бекапы на лентах заметно выгоднее.
ЗЫ: хотя с текущими ценами на винты, когда негелиевый 10тб стоит 50+, а стоил в 2020ом ~23, наверное планка упала где-то до 30тб.
Наработка на отказ одного картриджа – около 250 циклов (полных проходов чтения/записи всей ленты).
Меня еще смутило что наработка на отказ всего 250 циклов чтения. Т.е. это все не более чем юэкапы без возможности перезаписи(при таком ресурсе это совершенно глупо). Получается весь этот огромный объем не сравним с обычным hdd, поскольку идет огромное дублирование информации которую вообще говоря можно подтереть через несколько лет, "проредить" частоту старых слепков.
В общем я тоже не понял в чем смысл если только это не архивные денные.
Так что для моего варианта (личные нужды плюс мелкий бизнес) пока что серверная стойка с тем самым набитым HDD сервером под лестницей дома + облачный бэкап в Backblaze (через свою приватную инсталляцию Seafile) выигрывает у ленты, как ни считай...
вы неправильно ставите вопрос, не «лента против сервера с hdd», а «лента в дополнение к серверу с hdd» (против того же backblaze в вашем варианте).
вот смотрите, пусть у нас сотня терабайт и год.
backblaze будет нам стоить 0.005*100*1000*12=6к$
привод lto-8 и 10 лент на амазоне стоят около 4к$, уже дешевле.
притом с ленты будет читаться со скоростью больше 300 мегабайт в секунду и в случае, если интернета нет вовсе.
Не-не, Backblaze или Glacier или хоть какое удалённое хранилище (по возможности в иностранной юрисдикции) никуда не денутся, хоть я поставь три сервера и пять ленточных накопителей на разных площадках. Потому что если по всем этим локациям пройдется товарищ майор с ордером - только на это удалённое хранилище и надежда.
гхм, а зачем ленты хранить там же, где и приводы?
Ну наверное затем, чтобы на них писать. См. другие мои комментарии в этой ветке - ценность ленты, которая месяц лежала на полке, для меня стремится к нулю, из неё актуальный бекап не восстановишь. Нет, можно, наверное, какую-то редко изменяемую часть данных так хранить, а более динамичную - иначе, но это уже усложнение.
Ну и в целом, где эти ленты ни храни, сценарии, завязанныме на возможность доступа конкретных людей к конкретной физической локации, объединены общими рисками, которыми надо управлять. Тут опять же, у всех ситуация разная, и по рискам, и по возможностям. Для меня всё же настроить бекап в Backblaze/Glacier куда как проще, чем найти новое место для физического хранения чего бы то ни было, озаботиться системой доступа к этому месту и т.п.
ценность ленты, которая месяц лежала на полке, для меня стремится к нулю
какой месяц, зачем вдаваться в крайности? ежедневную ротацию лент обеспечить совсем несложно.
например:
ночью делается бэкап на сервер, утром он копируется на ленту.
днём в него дописываются инкременты.
вечером ответственный уходит сотрудник с работы, забирает записанную ленту, вставляет вместо неё следующую.
Сегодня я сохранил бекап за сегодня. Завтра у меня появляется бекап за завтра, и без него, записанного рядом с бекапом за сегодня (если он инкрементальный)
хм, и в чём тут проблема с лентами? берём ленту с основным бэкапом, ленту (ленты) с инкрементом — готово.
А когда объём данных больше объёма ленты
гхм, у доступных lto-8 объём 12 терабайт. вы правда бэкапите за сутки бо́льшие объёмы на backblaze?
Я о том, что ленты с более старыми бекапами имеют ценность только в комплекте с лентой с актуальным бекапом. Т.е. если я раз в месяц буду уносить ленту на хранение на условную конспиративную квартиру, а последняя лента будет оставаться в приводе - это мне вообще не поможет решить мои задачи. Каждый день таскать ленты куда-то - помилуйте, у меня личные нужды и малый бизнес, откуда у меня столько человекочасов на это? Поэтому если тот самый привод с актуальной лентой сгорит / украдут / изымут / мало ли что - я останусь с неактуальным бекапом. Так что проще уж все ленты и оставлять по месту их записи в библиотеке постоянно, результат тот же, телодвижений меньше.
Я в 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. Утилита диагностики: "Что-то вот у вас не так, не могу завершить тест".
Все, так окончился очередной эксперимент с использованием лент.
В общем, коллеги, которые не имели опыта использования лент, и которым в очередной раз очередной сэйл ленточек морочит голову про "энтерпрайзное решение, выбор банков" - не нужно вам это, потому что говно. Извините за прямоту.
Нипочему. General Read Error
Абсолютно типовая история)
Тут вопрос целевого использования и масштабов. В вашем примере вы покупаете и эксплуатируете "для себя" дома по современным меркам уже устаревшее оборудование, а сопоставляете с банками и энтерпрайзом, где выход из строя одного стриммера вообще не будет считаться проблемой. Я не думаю, что корректно делать так выводы о том, что технология "не очень". Чем больше надо хранить - тем привлекательней становятся ленты, когда цена за сами стриммеры с библиотеками и тех обслуживание уже нивелируется объёмом лент. Тем более, для архива реальных альтернатив нет.
Ну и о вопросе эксплуатации я предполагаю, что нужна высокая стерильность помещения для высокой сохранности стриммеров (как кстати и всего остального оборудования). Там например датацентр, куда пускают в машинный зал строго в бахилах, наличие разделения горячий/холодный коридор и температурного контроля, запрет на пронос картона и прочего. Ну и отдельное хранилище с нужной температурой и влажностью для лент. В реальности к сожалению если денег мало - такого не будет (.
Пытаюсь писать на новые ленты. А они уже не пишутся.
Cleaning tape покупали? Прогнать пробовали? Знаю, вопрос глупый, но... Просто по вашему рассказу создаётся впечатление, что получив подобную ошибку вы со злостью всё оборудование кидаете в мусор с матерным вариантом "да пошли к чёрту эти грёбаные ленты".
Cleaning tape покупали? Прогнать пробовали? Знаю, вопрос глупый, но...
Мне казалось, что я достаточно развернуто показал свой уровень знаний темы, чтобы не отвечать на вопрос "а вы пробовали выключить и включить"? ;)
Что же касается первого абзаца: я не отрицаю, что ленты имеют свою область применения. Видел многое. Речь про то, что их упорно пытаются впарить пользователям для непригодных или неподходящих кейсов и условий, аккуратно, до продажи, умалчивая о многочисленных недостатках, рассказывая только о "феноменальной надежности", "долговечности" и "беспрецедентной емкости и дешевизне хранения".
Сам со стримерами сталкивался редко, но почти всегда с негативным опытом. Из последнего - лет 10 назад одна очень крупная (полугосударственная) контора не смогла восстановить из архива запись звонка на горячую линию - по невыясненным причинам том с той записью отказался читаться, хотя кассеты использовались строго однократно, но это не мой личный опыт - знакомого коллеги. Из личного - только наматывание на внутренности стриммера ленты, да отрывание "поводки", при эксплуатации "в подсобке"... а, ну ещё видел несколько раз выведенные из эксплуатации библиотеки, установленные "в нормальных" серверных - сам их только "на поиграться" запускал, т.к. от предшественников были инструкции о неэффективности данного решения для текущих задач.
Единственный разумный сценарий для использования ленточных накопителей - хранение долгосрочных малоиспользуемых архивов (техдокументация на объекты строительства, упомянутая кем-то выше "геодезия", возможно, сканы каких-то документов). В подавляющем большинстве практических сценариев использование ленточных архивов себя не оправдывает.
Я никакой не сейлз. Первые ленты с приводом купил больше года назад. ЛТО5. Причем БУ (потом и новых лент докупил тоже). Все пишется, все читается. ЧЯДНТ ?
Возможно врете ошибаетесь. Возможно неосознанно.
Знаете как это бывает у фанатов. На каком-нибудь LOR очень заметно. Выступает человек, у которого на линуксе "все работает". Но неловко получается, если кто-то, знающий его, пишет в ответ "Лех, так у тебя и то не работало, и се, и настройки при апгрейде слетали, и три месяца ждали пока на видеокарту блоб перепишут, и networkmanager, помнишь, в том релизе официально не работал с полгода".
Но так-то - да, "все работает". Извечная проблема фан-комьюнити :)
Скорее вы врете. Потому что история про LTO5 вообще никак на реальность не натягивается. Повторю - у меня приводов много. Лент ещё больше. Пишутся они постоянно. И ни один картридж пока не сдох. (Хотя я к этому готов и это не станет для меня катастрофой).
А у вас как-то всё волшебно - первые ленты сразу сдохли. Все. Причём новые. И оставшиеся, новые, тоже дохлыми оказались вдруг. Прям чудеса. А чудес, как известно, на свете не бывает. Возможно увлеклись да. Переборщили с придумыванием ужасов.
И ещё "очень дорого, конский ценник, полгода назад" когда средняя цена бу стримера была 30тр на авито, куча предложений. А если поискать/подождать - то 20 и менее. Короче - "фантазёр".
Это надолго. Ведь ленточные накопители считаются самыми надежными из распространенных накопителей (срок хранения от 15 до 30 лет).
Неправда. Распечатка хранится дольше 30 лет.
Угумс, пол-мегабайта на лист А4. Сурово и долговечно... ;)
И считывающий привод не нужен, главное - информация о кодировании и любое устройство для создания изображений.
А была же такая древняя шутка про загрузочный лист для Windows 95 (полез искать, но уже все, не находится). Причем шутка почти реальная, при необходимости можно было бы пропатчить биос SCSI-сканера, чтобы он как диск, при включении считывал бы область страницы, и заливал ее в бинарном виде в память, куда и отдавать исполнение.
Я бы не сказал что на данный момент записи на стенах пешеры являются распространённым методом хранения информации.
А рачь шла именно про распространённые методы.
Мне к примеру известен реально применяющийся способ хранения информации с помощью керна и металлической пластины. Как раз из-за бешенной надёжности. Данные даже в пожаре не страдают. Но это не распространённый метод хранения.
Для длительного хранения лент (30 лет) - только 1 кратная запись и ЖЕСТКО регламентированы влажность и температура. Я уже забыл сколько гардусов 18 и влажность 50%, но допуски на них были примерно +-1 градус и не более +-5% влажности. Так что покупаем климатконтроль. Да, производитель лент Fuji, утверждает что у него есть устройства для считывания запорченных лент. Но можно ли реально этим сервисом в настоящее время - большой вопрос
Еще энтузиасты архивного хранения на лентах часто плавно обходят тему стандартов и форматов.
Вот смотрите, первый современный интерфейс "бытового" жесткого диска (я специально сейчас оставлю в стороне 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 Media
Нещитово, вы к диску и устройство чтения приложили (Неотъемлемое). А к лентам - нет. Приложите пару стримеров к лентам, и ВНЕЗАПНО окажется что там такой же scsi для общения.
Одно устройство для чтения всех дисков возможно положить на полку, один стример для всех лент — нет. Тем более, что usb адаптер можно и для других целей использовать, а стример для лент — только для архивирования на ленты. Бонусом — его ещё и воткнуть можно хоть в комп, хоть в ноут, хоть в телефон. А с usb-scsi адаптерами всё плохо, судя по гуглу. Т.е. в накладных расходах — стримеры за все эти года, адаптер scsi и комп, куда этот адаптер можно сунуть.
Одно устройство для чтения всех дисков возможно положить на полку,
Ещё раз - у вас к каждому диску (пачке блинов) приложено неотьемлемое устройство чтения. Это плата электроники, двигатель, блок головок, сам корпус. Для каждого хдд оно своё собственное. За него вы платите производителю, каждый раз. (И, кстати, без возможности переиспользования - отказ "устройства чтения" повлечёт потерю всех данных, даже если на блинах с ними всё прекрасно. Я, например, случайно сжёг два харда. Взяв пигтейлы питания от одного модульного БП и воткнув в другой. С механикой всё хорошо, а вот супрессоры спасли только древний 1тб диск, на втором отгорели головки и 3тб "отъехали" в мир иной навечно.). С лентами же отказ устройства чтения не означает потерю данных! Откуда взялось "одно устройство для чтения всех дисков", о чём вы вообще ?
один стример для всех лент — нет
Это ещё почему ? У меня 3 запасных стримера. Четвертый в компе. Если надо подключаю один-два из запасных, и пишу на несколько картриджей одновременно.
Тем более, что usb адаптер можно и для других целей использовать
Откуда вдруг взялся USB адаптер ? Что за цели ?
А с usb-scsi адаптерами всё плохо, судя по гуглу.
А с USB-SAS ?
Т.е. в накладных расходах — стримеры за все эти года, адаптер scsi и комп, куда этот адаптер можно сунуть.
И сколько стримеров нужно ? У меня второй год ленты, и пока ни один стример не сдох. Адаптер FC для PCIe стоит 500 рублей. Ну а комп у меня и так есть, и не один. Не люблю убогие ноуты. Не возражаю чтобы их владельцы немножко пострадали, раз они выбирают "мобильность" (или, по крайней мере, думают так).
Откуда взялся, устройство для чтения всех дисков, что за usb адаптер, сколько стримеров нужно за два года…
Пожалуйста, прочитайте первое сообщение в этой ветке ещё раз. Там указаны и года, и адаптеры.
И да, сжечь можно вообще что угодно, было бы желание. Тот же стример тоже может умереть разнообразными способами, в том числе и убив ленту. Примеры от человека из сервис-центра были где-то выше.
Пожалуйста, прочитайте первое сообщение в этой ветке ещё раз. Там указаны и года, и адаптеры.
Причем тут первое сообщение, если у нас диалог уже совсем про другое - про устройство чтения, которое от хдд не отделить.
И да, сжечь можно вообще что угодно, было бы желание. Тот же стример тоже может умереть разнообразными способами, в том числе и убив ленту.
Может умереть. Может умереть убив ленту. А может и не убив. И уж всяко не убив ВСЕ ленты (а хдд убьёт все данные, т.е. десятки лент сразу. И убьёт надёжно).
а хдд убьёт все данные, т.е. десятки лент сразу. И убьёт надёжно
...или не убьёт - я обращался в как минимум 3 сервиса (два из которых в Москве), способных восстановить данные после выхода из строя электроники, и с ненулевой вероятностью - при повреждении механики... а уж "пересадку головок" чуть не любой "подвальный сервис" умеет производить.
У меня 3 запасных стримера. Четвертый в компе. Если надо подключаю один-два из запасных, и пишу на несколько картриджей одновременно.
Щитово-щитово. Диски SATA появились примерно с середины 2000-х, где-то с 2005, допустим.
И для того, чтобы их прочитать, мне не нужно никаких интерфейсов или отдельных устройств, потому что SATA есть всюду.
Сколько бы мне пришлось держать (причем еще и время от времени убеждаясь в их работоспособности) "интерфейсов" для чтения лент?
Только LTO сменилось СЕМЬ поколений, а были всякие DLT, SDLT, DDS, IBM 3890, Storagetek, AIT, VXA (это вот все я так или иначе вживую видел в России).
Для дисков ДО 2005 и эпохи SATA нужен тоже ровно ОДИН интерфейс, причем найти его сравнительно элементарно. А вот насколько элементарно будет найти како-нибудь драйв для QIC80 или IOmega Ditto?
Только LTO сменилось СЕМЬ поколений
Девять уже. И все эти LTO это старый добрый SCSI. Который завёрнут в два физ.интерфейса, используемых во всех 9ти поколениях - SAS и FC.
а были всякие DLT, SDLT, DDS, IBM 3890, Storagetek, AIT, VXA (это вот все я так или иначе вживую видел в России).
В которых также старый добрый SCSI. И наверняка физических интерфейсов было тоже немного, если не единственный.
Для дисков ДО 2005 и эпохи SATA нужен тоже ровно ОДИН интерфейс
Уже нет. Твердотельные диски внесли свою лепту. Есть SATA. Есть NVMe. Есть SATA но в M.2 формате.
Вы совершенно напрасно глупо упорствуете в своем видении. Это вас вообще не красит.
SCSI (кторых тоже было примерно 4 или 5) он "старый добрый" только в том случае, если у вас к картриджу есть еще и устройство чтения. Для HDD мне не нужно устройство чтения, оно всегда уже находится внутри диска. А для картриджа с лентой мне еще где-то надо найти это устройство. И вот тогда уже "SCSI".
Давайте, найдите мне драйв на SDLT сейчас.
Для HDD мне не нужно устройство чтения, оно всегда уже находится внутри диска.
Не понимаю, почему вы считаете это плюсом. Производители делают так от безысходности. Первые диски вполне имели раздельными устройство чтения и пластины с данными. В современных же, даже просто плату электроники не поменять, без переноса адаптаций.
А для картриджа с лентой мне еще где-то надо найти это устройство.
Зато для картриджа оно может быть одно, на весь парк картриджей соотв. поколения. С вытекающими отсюда достоинствами.
Давайте, найдите мне драйв на SDLT сейчас.
Их полно на ebay.
Но как вы не поймёте, устройства имеют естественное устаревание. Даже LTO-4 не выглядят особо интересными сегодня. А всё более древнее тем более, включая хдд. Данные с этих динозавров давно перенесены. А если даже ВДРУГ нет - ebay в помощь.
Вы, кстати, тоже просто так не подключите IDE диск к современному PC. К ноуту вообще ничего не подключите, кроме USB. Нужны будут переходники. Да, их сейчас много и они дешёвые, ибо массовые. Но суть это не меняет.
Следующий уровень это SAS HDD. Ещё труднее будет подключить старый SCSI HDD (хотя устройство чтения внутри, всё как вам нравится).
Интересно будет посмотреть на попытку поработать с MFM HDD, ровесником вашего DLT. И как "встроенное устройство чтения" вам поможет.
Интересно будет посмотреть на попытку поработать с MFM HDD, ровесником вашего DLT. И как "встроенное устройство чтения" вам поможет.
Вы про двухшлейфовые 5" накопители сейчас? Которые ST-506/ST-412? Их и 30 лет назад встретить было большой редкостью (мне как раз в 92-м удалось заполучить в свою коллекцию такой экземпляр, напару с 8" дисководом), а DLT в эти годы только "родился"...
Del (промахнулся)
Устройство не устанавливается в стойку и существует только настольном варианте.
Не только. У HP есть стоечный корпус, куда можно воткнуть два привода половинной высоты:
/https://buy.hpe.com/emea_europe/en/storage/tape-storage/tape-rack-mount-kits/tape-enclosures-arrays/hpe-storeever-1u-generic-rack-mount-kit/p/bc029a
Это именно просто корпус, не автозагрузчик. У IBM, кажется, тоже такое было.
Так как приводы могут быть разных стандартов LTO и с разным типом подключения (FC или SAS), устройство продаётся без привода. Привод нужно покупать отдельно.
Не обязательно, зависит от комплектации. Один и тот же автозагрузчик или библиотека может идти как в виде одного шасси, без приводов, так и с разными вариантами установленных приводов. Я лет двенадцать назад однажды купил популярную библиотеку HP MSL2024 в варианте с двумя старыми приводами LTO2 - она стоила дешевле, чем просто новое шасси без приводов.
Типовые схемы подключения
Говоря о схемах подключения, стоит упомянуть, что современные приводы бывают двухпортовыми (по крайней мере, SAS). Это довольно удобно для небольших систем без полноценной SAN - можно к одной библиотеке подключить два сервера без SAN-коммутатора.
Говоря о схемах подключения, стоит упомянуть, что современные приводы бывают двухпортовыми (по крайней мере, SAS). Это довольно удобно для небольших систем без полноценной SAN - можно к одной библиотеке подключить два сервера без SAN-коммутатора.
если ПО и позволяет писать одновременно на несколько драйвов библиотеки, то роботом управлять может только одно устройство. такую схему надо продумывать, чтобы не было конфликтов. и скорее всего SAN коммутаторы уже будут и не очень понятно зачем отказываться от их использования в данном случае.
Поправьте, про совместимость.
Начиная с LTO-8 совместимость назад только на одно поколение.
LTO-8 не прочитает LTO-6
LTO-9 не прочитает LTO-7.
в двух последних вариантах корректнее называть не FC коммутаторы, а FC фабрики.
у IBM есть софт который позволяет представлять библиотеку пользователям как сетевой диск. при этом он мониторит работу с данными и переносит на ленту холодные данные автоматически. это ПО кстати можно бесплатно скачать.
Спасибо за интересную статью, подскажите, почему в документации по магнитным лентам никогда не упоминается такой фундаментальный показатель, как IOPS (в отличие от пропускной способности, throughput)?
Ведь Throughput = IOPS * BlockSize, следовательно, раз уж в стандартах LTO пропускная способность постулируется, значит, известны и IOPS, и BlockSize.
Кстати, что является элементарной единицей хранения данных для магнитной ленты (аналог сектора HDD и блока страниц NAND)?
Да, этот пример понятен, но, если не ошибаюсь, это пример как раз random IO (прочитали по одному смещению, потом читаем совсем по другому, и поэтому долго мотаем ленту). В последовательном IO (как минимум при записи благодаря serpentine recording) должно быть всё хорошо с IOPS, иначе откуда такой throughput?
Или последовательное чтение ленты от начала и до конца также приведёт к паузам в IO вплоть до нескольких минут?
а что такое iops для последовательного чтения? всё чтение ленты (без перемотки) можно считать одной операцией
Я подозреваю (но совсем не уверен), что в ленточных накопителях чтение идёт блоками, как и в HDD. Следовательно, за 1 IO-операцию можно либо записать, либо прочитать один физический блок. Если работаем с лентой последовательно, такие блоки вычитываются очень часто, и IOPS должен быть высокий (но какой? никто не пишет). Если работаем с лентой в режиме, описанном выше, то получаем IOPS сильно меньше 1. Есть ли ошибки в моём рассуждении?
Для ленты показатель IOPS не имеет смысла, поскольку произвольный доступ там практически не используется. Поэтому никто его и не рассчитывает.
Ну скажут вам, что для LTO-9 этот показатель равен 0,002, и?
PS: Максимальный размер блока на ленте менялся с ходом времени, от 491520 байт в LTO-1/2, 1616940 байт в LTO-3/4, и до 8388608 байт в последних версиях. Причем в последних версиях упоминается про возможность задания нужного размера блока в диапазоне от 1 байта до максимума. А для пользователя оговаривается только минимальный рекомендуемый transfer size - 256 КБ.
Я подозреваю (но совсем не уверен), что в ленточных накопителях чтение идёт блоками, как и в HDD
само понятие iops имеет смысл когда производительность ограничена именно временем выполнения операции доступа (случайный доступ: перемотка ленты для lto; перемещение головок, ожидание прохождения нужного сектора под головкой для hdd).
а когда подобных действий не требуется (ну или почти не требуется в случае hdd — там после чтения одной дорожки нужно перемещение на следующую, но hdd оптимизированы для этой операции и она занимает совсем небольшое время), производительность ограничена линейной скоростью (плотностью записи + скоростью протяжки ленты, скоростью вращения блинов hdd)
Ленточка это в первую очередь "отчуждаемый" носитель информации, и потом уже все остальное.
Наработка на отказ одного картриджа – около 250 циклов
Очень мало. Я думаю прорыв ленточных накопителей случится только тогда, когда они реализуют бесконтактные чтение/запись (как у HDD) - когда готовки будут работать на несколько микрон над лентой. И/или реализуют технологию лазерной записи/чтения на ленту (как DVD) - просто использовать поверхность ленты как поверхность лазерного диска - бесконтактно тоже.
В идеале вообще конечно бабины ленты любой длинны как в старых магнитофонах - без всяких картриджей. Пошел купил ленты километров 10, намотал на бабину(ы) - так лампово.
Кстати, что у нас с фотопленочным долгосрочным хранением? 15 лет назад были же какие то эксперименты. На один кадр 35 мм пленки умещали от 100 до 300 Мб информации. То есть плотность хранения информации приближалась как у DVD уже тогда, а надежность хранения на порядок выше, хоть и не перезаписываемое.
===================
Вообще за 10 лет самым надежным способом хранения оказалось распределенное хранение. Сначала хотели пользовать распределенную файловую систему, но решили сначала в ручном режиме.
Организация с примерно 300 офисных компьютеров разнесенных территориально по нескольким независимым офисам. Все офисы соединены VPN - 150-200 Mбите/сек. На каждом офисном ПК специально есть от 500- до 1000 Гб свободного места - потому что мы его специально заложили под задачи резервного копирования, но пока (уже 10 лет) делаем это вручную. То есть у нас есть примерно 20-25 Тб архив (который по чуть чуть еще растет), и мы вручную раскидываем его тома на свободное место офисных компов (сейчас с репликацией 8-10 копий). 10 лет назад, когда архив был поменьше - то репликацию доводили и до 20-30 копий. В принципе нас устраивает и ручное управление копиями, и как показала практика этот способ в целом оказался очень надежным даже на длинном промежутке времени. Если на каком то офисном диск и ломался, то меняли и закидывали на него снова как было до поломки. За 10 лет не было ни разу, чтобы выходили из строя более 1 диска одновременно (из почти 300). Сейчас если иногда и выходят из строя (в среднем 2 диска в год), то уже меняем на 2-3Тб. Сами диски в офисных компах никак не мешают работающим на этих компах. многие диски вообще программно отключаем когда не нужны. То есть из всех вариантов (ленты, блю рей, NAS, сервера с RAID) мы выбрали просто покупать в компы сотрудников HDD либо большего размера чем им требуется, либо вовсе дополнительный HDD помимо SSD который у них стоит. попробовали для пробы, чтобы не организовывать серверную, и вот уже 10 лет всё успешно пробуем. При этом диски покупаем самый обыкновенные офисные (потребительские) и никогда не следим там за SMART просто ждем когда сдохнет и меняем на новый. Но вообще хоть все и хорошо, постоянно крутится мысль как то автоматизировать этот процесс, чтобы какая то утилита сама смотрела на каком компе сколько свободного места, распределяла нагрузку равномерно и всегда держала максимум копий в зависимости от имеющегося объема свободного пространства и объема архива (то есть все свободное место использовала под завязку для копий).
Ленточные накопители: фантастические твари мира архивирования