LINUX.ORG.RU

Нужен бэкап системы на soft-raid + lvm: клон, снэпшоты?

 , , ,


3

3

Привет всем!

Люди добрые подскажите как решить задачку. Имеется в сети важный компьютер, даже можно сказать сервер, который и связь держит на 2 направления, и пакеты роутит и локальную сеть обеспечивает DNS'ом, DHCP, жабером, проксей, файлпомойкой (самба3) и кое-чем еще. Он является по сути дела слабым звеном, при потере которого вся работа встанет и это плохо. Кое что конечно сделано: мощный ИБП (компьютер автовыключается через 10 минут отсутствия электричества), Soft Raid 1го уровня из двух терабайтных дисков WD RE, поверх массива 3 тома lvm (/boot, swap, /). Debian Stable.

Хотелось бы каким либо образом, желательно «на горячую», не выключая компьютер сделать полную копию системы. Если система упадет, то пользовательские данные с файлпомойки можно взять из бэкапа, а вот саму систему придется ставить и настраивать. А быстро это не получится (тот же ldap + samba с пользователями в нем). И поэтому было бы неплохо в таком случае иметь пусть даже месячной давности копию рабочей системы (клон диска) в виде 3го диска, который просто нужно воткнуть в новый корпус. На нем также должен быть raid + lvm, чтобы банально добавить в raid 2й диск-зеркало и работать дальше. То есть нужно сделать полную копию.

Пока у меня 2 мысли: клонировать диски с использованием mdadm, пример: 1) Выключаем работающий компьютер с рэйдом (диски А, Б). 2) Вынимаем диск Б, вставляем диск С, на который нужно скопировать систему. 3) Включаем комп, собираем массив, дожидаемся ребилда. 4) Выключаем комп, достаем наш диск С (диск под копию). 5) Вставляем вынятый ранее диск Б, включаем компьютер. 6) И тут теоретический вопрос. Как mdadm определит, какой из двух дисков правильный? Диск А, который содержит уже более новые файлы или диск Б, который был достан первым? Информация будет взята из суперблока каждого диска? Кроме того такая схема требует физического выключения компьютера и похода до него с дисками, монитором и клавиатурой (а если раз в месц это делать - ужас). Незнаю можно ли в mdadm просто отзеркалить 3й диск и выдернуть его из массива, не помечая как сбойный, чтобы потом вставить диск в другой комп и он заработал. Такое возможно? Но опять же тут нужно открывать корпус и дергать диски.

Второй вариант более «горячий». Это lvm-снэпшоты. К примеру на диске, который будет клоном можно создать такую же разметку raid autodetect, импортировать на него схему разметки томов lvm и приступить к снятию снэпшотов скажем раз в месяц удаленно. Под файлы снэпшотов в комп можно на ПМЖ вставить какой нибудь 500Гиговый диск. Сделать первый снэпшот, скопировать на диск-клон, поставить загрузчик. А потом раз в месяц просто обновлять диск-клон на всякий пожарный случай. Однако с снэпшотами мне не совсем все понятно. Так как снэпшот - это по сути снимок, а мне нужно сделать снимок работающей системы, то такой снимок будет логически неверен. Как минимум в снимке не нужны файлы блокировок работающих процессов. Нужно отключать сервисы? Но ведь все процессы не отключишь. В общем получается, что в идеале это должен быть снимок системы с выключенного диска, но желательно наоборот. И тут противоречие. Кто-либо успешно делал снимок с работающей на lvm системы и восстанавливал его?

В общем простите за долгое описание, но честно говоря пока не уверен как же все таки периодически клонировать всю систему полностью, надежно, но как можно быстрее, без дергания дисков в корпусе, а то ведь и уронить можно ненароком. =)


А если банально tar с тщательно выбранными --exclude вроде /run, /var/run, /var/lock/, /tmp и т.п.?

AITap ★★★★★ ()

А что мешает тупо через сеть по dd слать винч на другой сервер? :)
Теме же самыми bacula и rsync если делать - фактически та же ОС, только без установленного груба на винче.

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

А что мешает тупо через сеть по dd слать винч на другой сервер? :)

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

Я за затаривание.

anonymous ()

С dd конечно вообще не вариант, боюсь слишком жирно + может вылезти куча побочных эффектов. С bacula не сталкивался вообще ни разу, как честно говоря и с rsync. Насчет затаривания - можно попробовать, но предварительно все таки нужно снять полную копию с рабочего винта, то есть выключить комп и сделать клон скажем тем же dd (но это будет ппц долго). А потом уже периодически затаривать и распаковывать с заменой файлов на диске-клоне.

Но все таки интересно, реально вообще сделать это снэпшотом? И насчет mdadm просто очень интерсно какой из дисков он сделает «рабочим» при вышеописанной схеме клонирования?

gard ()

во время наименьшего IO делаешь снапшот, таришь с --exclude`ами
далее, сервисы уже backup со своей спицификой, ldap можно реплицировать, samba - rsync проходить, /etc загоняешь в git

в случае чего у тебя есть: полный архив с ОС, данные сервисов в удобном виде, конфиги в git и душевное спокойствие )

uspen ★★★★★ ()

Вариант с RAID'ом можно сократить до одного шага: просто одним действием вынимаешь диск Б и ставишь диск С. Диск С синхронизируется и работает дальше, диск Б кладешь на полку. При необходимости обновляешь загрузчик.
Через нужный промежуток времени повторяешь операцию, какой диск менять на этот раз - выбираешь сам.

Как mdadm определит, какой из двух дисков правильный? Диск А, который содержит уже более новые файлы или диск Б, который был достан первым?

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

Как минимум в снимке не нужны файлы блокировок работающих процессов.

Обычно они лежат где-нибудь в /run, который в tmpfs, так что на диске их нет. А даже если будут - нормально сделанный сервис обычно такое спокойно переваривает. Иначе машинка бы при внезапном ребуте (сбой питания или уборщица шваброй на reset нажала) ничего бы не могло подняться.

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

с тщательно выбранными --exclude вроде /run, /var/run, /var/lock/, /tmp и т.п.?

Можно ведь проще: # tar c --one-file-system / | bla

Ведь

/var/run -> /run
/run, /var/lock, /dev -> tmpfs
/tmp особо роли не играет и чистится при загрузке

и так далее. При некоторых условиях даже снапшоты делать не обязательно.

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

Вариант с RAID'ом можно сократить до одного шага: просто одним действием вынимаешь диск Б и ставишь диск С. Диск С синхронизируется и работает дальше, диск Б кладешь на полку. При необходимости обновляешь загрузчик. Через нужный промежуток времени повторяешь операцию, какой диск менять на этот раз - выбираешь сам.

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

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

А даже если будут - нормально сделанный сервис обычно такое спокойно переваривает. Иначе машинка бы при внезапном ребуте (сбой питания или уборщица шваброй на reset нажала) ничего бы не могло подняться.

Хм, а ведь точно. В принципе ситуация снятия снэпшота целиком получается навроде включения после непредвиденного отключения по питанию. =)

gard ()

Rsnapshot или простой rsync на другой комп?

xorik ★★★★★ ()

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

MikeDM ★★★★★ ()
Последнее исправление: MikeDM (всего исправлений: 1)

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

1) Уменьшаю размер ФС под / скажем на 110Гб 2) Уменьшаю размер lvm-тома под / на 100Гб 3) Растягиваю размер ФС до фактического размера lvm-тома под / 4) В освободившемся месте группы томов lvm можно создавать снэпшот в 100Гб (этого думаю на время запуска бэкапа rsync'ом или tar'ом хватит, чтобы временно хранить изменяющиеся данные).

Вот такая вот схема нарисовалась. Потом, как посоветовал YAR сделать копию диска с помощью raid и уже затем время от времени обновлять ее с помощью снэпшотов и бэкапа с них.

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

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

gard ()

А нет, не буду вводить в заблеждение тех, кто может прочитать. Снэпшот делается в той же vg, а она содержит в себе определенные pv. Так что оно небезопасно. Если vg с raid растянуть на новый pv, то там же могут оказаться и важные данные, тогда и raid не поможет в случае выхода из строя одиночного нового pv. Ну как то так. Придется таки умеьшать раздел, займусь через часик как рабочий день закончится.

gard ()

вы себя сами запутали похоже :) описанные задачи абсолютно стандартные, а в таком деле творческий подход не рулит вообще, только опыт, написанный кровью поколений админов с помощью mdadm можно (в онлайне, не мешая работать системе) добавить к зеркалу 3-й винт, примерно такой командой: mdadm --grow /dev/md11 --raid-devices=3 --add /dev/устройство после этого смотрим файлик /proc/mdstat - там будет обновляться инфа по синхронизации - сколько времени осталось (если система не адово перегружена - то при локальном подключении такого же диска где-то в 2-2.5 часа должно уложиться. скорость регулируется записями значений в файлики /sys/block/md11/md/sync_speed_max,sync_speed_min и др. дальше, когда копия готова и хочется ее унести в надежное место, делается так. диск надо пофейлить и убрать из массива (mdadm /dev/md11 -f /dev/... -r /dev/...). рейд продолжит работать, будет называться degraded, но при данной конфигурации это пофиг. из нового диска надо собрать рейд-1 и запустить в degraded режиме, примерно так: mdadm --create /dev/md/new_name -l1 -n2 -R -e1 --force /dev/диск missing дальше завести его на отдельной vg: vgcreate newvg /dev/диск;vgchange -ay получатся 3 lv, по ним надо прогнать fsck, замаунтить, визуально оценить - похоже ли и что надо удалить/поправить (в основном проверить конфиг загрузчика, fstab, mdadm.conf/lvm.conf, в таком духе). дальше аккуратно все отмаунтить, винт вынуть и можно увозить.

а дальше по сети уже не проблема досылать изменения с помощью rsync/tar/cpio/dump/cpdup/lftp - кому что нравится. я б вообще не парился и cpdup'ом по сети с самого начала копировал.

а lvm-снапшоты лучше на досуге поизучать потом, там много интересного последнее время наворотили

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

А я вчера как раз таки уменьшил размер ФС и lv-тома под корневой раздел, освободив место под снимки. Сейчас вот пересобирается как раз raid. Сейчас соберется, потом уже буду думать насчет 3го диска. Беда в том, что после моего ухода вчера примерно через час массив собрался до 48%, что-то вызвало ошибку чтения диска и он остановился, оставив 1 диск активным, второй - запасным. Сижу, жду ребилда.

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

Спасибо всем за советы, решил все таки делать затариванием примерно по следующей схеме: 1) 1го числа каждого месяца создается полный бэкап 2) каждое вс недели, кроме 1го числа создается недельный бэкап 3) каждый день, кроме 1го числа и вс создается дневной бэкап

Все это делается с использованием --listed-incremental опции tar. На случай восстановления нужно будет поочередно развернуть месячный, недельный и дневной бэкап.

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

Насчет клонирования 3го диска пока думаю, попробую не использовать ребилд mdadm, а сделать экспорт-импорт структуры lvm, а дальше уже распаковать на него последние бэкапы. Если не выйдет - буду зеркалить с помощью mdadm. Пусть лежит, на всякий пожарный. Если кому-то нужен код моих корявых скриптов - могу скинуть сюда. =)

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

Конечно можно, но только сейчас прочел ваше сообщение :(. Если надо - напишу.

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