Бекап в Xen4

[cabeza]

«которая явлеяется примонторированным хранилищем»

Что-то тут надо исправить)

[felvis]

:) спасибо, уже поправил

[br0ziliy]

Подтверждаю — в продакшене работает без проблем и танцев. Главное — бэкапное хранилище побольше.

[Masterkey]

создание слепка делаете на нагруженной системе или в момент нулевой нагрузки?
как-то давно слышал, что создание слепка на системе под нагрузкой могло привести к краху.

[felvis]

на старом Xen был неприятный опыт — процесс dd уходил в D mode, естественно только ребут помогал. виртуальки при этом не страдали.
я выбрал время максимально разгруженное субботу, утро(в примере ночь стоит)
когда никого в офисе нет и удаленные сервисы не используются почти из-за разницы часовых зон у клиентов

[Igg]

Утро субботы и воскресенья — наше все)

[opium]

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

[felvis]

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

[drunken]

Замечательно. Автор делает снапшот Windows 2003 c MSSQL, не стопая ни тот, ни другой.
Скажите, вы проверяете работоспособность каждого снапшота после такого, или просто складируете на авось?

[felvis]

:) пример имени был взят наобум.
виртуалки БД не участвуют в бекапе в принципе, все бекапы с нее сливаются штатными методами. но это тема не этой статьи )

[rambominator]

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

virsh save test
cp test.dump /backup/
lvcreate -L20G -s -n test-s /dev/vg/test
virsh restore test
dd if=/dev/vg/test-s of=/backup/test.dd bs=1M
lvremove /dev/vg/test-s

Ну и да lvm snapshot не является средством для бэкапа бд.

[fakedream]

Ну вообще, lvm snapshot очень даже является вредством для бекапа БД. И очень распространенным, т.к. не создает оверхед на сервер, и довольно быстрый. Только бд неплохо предварительно подготовить для этого :)
А так да, соглаен, если так, то такой бекап работает как ресет.

[rambominator]

На подготовленной бд можно и таром файлы забэкапить.

[fakedream]

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

[rambominator]

Если под заморозить имеется ввиду xfs freeze, то это не многим лучше простого снапшота на рабочей бд.

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

[fakedream]

нет, безусловно я не имел в виду xfs freeze. я имел в виду заморозить операции любым доступным для той или иной бд способом, вплоть до остановки инстанса (если это слейв реплика), затем снятие снапшота и далее «размораживание» операций :) собственно плюс в данном случае снапшота в том, что мы тратим время только на заморозку/разморозку. а в время копирования таром или другим подобным инструментом бд работает в штатном режиме.

[felvis]

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

[drunken]

lvm snapshot даже для обычной файловой системы под нагрузкой вызывает вопросы, не говоря уже о дампах баз данных. Отложенная запись улетает в никуда, записи теряются, журнал не пишется.
Грош цена таким бакапам.
rambominator, так тоже можно делать, но тогда дамп памяти жестко связан с дампом диска. Лучше все-же стопать сервисы, делать дамп и запускать обратно :)

[felvis]

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

[sply]

Если нужен чистый бэкап без отдельного дампа машины, можно сделать сплит виртуальной машины одновременно с снэпшотом диска — оригинальная машина продолжает работать, вторая виртуальная машина с снэпшотом штатно шатдаунится.

[sply]

Но стандартно через xend/xm подмена бэкендов на лету невозможна, нужно самостоятельно писать обертку. Кажется, в XCP был contributed инструмент, но не уверен.

[equand]

Несколько раз замечал глюки снапшоттинга на KVM например.
Системы «откатывались» к моменту начала снапшоттинга.
Так ставишь обновление, закачиваешь данные и хоп все на полчаса назад…

[felvis]

завтра проверю с xen, но вроде такого не было

[equand]

Происходило при активном пользовании VNC к системам. На FreeBSD делалась компиляция ядра и обновление мира (а также пару десятков пакетов поставили), все смыло.
На Linux просто настраивались сетевые данные, после бекапа даже по времени откат был (приходилось npdateить)

[antosha]

А что по скорости работы с жестким диском в этот момент? Случалось сталкиваться с таким, что во время работы со снапшотом LVM скорость записи/чтения с диска существенно падала.

Также, насколько помню, компания r1soft.com предлагает коммерческие решения для бэкапа виртуальных машин на базе xen.

[cvss]

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

[felvis]

точно.
я там выше отписывался
>я выбрал время максимально разгруженное субботу, утро(в примере ночь стоит)
когда никого в офисе нет и удаленные сервисы не используются почти из-за разницы часовых зон у клиентов. и снепшот автоматически удаляется после копирования.