Алексей>Но упомяну так же наличие функционала периодической проверки лент.
?? вот настаёт час Х и вы узнаете, что лента повреждена - царапина, к примеру, что дальше? Также не стоит забывать, что от того чем больше проверяются (и вообще используются) ленты, тем больше вероятность того, что они повредятся.

Алексей>Я согласен с тем, что B2D более правильное и удобное решение, но есть ряд “нишевых” задач, где без лент не обойтись.
В предыдущем посте и предложен вариант применения лент.

Я не привожу никаких цифр для сравнения.

> но есть ряд “нишевых” задач, где без лент не обойтись.

Но вы точно также неправильно поняли мой пост. :) Это нигде и не оспаривается.
Да, ленты это нишевой, но не мэйнстримовый, как это массово воспринимается, продукт для бэкапа. ??м присущ ряд серьезных недостатков, на которые нельзя закрывать глаза. На сегодня ленты в “мэйнстриме” бэкапа даже не являются самыми удобными, самыми надежными или самыми перспективными решениями. На своем месте они вполне применимы, но именно на своем месте. Заголовок поста вполне однозначно указывает задаваемым вопросом на освещаемую тему.

>>Какие цифры?

Различные цифры стоимости, которые приводятся для сравнения. По стоимости хранения библиотеки пока (подчёркиваю, пока) остаются выгоднее дисков. Особенно при долговременном хранении.

>>> ?? ещё с первого поста на эту тему хотел отметить, что существую как библиотеки, так и ПО резервного копирования, осуществляющие, грубо говоря, RAIT (вместо disks tapes).

>>Есть. Только это сугубо теоретическая возможность, и “вы этого не захотите”. Ни разу не видел использования этого “в природе”, а попробовашие утверждают, что это непригодно для использования, и я им верю.

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

>>> А про слабые процессоры в предыдущем коментарии - это вообще просто смешно!

>>Было приятно вас повеселить, но увы, это реальность жизни.

У наших заказчиков (особенно на рынке Enterprise) соблюдается старое доброе правило 80/20, т.е. 80% CPU загружены на 20%. А уж с выходом новых Power7 от IBM и новой серии Xeon от Intel вряд ли будет меняться без консолидации. ??менно поэтому так активно сейчас развивается виртуализация.

В общем, Вы неправильно поняли мой комментарий. Я согласен с тем, что B2D более правильное и удобное решение, но есть ряд “нишевых” задач, где без лент не обойтись.

Какие цифры?

> ?? ещё с первого поста на эту тему хотел отметить, что существую как библиотеки, так и ПО резервного копирования, осуществляющие, грубо говоря, RAIT (вместо disks tapes).

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

> А про слабые процессоры в предыдущем коментарии - это вообще просто смешно!

Было приятно вас повеселить, но увы, это реальность жизни.

?? ещё с первого поста на эту тему хотел отметить, что существую как библиотеки, так и ПО резервного копирования, осуществляющие, грубо говоря, RAIT (вместо disks tapes).

??МХО (впрочем, как и многих других) наиболее оптимальным по скорости/сохранности/цене является двухступенчатое резервное копирование, когда сначала льётся бэкап на диски, а после некоторого времени ротации с весьма быстрой скоростью сливается на ленты. Ну и, конечно же, резервное копирование выполняется не с оригинала данных и не на основном сервере, а с клонов на выделенном сервере резервного копирования.

Так что по сути единственным, но безусловно сильно решающим фактором перехода только на B2D является набирающая силы дедупликация.

PS. А про слабые процессоры в предыдущем коментарии - это вообще просто смешно!

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

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

Третий вариант - кроме серверов, которые наверняка уже “на гигабите” есть еще и локальные рабочие места, их данные тоже надо сохранять в очень большом количестве случаев. Они, все еще чаще всего, не на гигабите. А даже если и на гигабите, то опять же: мелкие файлы или слабые процессора.

То есть ограничений скорости в реальной жизни всегда достаточно, и в них нет ничего смешного.