Comments 27
«которая явлеяется примонторированным хранилищем»
Что-то тут надо исправить)
Что-то тут надо исправить)
Подтверждаю — в продакшене работает без проблем и танцев. Главное — бэкапное хранилище побольше.
создание слепка делаете на нагруженной системе или в момент нулевой нагрузки?
как-то давно слышал, что создание слепка на системе под нагрузкой могло привести к краху.
как-то давно слышал, что создание слепка на системе под нагрузкой могло привести к краху.
на старом Xen был неприятный опыт — процесс dd уходил в D mode, естественно только ребут помогал. виртуальки при этом не страдали.
я выбрал время максимально разгруженное субботу, утро(в примере ночь стоит)
когда никого в офисе нет и удаленные сервисы не используются почти из-за разницы часовых зон у клиентов
я выбрал время максимально разгруженное субботу, утро(в примере ночь стоит)
когда никого в офисе нет и удаленные сервисы не используются почти из-за разницы часовых зон у клиентов
Если виртуалки ваши, а не клиентов проще делать бекап какой нибудь системой внутри гостевой системой, например той же бакулой.
В случае краха разворачиваю эталонную виртуалку и заливаю бекап с бакулы.
Возможность бекапа виртуалок с лвма не живая, если разделы большие и надо иметь большое количество бекапов во времени. То есть скажем ежедневные за полгода.
В случае краха разворачиваю эталонную виртуалку и заливаю бекап с бакулы.
Возможность бекапа виртуалок с лвма не живая, если разделы большие и надо иметь большое количество бекапов во времени. То есть скажем ежедневные за полгода.
Замечательно. Автор делает снапшот Windows 2003 c MSSQL, не стопая ни тот, ни другой.
Скажите, вы проверяете работоспособность каждого снапшота после такого, или просто складируете на авось?
Скажите, вы проверяете работоспособность каждого снапшота после такого, или просто складируете на авось?
Бэкап рабочей системы со слепка, а тем более с бд внутри будет неконсистентным, т.е. в результате развертывания этого бэкапа, система будет в состоянии как после неожиданного ребута или краха.
На мой взгляд интереснее вариант с сохранением виртуалки, снапшот и затем старт виртуалки. В бэкапе остаются образ со снапшота и дамп памяти. На быстрых дисках лаг несколько секунд.
Ну и да lvm snapshot не является средством для бэкапа бд.
На мой взгляд интереснее вариант с сохранением виртуалки, снапшот и затем старт виртуалки. В бэкапе остаются образ со снапшота и дамп памяти. На быстрых дисках лаг несколько секунд.
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, так тоже можно делать, но тогда дамп памяти жестко связан с дампом диска. Лучше все-же стопать сервисы, делать дамп и запускать обратно :)
Грош цена таким бакапам.
rambominator, так тоже можно делать, но тогда дамп памяти жестко связан с дампом диска. Лучше все-же стопать сервисы, делать дамп и запускать обратно :)
некоторые сервисы отсинхронизированны на время проведения бекапа.
стоило об этом упомянть, завтра на работе допишу правки
спасибо за поправки
стоило об этом упомянть, завтра на работе допишу правки
спасибо за поправки
Если нужен чистый бэкап без отдельного дампа машины, можно сделать сплит виртуальной машины одновременно с снэпшотом диска — оригинальная машина продолжает работать, вторая виртуальная машина с снэпшотом штатно шатдаунится.
Несколько раз замечал глюки снапшоттинга на KVM например.
Системы «откатывались» к моменту начала снапшоттинга.
Так ставишь обновление, закачиваешь данные и хоп все на полчаса назад…
Системы «откатывались» к моменту начала снапшоттинга.
Так ставишь обновление, закачиваешь данные и хоп все на полчаса назад…
А что по скорости работы с жестким диском в этот момент? Случалось сталкиваться с таким, что во время работы со снапшотом LVM скорость записи/чтения с диска существенно падала.
Также, насколько помню, компания r1soft.com предлагает коммерческие решения для бэкапа виртуальных машин на базе xen.
Также, насколько помню, компания r1soft.com предлагает коммерческие решения для бэкапа виртуальных машин на базе xen.
Sign up to leave a comment.
Бекап в Xen4