Любое облачное хранилище - это где-то "там" и нет никаких долговременных гарантий на его доступность, политику и ценообразование. Прецеденты когда тот или иной сервис банкротится, перекупается, меняет ценовую политику (например резко поднимет цены или ограничивает объемы и сроки хранения), блокирует аккаунты, теряет данные и т.п. были есть и будут. Т.е. шанс внезапно потерять доступ к этой копии вовсе не нулевой и это может произойти внезапно. Поэтому иметь домашний сервер на который идут регулярные бэкапы личных устройств (смартфоны, ноутбуки, и .п.) вполне оправдано. В случае проблемы с самим устройством - восстановление с локального бекапа это быстрая и "бесплатная" операция. А уже с локального сервера можно делать дополнительные копии критичных данных в облачное хранилище.
Локальная копия данных (на домашнем сервере) - это "первичный" бэкап с высокой скоростью/доступностью. Облачная копия данных - это "вторичный" бэкап с потенциально более долгим сроком хранения и потенциально большей надежностью (тут сильно зависит от конкретного облака и предоставляемых гарантий надежности/сохранности).
На этом же домашнем сервере могут жить дополнительные "некритичные" но удобные сервисы. На домашнем сервере обычно хранится локальная коллекция любимой музыки и фильмов/сериалов, которая скорее всего никуда не бэкапится так как при полной потере можно постепенно восстановить, но вот RAID для этого очень даже полезен. Да, современные стриминговые сервисы делают такую коллекцию менее востребованной, но не всё и не всегда есть на имеющемся стриминговом сервисе(ах) да еще и в нужном качестве с любимым переводом или с правильными субтитрами. Ну и контент в высоком качестве надежнее транслировать с локального сервера по Ethernet-кабелю чем из внешнего сервиса по общему и, как правило, негарантированному интернет-каналу.
Вроде бы в РЖД и Yadro ЕС14 (aka IBM z14) успели поставить до известных событий.
По поводу новой версии "АСУ Экспресс" - будем надеяться что новая система будет справляться с потоком запросов как минимум не хуже чем существующая. Жаль в статья нет никаких подробностей что там под капотом в этой новой версии.
iMazing - на самом деле отличная утилита, несколько раз очень выручала в "нестандартных" ситуациях.
Новая политика лицензирования по моему требует дополнительных пояснений от компании. Насколько я понял, лицензия теперь по количеству устройств (слотов) и активация "слота" привязана к конкретному устройству "пожизненно" без возможности переноса. При этом привязка "слота" к устройству происходит только при использовании определенных "фич" программы. Т.е. многие базовые операции (тот же бекап/восстановление) вроде бы можно выполнять без привязки слота лицензии к устройству.
К сожалению очень удобная функция автоматического бекапа по расписанию напрочь "убита" одним из апдейтов безопасности для iOS, который требует ввода пин-кода каждый раз для запуска бекапа. Удобное время для бекапа - ночь, когда все спят а гаджеты на зарядке. Но кто же ночью будет вводить пин-код?
А АКБ жив? Если АКБ прошивкой/системой помечен как проблемный/неисправный - система будет достаточно жестко ограничивать производительность процессора даже когда питание от сети подключено. Проще и надежнее в этом случае заменить АКБ.
А это особенность организации "классической" части операционной системы z/OS (предки: MVS и OS/390). Там действительно нет иерархической файловой системы в том виде как она есть для Windows/Unix/Linux.
Есть таблица оглавления диска "VTOC" и именованные "наборы данных". Имена наборов данных "одномерные" с максимальной длиной в 44 символа. По сути "набор данных" это аналог файла, но, в отличие от файла он имеет набор дополнительных параметров определяющих его свойства и назначение. От этих свойств зависит способ работы с этим набором даных.
Кроме этого на уровне операционной системы есть структура каталогов которая объединяет оглавления разных дисков в единое представление.
Поэтому "иерархической файловой системы" там действительно нет, но при этом информация на диске структурирована, правильнее будет сказать что "плоская" файловая система там есть.
Кроме "классической" части в z/OS есть еще и "Unix" часть, вот там уже есть вполне привычная иерархическая файловая система, Unix-way.
Насколько я помню у IBM было собственное руководство по разработке таких интерфейсов и там было и про цвета и их комбинации, и про взаимное расположение элементов, и про количество элементов на экране и про именование команд и сокращений и про допустимое количество «шагов» (переходов) между пунктами и многое другое. Полезное руководство было.
Кстати до сих пор в IBM z/OS многие действия быстрее и «короче» выполнить в терминале 3270 чем через аналогичное браузерное приложение.
Недавно случайно выяснили что Apple Maps лучше «знают» про местные автобусные и трамвайные маршруты (Германия, Маннхейм). Там где гуглокарты предлагали только пешком или на такси - карты Apple подсказали актуальные маршруты общественного транспорта.
Озвучьте пожалуйста "критично значительные" минусы лент и ленточных накопителей.
Сразу напоминаю что лента (ленточный картридж) это сменный накопитель предназначенный для последовательного чтения или записи больших объемов данных. Не предназначена для быстрого произвольного доступа.
Основное назначение - долговременное хранение данных. Насколько я помню: в оптимальных условиях до 30 лет, в реале 10-20 лет. Более точно нужно смотреть спецификации на конкретные стандарты и поколения.
Современный HDD является технически сложным устройством и не факт что он сможет гарантированно пролежать на полке без единого включения 10-20 лет и остаться исправным.
Получается что на ленте с определенного объема хранить данные будет просто дешевле, даже при том что устройство чтения LTO-9 обойдётся в ~6000$. Если не ошибся в расчетах, то уже (50 лент + привод) будут равны по стоимости 50 HDD на 18 ТБ. (120$*50+6000$ = 240$*50).
Если эксплуатируют и не собираются отказываются - значит все устраивает. Почему бы и не похвалить тогда?
Я хвалю ленты и ленточные библиотеки. Свой класс задач они решают, проблем (с точки зрения настройки/эксплуатации) особо не доставляют. Да, как любое другое оборудование - оно тоже иногда выходит из строя, но это решается гарантией или резервированием.
PS: Пару раз участвовал в процессе миграции данных между физически удаленными площадками когда допустимое время на "простой" было весьма ограничено, возможности настроить репликацию данных не было, а копирование данных по интернет-каналу не умещалось в выделенный промежуток времени. При этом на обоих площадках были ленточные приводы и задача решалась выгрузкой данных на ленты, физической доставкой лент на другую площадку (в одном из случаев это был самолет) и дальнейшей загрузкой данных с лент. После миграции эти же ленты стали частью ленточной библиотеки для регулярного использования. Да можно было бы сделать подобное и на обычных HDD, но их еще нужно было где-то приобрести к моменту миграции, а ленты уже были в наличии и они из библиотеки изымаются/вставляются штатно.
Мой ответ был на комментарий что ленты хвалят те кто их "не пробовал". Так вот это не так. Есть те кто эксплуатирует и отказываться не собирается.
Компания, где работаю, ежегодно пересматривает и оценивает эксплуатационные расходы. Если будет приемлемая альтернатива лентам - от них откажутся. Я работаю в команде которая отвечает, в том числе, и за реализацию политик хранения, миграции и восстановления данных. Мы регулярно оцениваем альтернативы на предмет снижения эксплуатационных расходов.
Ленты и ленточные библиотеки вполне себе конкурентны с другими технологиями для конкретных сценариев. Но да, можно и без лент обойтись и построить систему резервного копирования на других технологиях. Зависит от ситуации, потребностей и возможностей.
Это зависит от конкретного бизнеса, юридических/законодательных обязательств по сохранности и срокам хранения данных, объёмов хранимых и обрабатываемых данных и многого другого.
У компании где работаю сейчас (Германия, основной офис - США) - две площадки. На каждой площадке есть СХД, виртуальная ленточная библиотека и физическая ленточная библиотека. Между площадками настроена репликация отдельно для СХД и отдельно для виртуальных лент. Далее каждая виртуальная ленточная библиотека независимо "экспортирует" виртуальные ленты на физические ленты. Все оборудование на гарантии и на поддержке. Компания коммерческая, расходы считает достаточно четко. Текущая конфигурация по соотношению расходов и рисков всех устраивает.
По хорошему устройств любого типа (речь не только про чтение/запись лент, но например и про маршрутизатор) нужно иметь как минимум два чтобы обеспечить хоть минимальную защиту от неожиданного выхода из строя. Это "мышку" можно купить быстро и то желательно иметь запас у себя на складе чтобы быстро заменить. А тут - часть системы резервного копирования. Если устройство чтения лент всего одно - значит есть шанс на неопределенное время остаться без доступа ко всем архивам пока не будет найдена, куплена и доставлена замена.
Следом вопрос к организации эксплуатации - вовремя заменять устройства на более новые по заданным критериям (срок работы, снятие с поддержки вендором, окончание срока гарантии и т.п.). То же относится и к лентам - периодически заменять и следить чтобы используемый тип лент был совместим с текущим (а желательно и следующим) поколением устройств для чтения.
Одиночная лента которую нужно ручками доставать из спец. хранилища и руками вставлять в считыватель - это конечно "дико холодные" данные.
Автоматическое ленточное хранилище это уже "гораздо теплее". Основная задержка там - это роботу "взять ленту из лотка и доставить в считыватель" + "перемотать до нужного места" и далее уже последовательное чтение или запись данных с достаточно высокой скоростью. Для архивов, резервных копий, архивных логов СУБД и других файлов которые нужно читать или писать только целиком и последовательно - отлично подходит. ПО управления ленточной библиотекой помогает управлять "жизненным циклом" данных на лентах.
Там где нужно минимизировать задержки на обращение к физическим лентам - перед физическими лентами ставят "виртуальную ленточную библиотеку" которая по интерфейсу - лента, но фактически внутри нее диски SSD или HDD, и она служит кэшем/буфером к физической ленте.
Те организации кто пишут/читают большие объемы лент - обычно не вставляют картриджи с лентой вручную. Там используются полностью автоматические хранилища, внутри которых полки с лентами и несколько "роботов" и приводов для работы с этими лентами. С жесткими дисками подобную автоматику сделать конечно можно. Но, насколько я помню, жесткие диски не любят частых включений/выключений и физических перемещений. Поэтому для жестких дисков это "вырождается" в обычные дисковые полки или массивы где диски включены постоянно, тратят свой физический ресурс, потребляют электричество и греют воздух.
Конечно, условия хранения должны быть соблюдены и это справедливо для любого носителя данных.
Для бумаги/пергамента тоже нужны определенные условия хранения, просто "диапазон" другой. Бумага тоже боится огня и влажности, ее могут "погрызть", используемые компоненты для печати могут выцвести, и т.п.
У ленты гораздо более высокая плотность хранения по сравнению с бумагой и при записи используются технологии для возможности восстановления данных: избыточность, специальное кодирование и т.д. Ну и для тех кому это действительно нужно, могут использовать несколько разных типов носителей, в расчете что что-то да сохранится.
Согласно спецификации IBM на картриджи 3592, они должны хранить данные порядка 30 лет. В самом документе, в разных местах написано "более 30 лет" и "до 30 лет". Сами картриджи разных моделей вышли уже после 2000г., поэтому эти данные приведены по тестам "ускоренного старения", так как даже самые старые картриджи из этой линейки "доживут" до указанного значения через 12 лет (2033 г.).
Насколько я помню, финансовые организации, в соответствии с законодательством стран, где они работают, обязаны хранить исторические данные очень много (десятки) лет. При этом, по правилам, нужно хранить несколько копий, географически удаленно друг на друга. Т.е. "потерять" эти данные финансовая организация не имеет права ни в коем случае.
Уж не знаю как сейчас насчет "физической бумаги", хотя ранее видел как печатают и хранят ежедневную бумажную отчетность по определенным операциям.
Практики, когда важные данные выгружаются на ленту (несколько копий) и развозятся по разным изолированным складам/хранилищам точно существуют и по сей день. Хранить магнитную ленту все таки проще и дешевле чем, например, жесткие диски сравнимого объема.
Нет конечно. :) В качестве "первичного носителя" магнитная лента не используется очень давно (точно более 20 лет). Используются внешние СХД, сейчас все чаще "Full Flash".
При этом, магнитная лента вполне себе используется и сейчас как второй/третий уровень для хранения резервных копий и миграции "холодных" данных. Емкость современных магнитных картриджей очень неплоха, 20ТБ сырой емкости на картридж размером 25ммx110ммx125мм.
Любое облачное хранилище - это где-то "там" и нет никаких долговременных гарантий на его доступность, политику и ценообразование. Прецеденты когда тот или иной сервис банкротится, перекупается, меняет ценовую политику (например резко поднимет цены или ограничивает объемы и сроки хранения), блокирует аккаунты, теряет данные и т.п. были есть и будут. Т.е. шанс внезапно потерять доступ к этой копии вовсе не нулевой и это может произойти внезапно.
Поэтому иметь домашний сервер на который идут регулярные бэкапы личных устройств (смартфоны, ноутбуки, и .п.) вполне оправдано. В случае проблемы с самим устройством - восстановление с локального бекапа это быстрая и "бесплатная" операция. А уже с локального сервера можно делать дополнительные копии критичных данных в облачное хранилище.
Локальная копия данных (на домашнем сервере) - это "первичный" бэкап с высокой скоростью/доступностью. Облачная копия данных - это "вторичный" бэкап с потенциально более долгим сроком хранения и потенциально большей надежностью (тут сильно зависит от конкретного облака и предоставляемых гарантий надежности/сохранности).
На этом же домашнем сервере могут жить дополнительные "некритичные" но удобные сервисы. На домашнем сервере обычно хранится локальная коллекция любимой музыки и фильмов/сериалов, которая скорее всего никуда не бэкапится так как при полной потере можно постепенно восстановить, но вот RAID для этого очень даже полезен. Да, современные стриминговые сервисы делают такую коллекцию менее востребованной, но не всё и не всегда есть на имеющемся стриминговом сервисе(ах) да еще и в нужном качестве с любимым переводом или с правильными субтитрами. Ну и контент в высоком качестве надежнее транслировать с локального сервера по Ethernet-кабелю чем из внешнего сервиса по общему и, как правило, негарантированному интернет-каналу.
Если память не изменяет это уже были "имортозамещенные" Yadro EC13, понятное дело что по факту это "OEM-версия" IBM z13. https://st.yadro.com/docs/EC/YADRO_EC13_DS_2017_08_RUS.pdf
Вроде бы в РЖД и Yadro ЕС14 (aka IBM z14) успели поставить до известных событий.
По поводу новой версии "АСУ Экспресс" - будем надеяться что новая система будет справляться с потоком запросов как минимум не хуже чем существующая. Жаль в статья нет никаких подробностей что там под капотом в этой новой версии.
Ну скорее его потомки которые в наши дни называются "IBM Z", с актуальной моделью z16 :)
iMazing - на самом деле отличная утилита, несколько раз очень выручала в "нестандартных" ситуациях.
Новая политика лицензирования по моему требует дополнительных пояснений от компании. Насколько я понял, лицензия теперь по количеству устройств (слотов) и активация "слота" привязана к конкретному устройству "пожизненно" без возможности переноса. При этом привязка "слота" к устройству происходит только при использовании определенных "фич" программы. Т.е. многие базовые операции (тот же бекап/восстановление) вроде бы можно выполнять без привязки слота лицензии к устройству.
К сожалению очень удобная функция автоматического бекапа по расписанию напрочь "убита" одним из апдейтов безопасности для iOS, который требует ввода пин-кода каждый раз для запуска бекапа. Удобное время для бекапа - ночь, когда все спят а гаджеты на зарядке. Но кто же ночью будет вводить пин-код?
А АКБ жив? Если АКБ прошивкой/системой помечен как проблемный/неисправный - система будет достаточно жестко ограничивать производительность процессора даже когда питание от сети подключено. Проще и надежнее в этом случае заменить АКБ.
Есть еще вариант "пошаманить" с настройками CPU чтобы заблокировать получение процессором сигнала "BD_PROCHOT". Сам такое не пробовал.
Найдено здесь: https://hackaday.com/2023/02/17/hack-lets-intel-macbook-run-without-a-battery/
А это особенность организации "классической" части операционной системы z/OS (предки: MVS и OS/390).
Там действительно нет иерархической файловой системы в том виде как она есть для Windows/Unix/Linux.
Есть таблица оглавления диска "VTOC" и именованные "наборы данных". Имена наборов данных "одномерные" с максимальной длиной в 44 символа. По сути "набор данных" это аналог файла, но, в отличие от файла он имеет набор дополнительных параметров определяющих его свойства и назначение. От этих свойств зависит способ работы с этим набором даных.
Кроме этого на уровне операционной системы есть структура каталогов которая объединяет оглавления разных дисков в единое представление.
Поэтому "иерархической файловой системы" там действительно нет, но при этом информация на диске структурирована, правильнее будет сказать что "плоская" файловая система там есть.
Кроме "классической" части в z/OS есть еще и "Unix" часть, вот там уже есть вполне привычная иерархическая файловая система, Unix-way.
IBM Omegamon ?
Насколько я помню у IBM было собственное руководство по разработке таких интерфейсов и там было и про цвета и их комбинации, и про взаимное расположение элементов, и про количество элементов на экране и про именование команд и сокращений и про допустимое количество «шагов» (переходов) между пунктами и многое другое. Полезное руководство было.
Кстати до сих пор в IBM z/OS многие действия быстрее и «короче» выполнить в терминале 3270 чем через аналогичное браузерное приложение.
Недавно случайно выяснили что Apple Maps лучше «знают» про местные автобусные и трамвайные маршруты (Германия, Маннхейм). Там где гуглокарты предлагали только пешком или на такси - карты Apple подсказали актуальные маршруты общественного транспорта.
Озвучьте пожалуйста "критично значительные" минусы лент и ленточных накопителей.
Сразу напоминаю что лента (ленточный картридж) это сменный накопитель предназначенный для последовательного чтения или записи больших объемов данных. Не предназначена для быстрого произвольного доступа.
Основное назначение - долговременное хранение данных. Насколько я помню: в оптимальных условиях до 30 лет, в реале 10-20 лет. Более точно нужно смотреть спецификации на конкретные стандарты и поколения.
Современный HDD является технически сложным устройством и не факт что он сможет гарантированно пролежать на полке без единого включения 10-20 лет и остаться исправным.
Другие параметры LTO-9 на примере FUJIFILM: https://asset.fujifilm.com/www/us/files/2021-09/00cf66b46b9ddfd4c3f35d8f93230c7d/FB_LTO9_SellSheet_V1.pdf
Размер картриджа: ~ 110x110x22(мм).
Вес картриджа: 250-300 грамм.
Стоимость: примерно 120$ (смотрел в Амазоне).
Картридж: https://www.amazon.de/-/en/LTO9-18TB-45TB-Ultrium-BaFe/dp/B09L4TLR6D/ref=sr_1_3?crid=1F0KCM0EGJA08&keywords=LTO9+tape&qid=1693503979&sprefix=lto9+tape%2Caps%2C186&sr=8-3
Привод для чтения картриджей: https://www.amazon.de/-/en/StoreEver-LTO-9-Ultrium-45000-Internal/dp/B0B45D5PGL/ref=sr_1_12?crid=1RHDNMJWV06NW&keywords=LTO9+drive&qid=1693503422&sprefix=lto9+drive%2Caps%2C155&sr=8-12
HDD аналогичной емкости (18ТБ) будет немного больше по физическим размерам, тяжелее в 2-3 раза и дороже примерно в два раза.
https://www.amazon.de/-/en/Toshiba-18TB-Enterprise-Internal-Drive/dp/B093Z5LFWD/ref=sr_1_4?crid=27QDCEXOA78CG&keywords=HDD%2B18TB&qid=1693504033&sprefix=hdd%2B18tb%2Caps%2C138&sr=8-4&th=1
Получается что на ленте с определенного объема хранить данные будет просто дешевле, даже при том что устройство чтения LTO-9 обойдётся в ~6000$. Если не ошибся в расчетах, то уже (50 лент + привод) будут равны по стоимости 50 HDD на 18 ТБ. (120$*50+6000$ = 240$*50).
Если эксплуатируют и не собираются отказываются - значит все устраивает. Почему бы и не похвалить тогда?
Я хвалю ленты и ленточные библиотеки. Свой класс задач они решают, проблем (с точки зрения настройки/эксплуатации) особо не доставляют. Да, как любое другое оборудование - оно тоже иногда выходит из строя, но это решается гарантией или резервированием.
PS: Пару раз участвовал в процессе миграции данных между физически удаленными площадками когда допустимое время на "простой" было весьма ограничено, возможности настроить репликацию данных не было, а копирование данных по интернет-каналу не умещалось в выделенный промежуток времени.
При этом на обоих площадках были ленточные приводы и задача решалась выгрузкой данных на ленты, физической доставкой лент на другую площадку (в одном из случаев это был самолет) и дальнейшей загрузкой данных с лент. После миграции эти же ленты стали частью ленточной библиотеки для регулярного использования.
Да можно было бы сделать подобное и на обычных HDD, но их еще нужно было где-то приобрести к моменту миграции, а ленты уже были в наличии и они из библиотеки изымаются/вставляются штатно.
Согласен.
Если одной ленты хватает на неделю - тогда можно и руками поменять. Но это относительно небольшие объемы данных.
Мой ответ был на комментарий что ленты хвалят те кто их "не пробовал". Так вот это не так. Есть те кто эксплуатирует и отказываться не собирается.
Компания, где работаю, ежегодно пересматривает и оценивает эксплуатационные расходы. Если будет приемлемая альтернатива лентам - от них откажутся. Я работаю в команде которая отвечает, в том числе, и за реализацию политик хранения, миграции и восстановления данных. Мы регулярно оцениваем альтернативы на предмет снижения эксплуатационных расходов.
Ленты и ленточные библиотеки вполне себе конкурентны с другими технологиями для конкретных сценариев. Но да, можно и без лент обойтись и построить систему резервного копирования на других технологиях. Зависит от ситуации, потребностей и возможностей.
Это зависит от конкретного бизнеса, юридических/законодательных обязательств по сохранности и срокам хранения данных, объёмов хранимых и обрабатываемых данных и многого другого.
У компании где работаю сейчас (Германия, основной офис - США) - две площадки. На каждой площадке есть СХД, виртуальная ленточная библиотека и физическая ленточная библиотека. Между площадками настроена репликация отдельно для СХД и отдельно для виртуальных лент. Далее каждая виртуальная ленточная библиотека независимо "экспортирует" виртуальные ленты на физические ленты. Все оборудование на гарантии и на поддержке. Компания коммерческая, расходы считает достаточно четко. Текущая конфигурация по соотношению расходов и рисков всех устраивает.
Так это уже вопрос к организации эксплуатации.
По хорошему устройств любого типа (речь не только про чтение/запись лент, но например и про маршрутизатор) нужно иметь как минимум два чтобы обеспечить хоть минимальную защиту от неожиданного выхода из строя. Это "мышку" можно купить быстро и то желательно иметь запас у себя на складе чтобы быстро заменить. А тут - часть системы резервного копирования. Если устройство чтения лент всего одно - значит есть шанс на неопределенное время остаться без доступа ко всем архивам пока не будет найдена, куплена и доставлена замена.
Следом вопрос к организации эксплуатации - вовремя заменять устройства на более новые по заданным критериям (срок работы, снятие с поддержки вендором, окончание срока гарантии и т.п.). То же относится и к лентам - периодически заменять и следить чтобы используемый тип лент был совместим с текущим (а желательно и следующим) поколением устройств для чтения.
Одиночная лента которую нужно ручками доставать из спец. хранилища и руками вставлять в считыватель - это конечно "дико холодные" данные.
Автоматическое ленточное хранилище это уже "гораздо теплее". Основная задержка там - это роботу "взять ленту из лотка и доставить в считыватель" + "перемотать до нужного места" и далее уже последовательное чтение или запись данных с достаточно высокой скоростью. Для архивов, резервных копий, архивных логов СУБД и других файлов которые нужно читать или писать только целиком и последовательно - отлично подходит. ПО управления ленточной библиотекой помогает управлять "жизненным циклом" данных на лентах.
Там где нужно минимизировать задержки на обращение к физическим лентам - перед физическими лентами ставят "виртуальную ленточную библиотеку" которая по интерфейсу - лента, но фактически внутри нее диски SSD или HDD, и она служит кэшем/буфером к физической ленте.
Те организации кто пишут/читают большие объемы лент - обычно не вставляют картриджи с лентой вручную. Там используются полностью автоматические хранилища, внутри которых полки с лентами и несколько "роботов" и приводов для работы с этими лентами.
С жесткими дисками подобную автоматику сделать конечно можно. Но, насколько я помню, жесткие диски не любят частых включений/выключений и физических перемещений. Поэтому для жестких дисков это "вырождается" в обычные дисковые полки или массивы где диски включены постоянно, тратят свой физический ресурс, потребляют электричество и греют воздух.
Конечно, условия хранения должны быть соблюдены и это справедливо для любого носителя данных.
Для бумаги/пергамента тоже нужны определенные условия хранения, просто "диапазон" другой. Бумага тоже боится огня и влажности, ее могут "погрызть", используемые компоненты для печати могут выцвести, и т.п.
У ленты гораздо более высокая плотность хранения по сравнению с бумагой и при записи используются технологии для возможности восстановления данных: избыточность, специальное кодирование и т.д.
Ну и для тех кому это действительно нужно, могут использовать несколько разных типов носителей, в расчете что что-то да сохранится.
Согласно спецификации IBM на картриджи 3592, они должны хранить данные порядка 30 лет. В самом документе, в разных местах написано "более 30 лет" и "до 30 лет". Сами картриджи разных моделей вышли уже после 2000г., поэтому эти данные приведены по тестам "ускоренного старения", так как даже самые старые картриджи из этой линейки "доживут" до указанного значения через 12 лет (2033 г.).
Ссылка на документ со спецификацией: https://www.ibm.com/downloads/cas/GLDJAXRP
Насколько я помню, финансовые организации, в соответствии с законодательством стран, где они работают, обязаны хранить исторические данные очень много (десятки) лет. При этом, по правилам, нужно хранить несколько копий, географически удаленно друг на друга. Т.е. "потерять" эти данные финансовая организация не имеет права ни в коем случае.
Уж не знаю как сейчас насчет "физической бумаги", хотя ранее видел как печатают и хранят ежедневную бумажную отчетность по определенным операциям.
Практики, когда важные данные выгружаются на ленту (несколько копий) и развозятся по разным изолированным складам/хранилищам точно существуют и по сей день. Хранить магнитную ленту все таки проще и дешевле чем, например, жесткие диски сравнимого объема.
Нет конечно. :) В качестве "первичного носителя" магнитная лента не используется очень давно (точно более 20 лет). Используются внешние СХД, сейчас все чаще "Full Flash".
При этом, магнитная лента вполне себе используется и сейчас как второй/третий уровень для хранения резервных копий и миграции "холодных" данных. Емкость современных магнитных картриджей очень неплоха, 20ТБ сырой емкости на картридж размером 25ммx110ммx125мм.