forum.lissyara.su

Всем здраствуйте.
Стоит такая задача надо сделать бэкап серверов. Хочу сделать так:
1) Сделать полную копию системы, чтоб если полетит жёсткий диск или ещё какае-то напасть просто слить на другой хдд и не парится. Планировал сиспользовать pax , как я обычно делал когда дублировал системы, но оказалось что на многих серверах просто нет места на хдд , так что выход вижу только один лить сразу по сети на спецально отведённый сервер, не создавая временный образ на жёстком. Вроде rdump и rrestore подходят для этого, но что-то чтение манов меня не сильно просветило

2) Делать например каждые 2 дня бекапы конфигов и пользовательских данных, вроде для этого подходит fsbackup.

Больше всего интересует rdump и rrestore или может возможно на лету поток pax сжимать gzip и заливать по фтп или ссх !?!? С удовольствием расмотрю и другие варианты.

попробуй тар поюзать через rsh. переведенные маны по dump, restore, tar есть у Лиса на сайте

Что-то не получается ...

• tar -cj --exclude "ports/" -f - . | rsh -l zik 172.16.7.70 "cat > usr.tbz"
  172.16.7.70: Connection refused

Мне впринципе всё равно, а можно и по фтп лить или по ссх просто я незнаю будут ли они читать входной поток ...

Ещё не совсем понял как dump сохраняет на удалённом хосте файлы, он использует NFS ? если нет, то как проходит аутинфикация пользавотеля ?

можно и ssh

lissyara писал(а):можно и ssh

А если не секрет, то как ?
Так, а через какой протокол dump работает ?..

по ssh подозреваю, что это scp

Пробывал

lissyara писал(а):tar czvf - dir_name | ssh -c blowfish lissyara@hz.server.name dd of=dir_name.tar.gz

и пробывал

lissyara писал(а):dump -0u -f - dir_name | gzip -2 | ssh -c blowfish lissyara@hz.server.name dd of=dir_name.gz

По времени быстрее получилось, через дамп. Так что мой выбор остаётся на нём Теперь вопросы:
1) Можно как-то ограничить 100 % нагрузку процессора ( обоими способами полностью загрузка была), потому что будет это всё делать на нагруженных серверах и даже ночью нежелательно, чтоб была полная загрузка проца !
2) Сделать, так чтоб при заходе по ссх не спрашивался пароль ? пробывал user:password@machine - всё равно спрашивало

про ssh - либо ключи либо в портах expect ищи.
про нагрузку - поставь двухголовые камни.
т.е. - никак.
можно nice поиграть - но это что мёртвому припарки - в данном случае лекарстов - тока вторая башка.

я по фтп гзипы лью - эффективнее. Правда сетка своя, поэтому за секьюрность нет беспокойства.

а я вот как-то подсел на scp...
очень удобно...

lissyara писал(а):а я вот как-то подсел на scp...
очень удобно...

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

abanamat писал(а):

lissyara писал(а):а я вот как-то подсел на scp...
очень удобно...

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

А такой вопрос , как перенаправить это по фтп ? И что оно меньше будет нагружать проц и по идеи скорость должна увеличится по сети ? или где-то в рассуждениях ошибка )

ну, у меня по scp мегов 10 в секунду льётся.
но и машины не ниже III пня

zik писал(а):

abanamat писал(а):

lissyara писал(а):а я вот как-то подсел на scp...
очень удобно...

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

А такой вопрос , как перенаправить это по фтп ? И что оно меньше будет нагружать проц и по идеи скорость должна увеличится по сети ? или где-то в рассуждениях ошибка )

ну конечно это быстро. но главное - фтп и так на каждой машине имеецо. и не только под фрями. перенаправить? мм.. в баше точно просто. На опеннете поройся - там этот вопрос пару раз в месяц стабильно появляется.

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

ну, инкрементально - не балуюсь, как-то баловался потом собрать из кусков одно не смог
можно сделать mydsqldump на удалйнной машине, а потом дифом сравнить два дампа и удалить совпадающие строки
как изврашённый вариант

я на это напоролся на дампе самого большого раздела сервера. пришлось дамп сливать сразу по сети на соседний сервер.
/sbin/dump -0aun -f - /dev/ad4s3e | ssh user@host dd 0f=path_to/file где
- /dev/ad4s3e раздел дамп которого нам нужен,
user пользователь имеющий возможность зайти по ssh на host,
host это машина на которую мы логинимся по ssh,
-0aun это указание делать полный дамп,
-f делать дамп в файл, а не на стриммер,
dd это утилита копирования и конвертации файлов
of= указывает на необходимость писать в файл, а не в стандартный вывод
/path_to/file соответственно путь к файлу готового дампа на host.
пользуйтесь.

Самая распостранненая ошибка при бекапе...- это НЕ тестирирование процесса восстановления данных.

С бекапом конфигов и данных все понятно...

Но вот прозаическая ситуация, на рейде сэекономили, софтварные мирроры(аля гмиррор) тоже не подняли, сервер увезли далеко(!) и пнули в продакшин.
(На сервере пару винтов)

Собственно постановка задачи:
1) чем пациенту можно помоч?
Из расчета на ситуацию, что в один прекрасный(очень!) день, отваливается раздел основного винта, или сам винт..

PS. без шуток Вопрос вполне реальный, причем это живая ситуация. На текущий момент там рсинком зеркалируются конфиги и данные пользователей на другой винт.
В качестве варианта секондари винт, конечно, можно разбить, и удаленно сделать dump\restore, тогда в случае выхода из строя первого винта, можно будет попросить сапорт выбрать при загрузке другой винт. И ,может быть,(!) все даже будет ок Но слишком костыльный вариант... Творчество эксперементов, к сожаленью, ограничено тем что серв далеко и продакшин.

втрой винт в зеркало.
чё сложного-то?

У нас на один сервер даже что-то через mount_smbfs даже бэкапится...БД 1С (сервер под 1С на w2k3)