Нельзя впихнуть невпихуемое.

ВНЕЗАПНО — рельно ленточка на 1,5 Тб. 3 Тб там будет если контроллер сумеет сжать данные вдвое.

И как правило сжимает.

Ну давайте, пожмите вдвое мою библиотеку медиаданных, jpeg'и всякие, avi'шки.

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

Посчитаем.

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

А давайте попытаемся провести калькуляцию. Сколько стоит кассета для магнитофона, сколько стоит коробка с вращающимися блинами, сколько на них влезает, сколько стоит библиотека, серверы для размещения НЖМД, искричество, кондиционирование. Реально любопытно, хотя в моей конторе резервное копирование на ленты пока не вариант. Данных не настолько много, хранить их надо не настолько долго, кассеты однократной записи против НЖМД с многократной записью смотрятся не настолько выгодно.

Это требования регламента, диски откатавшие гарантийный срок, подлежат ОБЯЗАТЕЛЬНОЙ замене, как и ленточка, прошедшая определенное число циклов записи/перемотки.

System Storage DCS9900 - до 1,2 петабайт в одной стойке.

http://www-03.ibm.com/systems/ru/storage/disk/dcs/dcs9900/index.html

Я говорил о контроллерах на 400 дисков sata.

>А давайте попытаемся провести калькуляцию. Сколько стоит кассета для магнитофона, сколько стоит коробка с вращающимися блинами, сколько на них влезает, сколько стоит библиотека, серверы для размещения НЖМД, искричество, кондиционирование.

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

Все зависит от режима работы.

>Это требования регламента, диски откатавшие гарантийный срок, подлежат ОБЯЗАТЕЛЬНОЙ замене, как и ленточка, прошедшая определенное число циклов записи/перемотки.

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

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

backbone

rsnapshot забыли

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

> Ну давайте, пожмите вдвое мою библиотеку медиаданных, jpeg'и всякие, avi'шки.

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

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

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

С client compression на ленту поместится еще больше, но я бы предпочел это не использовать. Разве что бэкапы на аутсорсе, и с вас берут деньги не за гигабайт на ленте, а за гигабайт, переданный на сервер. Тогда да, client compression может дать ощутимую экономию.

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

Кто его использовал, скажите, в ней можно задавать пути, включаемые в архив + маски файлов, выбираемые по этим путям?

Проще говоря, чтобы архивировались «Мои документы», но пропускались тонны музыки, лежащие там?

Чушь против чуши.

Это требования регламента, диски откатавшие гарантийный срок, подлежат ОБЯЗАТЕЛЬНОЙ замене, как и ленточка, прошедшая определенное число циклов записи/перемотки.

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

Чушь. Практика показывает, что НЖМД нужно менять после определённого «пробега». Люди меняющие диски по cron'у не с жиру бесятся, но борятся с реальной высокой нагрузкой.

>Чушь. Практика показывает, что НЖМД нужно менять после определённого «пробега». Люди меняющие диски по cron'у не с жиру бесятся, но борятся с реальной высокой нагрузкой.

Тоже вариант, если под «пробегом» понимать теже самые данные smartctl с его процентом перемещеных секторов, временем работы и т.д., а не тупое сравнение datetime() с датой покупки девайса.

Именно datetime().

Тоже вариант, если под «пробегом» понимать теже самые данные smartctl с его процентом перемещеных секторов, временем работы и т.д., а не тупое сравнение datetime() с датой покупки девайса.

Именно что datetime()! Только он сравнивается не с датой покупки, но с датой установки. Нагрузка примерно равномерная (всё время высокая), так что время работы из smartctl даже вытаскивать не нужно. А если есть перемещённые сектора, то НЖМД немедленно меняется.

внезапно диск на 3 Tb