On Thu, Sep 19, 2002 at 12:18:11PM +0400, Victor Wagner wrote: > > On Thu, Sep 19, 2002 at 11:00:02AM +0400, Victor Wagner wrote: > > > > Я бекаплю всю серверную на ленточку Amanda-ой. > > > > Весьма приятная вещь. Рекомендации лучших собаководов. > > > > В Дебиане есть. Настроек минимум. > > > Вот это-то и хреново. Ситуация из тех, когда лучше два часа потерять, > > > а потом за пять минут долететь. Поэтому решения, которые обеспечивают > > > максимальную гибкость в настройке > > А мне не шашечки, мне ехать. Я оказывался пару раз в ситуации когда у > А мне - тоже ехать. Да так, чтобы не разориться на бензине, не слишком > медленно, и чтобы само везло.
Словоблудие. > > меня летели винты. Восстановление было максимально коротким: > > Выяснили какие ленточки понадобятся для восстановления слайса: > > # /usr/sbin/amadmin DailySet1 info mail ad0s1a > > Сливаем этот слайс с ленточек в файл. > > # /usr/sbin/amrestore -p /dev/nst0 mail ad0s1a >/root/kusok > > # cd /tmp > > Затем распаковываем файл в иерархию директорий, или сразу тем же > > amrestore, заливаем его на новый винт. В этом случае последний две > > команды лишние. льем просто >/dev/ad0s1a > > # restore -rf /root/kusok > Что-то сложно. Во-первых, непонятно как в /root этот самый kusok > уместился. Как это вообще на нормальной машине может на диске найтись > место, куда можно сложить архив цельной файловой системы (если, конечно, > это не /) Виктор, ну от тебя я не ожидал:) Не нравится руут, складывай в другой место, да хоть сразу на новый винт лей, хоть через пайп на ресторе кидай. Шо нэясно? В чем проблемы? Упрямство? > во-вторых у меня это делается так: > mt fsf `grep -n 'feast.*:/var$' /etc/backup/filesystems|cut -d : -f 1` > rsh feast restore -rf party:/dev/nst0 > что по-моему, несколько короче, и, главное, удобозапоминаемее. > Поскольку основное место в данных двух командах занимают стандантные > grep и cut, которые помнить не надо - и так в пальцах сидят. А ежели на > сисадмина совсем затмение найдет, можно этот файлик less-ом открыть и > пальчиком строчки посчитать. Это мало чем отличается от моего варианта... У меня тоже одна строка, или дописать к restore ключики извлечения _конкретного_ файла? Я просто выше показывал строку восстановления _всей_ файловой системы, на полетевшем винте. Так что равнозначно. Да кстати, ты не рассмотрел случай, наличия _нескольких_ ленточек и разноуровневого бэкапа. В твоей строке принимается как данное, что ты в голове держишь на какой леточке бэкап чего и какого уровня лежит и эту ленточку ты уже вставил в тайп. Этим как раз занимается моя первая строка. > А самое главное - точно такая же схема применима в случае, когда > прибегает девочка секретарша и говорит "ой, я тут важный-важный файл > убила, как называется - не помню". Только restore надо с ключиком -i > запускать. Не спорю. Применима. > Я не пытаюсь доказать, что аманда плоха. Правда, почему-то каждый раз > когда мне требуется внести изменения в схему бэкапа, потому что старая > перестала по каким-то причинам устраивать, и начинает рассматриваться > вопрос, а не перейти ли на аманду, прибегает злобный старик Оккам, > размахивая огромной бритвой, и аманду отсекает нахрен. Шелловский Ну что я могу сказать, личные предпочтения, - не преступление. Но в данном случае по функциональности аманда меня вполне устраивает. Она тоже складывает dump-ом, файловые системы или директории tar-ом, на ленточку в несколько записей. Далее наши пути одинаковы: в случае проблем, есть сбэкапленная иерархия файлов/директорий, и тут уж у кого насколько ума хватит над этим поизвращаться во всех направлениях в процессе восстановления. Что аманда делает из полезного, этого сама ведет журнал что куда и какого уровня сбэкаплено. Уж этот велосипед заново писать я не хотел бы. А во всем остальном, она полностью аналогична твоим вариантам. Разве не так? Хорошо, поставим вопрос по-другому... если ты найдешь, то нечто, что аманда не сможет сделать ибо не может, а вот ты с помощью tar+dump это сделаешь, и я скажу да "Реально на аманде я такого не сделаю", то я прекращаю спор. И говорю "Ты прав". Пока что, твои аргументы неубедительны. Мне есть чем заниматься кроме как изобретать велосипед. > скриптик из 10 строк, который читает упомянутый файлик со списком > файловых систем проще и не требует специальных усилий на освоение и > понимание - любой новичок-сисадмин, пришедший в контору, его один раз > прочитает и все поймет. Если он, конечно шелл знает. А такого, который > не знает, я в кандидаты на сисадмина не возьму. Я знаю шел, ну и что? Я обожаю писать на bash+cut+grep+awk+sed итд. Ну и что? О чем спор? Я не хочу засорять Дебиан самосбором, тем более таких задач которые уже реализованы и реализованы неплохо. Почему бы тебе не написать mutt или rtin на баше, свой, зачем пользоваться тем что уже написано? > > Мне большей гибкости не надо. > > Вопросы для самопроверки: > > 1. Какие порты надо открыть на файрволлах, чтобы машина с ленточкой > и клиент могли при помощи аманды общаться (вот тебе и ненулевая > конфигурация клиента) В данном случае, все машины в трастед нетворк. Файрволл только снаружи. В случае возникновения такой потребности, на циске моим машинам разрешено посылать TCP с SYN, наружу и определенным машинам. То же касается и прохождения пакетов снаружи, вовнутрь. Это не проблема. Тоже самое придется сделать в любом случае, при коммуникациях через файрволл, даже для твоей поделки общающейся через ssh. Или ssh уже правилам не подчиняется? Так что насчет файрволла мимо. > 2. Если у нас имеется девочка-секретарша, уходящая из офиса последней, > у которой шелла на машине с > ленточкой нет, но кассету в стример она втыкать умеет, какие понадобятся > усилия чтобы научить ее перед уходом запускать бэкап? Эээ... это подробней... я не понял вопроса... Ленточку втыкаю я, часов так в 16 дня, когда ко мне приходит письмо с результатами проверки готовности системы к ночному бэкапу. Рассказывает, та ли ленточка, что ожидалась, стоит в драйве, если нет, то говорит номер какой оно ожидает увидеть. В том числе доступны ли все хосты, которые необходимо беэкапить, есть ли место для предварительного складывания переливаемых кусков (сам определяешь размер этого места, можно вообще его не давать, в этом случае лить будет прямо на драйв). > 3. Если рабочие часы ненормированные, и мы не можем быть > уверенными что в тот момент, когда крону захотелось сделать бэкап, > мне не захотелось вставить в стриммер какую-то ценную кассету и почитать > ее, какие усилия понадобится предпринять мне (имеющему шелл на данной > машине, но не факт, что имеющему там рута) чтобы не дать аманде > перезаписать ценную ленту. То есть бэкап в час ночи ты запускаешь сам _лично_? Не по крону? В моем случае все проще. Я имею рута на всех серверах. Насчет же перезаписи бэкапа, ты немножко не в ту степь:) amanda как раз проверяет куда она пишет... и если лента не та, что ожидалась, бэкап обломится с сообщением о том что expected лента номер такой-то, а вместо этого номер такой-то, или вообще немаркированная лента, то есть не принадлежащая аманде. Все ленты включенные в кольцо бэкапа аманды, обязательно проходят amlabel, ленте присваивается номер, и в начало ленты записывается идентицикационная метка. Так что даже если наклейки с кассет посрывать или уничтожить, ленту все равно можно идентифицировать. А вот каким образом твой скрипт проверяет какую ленту ему подсунули, я не знаю:) Возможно никак не проверяет... Так что, это мимо. > 4, Если у меня накрылась партиция на машине с ленточкой, причем как раз > та, где лежат всяческие логи бэкапной системы, то как я узнаю, с какой > ленточки мне восстанавливаться и какой файлик с нее читать? > /etc/backup/filesystems у меня распечатан посредством > a2ps --line-numbers=1 и на стенку над машиной с ленточкой повешен. Бэкапная, машина тоже бэкапится:) На ту же ленточку... Рассказывать как на соседней машине подключить драйв и слить список? Или ты вообще каждой машине дал по ленточке и никакого кольца? никаких уровней? Если так, то еще раз повторю - не ожидал от тебя такого:) В случае концептуально правильного бэкапа, с применением кольца и уровней, никакого _статического_ списка лента=машина, быть в природе не может. Разве что твой скрипт просто по окончании бэкапа на принтер каждые сутки кидает бумажку... ну так что? я тоже так могу сделать. > > Что еще нужно? > > По-моему задача бэкапа настолько тривиальна, что особо извращаться не > > стоит. > А по-моему - нет. Поскольку есть куча привходящих обстоятельств, > зависящих от организации бизнес-процессов в конторе, и далеко не все из > них учтены авторами аманды. Ее все равно придется скриптами обвешивать. Я же спросил, _конкретные_ пример? Я не вижу _ни_одной_ ситуации в которой бы аманда не вырулила. > > Вопрос: рулить библиотекой на 4-ре драйва DLT, и 6 контейнеров по 10 > > ленточек в каждом, тоже будем с помощью tar+gzip+mt? > > Можно. Не проще ли взять соответствующие решения Sun-а или HP? > А не факт. Надо внимательно посмотреть и подумать. Планирование бэкапа > это задача, которая однозначного решения не имеет. Потому что > планируется оно один раз, делается каждый день (и должно быть > спланировано так, чтобы делать его правильно было удобно, а "правильно" > - у каждого свое), а используется редко, но в обстановке крайней спешки. :) Тьфу:) Задача бэкапа складывается из нескольких этапов: 1 подготовка клиента, если необходимо. Это например дать команду ораклу о начале горячего бэкапа или сделать флаш для каких либо пишущих процессов. Ну смысл понятен. 2 Собственно сам процесс сборки и упаковки необходимых данных, пересылка на центральный хост. 3 Здесь вступает система менеджмента бэкапными кусками. В случае с лентой, проверка на именно ту ленту что необходима, в случае с библиотекой, смена кассет на необходимые в процессе бэкапа, и в обоих случаях - ведение журнала бэкапа для учета лент. Нетривиальность может вытекать из шибко жутко быстро меняющейся fs которую dump-ом просто не снять. Либо из времени бэкапа, например какая-то машина хочет бэкапиться днем, а ночью загружена работой. Какие еще варианты? > > Я имел в виду со стороны клиента настроек минимум. То что Вы поскипали > > выше:) > А я имел в виду, что мне в общем-то пофигу с какой стороны настройки. > Я настраиваю систему. Рутовый шелл сервера у меня в одном окне, рутовый > шелл клиента - на соседним > А настройки по клиентам наряду с прочим содержимым > /etc можно и rdist-ом али там cvs-ом распространять. Давай к uucp спустимся еще?:) > > Со стороны сервера, как и положено на клиент-серверных приложениях, > > настроек побольше. И продиктованы они самыми реальными потребностями. > > Что из вышеприведенных настроек лишнее? > Ничего. В общем случае. В каждом конкретном - примерно половина. > Например, если у меня бэкап делается когда все уходят из офиса, нафига > мне полосу, занимаемую им, ограничивать? А если твоими же словами про "ненормированный рабочий день"?:)) Ну ты понял... > > Или на написание скриптов их отладку, дописывание, и разнесение их на все > > машины Вы потратите меньше времени? Вряд-ли. > Заметим, что в моей схеме скрипты бывают только на одной машине. На той, > на которой ленточка. А на остальных нужно только иметь сервер > соответствующего транспортного протокола (rsh или ssh) но он там все > равно есть, и dump/restore, которыми, насколько я понял из примера, > аманда все равно пользуется. У мну тоже самое. Вместо ssh стоит amanda-client. Равнозначная замена. > > В данном случае amanda входит в дистрибутив Debian. И по времени > > развертывания системы бэкапа "с нуля", на мой взгляд является > > оптимальным. > Признаюсь честно, данную схему я никогда не разворачивал с нуля. > Она унаследована еще со времен BSDI 2.1. А если учесть что сетка была > и осталась гетерогенной - в ней есть, например солярисы, то время > разворачивания с нуля возрастает существенно. Аманда есть под Солярис. > > А самосбором заниматься не люблю. Политика Дебиана не позволяет... да и > Почему-то мне - позволяет. Цельный репозиторий самосбора на ftp.ice.ru > держу. На вкус и цвет... Я предпочитаю копаться и извращаться в своем домашнике. > > на Slackware, откуда я пришел пару лет назад, этим назанимался под самое > > некуда... > > Самосбор в Дебиане оправдан только для тех решений, для которых нет > > адекватного решения в самом дистре. Или решение есть, но не выполняет > > ожидаемых от него функций. > Вот именно. Но видать у меня ожидания завышены. Я еще не услышал _конкретных_ ожиданий, которые по-твоему не реализует аманда. -- С уважением, Лях Юрий сервисный инженер, V6 tel/fax: +7 (095) 363-0140, http://www.v6.ru
