А как вы бакапите свои виртуальные машины ?

Так же, как и реальные.

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

У меня к примеру есть ряд не особо нагруженных и не особо критичных машинок. Я делаю снепшот от тома где лежат имиджы VM. Соот-но в случае если потребуется восстановление - то это будет просто как reboot машинки.

Если же есть КРИТИЧНЫЕ машинки то это только или уровень аппликаций которые там крутятся, либо уровень veem backup, или подобных энтерпрайзных софтин.

Ах да: по полученным образом я пробегаюсь при помощи rdiff-backup, и храню потом несколько различных образов фактически, чтобы иметь возможность вернуться назад в случае чего. И место много backup не занимают, и backup делаются довольно быстро.

zfs

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

kvm давно поддерживает live snapshot. кроме того есть LVM

на продакш ставить zfs ?

glusterfs geo-replication+backuppc+бекапы сервисов по необходимости

Для KVM, как правильно заметили, есть Live Snapshots.
В общем случае:
1) «Фризится» виртуалка
2) Снэпшотится нижележащий уровень хранения, включая swap, если он есть (aka LVM snapshot, BTRFS subvolume)
3) Сбрасывается в файл дамп оперативной памяти машинки
4) Виртуалка «размораживается»
5) Делается архивная копия содержимого снэпшота(ов) уровня хранения, после чего в эту же копию или рядом с ней кладётся дамп оперативной памяти
6) Удаляе(ю)тся снэпшот(ы) уровня хранения
В реальной практике в случае с OpenVZ-контейнерами проблема была в том, что дамп оперативной памяти приходилось размещать... в оперативной памяти! (в tmpfs) Хотя абсолютно логично, что дамп ОЗУ должен сжиматься той утилитой, которая его «снимает», тем не менее в OVZ это не делается, а запись даже 3-х гигабайт оперативки на диск может привести к очень критичному даунтайму.

«Фризится» виртуалка

у меня постоянно должен отрабатывать сервис на nginx+jetty+oracle
И каждый на отдельной машине.

у меня постоянно должен отрабатывать сервис на nginx+jetty+oracle

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

dada

у меня постоянно должен отрабатывать сервис на nginx+jetty+oracle

И каждый на отдельной машине.

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

А зачем вообще делать дамп памяти, если это не какой-то суперважный SQL-сервер? Просто делаем sync внутри виртуалки и делаем снапшот только диска без простоя. У RH вообще есть агенты, которые заставляют виртуалку не писать на диск пока гипервизор не разрешит.
Тем более, зачем делать дамп памяти в случае с openvz? Или у тебя сервисы из дампа оперативки поднимаются быстрее, чем стартуют?

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

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

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

sync делаешь и сразу делаешь снапшот только диска. Если там не 1000000 iops и не финансовые данные, то проблем не вижу (и не было у меня лично).
Ну ещё есть вариант с bacula изнутри клиентов. А ещё можно использовать qcow2 со сжатием и снапшотами. А ещё можно использовать ZFS, в которой файлы виртуалок располагать, и делать снапшоты на уровке ZFS, забирать от туда снапшоты, разряжать снапшоты.

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

Ещё варианты джентельмены ?

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

А зачем вообще делать дамп памяти, если это не какой-то суперважный SQL-сервер?

Восстановление виртуалки без дампа оперативки равнозначно включению компьютера после сбоя электропитания. Базы данных таких выкрутасов очень не любят. Причём практически любые базы данных, SQL здесь ни при чём.

LMV снапшот в момент паузы машины

Проблема в том, что даже на паузу нельзя. uptime должен постоянно расти.

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

Это очевидно, но консистентным такой снэпщот не является ни в коем разе.
Я был на семинаре VMware, и там рассказывали о том, как в хорошем дорогом энтерпрайзе реализованы отказоустойчивые решения, позволяющие при сбое одного хост-сервера мгновенно запустить виртуалку на другом. Так вот, там кроме собственно общего сетевого хранилища с высокой отказоустойчивостью используется и полная синхронизация состояния. И знаете как? О,это просто сказка! По 10-ти гигабитной сети в виртуальную машину-клон копируются все команды процессора, выполняемые на оригинале! Соответственно, и содержимое оперативки меняется синхронно.

на продакш ставить zfs ?

Её именно там и используют в первую очередь.

Проблема в том, что даже на паузу нельзя

Это бред. Я думаю, если вы хорошо подумаете, то можете внезапно осознать, почему это бред. Даю подсказку: на хост-сервере виртуалок может быть сильно больше количества физических процессорных ядер хост-системы. Тем не менее это почему-то не приводит к полному коллапсу всей IT-индустрии.

Её именно там и используют в первую очередь.

На Solaris?

По 10-ти гигабитной сети в виртуальную машину-клон копируются все команды процессора, выполняемые на оригинале! Соответственно, и содержимое оперативки меняется синхронно.

О_о
Разве 10ки на это хватает?

По 10-ти гигабитной сети в виртуальную машину-клон копируются все команды процессора, выполняемые на оригинале!

Тебя такой подход не устраивает ?
//me как-то перенёс сервачок с oracle-ом и вэб-сервисом(weblogic) на более мощный простым rsync/

На Solaris?

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

//me как-то перенёс сервачок с oracle-ом и вэб-сервисом(weblogic) на более мощный простым rsync/

Мы тут вроде в сторону live-migration ушли.

Я сейчас ищу инфу об отношениях zfs и redhat.
Никогда не использовал zfs. Если ок - пойду тестить.

Ну ещё есть вариант с bacula изнутри клиентов. А ещё можно использовать qcow2 со сжатием и снапшотами. А ещё можно использовать ZFS, в которой файлы виртуалок располагать, и делать снапшоты на уровке ZFS, забирать от туда снапшоты, разряжать снапшоты.

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

Проблема в том, что даже на паузу нельзя. uptime должен постоянно расти.

Кластеризуй тогда, делай репликацию. А вот бекапь уже реплику.

Я сейчас ищу инфу об отношениях zfs и redhat.

Нету их, потому что трабла с лицензией и в ядре её не будет никогда скорее всего.
Но автору апача я доверяю и он допилил её под продакшн. Почитай гитхаб и зачем он её переносил.

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

Для баз только реплика на другой сервер а вот его уже бекапить.

Для баз только реплика на другой сервер а вот его уже бекапить.

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

Кластеризуй тогда, делай репликацию

Этот вариант в силе, как самый последний. Много машин, хочется чего-то одного

Для oracle будет dataguard. Идеальное решение.

См. выше, я изначально говорил о том, что это не нагруженный SQL. В случае (видел в ынтерпрайзе на postgresql) используется репликация, отдельная нода именно для нужд бекапа. Если SQL-ПО нормально (как PS), то оно позволяет с себя слить консистентный дамп, при этом без блокировок других нод на запись. В ином случае используется (часто с mysql так делают) отрезание ноды от кластера и бекап с неё. После этого нода подключается и синхронизируется. Но я не спорю, что снапшоты с оперативкой тут куда удобнее. :)

Для oracle будет dataguard. Идеальное решение.

Что за dataguard? Встроенный бекап-менеджер?

Ага.

Но автору апача я доверяю и он допилил её под продакшн.

Ты ставил на продакшн то, что тестировали 1,5 разработчика на локалхосте ? (сорри если ответ грубый)

Этот вариант в силе, как самый последний. Много машин, хочется чего-то одного

Все что тебе надо уже давно придумано. стоит только поднапрячься и почитать умных дядек на предмет отказоустойчивого кластера на базе drdb или glusterfs + live migration для твоей системы виртуализации. НО резервное копирование это другое. тут надо иметь замороженный слепок активной системы виртуализированной. у меня такие есть в продакшине.

Этот вариант в силе, как самый последний. Много машин, хочется чего-то одного

В не самой нагруженной среде я решал это так:
Бакула + клиенты везде на каждую ОС. Там где бд - сливается дамп хуком у бакулы. Потом файлы соответственно сливаются в файл на zfs хранилку, где стоит сторадж демон бакулы.

Если еще важны образы виртуалок - снимается снапшот виртуалки и сливается, квм это умеет.
Минусов много, зато быстро, просто и работает :)

Восстановление виртуалки без дампа оперативки равнозначно включению компьютера после сбоя электропитания. Базы данных таких выкрутасов очень не любят. Причём практически любые базы данных, SQL здесь ни при чём.

Кэп? Что ты делаешь под аккаунтом DRVTiny?

http://docs.oracle.com/cd/B19306_01/server.102/b14239/concepts.htm

Но я не спорю, что снапшоты с оперативкой тут куда удобнее. :)

Они стоят как самолет :)

Я был на семинаре VMware, и там рассказывали о том, как в хорошем дорогом энтерпрайзе реализованы отказоустойчивые решения, позволяющие при сбое одного хост-сервера мгновенно запустить виртуалку на другом. Так вот, там кроме собственно общего сетевого хранилища с высокой отказоустойчивостью используется и полная синхронизация состояния. И знаете как? О,это просто сказка! По 10-ти гигабитной сети в виртуальную машину-клон копируются все команды процессора, выполняемые на оригинале! Соответственно, и содержимое оперативки меняется синхронно.

Есть Xen remus (и ушерший kvm kemari). Там это делано через теневое копирование оперативной памяти и запирание сети. То, что ты тут пишешь - это бред. Во первых, это оооочень дорого и технологически проблематично делать копию команд процессора, да и это не даст консистентного состояния (например, разное поведение виртуальных устройств, разные задержки, разные таймеры). Во вторых, для этого нормальных ынтерпрайзах применяется IB, а не 10GbE, т.к. при теневом копировании памяти самое важное - задержки. А тут и прямой доступ к памяти (что не грузит принимающий хост), и скорость, и нет задержек.

Они стоят как самолет :)

В смысле? Ты про сжирание диска?

Но вообще снапноты вызывают проблемы с часами. А кривое ПО может не понять внезапного сдвига времени.

Но вообще снапноты вызывают проблемы с часами. А кривое ПО может не понять внезапного сдвига времени.

Чего? О_о

Ты про сжирание диска?

Я про А как вы бакапите свои виртуальные машины ? (комментарий)

Если у тебя не мегакластер, то для теневого копирования памяти хватит, но лучше использовать IB. Можно хоть 100MbE использовать через Интернет, только виртуалки будут тормозить. См Xen Remus.

Если у тебя не мегакластер, то для теневого копирования памяти хватит, но лучше использовать IB. Можно хоть 100MbE использовать через Интернет, только виртуалки будут тормозить. См Xen Remus.

Прикольно. А аналог для квм? :)

Но вообще снапноты вызывают проблемы с часами. А кривое ПО может не понять внезапного сдвига времени.

Чего? О_о

Того. Если ты ставишь виртуалку на паузу (особенно при снапшоте с RAM), то часы виртуалки на время снапшота тоже замараживаются.