Кто-нибудь юзает резервное копирование на ленты? Поделитесь опытом.

Перфокарты надежнее.

Забыли как страшный сон, чего и тебе желаем. Бекапимся на 2тб внешние\съёмные винты, с дублированием, и храним их в сейфах с термоконтролем на объекте и за пределами объекта. Раз в полгода провожу учения среди персонала по восстановлению.

Резервное копирование — это задача, для которой скорость восстановления — критически важна. Можно считать даже, что это вообще самый важный параметр такого процесса как «резервная копия» — скорость, с которой из этой копии можно восстановить исходное состояние данных на оригинальном носителе.
Тебе никогда не доводилось восстанавливать большую резервную копию с лент из Full + цепочки Incremental, особенно если они с поочерёдной группировкой данных и на разных лентах? Очень весёлый и неторопливый процесс.
И ещё веселее он становится, когда выясняется, что одна из лент сета не читается или читается с проблемами (или вовсе повредилась при загрузке, такое бывает не так редко, увы). RAID-то нет, в отличие от дискового массива. «Умерла — значит умерла».

Всё это не столь важно для архивов, которые, обычно, данные write-only, но для резервного копирования это всё критически важно. И если у тебя не оборудование времён прошлого века, на сегодня нет ни одной реальной причины использовать ленты именно для резервного копирования.

Расскажи всё это Гуголу, который с лент восстановил почту после крупного сбоя. А еще посмотри сколько по скорости будет записать/восстановить данные с нормальных лент, сколько это будет ресурсов занимать, и сколько то же самое построить на дисках. Долго думай.

И да, чисто ради прикола, сколько ты данных бэкапишь, как часто, и какой у тебя инкрементальный бэкап в день? Ну чтоб знать твой уровень.

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

Лол, видимо ты до сих пор живёшь 90-ыми. Сейчас лента по 2,5Тб хранит, 150Мб/сек со сжатием выдаёт, в проприетарном ПО есть RAIT (RAID on tape) и дублирование. А также возможность чтения сразу с нескольких стримеров. Я уж молчу о стоимости хардов и обвязки для них. Бекапить гуглоресурсы можно только на ленту даже чисто из-за стоимости. Мало того: IBM сделала LTFS - файловую систему на ленте, в платной версии ФС на несколько лент может расползаться. Плюс поддержка аппаратного шифрования. Что к теме скорости восстановления, то для этого есть виртуальные ленточные библиотеки на хардах, которые дублируют горячие данные.

Сейчас лента по 2,5Тб хранит, 150Мб/сек со сжатием выдаёт, в проприетарном ПО есть RAIT (RAID on tape) и дублирование

Это сразу увеличивает стоимость решения минимум на стоимость ещё одного драйва и ещё более усложняет картину. На самом деле проблема лент совсем не в скорости записи или считывания с одной ленты, скорее даже, парадоксальным образом, наоборот, эта скорость бывает слишком велика. Именно для этого используют мультиплексирование, запись на одну ленту резервных копий сразу от нескольких клиентов, так как ленты (в отличие от дисков, кстати) требуют постоянный поток данных максимальной скорости, иначе начинается крайне невыгодный стартстопный режим работы, тратящий время и изнашивающий ленту.

Говоря про медленность процесса я имел ввиду не скорость чтения копии, а процесс загрузки-выгрузки кассет с лентой.
Представь, что у тебя есть кассета (кассеты) с еженедельным Full backup, сделанная в субботу. А потом ты делаешь Incremental каждый день. И у тебя случилась авария, допустим, в пятницу утром. Значит, тебе надо сперва загрузить ленты Full, прочитать их и восстановить на диски целевой системы. Пожужжать роботом, выгрузить эти ленты (или поморгать лампочкой и дождаться, пока ленту вынет оператор в нероботизированной системе), загрузить ленту для понедельника, промотать её до нужного места, где хранятся изменённые данные за понедельник для этой системы. Считать, вынуть ленту. Вставить ленту для вторника, помотать…

При этом для дисков ты можешь сразу читать нужные файлы.

Это сразу увеличивает стоимость решения минимум на стоимость ещё одного драйва и ещё более усложняет картину.

Очевидно, что у вас и так должен быть запасной драйв на случай зажевывания кассеты.

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

Да Вы прям ыксперт. Что ещё очевидное расскажите? Кстати, VTL решает и эту проблему: бекап переносится на ленту только того, как виртуальный картридж полностью забился и перешёл в RO.

Говоря про медленность процесса я имел ввиду не скорость чтения копии, а процесс загрузки-выгрузки кассет с лентой.

Вам тут все уже 10 раз повторили, что лента - это лишь один из носителей бекапа, обычно горячие данные на хардах также (или только) лежат. Мало того, в продашкене обычно используется не восстановление из бекапа, а откат снапшота на СХД.

Представь, что у тебя есть кассета...

И что? Если у тебя полетели снапшоты, дисковые бекапы или тебе нужны данные 10-летней давности, то пусть бизнес подождёт, чем соснёт хер.

При этом для дисков ты можешь сразу читать нужные файлы.

Ещё раз: лента - это либо последний рубеж бекапа, либо архивные данные, либо бекап сверхбольших объёмов (облака).

Вылези из криокамеры: сейчас восстановление с ленты делается в два клика (если есть робот и все картриджи в нём), а используется она только в последнюю очередь. Никто сегодня не делает бекапы тупо на ленту таром.

Вам тут все уже 10 раз повторили, что лента - это лишь один из носителей бекапа, обычно горячие данные на хардах также (или только) лежат

Для резервного копирования ленты — крайне неудобная и непрактичная штука.

Вылези из криокамеры: сейчас восстановление с ленты делается в два клика (если есть робот и все картриджи в нём), а используется она только в последнюю очередь

Скорость загрузки и выгрузки ленты при использовании робота-загрузчика ничуть не изменяется и ни на секунду не короче, чем при ручной загрузку-выгрузке. Ну вот только вручную её (ленту) из коробки доставать не надо и в слот драйва вталкивать, только и всего. В остальном загрузка и выгрузка ленты занимает ровно то же самое (значительное) время.

нужны данные 10-летней давности

Это называется архивная копия, а не резервная. Разные вещи.

Да, использую Amazon Glacier. Всем доволен. Мультимедию не шифрую, бекапы данных - шифрую.

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

2. Как часть дохнет лента?

Чаще чем хотелось бы (это к неудобству восстановления). Был случай когда по разгильдяйству была сделана только одна копия, лента оказалась не читаемой, в результате данные потеряли.

Первое - кассеты реально быстрые, и у них есть пачка механизмов чтоб сделать их еще быстрее. Да, они быстрые только на последовательном чтении, random access на них никакой. Но в случае бэкапа всего харда как блока либо пары очень толстых файлов скорость кассет будет выше чем у хардов.

Второе - стоимость. Кассеты дешевле, оборудование дешевле.

Третье - возможность смены носителя без танцев с бубном. Да, есть обвязки для хардов с возможностью удобного hot swap. Ну и сколько хардов ты туда впихаешь? Десять? И сколько она будет стоить? И кто харды подавать будет, пара китайцев? Когда у тебя реально жопой жрать сколько данных, полка кассет и робот который их меняет куда удобнее коробки хардов и пары джуниоров на подхвате.

Я говорю именно про вариант когда данных натурально жопой жрать сколько. И это не 20 и не 30 тб, а куда больше.

И если у тебя не оборудование времён прошлого века, на сегодня нет ни одной реальной причины не использовать ленты именно для резервного копирования.

Поправил, можешь не благодарить.

процесс загрузки-выгрузки кассет с лентой.

Ты эти ленты вообще видел? У роботов это занимает секунды.

или вовсе повредилась при загрузке, такое бывает не так редко, увы

Это руки из жёппы штоле? С роботами такое крайне редко происходит.

наоборот, эта скорость бывает слишком велика...

медиа сервер, а потом несколько потоков по 300mb/s на разные драйвы? не, не слышале

Сейчас лента по 2,5Тб хранит, 150Мб/сек

LTO7 6TB 300MB/s native, up to 15TB 750MB/s compressed нынче в моде. У некоторых других производителей уже относительно давно 8.5TB и 10TB native имеются.

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

Например, для какого объёма данных сложный процесс восстановления, низкая скорость процесса смены частей данных, использование хрупких и чувствительных к пыли картриджей с лентой и дорогостоящих точных механических драйвов, читающих и пишущих исключительно последовательно, что ведёт к существенному увеличению времени восстановления, это куда удобнее коробки хардов?

медиа сервер, а потом несколько потоков по 300mb/s на разные драйвы?

С учётом того, что основная стоимость недорогой ленточной библиотеки — это драйвы, это ещё ухудшает показатель экономической эффективности.

Вот читаю топик и все еще остаюсь с вами солидарен. Из выше отписавшихся мне кажется никто не использовал реально восстановление, а все доводы «за» подчерпаны исключительно с теории «как оно будет».
Например в работе бывает нужно восстановить файл[ы] за определенное время (не на рабочую систему, а просто нужно), ну чего-то по станиславскому не верю что это не обернется долгим ожиданием в случае с лентами.

это ещё ухудшает показатель экономической эффективности.

У тебя есть расчёты? У меня да и они далеко не в пользу дисков. Хотя и не отменяют их использование в цепочке резервирования.

С учётом того, что blahblahblah

С учётом того, что ты в этом ничего не понимаешь, отправлю тебя изучать первые ссылки из гугла раз и два.
Вот тебе сразу пару тезисов

For long term storage, over the five year study period, the cost of disk is about 23 times that of the tape.
The cost of energy is 290 times that of tape.

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

Мне кажется, как раз те кто верят/не верят и не использовал.
Даже у LTO среднее время доступа к файлу 50 сек.

Хорошо, просто честно ответьте на вопрос «Вам приходилось восстанавливать с лент?».

Например, для какого объёма данных сложный процесс восстановления, низкая скорость процесса смены частей данных, использование хрупких и чувствительных к пыли картриджей с лентой и дорогостоящих точных механических драйвов, читающих и пишущих исключительно последовательно, что ведёт к существенному увеличению времени восстановления, это куда удобнее коробки хардов?

когда эта коробка хардов будет размером с камаз. Когда у тебя будет натурально тысяч 5-10 дисков, и вручную у тебя никаких джуниоров не хватит это все подключать/переключать. Тут только робот и библиотека кассет.

Приходилось, не боись, целыми сайтами(не те что www) восстанавливали.

целыми сайтами(не те что www) восстанавливали.

С ленты

целыми сайтами

Не смешно. А что нибудь покрупнее небыло?

Ты ещё и читать не умеешь?

сайтами(не те что www)

датацентрами

Специально для вас повторюсь. Опыт с «камазом» есть?

1. Извините но не телепат ) Сайты != датацентры
2. Вы восстанавливали после «падения» - я правильно понял?
Если да, то я в том числе спрашивал про:

Например в работе бывает нужно восстановить файл[ы] за определенное время (не на рабочую систему, а просто нужно)

Что можите про такой опыт сказать?

Что ты пытаешься доказать?

For long term storage, over the five year study period

5 лет на архивную не потянет. В минус.

Либо я тебя не понимаю, либо ты — меня.

когда еще жил в дс, на одной из предыдущих работ у половины отдела этого опыта было по самое некуда, часто ходили к кассетам. У меня к сожалению допуска не было, однако веселые истории про «зарядить по 1.5к кассет на человека в день» были повсеместно.

У меня в продуктиве для порядка 10 баз используется бэкап/рестор именно через ленты для создания резервного хоста. С учетом всех задержек в нетбекапе весь процесс восстановления стабильно укладывается в 3 минуты.

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

Сайты != датацентры

У кого как.

Вы восстанавливали после «падения» - я правильно понял?

Да, у пары клиентов приключались истории из разряда «всё пропало»

Например в работе бывает нужно восстановить файл[ы] за определенное время (не на рабочую систему, а просто нужно)

Зависит от disaster recovery policy, обычно минуты.

То, что ты ересь пишешь. Наверное на локалхосте или с парой серверов диски дешевле и удобней, но в остальном не выходит по твоему.

Разговор зашёл в тупик, на мой взгляд, если твой опыт тебе говорит об удобности дисков — твоё право. Я оставляю за собой право иметь другое мнение по этому вопросу.

5 лет на архивную не потянет. В минус.

Ты о чём?

For long term storage, over the five year study period, the cost of disk is about 23 times that of the tape.

The cost of energy is 290 times that of tape.

К сожалению в статье не учитывается еще стоимость лицензий на приводы в софте и стоимость дальнейшей покупки. Хотя как мы несколько лет считали - получалось все равно дешевле жирных массивов

когда еще жил в дс, на одной из предыдущих работ у половины отдела этого опыта было по самое некуда, часто ходили к кассетам. У меня к сожалению допуска не было, однако веселые истории про «зарядить по 1.5к кассет на человека в день» были повсеместно.

Каждый день падало? :)
Т.е. реального опыта восстановления данных с лент (пусть и по запросу к коллегам) у вас не было?

Ну так для дисков тоже надо бэкап-софт :)

Тут на обьем можно было бы перейти, но 3 мин рестора с ленты уже сам по себе показатель. Спасибо вы первый кто хоть привел реальные данные а не «коня в жидкой_среде»

5 лет для архива зачастую очень мало.

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

Но как можно догадаться, нужно ж все это хозяйство непрерывно бэкапить и загружать все новые и новые кассеты. Это ж не то что загрузил 80к кассет и живешь радуешься. Это типа «загрузил на этой неделе, на следующей еще загрузил» и так далее.

Т.е. реального опыта восстановления данных с лент (пусть и по запросу к коллегам) у вас не было?

лично, своими руками, к сожалению, нет. допуска нема было :(

Чем больше период, тем больше разница. Lower TCO применимо к регулярным бэкапам тоже.

например BasicDisk в netbackup не требует доп. лицензий - жирный медиа сервер + nfs = profit ) Мы в свое время считали - netapp c компрессией и дедупум вышли дешевле, чем если бы пришлось расширять существующую библиотеку

жирный медиа сервер

Куда же без него )

чем если бы пришлось расширять существующую библиотеку

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

лично, своими руками, к сожалению, нет. допуска нема было :(

Что бы не обдумано вас не оговорить, попробую еще раз спросить. Под вопросом "(пусть и по запросу к коллегам)" я подразумевал время восстановления не обязательно вашими руками, это могли делать ваши коллеги но по вашей просьбе. Если такой опыт был, то как вы оцениваете скорость восстановления. И насколько часто такое приходилось делать, что бы оценить среднюю скорость?

Ты же совсем не прав:

сложный процесс восстановления

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

низкая скорость процесса смены частей данных

Оно состоит из засовывания в устройство, и поиска на устройстве. У лент медленнее только второе, и, при адекватном количестве приводов, вполне амортизируется до несущественного.

использование хрупких и чувствительных к пыли картриджей с лентой

Это моток ленты то хрупкий? Ну, пластиковый корпус, конечно, не сравнить с толстым металлом у ЖД, но зато внутри ломаться почти нечему.

точных механических драйвов

Площадь одной ленты - порядка 10 квадратных метров, сравни с полезной поверхностью диска сравнимого объёма, и ещё раз подумай, кого «точным» обзывать. К тому же, замена лентотяги в полевых условиях проста и не (всегда)? вызывает потерю носителя с данными.

читающих и пишущих исключительно последовательно

Внезапно - диски тоже последовательно читают, у них только поиск быстрее. Результаты злоупотребления - в предпоследней колонке vmstat-а. А флеш и прочая твердотельщина пока не дорасла.

что ведёт к существенному увеличению времени восстановления

Можно спорить, что при сравнимом количестве приводов, оно было бы несущественное. Просто в случае лент сильно экономят на оных.

это куда удобнее коробки хардов

О! Коробку со 100 картриджами могут таскать изящные операторши. Для аналогичного объёма ЖД понадобятся огромные качки, которые неосторожным движением будут выламывать места втыкания дисков, т.ч. ТЦО вырастет нецензурно:)

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

Тебе никогда не доводилось восстанавливать большую резервную копию с лент из Full + цепочки Incremental, особенно если они с поочерёдной группировкой данных и на разных лентах? Очень весёлый и неторопливый процесс.

Нажал на кнопку - и все. Занимаешься другими делами или, если делать нечего, представляешь себе, какая сейчас бурная деятельность происходит в библиотеке. Если это один большой файлик (почтоый ящик к примеру), восстановится за пару минут. Если это сотни тысяч файлов, раскиданных по разным лентам, может занять пару часов. RTO для холодных данных (которые обычно и уходят на ленту) обычно выше, чем для горячих (которые хранятся в дисковом пуле), и должен быть заранее обговорен с бизнесом.
Full+Incremental, пфф... Да у некоторого энтерпрайзного бэкапного софта (TSM к примеру) вообще нет Full - только инкрементальные бэкапы. Подход у IBM такой - incremental forever. И никаких проблем. Конечно, есть свои средства, чтобы данные слишком сильно не расползались по лентам (collocation-группы, рекламация).

И ещё веселее он становится, когда выясняется, что одна из лент сета не читается

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

Netbackup? Или что?