On 2002.09.19 at 14:54:04 +0400, Yury Lyakh wrote: > > Ну что я могу сказать, личные предпочтения, - не преступление.
> Но в данном случае по функциональности аманда меня вполне устраивает. В это я вполне верю. Я в данном случае настаиваю на том, что ты не привел НИ ОДНОГО аргумента в пользу того, что она делает что-то что не делается с теми же или меньшими усилиями с помощью стандартных textutils и cron. А соответственно злобный старика Оккам со своей бритвой тут как тут. > Что аманда делает из полезного, этого сама ведет журнал что куда и > какого уровня сбэкаплено. Уж этот велосипед заново писать я не хотел бы. А вот я считаю, что этот журнал ни в коем случае нельзя держать в файлах. Он должен писаться от руки на бумажке. Чтобы в случае полного физического разрушения дисков он оставался незамедлительно доступен. > > скриптик из 10 строк, который читает упомянутый файлик со списком > > файловых систем проще и не требует специальных усилий на освоение и > > понимание - любой новичок-сисадмин, пришедший в контору, его один раз > > прочитает и все поймет. Если он, конечно шелл знает. А такого, который > > не знает, я в кандидаты на сисадмина не возьму. > > Я знаю шел, ну и что? Я обожаю писать на bash+cut+grep+awk+sed итд. Ну и > что? О чем спор? > Я не хочу засорять Дебиан самосбором, тем более таких задач которые уже А я не хочу засорять свою голову знаниями новых форматов конфигов. Мой скриптик, который делает бэкап соизмерим по размеру с конфигом амандовского сервера. > реализованы и реализованы неплохо. Почему бы тебе не написать mutt или > rtin на баше, свой, зачем пользоваться тем что уже написано? Кстати, мы с Артемом Чуприной периодически обсуждаем вопрос о написании модульной ньюсочиталки. Модули которой можно будет интегрировать разными способами посредством shell, Tcl/Tk или чего там в голову взбредет. доступ к спулу - отдельной утилитой, тредилку отдельной и так далее. > > 1. Какие порты надо открыть на файрволлах, чтобы машина с ленточкой > > и клиент могли при помощи аманды общаться (вот тебе и ненулевая > > конфигурация клиента) > В данном случае, все машины в трастед нетворк. Файрволл только снаружи. > В случае возникновения такой потребности, на циске моим машинам > разрешено посылать TCP с SYN, наружу и определенным машинам. То же > касается и прохождения пакетов снаружи, вовнутрь. Это не проблема. > Тоже самое придется сделать в любом случае, при коммуникациях через > файрволл, даже для твоей поделки общающейся через ssh. Или ssh уже > правилам не подчиняется? Как правило, существует десять тысяч других причин чтобы ssh туда пускали. Чем, собственно и велик старик Оккам. Если ты не умножаешь сущностей без необходимости, то количество вещей, которые ты должен не забыть заметно меньше. НЕОБХОДИМОСТЬ использования такой системы как аманда ты не продемонстрировал. > > ленточкой нет, но кассету в стример она втыкать умеет, какие понадобятся > > усилия чтобы научить ее перед уходом запускать бэкап? > > Эээ... это подробней... я не понял вопроса... > Ленточку втыкаю я, часов так в 16 дня, когда ко мне приходит письмо с > результатами проверки готовности системы к ночному бэкапу. Вот у нас система устроена немножко по-другому: Ленточка втыкается непосредственно перед началом бэкапа, после чего дергается за ручку, что пора начинать. Причем ручка устроена так, что дернуть за нее можно и с виндовой машине по самбе. В этот же момент фиксируется на той самой бумажке какую кассету воткнули, и когда. Производится эта операция последним человеком, уходящим из офиса. Наряду с другими операциями, такими как выключение кондиционеров и света. Таким образом гарантируется а) что активность на файловых системах, которые бэкапятся - минимальна (что не всегда можно гаратировать при запуске бэкапа по cron) б) промежуток времени между попаданием результатов дневной работы в CVS и их попаданием на ленточку - минимален. > > То есть бэкап в час ночи ты запускаешь сам _лично_? Не по крону? В моем > случае все проще. Я имею рута на всех серверах. Я тоже имею. Но не пользуюсь по возможности. И главное, я могу себе представить у себя в конторе сотрудника, который имеет право читать с ленты, но не имеет рута. > Насчет же перезаписи бэкапа, ты немножко не в ту степь:) > amanda как раз проверяет куда она пишет... и если лента не та, что > ожидалась, бэкап обломится с сообщением о том что expected лента номер Ну правильно - в 16:00 кассетку перепутали, бэкап в час ночи обломился, в три часа ночи на провода высоковольтки упало дерево, и в десять часов утра у тебя нету ни дисков, ни вчерашнего бэкапа. Все-таки стартовать бэкап в присутствии человека, даже если это девочка-секретарша, которая ничего сделать не может, кроме как позвонить админу на мобильник и сказать "ой тут что-то страшное случилось, не пойму что" чем-то надежнее. > такой-то, а вместо этого номер такой-то, или вообще немаркированная > лента, то есть не принадлежащая аманде. > > Все ленты включенные в кольцо бэкапа аманды, обязательно проходят > amlabel, ленте присваивается номер, и в начало ленты записывается > идентицикационная метка. Так что даже если наклейки с кассет посрывать > или уничтожить, ленту все равно можно идентифицировать. Вообще говоря, это тоже лишняя сущность. restore -i и команда what все замечательно расскажут. > > Или ты вообще каждой машине дал по ленточке и никакого кольца? никаких > уровней? Если так, то еще раз повторю - не ожидал от тебя такого:) Кольца есть, а уровней нету. С уровнями неудобно отдельные файлики восстанавливать. Вот грохнули файлик, даты изменения которого никто не помнит - то-ли вчера, то-ли в прошлый четверг. На какой ленте его искать? А если бэкап всегда делается полный, тупо втыкаешь последнюю ленту и с нее восстанавливаешь. Хотя, согласен, именно эту задачу аманда со своими логами решает. Она не решает другую - уровни осмыслены только тогда, когда низкие уровни занимают более одной кассеты. А это значит, что присутсвие человека при беэкапе низкого уровня необходимо в течении n/n+1 его времени, а не только в момент начала. Если же полный бэкап влезает на кассету, то уровни попадают под бритву злого старика. > Задача бэкапа складывается из нескольких этапов: > > 1 подготовка клиента, если необходимо. Это например дать команду ораклу о > начале горячего бэкапа или сделать флаш для каких либо пишущих > процессов. Ну смысл понятен. > > 2 Собственно сам процесс сборки и упаковки необходимых данных, пересылка > на центральный хост. > > 3 Здесь вступает система менеджмента бэкапными кусками. В случае с > лентой, проверка на именно ту ленту что необходима, в случае с > библиотекой, смена кассет на необходимые в процессе бэкапа, и в обоих > случаях - ведение журнала бэкапа для учета лент. > Ни разу. Задача организации бэкапа начинается с определения частоты с которой копируются те или иные данные, и места где хранятся копии (например, аренды сейфа в банке) А также процедуры добывания их из оного места в любое время дня и ночи. Регламент выполнения собственно резервного копирования - очень небольшая часть задачи в целом. Причем 90% этого регламента опять же не имеет отношения к задачам, которые можно решить с помощью аманды. А после этого идет регламент восстановления, тренировка персонала на выполнение этого регламента, и регламент регулярной верификации копий. Чтобы быть уверенным что ленточка с бэкапом 0-го уровня (если уровни есть) не протухла. > Давай к uucp спустимся еще?:) Кстати, я uucp активно использую. Не с целью резеревного копирования, но все же. > > У мну тоже самое. Вместо ssh стоит amanda-client. Равнозначная замена. Наверняка не вместо, а вместе. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
