Видео ролики бесплатно онлайн

Смотреть молоденькие видео

Официальный сайт audiophilesoft 24/7/365

Смотреть видео бесплатно

greybrother 13.05.2012 17:28

Есть вопрос!Автоматическое снятие образа с сервера

Есть сервер. Физический. Сторонней организации, ну пусть называется "клиентский". Т.е. в общем случае о его конфигурации я могу чего-то не знать, админ клиента может что-то изменить, вплоть до полной переустановки (IP известен, даже логины-пароли подходящие они ради дела сообщить согласны). Что-то поломать своими действиями не хочется :)

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

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

Т.е. сейчас это делается так: приходит живой админ (в его и моё рабочее, а значит - и клиентов сервера рабочее, время), гасит сервер, грузит с флешки лив, делает образ (несколько часов), потом перезагружает сервер в штатном режиме. В результате, даже если оставлять делаться образ на ночь, вечер и утро - для работы потеряны.
Подход к вопросу типа "а админу должно быть не влом ехать через город в сервачечную в выходные, чтобы вставить флешку, а потом перезагрузить сервер с рейда" уже существует. Всем не нравится, ибо сильно зависит от лояльности/здоровья/настроения админа и доступа в серверную.

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

Есть желание сделать что-то вроде:
1. В 2:00 АМ субботы сервер сам перегружается на вставленную флешку.
2. На флешке лив-система, которая автоматически делает образ и складывает его на внешний диск.
3. После завершения - сервер перезагружается уже с родного рейда и продолжает штатную работу.
4. При внезапных перезагрузках сервер должен подниматься только с рейда.

Как сделать 2 я примерно представляю, ничего там особо сложного нет, скрипт в загрузку зашить - и всё.

А вот как сделать 1 и 3? В случае, если заранее досконально неизвестно что там на сервере и как настроено? Ну, RHEL5.x как базовая система - гарантирован, а в тонкостях - нет, даже вплоть до того 5.4 или 5.6.

В голову пока приходит только вариант с логином скрипта по ssh с другого сервера по крону. Но.

Записывать-то по идее ничего на диск нельзя, с него потом образ снимать, т.е. бут-раздел не подменить, к примеру. Или, если записывать, надо сделать, чтобы при восстановлении образа всё вернулось обратно, но вообще это выглядит костылями.

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

Подменять конфиг GRUBа? Т.е.
1. Зайти по сш, забекапить рабочий конфиг граба, вписать сервисный, в котором загрузка чётко с флешки, дописать в (куда?) некий скрипт, который подменит обратно сервисный на рабочий, если вдруг во время бекапа "что-то пойдёт не так". Выглядит, особенно последнее, очень уж криво...

2. Как вариант. После загрузки с сервисной флешки, подмонтировать рейд, заменить на нём сервисный конфиг загрузчика на рабочий? Решение самого костыльного момента п.1. Отмонтировать. Снять образ. Перезагрузиться. Вопрос - а если случится что-то, что подмонтировать не удастся? Рабочая система так и зависнет с сервисным конфигом до тех пор, пока это руками не поправится...

Красивее смены бут-девайса в биосе из скрипта что-то ничего в голову не лезет, но я таких средств что-то не нашёл. Если знаете - ткните носом, что-ли? Или я велосипед изобретаю, и в природе это всё уже есть? Серверов вообще три :), звать их HP DL 120/380 G6.

Бррр... Вобщем, сижу, моцк себе ломаю... :)


Тэги:
+ 0 -
Похожие Поделиться

jh 13.05.2012 17:58 #
+ 0 -
жесть.
а такой вариант:
перемонтировать фс только для чтения, сделать образ, перемонтировать обратно.
greybrother 13.05.2012 19:05 #
+ 0 -
Оммм... Там вообще несколько fs на LVM, можно, конечно, пытаться разбираться как они там размещены... Хотелось именно "малой кровью" сам бэкап делать, запустить dd с встроенного на внешний винт - и всё, как уже делается, есть люди, могущие подменить админа при восстановлении бекапа, даже ручками, для обратного dd ума надо меньше, чем для обратного корректного размещения всех фс.
А размонтирование фс на живой системе выглядит, скорее, полной сменой концепции бэкапа :) Впрочем, если умнее ничего не придумается, возможно так и переделаем...
jh 14.05.2012 04:35 #
+ 0 -
еще вариант - сделать initrd, в него прописать скрипт который будет далать образ до монтирования файловых систем, после загружаться нормальном режиме.
uscr 14.05.2012 10:52 #
+ 0 -
LVM же умеет снапшоты? Или я не о том?
Dark_SS 13.05.2012 20:40 #
+ 0 -
Может, поможет "Создание резервной копии корневого раздела в режиме rw".

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

С помощью tar:

# tar --one-file-system -jcf /mnt/another/backup.tar.bzip2 /


Затарит, после чего сожмёт с помощью bzip2.
Аналогичным образом можно сделать бэкап сжатый gzip:

# tar --one-file-system -zcf /mnt/another/backup.tar.gzip /


А можно вообще ничем не сжимать:

# tar --one-file-system -cf /mnt/another/backup.tar /



С помощью fsarchiver:

# fsarchiver savefs -Aaz 9 /mnt/another/backup.fsa /dev/sda1


Получается архив lzma максимального сжатия. Опции "A" и "a" указывают не обращать внимания на то, что раздел смонтирован rw и не использовать Acl и user-xattr. Минус данного способа очевиден: нужно иметь fsarchiver на live cd, если разворачивать бэкап предполагается с него.

С помощью cp
Как ни странно бэкап можно сделать простым копированием:

# cp -ax / /mnt/another/backup


Плюс такого метода очевиден - скорость работы, но бэкап опять же получается не сжатым и будет занимать ценные гигабайты.
-a, --archive
По возможности сохраняет структуру и атрибуты исходных файлов при копировании (но не сохраняет структуру каталогов). Эквивалентно заданию опций -dpPR.
-x, --one-file-system
Пропускать подкаталоги, которые расположены на файловых системах, отличных от той, где начиналось копирование.
Daria 15.05.2012 13:28 #
+ 0 -
это пофайлова, клиент хочет дамп диска.
greybrother 15.05.2012 14:15 #
+ 0 -
Это "пофайлосистемно" по сути. Без бэкапа пустого места на разделе, но без разбора файлов по полезности и без сохранения общей структуры разбиения диска. С учётом LVM'а, который может меняться по живому, после очередного обновления нельзя быть уверенным, что на диске те же (по размеру и назначению) файловые системы, что были перед его запуском, и что растаривание такого бэкапа получится и вообще будет полезным. Т.е. для восстановления нужен живой человек, которому ещё нужно предоставить данные о старой структуре файловых систем, чтобы он проверил, возможно поправил...

Клиент ничего конкретно не хочет :) Просто есть работающий сервер, есть имеющаяся и устраивающая его технически (в том числе проверенная в боевых условиях) система бэкапов. Единственное слабое место - для неё нужен живой человек с допуском к серверу, который должен приехать через стопицот километров, ради только того, чтобы нажать несколько кнопок, и потом, через несколько часов - ещё несколько. У нас же не полноценный коммерческий датацентр, физическую консоль я ему удалённо предоставить не могу. Могу сам вставить флешку и сделать бэкап. Или восстановить. Но это как-бы вариант на "не влом", если я есть в офисе, не болею, не в отпуске. А если им надо сделать бэкап в выходные? Мне что, ехать в серверную чтобы воткнуть флешку в чужой вообще сервер? А его в выходные туда одного вообще не пустят, опять или мне или кому-то ехать. В смысле, я сейчас и езжу. Мне не нравится, админу не нравится, его начальству не нравится оплачивать ему и мне переработки, моему начальству неудобно меня заставлять, если я не могу, или у меня планы, которые отменять ну очень не хочется (и я с ними согласен :) ).

Соответственно, я ищу, скорее, решение для себя. Мне спокойнее, да и с новой задачей разобраться интересно. У клиента есть простой процесс, в котором недоавтоматизировано нажатие на пару кнопок. Если есть дешёвое решение по полной автоматизации - значит достаточно применить его и всё.
dront78 13.05.2012 22:33 #
+ 0 -
например - запускать систему из под kvm и делать снапшоты периодически
cppmm 14.05.2012 08:37 #
+ 1 -
Я понимаю, что задача обрисована в топке довольно подробно, но я всё-равно не понимаю - зачем? Зачем делать дамп файловой системы и сохранять кучу некритичных файлов? Про то, что потом надо быстро разворачивать, говорить не надо, потому что восстановление из такого образа будет длиться дольше, чем установка чистой системы и накатывание необходимых конфигов - dd работает медленне, чем cp. Полное копирование всех разделов справедливо только в одном случае - если вы копиуете их на винт, аналогичный тому, на котором работает сервер на случай, если основной винт загнётся. Тут да, всё понятно - поменял железку и работаем дальше. Но во-первых в тексте промелькнуло магическое слово RAID, так что эту проблему можно(и нужно) решить использованием рейда с зеркалированием.
Собственно, я о чём. Может всё-таки продумать целесообразность таких "бекапов" и убедить клиента сделать по уму, а не молчаливо решать бессмысленную задачу?
greybrother 15.05.2012 10:47 #
+ 0 -
Для полной переустановки системы требуется человек, разбирающийся в системе. Полная переустановка всего на сервере с последующим разворачиванием бэкапов занимает примерно полтора рабочих дня (разворачивание бэкапов - часа четыре).

Образ dd не сможет накатить ну разве что совсем деревянный админ, которому вообще не требуется знать что там внутри. Скорость копирования всё равно будет ограничена, скорее, толщиной канала до стораджа, чем скоростью работы софта.

Рэйд не спасает, потому что это попытка защиты не от повреждения диска, а от сноса системы. Криворукого админа (сотрудника поддержки/разработчика), кривого обновления, багов в самом софте.

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

Под квм разворачивать систему совсем не хочется. Современная виртуализация и так работает довольно дерьмово для low-latency систем, а там ещё три виртуалки внутри крутятся кроме основного сервера. При разворачивании всего этого под ESX работа становится ну очень печальной, сообщения от RealSpeak'а без кровавых слёз невозможно слушать.
cppmm 15.05.2012 11:42 #
+ 0 -
Для полной переустановки системы требуется человек, разбирающийся в системе. Полная переустановка всего на сервере с последующим разворачиванием бэкапов занимает примерно полтора рабочих дня (разворачивание бэкапов - часа четыре).

Здесь время слишком завышено. Установка голой системы - полчаса. Установка недостающего софта - ещё полчаса. Копирование конфигов - 15 минут. Копирование простых данных - зависит от размера, но уж точно быстрее чем заливание целого раздела руками. Разворачивание всяких баз данных и т.д. - тоже зависит от размера, но опять же не сутки. Для примера, у меня на разворачивание их бекапов большого проекта с базой на несколько десятков гигов, почти сотней гигов данных на винте и сопутствующего софта заняло последний раз около тех самых, указанных вами четырёх часов. Когда последний раз мне приходилось восстанавливать сервер бекапом из образов дисков с помощью dd, я проклял всё на свете. Сервер накрылся утром 31-го декабря и новый, тогда 2007-ой год, я встречал на работе...
Но соглашусь, для полной переустановки нужен разбирающийся в системе человек.
Рэйд не спасает, потому что это попытка защиты не от повреждения диска, а от сноса системы. Криворукого админа (сотрудника поддержки/разработчика), кривого обновления, багов в самом софте.

А вот это ключевой момент, я так понимаю. О нём надо было сразу. :)
В таком случае я бы начал думать о разворачивании автоматической системы бекапов, например, с помощью bakula. Возможно, для надёжности понадобится рядом с боевым сервером поставить ещё одну машинку, которая будет заниматься бекапами по сети. bakula среди прочего умеет инкрементные бекапы, так что восстановиться можно будет на нужном моменте до сбоя. Разумеется, к этой машинке у "криворукого админа" доступа быть не должно.
Просто очень уж ненадёжной и долгой выглядит схема с перезагрузками с флешек и снятием dd-образов. К тому же, это лишняя трата места. И при такой схеме придётся хранить несколько последних образов, так как если схема с флешкой будет запускаться автоматически в субботу, а "криворукий админ" поломает что-то в системе в пятницу вечером, последний бекап будет бесполезен.
thoughtful_fox 15.05.2012 11:59 #
+ 0 -
Хех, иногда dd гораздо надежнее) потому что даже пункт "заливание баз данных" может затянуться на ого сколько, софт нужный может быть древним как гавно мамонта, или вообще отсутствовать (и ставился он в течении недели предыдущим админом со всякими костылями (пользуясь случаем, хочу передать привет базе оракл под генту)), а загадочная джава может вообще решить, альтернатива джавы и компилятора не соответствует требуемыми антом или мавеном, и послать к чертям... Так что для критически важных бекапов я предпочел бы оба типа: и dd, и инкрементальные
thoughtful_fox 15.05.2012 11:51 #
+ 0 -
Тут самая умная идея, окромя инкрементальных бекапов, была именно что переносить сервер в виртуалку соответствующую.
Честно, это звучит очень лажово: "У нас архиважный сервер (три) с LVM, RAID и еще виртуалками внутри". Я бы его выключать даже боялся, не то что флешки непонятные вставлять)
Значит, нужно виртуалки держать отдельно, важный софт в виртуалке - тоже отдельно, но я так панимаю, это не от вас зависит...
greybrother 15.05.2012 13:37 #
+ 0 -
"Архиважных" из них один, остальные два просто попадут под раздачу, если для одного всё будет сделано, вернее, на менее важных потренируемся, а потом и на основном запустим процесс. А что LVM и RAID? Слова типа страшные? Кагрица, люби и знай свой земля. Оно работает достаточно стабильно, пока работает. И флешку же не "непонятную" вставляем, сами пекли, чётко понимаем что она делать будет.

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

**** тэкс. конструктивно.

Вобщем, беседы с пристрастием с местными инсайдерами ХП на тему "ну я же жопой чую, что у вас что-то должно быть для удалённого ковыряния в биосе сервера" принесли таки результат. Их есть у них. Только, как обычно, кто бы знал, что эта вот фигня делает именно ЭТО...

hччp://www.hp.com/go/ProLiantSTK
Из него команды reboot и setbootorder похожи на то, чего я хочу. Бум звонить админа тех серверов и им думать, надо будет бэкап-систему сделать на том же рекомендованном редхате, чтобы точно всё работало после перезагрузки с флеша. (интересно, а как отнесётся система к тому, что у неё будет один rebоot "системный", а второй - из SSSTK? куда, интересно, он его вывалит? сюрприз будет...)

Смотреть онлайн бесплатно

Онлайн видео бесплатно


Смотреть русское с разговорами видео

Online video HD

Видео скачать на телефон

Русские фильмы бесплатно

Full HD video online

Смотреть видео онлайн

Смотреть HD видео бесплатно

School смотреть онлайн