Главная Storages, Без рубрики, Новое Так ли незаменимы магнитные ленты для бэкапа? Часть 1
  • Так ли незаменимы магнитные ленты для бэкапа? Часть 1

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

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

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

    Если подойти к задаче оценки лент как устройства для резервного копирования непредвзято, то будет видно, что у лент есть, по большому счету, ровно два плюса:

    1. Высокая плотность мегабайт на площадь хранения
    2. Низкая “удельная цена” хранения мегабайта при больших и очень больших объемах.

    Все остальное, увы – сплошные минусы.

    Например:

    1. Отсутствие произвольного доступа (важно для снижения времени восстановления и, например, технологий устранения дубликатов хранимых данных)
    2. Избыточная скорость и емкость для множества применений.
    3. Невозможность организации защиты с избыточностью (RAID) кроме тупого ручного “зеркалирования” в виде записи двух экземпляров.
    4. Невозможность контроля состояния записанных данных при хранении (повреждения и невозможность считывания данных, зачастую обнаруживаются только при попытке восстановления данных в час “Ч”)
    5. Механическая непрочность носителя, строгие требования по условиям хранения и использования (влажность, запыленность).
    6. Сложность и высокая точность устройства чтения (лентопротяного механизма), и, как следствие, легкость его повреждений.
    7. Сложность организации управляемого устройства емкостью выше одного картриджа (роботизированные библиотеки)

    Как мы видим, “плюсы” лент находятся скорее в области так называемого “архивного хранения”, которое по своим задачам довольно замтно отличается от задач “резервного копирования”.
    Остановимся на этом вопросе подробнее, так как далеко не для всех, как я знаю, э та разница очевидна.

    Чем функционально отличается резервная копия от архивной копии?

    Прежде всего тем, что резервная копия создается для того, чтобы ее считывать. Возможно это звучит немного парадоксально, каким-то трюизмом, но это на самом деле так. Резервная копия нужна нам только для того, чтобы мы могли ее считать, чтобы восстановить данные после их внезапной потери. Эту мысль активно продвигает, например, Symantec, в своем продукте Backup Exec, начиная с версии 10d в 2006 году: “Не покупайте “сохранение” данных, покупайте “восстановление”. Чаще всего резервная копия имеет небольшой срок хранения, давность создания – минимальная (в идеале – “только что”), и подлежит частому “ротированию” для поддержания актуальности данных. Резервная копия старше нескольких дней чаще всего уже никому не нужна как “резервная копия”, и постепенно превращается в “архивную копию”.

    Напротив, архивные данные это данные, как правило, write only. Они пишутся не для того, чтобы из них регулярно что-то читать и восстанавливать. Чаще всего архив компании требуется по причине соответствующих требований законодательства (в тех странах, где такие есть), и за таким сегментом хранения закрепилось название “Archive and Compliance” (где “Compliance” это некая область законодательного контроля, определяемая законодательными актами, в которых определен срок хранения тех или иных документов, зачастую весьма длительный, до десятков лет).

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

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

    Когда-то, много лет назад, жесткие диски действительно не удовлетворяли ни требованиям “цены за мегабайт”, ни требованиям плотности хранения “мегабайт на квадратный метр хранения”, ни надежности этого хранения, поэтому неудивительно, что ленты, несмотря на их существовавшие и тогда перечисленные минусы и недостатьки, заняли весь “рынок”, как архивного, так и backup-хранения. Другого приемлемого решения просто не было. Однако произошедшая на наших глазах за 5-10 лет “технологическая революция” в области технологий жестких дисков многое изменила. И теперь нет смысла соглашаться на весьма сомнительные компромиссы, которые нам диктуют магнитные ленты как средство хранения данных, просто потому что “мы всегда так делали”.

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

    romx

    http://blog.aboutnetapp.ru

Комментарии

  1. Ну использовать ленту как средство текущего бекапа, это ИМХО расточительство. 6-12 SATA дисков в рейде, даже на начальном котроллере решают 🙂

    Правда диски довольно проблематично переносить на другой локейшен (не всегда есть возможность связать локейшены оптикой). А ленту довольно легко – в конверт и курьеру в машину. Romx, а что скажешь об альтернативных средствах хранения архивной информации? Например о BR-дисках и таких решениях: http://ncm.ru/nsm_bd.shtm

  2. Об удаленном бэкапе и вариантах его решения в случае дисков будет третья часть статьи. Плюс с удовольствием приму любые варианты “а вот с лентами можно … а как с дисками?” на разбор.

    Что касается альтернативных решений, то пока не вижу того, что наши англоязычные коллеги называют proven.
    Архивное хранение требует выбора решения со временем жизни (по меньшей мере производства носителей и устройств чтения) в десятки лет.
    На чем теперь крутить и где купить при необходимости расширить емкость решения на магнитооптике или каких-нибудь PD-disc, UDO?
    Куда-куда, в какие дали отправился совсем недавно “так дышавший” HD-DVD?
    Это только ближайшие примеры. Вряд ли кто-то захочет в этой области экспериментировать над своими данными.
    В этом смысле ленты и диски (вернее интерфйсы и форматы их) себя зарекомендовали и перспективы их довольно ясные. Чего пока не сказать об альтернативах.

  3. При всем уважении к работе автора:
    1) Как сказал уже Алексей, зачастую нет лучшего решения для offsite backup
    2) Вообще большая часть проблем, описанная авторам преследует лишь тех, кто не в состоянии купить себе ленточную бибилиотеку.
    3) Сделать архив данных и не приложить к нему два устройства, способных его прочитать это верный признак ССЗБ =)
    4) Ленты уже давно уступают всем подряд в плотности записываемой информации на единицу объема и площади. Те же LTO4 – 1,5Г при сжатии.
    Но спасибо за свежий взгляд – нужно иногда осматриваться, а так ли все хорошо было задумано 😉

  4. насчет плотности я фигня сказал – помрачение рассудка =)

  5. > Как сказал уже Алексей, зачастую нет лучшего решения для offsite backup

    Давайте вернемся к этому вопросу после того, как вы прочитаете третью часть. Там мы обсудим, что именно является гвоздями в данном случае 😉

    > Вообще большая часть проблем, описанная авторам преследует лишь тех, кто не в состоянии купить себе ленточную бибилиотеку.

    На самом деле все проблемы начинают преследовать именно того, кто купил библиотеку, это же очевидно. “Нет библиотеки – нет проблемы!”.

  6. С нетерпением жду остальных частей 🙂

    ИМХО, библиотека только масштаб увеличивает. Мы должны архивные копии держать в другом месте, не в основной серверной. Если у нас есть линк хороший между этими локейшенами, то смысл на удаленной точке ставить библиотеку? Тогда уже лучше много-много дисков 🙂
    А если линка нет и библиотека там же где и всё, тогда курьеру придется таскать не один конвертик с лентой, а целые чемоданы 🙂

  7. 10-мегабитный линк между сайтами прокачиает за сутки около 100 гигабайт данных, а это ведь, по нынешним временам, практически “бытовой” канал.
    Очень немного задач порождает 100 гигабайт _измененных_ данных за сутки.

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

    UPD:хотя конечно ты прав большинство компаний канал имею

  9. 1. 10-мегабитный линк даст 100 гигов в сутки голой информации. Полезной будет меньше.
    2. Сопоставимые с этим объёмом информации даст почтовая система любой крупной компании (несколько тысяч почтовых ящиков).
    3. 10-мегабитный канал в России на обоих концах за МКАДом, по-моему что-то из области фантастики.

  10. > UPD:хотя конечно ты прав большинство компаний канал имею

    Даже больше скажу, обойдется такой канал при нынешних ценах значительно дешевле двух библиотек (на основном и резервном сайте).

    > 10-мегабитный линк даст 100 гигов в сутки голой информации. Полезной будет меньше.

    Естественно меньше, вплоть до нуля 😉

    > 2. Сопоставимые с этим объёмом информации даст почтовая система любой крупной компании (несколько тысяч почтовых ящиков).

    Вы пропутили слова про “измененные данные”.
    100 гигабайт измененных данных это правда очень много.
    Вот читаемый в настоящее время Best Practices по SAP утверждает, что можно оценивать в средней SAP-системе величину суточных изменений в 2%.
    Для нашего объема в 100GB это дает размер базы в 5TB. А это ОЧЕНЬ большая база.

    > . 10-мегабитный канал в России на обоих концах за МКАДом, по-моему что-то из области фантастики.

    Ага, а еще у нас тут пьяные медведи в ушанках с балалайками по улицам ходят 😉

  11. >Ага, а еще у нас тут пьяные медведи в ушанках с балалайками по улицам ходят
    Липецк, 900 метров оптики нам оценили в 0.5 млн и хорошо что еще рублей. Таганрог, порядка 5-6 км оптики, о цене даже задумываться не хочу 😉

  12. А кто говорит про оптику, в смысле dark fiber?
    VPN через интернет для этого вполне пригоден.

  13. Ну давайте по лентам подробнее. При наличии ленточной библиотеки для нас пропадают проблемы 3, 6, 7. Проблема 2 становится тоже не актуальной, ибо если организация может позволить себе такую библиотеку (штука и впрямь не из дешевых), то вопрос избыточности редко стоит. Скорее, начинается “а как бы нам не особо доплачивая туда еще десяток терабайт в день запхнуть”. По поводу механической непрочности: ИМХО, но любая современная лента по этому параметру даст фору любому HDD. Ну разве что SSD может быть получше, но покажите мне гуманоида, который будет обычный бекап на SDD делать =)
    Дальше:
    >>Очень немного задач порождает 100 гигабайт _измененных_ данных за сутки.
    И тут я урод… 100Г в час делают при некоторых не слишком редких обстоятельствах некоторые мои базы. Масштабы они разные, не нужно категоричности, которую я себе иной раз позволяю, увы =)
    >>VPN через интернет для этого вполне пригоден.
    Абсолютно не пригоден во многих случаях. Слишком нестабилен, часто занят другими приложениями, трудно контролируется. Тем, кто мне скажет, что это не так важно для бекапа пусть объяснят своему генеральному после сбоя, что они похерили RTO, RPO и, как следствие, SLA потому что это “неважно”.
    Про каналы в России я даже повторяться не буду – Алексей все правильно сказал. Выделенные 10М между двумя радом лежащими точками где-нибудь в Мухосрачинске обойдутся в суммы сравнимые с MPLS такой же цифры в Европу из Москвы.
    В общем, опять мое личное мнение: добавьте перед знаком вопроса в заголовке “для малого бизнеса” и концы начнут сходиться с концами хотя бы в первой части =)
    З.Ы. No offence, правда. Интересно иногда задуматься… Я вот начинал работу в текущем месте с анализа как раз применимости BR-хранилищ. Тогда не пошло, надо сейчас тему поковырять, вдруг требования стали лучше соответствовать =)
    З.З.Ы. Вообще, задача бекапа для Disaster recovery становится все менее и менее очевидно необходимой – разнообразные зеркала, DAG И прочее… В общем задачи Disaster Recovery в некоторых случаях уходят от чистого бекапа. Там и RTO и RPO много лучше, чем у классического резервного копирования. Остаются применения из разряда “я тут файлик стер два месяца назад”. До завершения этого процесса, конечно, еще дожить нужно 😉

  14. Есть еще одно важное преимущество лент – их можно унести. Физически. Взять и унести в сейф.

  15. >VPN через интернет для этого вполне пригоден
    Как бывшего работника провайдера в сталице ЮФО ___ОООЧЧЧЕЕНЬЬ____ улыбнуло. 🙂
    Типа по секрету – мы даже своим канал между городами, и даже некоторым каналам в пределах города, ничего серьезнее трафика клиентов не доверяли.

    Из более позднего опыта – гарантированный канал в 4 Мб (не паблик интернет) между двумя городами России в пределах одного провайдера – примерно $1000 – $1200 в месяц.

  16. Рейд-массив хорош для оперативных бэкапов в пределах датацентра. Долговременное хранение лучше всё-таки осуществлять на лентах.

    В отдельных случаях, когда объем бекапов небольшой, можно обойтись одним-двумя USB-винчестерами 🙂

  17. > При наличии ленточной библиотеки для нас пропадают проблемы 3, 6, 7. Проблема 2 становится тоже не актуальной,

    Вы ошибаетесь.

  18. “Вы ошибаетесь” – не аргумент. В чем конкретно? =)

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

  20. 2Romx
    >Естественно меньше, вплоть до нуля

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

    >Вы пропутили слова про «измененные данные».

    >100 гигабайт измененных данных это правда очень много.

    >Вот читаемый в настоящее время Best Practices по SAP утверждает, что можно оценивать в средней SAP-системе величину суточных изменений в 2%.

    >Для нашего объема в 100GB это дает размер базы в 5TB. А это ОЧЕНЬ большая база.

    я внимательно читаю. современные почтовые системы (это отнюдь не smtp/pop3/imap4 трафик) дают в день десятки гигабайт изменений у любой крупной организации. давайте не будем соскакивать с темы. я про SAP ничего не писал. а размер баз в 5Тб это не так и много. при среднем размере почтового ящика в 2.5Гб даст всего 2000 почтовых ящиков. много? не сказал бы. средняя цифра для крупной организации.

    в общем я соглашусь с Александром Трофимовым насчёт добавления «для малого бизнеса» =)

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

    Сергей, у сколько же вам дисков надо? И где та самая надежность хранения?

  22. >>Сергей, у сколько же вам дисков надо? И где та самая надежность хранения?
    А не так, чтобы много… Дисковая полка с SATA дисками дает почти 10Т места. Надежность хранения для оперативных задач бывает действительно не так важна. Весь пойнт в том, что это отнюдь не для всех так. Есть компании, где менеджеры за SLA за гениталии подвесят, а RPO & RTO настолько важны, что на них готовы потратить сотни тысяч долларов. Причем, не обязательно разово, это может быть и регулярный процесс – тратить деньги. И вот тут внезапно оказывается, что библиотека плюс курьер обеспечивают “пропускную полосу канала” 80ТБ за час на другой конец города, причем, on-demand 😉 А за пять часов “перекачивает” тот же объем в Европу. Причем много-много дешевле, чем натуральный канал, который гарантированно обеспечит такую скорость.
    И вот как организовать такое же с дисками, мне пока не очень понятно. Если объяснят – узнаю что-то новое.

  23. > давайте не будем соскакивать с темы. я про SAP ничего не писал.

    Не нравится SAP – давайте про Exchange. Руководство по сайзингу для Exchange 2007/2010 приводит пример расчета, указывая цифру в 450GB дневных изменений для системы в 25 тысяч активных пользователей, при 80/20 принятых-посланных писем средним размером около 100Kбайт (я просто цитирую руководство по сайзингу, приводящее такой расчет в качестве примера).
    100 гигабайт даст в четыре с половиной раза меньшее количество, то есть около 6 тысяч активных пользователей.
    6 тысяч активных пользователей это снова довольно таки много.
    Организация с 6 тысячами активных пользователей Exchange, как я догадываюсь, обычно уже не испытывает трудности с покупкой полосы канала для репликации.

    Но, по моему, мы давно отклонились от темы.

  24. Вот поди ж ты… Роман, Вы в заведомо невыгодной позиции – сдавайтесь =))))
    1) Вам, чтобы оказаться полностью правым, нужно доказать, что так, как Вы говорите – у всех организаций. Задача заведомо невыполнима, ибо отсутствие результата не особо результативное событие. А нам достаточно показать, что есть вполне нормальные повседневные задачи среднего бизнеса (мы со Станиславом представляем IT именно среднего бизнеса, насколько я знаю), которые могут генерить терабайты изменений в сутки, что мы и сделали.
    2) Вы нам рассказываете про документацию, которая далеко не всегда отражает реальную жизнь, что супротив реальных примеров смотрится опять-таки очень бледно.
    Поэтому я второй раз рекомендую внести ограничения в сферу применимости Вашего труда.
    З.Ы. Про эксчангу тоже не нравится. Подозреваю, что цитата идет про 2007, а 2010 все еще хуже. =(

  25. Я предлагаю всеже дождаться всех частей. А потом уже смотреть на цельную картину. Что-то мне подсказыает что Роман в последнюю очередь думал о смалл-бизнес 🙂

  26. Есть еще одно НО :
    – на тот же Ultrium бэкапить в 2 раза быстрее, чем разбекапливать. И если базы уходят на ленту за 2 часа, то восстановление займет 4-е..

    Посему, то, что должно быстро встать – пишем на винты, если влезет, конечно..

  27. 2Romx
    Руководство по проектированию хранилища это всего-лишь руководство. Его можно брать в качестве шаблона и расширять под требования бизнеса. Нужно отталкиваться от живых данных.
    6 тысяч ящиков это много. Но это среднее количество для крупной почтовой организации. Скорее даже ближе к верхнему пределу среднего бизнеса.
    Если такой бизнес начинает расширяться на периферию, то он может банально столкнуться с ситуацией, что канал необходимой ширины купить либо невозможно (есть места, куда лететь на вертолёте несколько дней =)), либо стоимость его будет неприемлемой.

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

  28. > Вот поди ж ты… Роман, Вы в заведомо невыгодной позиции — сдавайтесь

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

    > Про эксчангу тоже не нравится. Подозреваю, что цитата идет про 2007, а 2010 все еще хуже.

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

    > Но это среднее количество для крупной почтовой организации.

    Я специально указал, что это количество “активных” пользователей, ежедневн принимающих 80 100-килобайтных писем и отправляющих 20 таких же.
    Это довольно заметный запас в случае реальной жизни, если трафик компании не DVD-рипы в аттачах 😉

  29. >>Наоборот, количество ввода-вывода в базу у 2010 сокращено очень значительно, по сравнению с 2007, это одно из самых заметных улучшений 2010.
    Ага… Только вот объем самих баз увеличился значительно за счет искоренения SIS. Тут я, правда, теоретизирую, поскольку сами только в предпроцессе. Но “одна бабка сказала”, что у некоторых при переходе на 2010 оный объем вырастал в разы. Повторюсь – это непроверенная информация.
    Но что падение I/O может совершенно не кореллировать с размерами – это и так вполне понятно, я думаю. А нас интересует именно объем.
    >>Я специально указал, что это количество «активных» пользователей, ежедневн принимающих 80 100-килобайтных писем и отправляющих 20 таких же. Это довольно заметный запас в случае реальной жизни, если трафик компании не DVD-рипы в аттачах
    Я уже говорил – у Вас какая-то другая реальная жизнь… Отличная от нашей со Станиславом. У меня день без ста писем – счастливый день. Без двухсот – хороший. =) Ну и размер – всякий. нормальное письмо 50-70к. Есть и под 200 и мегабайтные. К тому же помимо этого входяще/исходящего потока есть еще и архивирование, которое хоть и раз в неделю, но тоже трафик в базу генерит 😉
    Давайте уже вторую и третью части – хочу новых знаний!

  30. жду с нетерпением =Р

  31. Лента ради ленты, бэкап ради бэкапа… а смысл в чём? В чём проблема посчитать Single Lost Expectancy? Хотя бы…

    …и прикинуть, что проще – купить ленту/организовать канал 10Mb/построить надёжный SAN? Или ну его нафиг, всё равно денег больше заработаем, нежели потеряем. ^__^

    Статья понравилась.

  32. Поддерживаю вышесказанное в статье, тк сам категорически против использования лент для резервного копирования. На практике постоянно вижу проекты в которых для тривиального бекапа используются системы класса HP EVA 🙂 что вызывает улыбку – если учесть ее стоимость и стоимость ПО.

    За статью спасибо.

  33. как НЕбэкапер, если здесь подводить итоги: для резервного копирования лучше SAN (уровень CX4, EVA), для архивирования ленточные библиотеки и уголок в золотоволютном хранилице для лент? 🙂

  34. > если здесь подводить итоги:

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

  35. Я бы предложил людям задуматься еще и о возможность бекапа на удаленные площадки, тот же амазон, за пару ночей полторы сотник Гб выливаются спокойно