А какие плюшки в сравнении с Bacula?

первая буква лишняя имхо

>А какие плюшки в сравнении с Bacula?

Присоединяюсь к вопросу.

s3 device

Есть только один истинный S3 device.

А существуют ли в природе люди, которые:

1. Смогли настроить эту аманду 2. Продолжают её использовать после успешной настройки

?

Какой БЕЗДАРНЫЙ сайт. Потратил 5 минут и не нашел списка поддерживаемых платформ. Дилетантство!

--седайко стюмчик

>...сервер и клиент...
Долго думал... Надоело...

Нет, вот вы мне скажите: а нафига для бэкапинга клиент?...

Криптовать данные и отправлять серверу?

уже несколько лет используем это поделие

И как ощущения?

Неэнтерпрайз.

Нет, вот вы мне скажите: а нафига для бэкапинга клиент?...

А вы когда-нибудь делали резервные копии более чем с дюжины машин? Суть в том, что есть машина с магнитофоном или сменными НЖМД — сервер, и куча машин, которые туда пишут данные — клиенты.

Интересно, как оно выглядит по сравнению с бакулой.

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

Но самое главное - кошмарная консоль. А тут?

>имплементирована

Реализована

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

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

не совсем понимаю - нахера оно? cron + bash + tar + sshfs + vpn + пара часов вечером = инкрементальное резервное копирование, с фулл-бекапами за неделю, и с учетом тонокостей баз данных, особенно при больших таблицах (>50млн записей). Не занимает ли настройка аманд/бакул больше? Про тонкости в настройке вообще говорить нечего - как напишешь, так и будет работать. И никаких дополнительных сервисов в памяти и на сетевых интерфейсах.

плюсую, нечего усложнять, если реально не требуется система, подобной этой.

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

А где-то еще есть ленты? Имхо с нынешними двух-террабайтными сата дисками куда проще создавать архивы на винчестерах.

А как у оной аманды с восстановлением данных?

Насколько проще мониторить объемы архивов, решать запросы пользователей на восстановление файлов и директорий за определенной число?

ВНЕЗАПНО - ленточка на 3TB

В бакуле на одно продумывание плана архивирования уйдет не один день

И что самое плохое, ошибки в этом плане сработают через недели-месяцы.

Восстанавливаться легко, любая запись аманды это dump/gz. Я делал изначально эмуляцию библиотеки средствами аманды. В итоге достаточно amadmin глянуть какие ленточки нужны для восстановления, идешь в папки соответствующих ленточек, копируешь оттуда дамп-файлы в темп-каталог, и там amrestore на файл, оно в текущий каталог разжимало весь бэкап, можно указать что конкретно разжимать и куда разжимать, мне как правило нужно было вытащить 1-2 файла, проще быть разжать во временный каталог.

Ну и что здесь внезапного? Всего-навсего в полтора раза больше объем и прощай произвольный доступ, прощай скорость, прощай по сути все.

Вот если бы ленты были на 30ТБ или на 50 ТБ, я бы понял, ради чего весь гемор. а так у меня детский раид5 на 14ТБ и что мне делать с лентами?

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

в том что они ведут вменяемый каталог записей

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

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

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

детский раид5 на 14ТБ

Я предполагаю он собран не из ширпотребовских десктопных винтов?
А то иначе при хорошей нагрузке за сколько они развалятся? А сколько стоит единица времени простоя твоего сервера? А сколько стоит единица времени простоя там, где используют такие решения?

>Восстанавливаться легко, любая запись аманды это dump/gz. Я делал изначально эмуляцию библиотеки средствами аманды. В итоге достаточно amadmin глянуть какие ленточки нужны для восстановления, идешь в папки соответствующих ленточек

ну в таком режиме проще rsync/xdelta использовать.

Я имел в виду скорость и удобство процесса. Насколько легко посмотреть, какие версии конкретного файла на какой момент есть. И насколько легко их восстановить на клиентской машине.

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

>Я предполагаю он собран не из ширпотребовских десктопных винтов?

собственно, по любому это ширпотребство. Какие бы наклейки на нем не стояли.

А то иначе при хорошей нагрузке за сколько они развалятся?

а раид5 на что? Сотни рабочих мест шерстят его - пока держится. Замена, восстановление целостности нагорячую.

А сколько стоит единица времени простоя твоего сервера?

во первых, я давно потерял всякое доверие к оценкам простоя. Пальцы все кидают, а тут банк Москвы в очередной раз весь день не работал и что? Все по*уй.

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

А сколько стоит единица времени простоя там, где используют такие решения?

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

На лентах можно создать относительно недорогое хранилище на 900 петабайт, в рамках т.н. single library image.

А винты использовать для бекапов - просто верх некомпентности, за такое сразу надо увольнять.

Угу, 900 петабайт на лентах по три ТБ с учетом сжатия 2:1 т.е. по 1,5 ТБ и временем записи в три часа одна лента. Круто же оное тормозить будет, а как гореть красиво будет...

Не нужно. Облака и CrashPlan рулят.
А вообще недостатком всем систем бэкапа является не их техническая реализация, а отсутствие внятной политики бэкапа. Строго говоря, при наличии внятной, досконально выверенной и проверенной на соответствие принципу KISS политики бэкапа - всё остальное можно реализовать на чём угодно, хоть BASH-скрипты написать. Bakula и Amanda никак не помогут с политикой бэкапа, зато создадут массу новых головоломных сущностей. Если нет жены и девушки, то, наверное, и такое может быть полезно...

Враки.

ВНЕЗАПНО - ленточка на 3TB

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

>А винты использовать для бекапов - просто верх некомпентности, за такое сразу надо увольнять.

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

Для 900 петабайт ленты может и имеют смысл, а большинству из читателей ЛОРа они должны быть глубоко пофиг.

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

>Диск нельзя вытащить, положить на полочку и через 5 лет включить.

Согласен.

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

В этом случае, хранение на диске гораздо более удобно, особенно если средства доступа к архивным данным интегрированы в ERP-систему или доступны сравнительно неквалифицированному персоналу для использования.

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

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

Но мне интересно бы услышать чем ленточка лучше винчестера, т.к. я не вижу таких факторов.

>Диск нельзя вытащить, положить на полочку и через 5 лет включить. Он может и не заработать. На ленту дают гарантию на 50 лет.

Про ЦДРом диски писали гарантия 10 дет. А реально они кернятся за год.

а винты, живущие по пять лет, это рядовая бытовуха.

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

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

>Но мне интересно бы услышать чем ленточка лучше винчестера, т.к. я не вижу таких факторов.

Ну во первых раньше ленты были реально больше винтов. Много больше. Винчестер 40-80мбайт, а ленточный арвид - 2гига. вот тебе и расклад.

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

А какие плюшки в сравнении с Bacula?

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

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

И как правило сжимает. Не 2:1 конечно, но сжимает. На практике получается где-то 2-2.4 TB. Пока ни разу не видел, чтобы на ленту LTO-5 влезало меньше 2 TB. Зато 3 TB - видел :)

ВНЕЗАПНО: У SUN Oracle есть ленты на 5 ТБ. Без сжатия. Со сжатием 2:1 - 10 ТБ. Но это уже Ъ-энтерпрайз, а не нищебродский LTO.

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

>ВНЕЗАПНО: У SUN Oracle есть ленты на 5 ТБ. Без сжатия. Со сжатием 2:1 - 10 ТБ. Но это уже Ъ-энтерпрайз, а не нищебродский LTO.

ВНЕЗАПНО, у гугла в gmail 7594.000749 мегов вообще даром. Подачка с барского стола.

>А вы данные в процессе бэкапа самостоятельно не сжимаете, до записи на ленты?

а смысл? tar со сжатием нельзя даже обновлять. и как архивировать бесконечный архив на куче кассет прикажете?

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

В течении 5 лет 90% дисков в рейде меняется на новые. Теперь умножь стоимость этого диска на 400. 200 тб на рейд10.

В течении 5 лет 90% дисков в рейде меняется на новые.

[источник?]

Не подтверждается. 10% в среднем это реально. Причем даже раид0 с ними не разваливается. То есть, вытащить данные можно.

И это в режиме постоянного включения и операций чтения-записи. Иначе диски не портятся за редким исключением.

>В течении 5 лет 90% дисков в рейде меняется на новые. Теперь умножь стоимость этого диска на 400. 200 тб на рейд10.
ну гарантия там от 3х лет, так что большинство дисков просто придет и заменит дядя бесплатно и никто даже не заметит. и как уже сказали 90% это перегиб, 10%, ну 20% максимум, более реально.

200 тб на рейд10.

Только йопнутый на всю голову будет 400 дисков объединять в раид 10.

Да таких контроллеров-то нет...

> 200 тб на рейд10

for f in `seq 100`; do truncate -s 2000G $f; done # такие?

>>А какие плюшки в сравнении с Bacula?

Присоединяюсь к вопросу.

rsnapshot забыли