Комментарии 59
ленточные библиотеки остаются важнейшим средством резервного копирования и долгосрочного архивирования.
Вы совершенно напрасно сливаете в одном предложении через запятую два разных процесса и два разных понятия. Важнейшим средством резервного копирования ленты НЕ являются, (наконец, и слава Труду), а архивного хранения — да, являются, и там им и место.
Но это две разные области применения, принципиально отличающиеся по своим требованиям к медиа и методам.
Чем бекап на ленточки принципиально хуже бекапа на диски?
Бэкап — это задача, для которой скорость восстановления — критически важна. Можно считать даже, что это вообще самый важный параметр такого процесса как «резервная копия» — скорость, с которой из этой копии можно восстановить исходное состояние данных на оригинальном носителе.
И тут устройство с линейным, последовательным характером доступа к данным уже изначально проигрывает. Оно просто, как вы заметили, принципиально хуже.
Вам никогда не доводилось восстанавливать большой бэкап с лент из Full + цепочки Incremental, особенно если они с интерливингом и на разных лентах? Очень веселый и неторопливый процесс.
И еще «веселее» он становится, когда выясняется, что одна из лент сета не читается, или читается с проблемами (или вовсе повредилась при загрузке, такое бывает не так редко, увы). RAID-то нет, в отличие от дискового массива. «Умерла — значит умерла».
Все это не столь важно для архивов, которые, обычно, «данные write-only», но для бэкапов это все критически важно. И если у вас не оборудование времен прошлого века, на сегодня нет ни одной реальной причины использовать ленты именно для бэкапа.
И тут устройство с линейным, последовательным характером доступа к данным уже изначально проигрывает. Оно просто, как вы заметили, принципиально хуже.
Вам никогда не доводилось восстанавливать большой бэкап с лент из Full + цепочки Incremental, особенно если они с интерливингом и на разных лентах? Очень веселый и неторопливый процесс.
И еще «веселее» он становится, когда выясняется, что одна из лент сета не читается, или читается с проблемами (или вовсе повредилась при загрузке, такое бывает не так редко, увы). RAID-то нет, в отличие от дискового массива. «Умерла — значит умерла».
Все это не столь важно для архивов, которые, обычно, «данные write-only», но для бэкапов это все критически важно. И если у вас не оборудование времен прошлого века, на сегодня нет ни одной реальной причины использовать ленты именно для бэкапа.
А я думал, что RTO с RPO у всех разные и выбор решения зависит от конкретной задачи.
Я ни разу не встречал хотелки бизнеса, отличные от «чем скорее — тем лучше» и «чем меньше потери — тем лучше». Потом их обычно удается умять, но начинают всегда с 0/0.
Это понятно, но цена тоже имеет значение — диски жрут электричество, греются и ломаются. Даже Google хранит бекапы на лентах, хотя казалось бы… Ещё есть кластеры под Hadoop, где данные раскиданы по нодам и для бекапа на диски придётся увеличивать количество стоек в 1.5-2 раза.
Если шпиндели дисков отключать/парковать, то получается довольно тихо и спокойно.
Вроде бы вам только, что объяснили разницу между бекапом и архивом, а вы опять за свое.
Про Гугл, кстати, точно ничего не известно, вот не надо. Гугл компания большая и засекреченная, и никто точно не знает, как именно и где у них данные хранятся, а сведения трех-четырех летней давности могут безнадежно устаревать.
Кластеры Hadoop это все еще экзотика, а не массовое применение, и это вообще специальная область. Я так понимаю, что для них вообще нет смысла делать общее сетевое хранилище резервных копий, а нужен (если нужен) локальный драйв, а не SAN-библиотека.
Кластеры Hadoop это все еще экзотика, а не массовое применение, и это вообще специальная область. Я так понимаю, что для них вообще нет смысла делать общее сетевое хранилище резервных копий, а нужен (если нужен) локальный драйв, а не SAN-библиотека.
Что бы не было «Умерла — значит умерла» — есть копии данных на других лентах.
Ну а касательно что только не бэкап на лентах — так зачем на дисках держать бакап 3-х,7-и,14-ти (каждому своё) дневной давности?
Плюс не забываем про распараллеливание, соответственно и восстановление будет быстрее чем с одной ленты.
Ну а касательно что только не бэкап на лентах — так зачем на дисках держать бакап 3-х,7-и,14-ти (каждому своё) дневной давности?
Плюс не забываем про распараллеливание, соответственно и восстановление будет быстрее чем с одной ленты.
Плюс не забываем про распараллеливание, соответственно и восстановление будет быстрее чем с одной ленты.
Это сразу увеличивает стоимость решения минимум на стоимость еще одного драйва и еще более усложняет картину. На самом деле проблема лент совсем не в скорости записи или считывания с одной ленты, скорее даже, парадоксальным образом, наоборот, эта скорость бывает слишком велика. Именно для этого используют мультиплексирование, запись на одну ленту бэкапов сразу от нескольких клиентов, так как ленты (в отличие от дисков, кстати) требуют постоянный поток данных максимальной скорости, иначе начинается крайне невыгодный старт-стопный режим работы, тратяший время и изнашивающий ленту.
Говоря про медленность процесса я имел ввиду не скорость чтения копии, а процесс загрузки-выгрузки кассет с лентой.
Представьте, что у вас есть кассета (кассеты) с еженедельным full backup, сделанная в субботу. А потом вы делаете incremental каждый день. И у вас случилась авария, допустим, в пятницу утром. Значит вам надо сперва загрузить ленты full, прочитать их и восстановить на диски целевой системы. Пожужжать роботом, выгрузить эти ленты (или поморгать лампочкой, и дождаться, пока ленту вынет оператор в нероботизированной системе), загрузить ленту для понедельника, промотать ее до нужного места, где хранятся измененные данные за понедельник для этой системы. Считать, вынуть ленту. Вставить ленту для вторника, помотать…
При этом для дисков вы можете сразу читать нужные фвйлы.
загрузить ленту для понедельника, промотать ее до нужного места, где хранятся измененные данные за понедельник для этой системы. Считать, вынуть ленту. Вставить ленту для вторника, помотать…
Давайте на чистоту, за последнее n-ое количество лет вы ввидели такое решение в организациях (имею в виду РК на стриммере)? Я — нет :) Такое видел буквально пару раз и то в организациях, где стриммер появился исторически когда-то еще во времена, когда жесткие диски стоили дорого и вмешали относительно небольшое количество данных. При этом стриммер там использовался примерно в качестве «дополнительной резервной копии».
Често, в настоящее время использование именно стриммера может быть только при каких-то специфических зачадах, в остальных случаях проще и дешевле будет записывать данные на жесткие диски.
В случае же использования ленточной библиотеки, я с вами не согласен, временем на загрузку ленты можно пренебречь, и, естественно, ручками уж точно ничего не придется делать ;)
Как ни крути, но лента вне конкуренции в крупном коропративном секторе, что бы то ни было: банки, атомная промышленность, заводы и т.д. Почти везде будет использоваться схема (в очень упрощенном виде): «Сервер»-->«Подключенный к нему Storage»-->«РК на ленточную библиотеку».
Давайте на чистоту, за последнее n-ое количество лет вы ввидели такое решение в организациях (имею в виду РК на стриммере)? Я — нет :)
И я — нет. Именно по той простой причине, что использование лент не только неудобно, но сегодня для малого-среднего бизнеса еще и экономически невыгодно, о чем я с самого начала и пишу тут.
В случае же использования ленточной библиотеки, я с вами не согласен, временем на загрузку ленты можно пренебречь
Почему это вдруг?
Скорость загрузки и выгрузки ленты при использовании робота-загрузчика ничуть не изменяется, и ни на секунду не короче, чем при ручной загрузку-выгрузке. Ну вот только вручную ее (ленту) из коробки доставать не надо, и в слот драйве вталкивать, только и всего. В остальном загрузка и выгрузка ленты занимает ровно то же самое (значительное) время.
Как ни крути, но лента вне конкуренции в крупном коропративном секторе
Даже из крупного сектора она постепенно вымывается (хотя и не быстро, все же бабло вбухано много, жалко просто выкинуть, это называется «защита инвестиций»), по той же самом причине: для бэкапов ленты — крайне неудобная и непрактичная штука. И неудобство ничуть не становится меньше от увеличения размеров бизнеса.
Согласен. Обычно конфигурация в дата-центре такая: один сервер и один ленточный накопитель. При современных объемах лент никто инкрементными архивами не балуется-зачем этот гемор когда проще просто заново все слить?
изначально проигрывает
Тут вы не правы, зависит от типа данных. В случае, например, с бэкапом здоровенной базы — очень даже выигрывает.
Это если мы говорим о решениях с приблизительно одинаковой стоимостью на гигабайт бэкапа.
особенно если они с интерливингом и на разных лентах
Можно использовать библиотеки с несколькими приводами.
RAID-то нет
Никто не мешает делать копии лент или конкретных бэкапов между этими лентами.
И в конце-концов, есть различные стратегии бэкапов, у меня, например, всё просто и примитивно — Full+Incremental пулы. В бэкапах в основном оракловые базы. И нам доступно ЛЮБОЕ состояние базы за последние 3 месяца. А за последние 3 недели мы получим бэкап даже если одну или несколько лент зажует привод.
Тут вы не правы, зависит от типа данных.
Например, для какого типа данных сложный процесс восстановления, низкая скорость процесса смены частей данных, использование хрупких и чувствительных к пыли картриджей с лентой и дорогостоящих точных механических драйвов, читающих и пишущих исключительно последовательно что ведет к существенному увеличению времени восстановления, это не является важным?
Можно использовать библиотеки с несколькими приводами
С учетом того, что основная стоимость недорогой ленточной библиотеки — это драйвы, это еще ухудшает показатель экономической эффективности.
Но вообще-то про интерливинг — это я о другом. Интерливинг, это когда на одну ленту параллельно льется несколько потоков от нескольких бэкап-агентов, то есть данные получаются записаны «в шахматном порядке». Очень немногие клиенты способны отдать на бэкап поток, неообходимый для полной загрузки потока ленты на номинальной скорости.
Никто не мешает делать копии лент или конкретных бэкапов между этими лентами.
Ну что-то все же мешает, так как никто этого не делает. Вот вы — делаете? ;)
Использование дисков для хранения данных без RAID — это скорее исключение, наоборот, скорее исключение — использование RAID для лент (откровенно говоря — не видел ни разу, в смысле вообще ни разу).
И в конце-концов, есть различные стратегии бэкапов, у меня, например, всё просто и примитивно — Full+Incremental пулы.
Сколько времени у вас занимает восстановление работоспособности базы (включая накат redo-логов) в случае наихудшего сценария — считали? Подтверждение на практике — делали?
Но вообще-то про интерливинг — это я о другом.
Я в этом топике слишком часто упоминаю бакулу, просто хотел сказать, что мне за это не платят =)
Так вот, она — умеет. Подробной статистики нет, посчитать максимальную скорость можно только по средней температуре по больнице, но на порядки расхождений там не будет.
Ну что-то все же мешает, так как никто этого не делает. Вот вы — делаете? ;)
Тут я попался, что сказать… У бакулы не существует протокола общения между двумя SD (Storage Daemon, который как раз на ленту пишет). Но если говорить о коммерческих системах резервного копирования — такой функционал есть (и за его игнорирование нужно больно бить).
Подтверждение на практике — делали?
К сожалению — проверяли в самых что ни на есть реальных условиях. Вытягивание бэкапа 20Гб базы с ленты около 10 минут, его восстановление около 10-15 минут (этим уже DBA занимаются). Давно учений не было, точнее не скажу.
Я в этом топике слишком часто упоминаю бакулу, просто хотел сказать, что мне за это не платят
Мне кажется, вы слишком обеспокоены тем, чтоб никто не подумал, что вам за что-то платят ;)
Так вот, она — умеет.
Что, «умеет»?
такой функционал есть (и за его игнорирование нужно больно бить).
Так вот, рассказываю: никто его не использует. Я не видел ни одного случая (а я видел многое), просто потому что это слишком сложно и ненадежно по факту.
Вытягивание бэкапа 20Гб базы с ленты около 10 минут, его восстановление около 10-15 минут
Думаю, вы находитесь в плену чрезмерной оптимистичности.
Я про наихудший случай.
Наихудший случай при full-incremental это:
1. сделан full в субботу днем.
2. каждый вечер рабочего дня делается incremental
3. все стрясается в пятницу во второй половине дня.
4. значит надо восстановить на диски full с кассеты full-ов. Вынуть кассету
5. вставить кассету incremental, помотать ее, найти первый incremental, в понедельник, восстановить его
6. найти incremental для вторника, восстановить его
7.… для среды, четверга. Ура, состояние диска восстановлено.
8. переходим к восстановлению состояния уже непосредственно базы. накатываем redo-логи, с момента создания incremental в четверг, до момента, когда все стряслось в пятницу.
9. И только после завершения накатки логов можно говорить о восстановлении работоспособности.
И это совсем не «10 минут считать 20GB с ленты».
Что, «умеет»?
Писать одновременно несколько потоков, практически полностью нагружая ленту.
Наихудший случай при full-incremental это:
Не совсем, у меня Full-бэкап на ленте — это несколько rman-овских full-бэкапов с arch-логами между ними. Оракловый full-бэкап есть на инкрементальных лентах и он делается каждый день, благо дисковая подсистема позволяет это сделать без потери производительности.
Переключение кассеты роботом занимает около 1 минуты, учитывая, что таких переключений может быть максимум 4, учитывая перемотку это добавит ну минут 7, да даже 10.
В своём сценарии вы предполагаете крайний вариант экономии лент. Я забираю Full-бэкапы баз каждый день.
Не совсем, у меня Full-бэкап на ленте — это несколько rman-овских full-бэкапов с arch-логами между ними. Оракловый full-бэкап есть на инкрементальных лентах и он делается каждый день,
Хм-хм. Крайне странная стратегия. Вы не откладываете full и дергаете всю ленту ради суточного бэкапа?
А вот, к примеру, вот эта вот, текущая лента, использованная вами сегодня, необратимо повреждается механически. Что именно и за сколько дней данные вы с ней теряете? Считаем, что вот эта лента целиком потеряна. Спустя минуту вы понимаете, что база также повреждена. На какой момент вам удастся восстановиться без этой ленты?
В своём сценарии вы предполагаете крайний вариант экономии лент. Я забираю Full-бэкапы баз каждый день.
Тем более непонятно, зачем при таком небольшом объеме (20 GB Full!) вам нужны ленты. Когда два десятка full backup можно запросто хранить на USB-диске, стоимостью 1000 рублей, вдобавок работающем более удобно.
А спустя 2 минуты на площадке загорается ЦОД, где стоит леточная библиотека.
Что вы пытаетесь доказать? Случаи какие-то пограничные… Что с дисковым массивом будет при аналогичных проишествиях?
24 часа максимальный откат по данным будет в таком случае. Придётся накатывать arch-логи за пару суток, но это не так страшно в подобной ситуации.
Вы судите по единственному приведённому мной примеру о суммарном размере ежедневных бэкапов?
У меня 2 ленточных бибилотеки, HP и IBM, 2500 и 680 суток аптайма соответственно. За это время один раз в драйве заклинило ленту, его замена заняла 2 суток. Кассеты не умирали вообще.
И теперь оно внезапно стало ненадёжным?
Что вы пытаетесь доказать? Случаи какие-то пограничные… Что с дисковым массивом будет при аналогичных проишествиях?
На какой момент вам удастся восстановиться без этой ленты?
24 часа максимальный откат по данным будет в таком случае. Придётся накатывать arch-логи за пару суток, но это не так страшно в подобной ситуации.
Тем более непонятно
Вы судите по единственному приведённому мной примеру о суммарном размере ежедневных бэкапов?
У меня 2 ленточных бибилотеки, HP и IBM, 2500 и 680 суток аптайма соответственно. За это время один раз в драйве заклинило ленту, его замена заняла 2 суток. Кассеты не умирали вообще.
И теперь оно внезапно стало ненадёжным?
А спустя 2 минуты на площадке загорается ЦОД, где стоит леточная библиотека.
Потеря ленты это все же куда более вероятный и простой случай, чем «пожар ЦОДа».
Что вы пытаетесь доказать? Случаи какие-то пограничные… Что с дисковым массивом будет при аналогичных проишествиях?
По порядку:
«пытаюсь доказать», что вы чересчур поверхностно и легкомысленно смотрите на проблему резервного копирования.
Случай совсем не пограничные.
При аналогичных — каких? При потере диска — будет работать RAID и целостность данных не будет потеряна ни на минуту. При потере ЦОДа, если это требование существует, то будет стоять удаленный дисковый массив на другой площадке с репликацией данных между ними.
24 часа максимальный откат по данным будет в таком случае.
С учетом того, что у вас на одной ленте И full И incremental?
Либо я вас не понимаю, либо вы — меня.
Вы судите по единственному приведённому мной примеру о суммарном размере ежедневных бэкапов?
Разумеется, только по тому, что вы сами захотели рассказать, я вас и ващу компанию не знаю, и ориентироваться могу только на то, что вы сами, по своей воле согласились рассказать.
За это время один раз в драйве заклинило ленту
А у меня вот, так уж получилось, из двух десятков жестких дисков, которые я использовал на протяжении лет десяти в свой жизни, не умер ни один. Должно ли это означать, что все, что пишут про надежность дисков другие — вранье, и диски абсолютно надежные, и принимать какие-то меры по защите от внезапного выхода их из строя — глупость?
вы чересчур поверхностно и легкомысленно смотрите на проблему резервного копирования.
У меня нет проблем ни с копированием, ни с восстановлением.
Разговор зашёл в тупик на мой взгляд, если ваш опыт вам говорит о надёжности дисков — ваше право. Я оставляю за собой право иметь другое мнение по этому вопросу.
ну вот вам для примера-скорость чтения LTO-6 400 МБ/сек, весьма приличная скорость. Особенно если не бакапить дамп файловой системы а только файлы на ней. Старые кассеты нужно регулярно заменять на новые. Да, они недешевые, но данные дороже.
RAID тоже не панацея-вот сейчас работаю над проблемой, когда у хранилища в один прекрасный день вышибло больше половины винчестеров! Тут уж никакой RAID не спасет. А вообще будущее за гетерогенными бакапами и архивами, то есть когда сохраняется на 2-3 разных физических носителя, например жесткий диск, ленту и DVD.
RAID тоже не панацея-вот сейчас работаю над проблемой, когда у хранилища в один прекрасный день вышибло больше половины винчестеров! Тут уж никакой RAID не спасет. А вообще будущее за гетерогенными бакапами и архивами, то есть когда сохраняется на 2-3 разных физических носителя, например жесткий диск, ленту и DVD.
Корпоративный сектор это конечно здорово и понятно. Но вот такой вопрос — как так получилось с ленточными накопителями, что раньше они были вполне доступны обычному домашнему пользователю (или маленькой организации), а теперь, с ростом объемов данных, цены на эти накопители оказались такими, что намного дешевле и удобнее закупать HDD?
Я в своё время пользовался и двумя Arvid'ами и нормальным стримером — хорошо помню те времена. Сейчас — достаточно посмотреть на цены и всякое желание отпадает сразу.
Я в своё время пользовался и двумя Arvid'ами и нормальным стримером — хорошо помню те времена. Сейчас — достаточно посмотреть на цены и всякое желание отпадает сразу.
Просто потому, что они перестали быть интересны малому-среднему бизнесу. Диски объективно удобнее. И это послужило поводом полного вытеснения их в «энтерпрайз», с соответствующим ценником (и ценообразованием).
Arvid устройство уникальное для своего времени, 2 гига на видеокассету во времена 200 мегабайтных хардов это было сильно!
Хотя по плотности записи уступало Alesis ADATам но то был просто многоканальный магнитофон, а авид вполне себе кошерный стример.
Хотя по плотности записи уступало Alesis ADATам но то был просто многоканальный магнитофон, а авид вполне себе кошерный стример.
Лента была и есть дешеве диска. Только раньше она была в 20 раз дешевле, а сейчас в ~6 раз.
Стример тоже будет стоить относительно недорого (по сравнению даже с самой простой ленточной библиотекой) + стоимость будет зависеть и от поколения привода. Но в большинстве случаев, конечно, небольшие организации выбирают вариант с покупкой нескольких дисков…
В 2013 г. модельный ряд достаточно сильно изменился относительно прошлого года.
И всё равно на шаг позади StorageTek.
По аудио- и видео-кассетам я помню, как со временем деградирует и сыплется лента и как-то не вызывает доверия такой способ архивации.
Может я просто чего-то не знаю о таких лентах и ошибкоустойчивости алгоритмов кодирования?
Какие гарантийные сроки заявлены производителями таких носителей?
Может я просто чего-то не знаю о таких лентах и ошибкоустойчивости алгоритмов кодирования?
Какие гарантийные сроки заявлены производителями таких носителей?
Лента да, дешевая — 4,4к рублей за 6,25ТБ. а сам стример? что-то я более-менее адекватных цен не нашел. всё что я видел — over 125к рублей, даже за внутренний 5,25 девайс, устанавливающийся в комп в отсек для DVD
Ага и ещё софт к нему, а было классное устройство для кино\видео производства.
Bacula бесплатна.
Бакула — бесплатна. Рабочее время — не бесплатно.
На самом деле не так много времени на неё уходит. Я не говорю, что она идеальна — нет, с точки зрения удобства использования — один из самых неприятных продуктов, однако — она работает, и работает довольно хорошо.
Чтобы не быть голословным, могу сказать — с нулевым опытом работы с бакулой разбор с «наследием царского режима» занял около 1,5 недель. Повседневной работы с ней нет, только если что-то надо улучшить или восстановить.
Мне было бы приятней, если бы была какая-то энтерпрайзная софтина с удобным интерфейсом, но стоят они крайне дорого и часто не всё умеют.
Чтобы не быть голословным, могу сказать — с нулевым опытом работы с бакулой разбор с «наследием царского режима» занял около 1,5 недель. Повседневной работы с ней нет, только если что-то надо улучшить или восстановить.
Мне было бы приятней, если бы была какая-то энтерпрайзная софтина с удобным интерфейсом, но стоят они крайне дорого и часто не всё умеют.
Tivoli Storage Manager совсем не бесплатен, однако приятным его тоже не назовёшь.
В российском космосе в наземных объектах (наземных оптико-лазерных системах), где требования по архивации информации составляют лет 10, очень даже эти системы используются. Как минимум с двойным резервированием.
Пока HP будет писать такие статьи, а не двигаться вперед, толку в компании не будет… С ужасом вспоминаю свой HP ленточный опыт.
НЛО прилетело и опубликовало эту надпись здесь
Мучительно пишем софт для архивации на тейп девайсы уже несколько лет, пока кастомеры не отказываются. У устройств есть достаточно большой буфер для записи, данные пишутся сразу на две кассеты для восстановления, информация о файлах и кассетах хранится в базе, что позволяет оптимально считывать данные.
А зачем, если есть Bacula?
+1 Bacula еще и роботизированными библиотеками умеет управлять.
Правда без подготовки будьте готовы убить на настройку дня два (-:
Подумываю написать топик howto.
Правда без подготовки будьте готовы убить на настройку дня два (-:
Подумываю написать топик howto.
Наше приложение по возрасту примерно как Bacula, плюс изначально интегрируется с другим нашими и не только софтом (например печать, редактируются файлы для печати (фонты, картинки и тп.), печатаются, потом чтобы освободить место на жестком диске дизайнеров архивируются на кассеты, понадобилось через год перепечатать — нет проблем).
Умеет практически все, что и Bacula, жесткие диски (можно на два одновременно для надежности), двд, юсб драйвы, кассеты, поддерживает валидацию, экономию электроэнергии (спип/хибернейт/выключение), перенос данных внутри системы (с кассет на двд, с двд на жесткий и тп), инкрементальную архивацию/востановление, поиск файлов, работает по сети, шифрование, может иметь произвольное количество рабочих станций — на одном компе двд архиватор, на другом кассетник, на третьем куча жестких дисков и тп, само приложение представляет собой томкет сервер с админкой и мониторингом(скорость, статус, процессы, сообщения типа вставьте кассету и тп) + сервера для архивации.
Умеет практически все, что и Bacula, жесткие диски (можно на два одновременно для надежности), двд, юсб драйвы, кассеты, поддерживает валидацию, экономию электроэнергии (спип/хибернейт/выключение), перенос данных внутри системы (с кассет на двд, с двд на жесткий и тп), инкрементальную архивацию/востановление, поиск файлов, работает по сети, шифрование, может иметь произвольное количество рабочих станций — на одном компе двд архиватор, на другом кассетник, на третьем куча жестких дисков и тп, само приложение представляет собой томкет сервер с админкой и мониторингом(скорость, статус, процессы, сообщения типа вставьте кассету и тп) + сервера для архивации.
Использую MSL4048 с Bacula для бекапов и архивов, данные первоначально хранятся в файловой системе на RAID и по истечению срока давности для типа бекапа перекладываются на ленту.
Плюсы:
1) Bacula позволяет не покупать HP USB ключ для шифрования данных, она это умеет «из коробки»;
2) Достать бекап из файловой системы намного быстрее, чем с ленты;
3) Всегда можно сделать копию или переместить данные на ленту, по любым критериям.
Минусы:
1) Реализовать все хотелки на Bacula получилось не сразу, пришлось вникать.
Плюсы:
1) Bacula позволяет не покупать HP USB ключ для шифрования данных, она это умеет «из коробки»;
2) Достать бекап из файловой системы намного быстрее, чем с ленты;
3) Всегда можно сделать копию или переместить данные на ленту, по любым критериям.
Минусы:
1) Реализовать все хотелки на Bacula получилось не сразу, пришлось вникать.
В качестве преимуществ дисковых бэкапов я бы ещё упомянул возможность использовать дедупликацию, которая даёт большо выигрышь при хранении резервных копий. И ту же самую компрессию.
CommVault умеет дедупликацию на кассетах:
www.channelregister.co.uk/2009/01/26/comvault_simpana_8/
www.channelregister.co.uk/2009/01/26/comvault_simpana_8/
Друзья, спасибо за комментарии, это значит что тема интересна читателям. Кратко отвечаю на возникшие вопросы.
Конечно, в общем и целом лента больше подходит для архивного хранения, но и для резервного копирования ее используют тысячи компаний. Я много общаюсь с заказчиками, и большинство не имеет проблем в ежедневном или еженедельном бэкапе на ленты — ни по скорости записи/восстановления, ни по надежности. Это означает, что количество биснес-критичных приложений у них невелико.
Да, сейчас с каждым годом и даже месяцем растет число заказчиков, которым необходим дисковый бэкап, и для них у нас есть, как вы знаете, библиотеки линейки HP StoreOnce (ранее известные как D2D). В данном случае НР предлагает самую полную линейку решений для резервного копирования и архивирования. При этом практически все заказчики, использующие дисковый бэкап, имеют и ленточные библиотеки. Дисковый бэкап мы рекомендуем использовать для ежедневного бэкапа наиболее важных данных, а ленточный — для еженедельного или ежемесячного полного резервного копирования и архивирования (некоторые картриджи потом вывозят на удаленный сайт).
Что касается надежности и долговечности лент, то не надо сравнивать дешевые потребительские аудиокассеты тридцатилетней давности с современными картриджами. Технологии ушли далеко вперед, поэтому записав сейчас на ленту информацию, вы и через 30 лет сможете прочитать ее, если условия хранения будут соответствовать заданным параметрам. Другой вопрос, найдете ли вы через столько лет LTO-драйв требуемого поколения :)
Конечно, в общем и целом лента больше подходит для архивного хранения, но и для резервного копирования ее используют тысячи компаний. Я много общаюсь с заказчиками, и большинство не имеет проблем в ежедневном или еженедельном бэкапе на ленты — ни по скорости записи/восстановления, ни по надежности. Это означает, что количество биснес-критичных приложений у них невелико.
Да, сейчас с каждым годом и даже месяцем растет число заказчиков, которым необходим дисковый бэкап, и для них у нас есть, как вы знаете, библиотеки линейки HP StoreOnce (ранее известные как D2D). В данном случае НР предлагает самую полную линейку решений для резервного копирования и архивирования. При этом практически все заказчики, использующие дисковый бэкап, имеют и ленточные библиотеки. Дисковый бэкап мы рекомендуем использовать для ежедневного бэкапа наиболее важных данных, а ленточный — для еженедельного или ежемесячного полного резервного копирования и архивирования (некоторые картриджи потом вывозят на удаленный сайт).
Что касается надежности и долговечности лент, то не надо сравнивать дешевые потребительские аудиокассеты тридцатилетней давности с современными картриджами. Технологии ушли далеко вперед, поэтому записав сейчас на ленту информацию, вы и через 30 лет сможете прочитать ее, если условия хранения будут соответствовать заданным параметрам. Другой вопрос, найдете ли вы через столько лет LTO-драйв требуемого поколения :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Лента – все еще лидер в резервном копировании данных