LINUX.ORG.RU

Amanda 3.3.0

 ,


0

2

2 июня 2011 года вышла очередная стабильная версия 3.3.0 инструмента для выполнения резервного копирования Amanda Network Backup.

Список изменений относительно корректирующей версии 3.2.3, вышедшей месяцем ранее, достаточно внушителен. Ознакомиться с ним можно на сайте проекта и в архиве с исходным кодом.
Вот лишь наиболее значимые изменения:

  • новые сервер и клиент amdumpd, позволяющие клиенту начать бэкап самого себя
  • имплементирована команда amzfs-sendrecv для восстановления при помощие amrecover
  • изменён список каталогов для поиска скриптов
  • в amanda.conf добавлены некоторые опции и разделы
  • новые алгоритмы в taperscan - по старшинству и лексический
  • s3 device - используется многопоточность для ускорения передачи
  • режим аутентификации по умолчанию «bsdtcp»

>>> Исходный код

>>> Официальный сайт

★★★

Проверено: svu ()

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

blind
()
Ответ на: комментарий от pylin

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

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

anonymous
()

s3 device

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

buddhist ★★★★★
()

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

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

?

anonymous
()

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

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

sedajko_stjumchik
()

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

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

Pronin ★★★★
()
Ответ на: комментарий от Pronin

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

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

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

Camel ★★★★★
()

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

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

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

AVL2 ★★★★★
()

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

Реализована

yoghurt ★★★★★
()
Ответ на: комментарий от AVL2

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

anonymous
()

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

prizident ★★★★★
()

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

dib2 ★★★★★
()
Ответ на: комментарий от dib2

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

uspen ★★★★★
()
Ответ на: комментарий от dib2

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

anonymous
()
Ответ на: комментарий от prizident

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

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

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

anonymous
()
Ответ на: комментарий от adriano32

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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


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

dib2 ★★★★★
()
Ответ на: комментарий от AVL2

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

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

adriano32 ★★★
() автор топика
Ответ на: комментарий от anonymous

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

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

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от adriano32

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

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

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

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

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

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

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

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

AVL2 ★★★★★
()

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

DRVTiny ★★★★★
()
Ответ на: комментарий от adriano32

Враки.

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

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

Camel ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

fagot ★★★★★
()
Ответ на: комментарий от fagot

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

anonymous
()
Ответ на: комментарий от anonymous

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

Согласен.

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

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

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

fagot ★★★★★
()
Ответ на: комментарий от anonymous

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

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

prizident ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от fagot

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от prizident

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

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от pylin

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

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

mashina ★★★★★
()
Ответ на: Враки. от Camel

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

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

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

bigbit ★★★★★
()
Ответ на: комментарий от bigbit

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

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

anonymous
()
Ответ на: комментарий от anonymous

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

[источник?]

Deleted
()
Ответ на: комментарий от anonymous

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

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

prizident ★★★★★
()
Ответ на: комментарий от anonymous

200 тб на рейд10.

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

> 200 тб на рейд10

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

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

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

rsnapshot забыли

backbone ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.