Pull to refresh

Comments 27

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

Что-то тут надо исправить)
:) спасибо, уже поправил
Подтверждаю — в продакшене работает без проблем и танцев. Главное — бэкапное хранилище побольше.
создание слепка делаете на нагруженной системе или в момент нулевой нагрузки?
как-то давно слышал, что создание слепка на системе под нагрузкой могло привести к краху.
на старом Xen был неприятный опыт — процесс dd уходил в D mode, естественно только ребут помогал. виртуальки при этом не страдали.
я выбрал время максимально разгруженное субботу, утро(в примере ночь стоит)
когда никого в офисе нет и удаленные сервисы не используются почти из-за разницы часовых зон у клиентов
Утро субботы и воскресенья — наше все)
Если виртуалки ваши, а не клиентов проще делать бекап какой нибудь системой внутри гостевой системой, например той же бакулой.
В случае краха разворачиваю эталонную виртуалку и заливаю бекап с бакулы.
Возможность бекапа виртуалок с лвма не живая, если разделы большие и надо иметь большое количество бекапов во времени. То есть скажем ежедневные за полгода.
да, многие виртуалки имеют внутреннию систему бекапов на основе именно бакулы.
но все же полезней иметь слепок всех систем, например чтобы только обновить конфиги, а не сетапить все занова.
Замечательно. Автор делает снапшот Windows 2003 c MSSQL, не стопая ни тот, ни другой.
Скажите, вы проверяете работоспособность каждого снапшота после такого, или просто складируете на авось?
:) пример имени был взят наобум.
виртуалки БД не участвуют в бекапе в принципе, все бекапы с нее сливаются штатными методами. но это тема не этой статьи )

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

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 не является средством для бэкапа бд.
Ну вообще, lvm snapshot очень даже является вредством для бекапа БД. И очень распространенным, т.к. не создает оверхед на сервер, и довольно быстрый. Только бд неплохо предварительно подготовить для этого :)
А так да, соглаен, если так, то такой бекап работает как ресет.
На подготовленной бд можно и таром файлы забэкапить.
ну дык тар уже после снапшота :) ну как бы со снапшотом просто это все быстрее, остановил базу на слейве например, или заморозил, снял снапшот, отпустил базу. и не надо ждать когда закончится бекап.
Если под заморозить имеется ввиду xfs freeze, то это не многим лучше простого снапшота на рабочей бд.

Способов бэкапа много, все зависит от конкретного случая, стратегии бэкапа и восстановления.
Постргес таром например можно и онлайн бэкапить.
нет, безусловно я не имел в виду xfs freeze. я имел в виду заморозить операции любым доступным для той или иной бд способом, вплоть до остановки инстанса (если это слейв реплика), затем снятие снапшота и далее «размораживание» операций :) собственно плюс в данном случае снапшота в том, что мы тратим время только на заморозку/разморозку. а в время копирования таром или другим подобным инструментом бд работает в штатном режиме.
согласен, комрад на один пост выше высказал законное удивление.
нормально работают внутренние бекапы бд и прочих активных сервисов.
lvm snapshot даже для обычной файловой системы под нагрузкой вызывает вопросы, не говоря уже о дампах баз данных. Отложенная запись улетает в никуда, записи теряются, журнал не пишется.
Грош цена таким бакапам.
rambominator, так тоже можно делать, но тогда дамп памяти жестко связан с дампом диска. Лучше все-же стопать сервисы, делать дамп и запускать обратно :)
некоторые сервисы отсинхронизированны на время проведения бекапа.
стоило об этом упомянть, завтра на работе допишу правки
спасибо за поправки
Если нужен чистый бэкап без отдельного дампа машины, можно сделать сплит виртуальной машины одновременно с снэпшотом диска — оригинальная машина продолжает работать, вторая виртуальная машина с снэпшотом штатно шатдаунится.
Но стандартно через xend/xm подмена бэкендов на лету невозможна, нужно самостоятельно писать обертку. Кажется, в XCP был contributed инструмент, но не уверен.
Несколько раз замечал глюки снапшоттинга на KVM например.
Системы «откатывались» к моменту начала снапшоттинга.
Так ставишь обновление, закачиваешь данные и хоп все на полчаса назад…
завтра проверю с xen, но вроде такого не было
Происходило при активном пользовании VNC к системам. На FreeBSD делалась компиляция ядра и обновление мира (а также пару десятков пакетов поставили), все смыло.
На Linux просто настраивались сетевые данные, после бекапа даже по времени откат был (приходилось npdateить)
А что по скорости работы с жестким диском в этот момент? Случалось сталкиваться с таким, что во время работы со снапшотом LVM скорость записи/чтения с диска существенно падала.

Также, насколько помню, компания r1soft.com предлагает коммерческие решения для бэкапа виртуальных машин на базе xen.
Скорость работы сильно страдает, поэтому бэкап луше делать в малонагруженное время и сделанный снэпшот лучше как можно скорее скопировать и удалить.
точно.
я там выше отписывался
>я выбрал время максимально разгруженное субботу, утро(в примере ночь стоит)
когда никого в офисе нет и удаленные сервисы не используются почти из-за разницы часовых зон у клиентов. и снепшот автоматически удаляется после копирования.
Sign up to leave a comment.

Articles