Как сделать backup OpenVZ контейнера без downtime

Дауны в пролете.

для не осиливших lvm снапшоты?

На удаленный хост по ssh?

>На удаленный хост по ssh?

спорное решение бэкапить сразу на удаленный хост, лучше разделить на две операци ;]

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

отрвать попу от стула и воткнуть доп. жестяк

Не хватает подписи:

>Ваш К.О.

ovz не нужен.

> отрвать попу от стула и воткнуть доп. жестяк
В стул, или в попу?

>отрвать попу от стула и воткнуть доп. жестяк
>В стул, или в попу?

в оба места :)

>отрвать попу от стула и воткнуть доп. жестяк

Вот такие как ты раньше никогда не кидали палки в плоды, а подымали попы и лезли на деревья за доп.плодами

Повезло тебе, что родился сейчас, а то раньше бы навсегда остался приматом

vzctl chkpnt 110 --suspend - разве это не даунтайм? оч короткий, но все же )

vzdump + lvm

и не пудрите людям мозги

>Вот такие как ты раньше никогда не кидали палки в плоды, а подымали попы и лезли на деревья за доп.плодами

{неразборчиво} думать, трясти надо! :o)

согласить, что лучше иметь бэкап, чем не иметь ничего ;]

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

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

Ну вот достался тебе сервер в продакшн без LVM

>vzctl chkpnt 110 --suspend - разве это не даунтайм? оч короткий, но все же )

Нет, это не даунтайм. Это просто маленькая задержка, за несколько секунд tcp сессии не оборвутся.

>Ну вот достался тебе сервер в продакшн без LVM

что значит достался? может еще обсудим как шаредхост без рута бекапить?

>что значит достался? может еще обсудим как шаредхост без рута бекапить?

Теоретик detected, можешь дальше фантазировать.

Забавно, но не люблю я все эти бакапы партиций и файловых систем целиком, бакап должен быть апликейшн-уровня индивидуально для каждой используемой службы.

Повезло тебе, что родился сейчас, а то раньше бы навсегда остался приматом

Боюсь тебя разочаровывать, но все мы и дальше приматы. И ты тоже.

> даже в несчастной системе на букву Л, обделенной таким чудом техники как ZFS

...в меру тонко...

>Ну вот достался тебе сервер в продакшн без LVM

use bacula, Luke

> Повезло тебе, что родился сейчас, а то раньше бы навсегда остался приматом

T_T

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

>Теоретик detected, можешь дальше фантазировать.

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

так что довольствуйся этим.

Потёр - и правильно сделал, бредятины и без того хватает.

ето точно. особенно по ссылке на новость

>кстате да. даже в несчастной системе на букву Л, обделенной таким чудом техники как ZFS, и то есть LVM и его кривые но вполне работающие снапшоты.

и в чем кривость снапшотов LVM?

>и в чем кривость снапшотов LVM?

при снапшоте LVM снапшотится весь раздел. а не та часть где реально размещены данные. потому что в линуксе же LVM один а FS - тысячи их! это так, первый пришедший в голову пример.

снапшоты в lvm делаются мгновенно с применением механизма Copy-On-Write. при этом НЕ требуется свободное место, равное полному объему данных снапшота, место выделяется на лету только для изменившихся данных. смонтировать снапшот и слить с него нужные данные проблемы нет. и вообще, lvm - система уровня управления логическими томами, со своими задачами справляется великолепно. почему-то вы сравниваете FS и Volume Manager, это некорректно. приведенный пример никак не доказывает кривости LVM.

дампается этот снапшот тоже мгновенно? дампать-то надо по размеру всего раздела-с.

дампается мговенно. почему - см. выше (COW). никакой задержки или остановов нету.

omfg.

dd if=/dev/VG_XXX/LV_XXX-snapshot of=/backupfile.dump тоже мнговенно сделает?

>time lvcreate -s -L 5G -n mysql-backup1 /dev/vg00/mysql

и шо ви вот так вот таки сбекаплись на тот же диск и думаете шо ви таки в домике?

[quote]dd if=/dev/VG_XXX/LV_XXX-snapshot of=/backupfile.dump тоже мнговенно сделает?[/quote]

я этого не утверждал никогда :)

так вот я зато утверждаю. если снапшот сделал с раздела в 400 гиг, из которых реально занятно 50, почему он должен при экспорте весить 400? это время, если хотите, лишние гигабайты, в случае с SAS или SSD - за немаленькие деньги.

[quote]и шо ви вот так вот таки сбекаплись на тот же диск и думаете шо ви таки в домике? [/quote]

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

>так вот я зато утверждаю. если снапшот сделал с раздела в 400 гиг, из которых реально занятно 50, почему он должен при экспорте весить 400?

а зачем в данном случае бэкапить весь раздел? что мешает смонтировать снапшот и сбэкапить только нужные данные? я вот так и делаю например.

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

ГДЕ КРИВОСТЬ LVM, я вас спрашиваю? ответьте наконец!

а зачем столько движений? почему LVM не соединить с FS и не бекапить одной командой?

>а зачем столько движений? почему LVM не соединить с FS и не бекапить одной командой?

vzdump --dumpdir /space/backup --snapshot 777

одна команда, устроит? :o)

>а зачем столько движений? почему LVM не соединить с FS и не бекапить одной командой?

lvm - прослойка между физ. дисками и файловыми системами. про фс она не знает ничего, это не ее задача. поверх lvm может работать любая FS. в zfs совместили оба слоя - такой подход тоже имеет право на жизнь, почему нет. и спорить по этому поводу не буду, т.к. zfs мне симпатична весьма. почему не соединить оба подхода? соединяют, вон - btrfs http://ru.wikipedia.org/wiki/Btrfs как раз и соединяет. пока в разработке, посмотрим, что выйдет.

так все же - В ЧЕМ КРИВОСТЬ LVM? Не уходите от ответа!

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

я уже около трех раз в лоб спросил: в чем кривость LVM? г-н gigabito упорно игнорирует вопрос, не приводя никаких аргументов, из-за чего навязывается вывод, что про "кривость lvm" он сболтнул лишнего, не разбираясь в вопросе, а теперь не знает как выкрутиться из сложившейся неловкости и упорно ищет недостатки в схеме резервного копирования, в vzdump'е, etc, чтобы отвлечь внимание общественности от своего провала.

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

а монтировать снапшот назад и снимать данные какими-то скриптами на коленках от такого труЪ интырпрайза как SWSoft, это офигенное решение в помощь недостаткам кривой дибильной разрозненной архитектуры. зачем нормальные технологии, щас нахуярим кластир из говна и палок а волонтёры из св-софта нахуярят баш-скриптов и будет коммунизм.

>я прямым текстом в 3й раз отвечаю: первым делом - отсутствие интеграции с FS.

это НЕ функция lvm by-design. я уже объяснял место lvm в системе. давайте заодно объявим кривыми логические разделы на жестком диске за отсутствие интеграции с файловыми системами :):)

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

сам снапшот и не занимает. если вытащить его с помощью dd, то займет. вы что из этого имели в виду?

повторюсь,

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

все заявленные функции lvm в линуксе выполняет как надо, работает стабильно в продакшн многие годы и реально помогает админить.

ни одного аргумента по поводу невыполнения ЗАЯВЛЕННОГО функционала не было.

>это маразм.

>а монтировать снапшот назад и снимать данные какими-то скриптами на коленках от такого труЪ интырпрайза как SWSoft, это офигенное решение в помощь недостаткам кривой дибильной разрозненной архитектуры. зачем нормальные технологии, щас нахуярим кластир из говна и палок а волонтёры из св-софта нахуярят баш-скриптов и будет коммунизм.

no comments. аргументы у gigabito кончились, жду перехода на личности и словесного потока в свою сторону :)

>давайте заодно объявим кривыми логические разделы на жестком диске за отсутствие интеграции с файловыми системами :):)

давайте. это тяжелое наследие досовско-писюковских времен.

>сам снапшот и не занимает.

сам снапшот - занимает блять. то что он физически на винте содержит только изменения, это не значит что его логическая длина не равна длине раздела. и если его вытащить - шило из мешка вылезет.

>жду перехода на личности

да нахуй мне твоя личность -) возьми лучше какуюнть btrfs почитай если уж судьба на линукс забросила. хотя имхо ларри ее прибьет, как и OEL. они ему больше не нужны

>сам снапшот - занимает блять. то что он физически на винте содержит только изменения, это не значит что его логическая длина не равна длине раздела. и если его вытащить - шило из мешка вылезет.

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

бэкапить с помощью dd неэффективно. смонтировать и вытащить нужные данные - эффективно. насколько это костыль, каждый решит сам. в баше 3 строки - mount, cp|tar|..., umount страшно испугают неокрепшие умы.

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

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

спокойной ночи.

"пофайлово бекапить сподручнее чем снапшотами". извини но ты точно идиото. а если файл занимал 50 гигов а в нём изменились 50 байт? будем 50 гигов бекапить? и тут на арену выходят еще два актёра - rsync и возможно прогон find'a с newer-mtime. чуствуешь как костыль усложняется? а когда это всё у тебя йобнется, ты вспомни наш разговор.

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