Как бэкапить снапшоты LVM?

[rfcr]

Всем привет!
Кто знает чем можно забэкапить снапшоты LVM?

[nesk]

Всем привет!
Кто знает чем можно забэкапить снапшоты LVM?

Монтируете снапшот, и бекапети его любой вашей любимой командой для снятия бекапа.
tar - например.
Или я вопрос не так понял?

[rfcr]

>Или я вопрос не так понял?
Да не правильно. Сформулирую иначе вопрос.
Как бэкапить VG и LV?

[nesk]

>Или я вопрос не так понял?
Да не правильно. Сформулирую иначе вопрос.
Как бэкапить VG и LV?

Это если заголовки lvm (VGRA PVRA) потрутся? Как их восстанавливать?
команды vgcfgbackup и vgcfgrestore в линуксе есть?

[Ленивая Бестолочь]

команды vgcfgbackup и vgcfgrestore в линуксе есть?

Код: Выделить всё

yuki:/home/rakul# vg
vgcfgbackup   vgchange      vgconvert     vgdisplay     vgextend      vgmerge       vgreduce      vgrename      vgscan
vgcfgrestore  vgck          vgcreate      vgexport      vgimport      vgmknodes     vgremove      vgs           vgsplit

[rfcr]

Это если заголовки lvm (VGRA PVRA) потрутся? Как их восстанавливать?
команды vgcfgbackup и vgcfgrestore в линуксе есть?

Если винчестер сломается. Как сделать бэкап, чтобы восстановить VG и LV?

[nesk]

Как сделать бэкап, чтобы восстановить VG и LV?

ну я как бы намекнул на полезные команды:
man vgcfgbackup

[nesk]

3.4. Logical Volume Backup

[rfcr]

Хорошо, забэкапил я конфигурации группы томов, винт поломался но есть бэкап конфигурации. Как восстановить потерянные данные?
Цитирую:
"Note that a metadata backup does not back up the user and system data contained in the logical volumes. "

[nesk]

Как восстановить потерянные данные?

данные надо бекапить отдельно (например командой tar или pax или любой другой программой для снятия бекапа)
Или я опять не понял?

[rfcr]

Ок. Как таким способом (бэкап конфигурации и бэкап данных) восстановить 2 снапшота и так, чтобы они занимали места столько же сколько они занимали когда делались изначально? Если просто скопировать данные даже при уже работающем LVM в снапшот то это уже будет не снапшот. Проверял уже.

[Ali1]

dd .... gzip -9 ? Вам ведь надо винт посекторно восстановить.

[nesk]

Ок. Как таким способом (бэкап конфигурации и бэкап данных) восстановить 2 снапшота и так, чтобы они занимали места столько же сколько они занимали когда делались изначально?

На сколько мне известно - никак.


Может не много не в тему: есть специальные утилиты для создания инкрементальных бекапов.

ЗЫ Ali1 предложил наверно единственно возможный вариант решения

[Ленивая Бестолочь]

скопировать данные даже при уже работающем LVM в снапшот

эм. даже не представляю зачем это нужно.

http://www.howtoforge.com/linux_lvm_snapshots

[rfcr]

Про инкрементальные бэкапы не понял, тут это не причем...
Ленивой бестолочи спасибо, документ вроде похож на то что нужно, попытаюсь осилить.
Но вопрос остается открытым, т.к. хотелось бы что-то более автоматизированное иметь, вроде backup exec и иметь возможность восстанавливать (например те же снапшоты) по сети...

[rfcr]

http://www.howtoforge.com/linux_lvm_snapshots

Нет это не то... Там человек делает снапшот того раздела, который он хочет бэкапить, затем монтирует этот снапшот и "загоняет" его в образ.
Далее перезагружается и восстанавливает РАЗДЕЛ из этого образа.

А в контексте темы нужно восстановить снапшот! Т.е. Был раздел А, из него создали снапшот 1, затем снапшот 1 примонтировали и начали использовать. В снапшоте удалили/испортили файл. Как восстановить снапшот? Ведь если просто забэкапить файл из примонтированого снапшота 1 и затем его скопировать обратно из бэкапа то это уже будет не то! Снапшот вырастет на размер этого файла. А нужно чтобы он не вырос. Ну не знаю как еще объяснить...

[Ленивая Бестолочь]

В снапшоте удалили/испортили файл. Как восстановить снапшот?

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

[rfcr]

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

[Ленивая Бестолочь]

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

[rfcr]

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

>> как это поможет вам восстановить данные, через неделю, например?
Ну дак, снапшот был забэкаплен например 1 числа, потом до 10 в него вносились изменения, а потом весь снапшот был перезаписан (на уровне раздлов) снапшотом сделанным 1 числа. Ведь если я правильно понимаю данные в разделе с которого делался снапшот не меняются, меняется сам снапшот. Так что перед рестором в наличии будет бэкап снапшота и раздел с которого этот снапшот был изначально сделан. Вроде как по логике все есть.

[Ленивая Бестолочь]

счас попробую вам объяснить в кратце как работает снепшот:

у вас есть блоки на блочном устройстве, некоторые содержат информацию, некоторые нет:

Код: Выделить всё

--[0]--[X]--[0]--[0]--[X]--[X]--

что-то типа того.
юзер что-то записал, инфа изменилась:

Код: Выделить всё

--[0]--[X]--[0]--[X]--[X]--[X]--

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

Код: Выделить всё

--[0]--[X]--[0](X)--[X]--[X]--[X]--

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

[nesk]

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

Используйте команду dd, что бы бекапить все содержимое VG, как предложил Ali1

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

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

Снепшот - это объект который всегда связан с исходным LV. Снапшот частично разделяет мапенинг с исходным LV.
То есть карта снепшота частично указывает на новое место, а часть на старое.

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

Не совсем. Снепшот - это Point in Time копия исходного LV. Идея была заморозить состояния диска, для того, что бы не останавливая сервис (не останавливая запись в основной LV) можно было сделать бекап неизменяющихся
данных. Если мы пишем в LV, меняется LV (снепшот разрастается спасая старые не модифицированные данные)
Если мы пишем в Снепшот, меняется снепшот - он разрастается, что бы хранить новые данные.
Как то так.

Вот нашел анимацию http://www.lascon.co.uk/mssqlsnap.gif

[rfcr]

Если мы пишем в LV, меняется LV (снепшот разрастается спасая старые не модифицированные данные)

Это что-то новое для меня. Почему в этом случае должен снапшот меняться?

Если мы пишем в Снепшот, меняется снепшот - он разрастается, что бы хранить новые данные.

Вот так я и хочу попробовать сделать. Вы угадали на счет виртуальных машин. Т.е. у меня будут ВМ-ы (по замыслу) работать только на снапшотах.
И их необходимо как-то бэкапить.
Вывод сделал такой: бэкапить можно но только на уровне файловой системы... Например как и подсказали - "dd". Я надеялся что это можно будет делать штатными средствами LVM но видимо такого нет

В бесплатных гипервизорах не нашел такого функционала. Т.е. нужен аналог связанных клонов из vmware workstation.

[nesk]

Это что-то новое для меня. Почему в этом случае должен снапшот меняться?

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

Про инкрементальные бэкапы не понял, тут это не причем...

А вот как раз инкрементальные бекапы имеют прямое отношения к решению Вашей задачи
По сколько у Вас состояние исходного тома не меняется, а меняются только снимки.
Мы делаем полный бекап (с уровнем инкремента 0) исходного тома.
А потом для каждого снимка мы делаем инкрементальный бекап того, что изменялось относительно полного бекапа исходного тома.
Если надо будет восстановиться:
Мы восстанавливаем содержимое исходного тома ( если оно повреждено )
Делаем новый снимок, и заливаем туда данные из инкрементальной копии.

Решено?

Вот так я и хочу попробовать сделать. Вы угадали на счет виртуальных машин. Т.е. у меня будут ВМ-ы (по замыслу) работать только на снапшотах.

Если бы Вы сразу полностью сформулировали бы задачу, то было бы проще подсказать Вам решение.
А сколько у Вас планируется виртуальных машин?

В бесплатных гипервизорах не нашел такого функционала. Т.е. нужен аналог связанных клонов из vmware workstation.

Может следует создать новую тему, и там спросить про нужную функциональность свободных/бесплатных гипервизоров?
Надо будет глянуть функционал xen.

[rfcr]

Мы восстанавливаем содержимое исходного тома ( если оно повреждено )
Делаем новый снимок, и заливаем туда данные из инкрементальной копии.

Решено?

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

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

Не менее 10. Одновременно работать должны будут примерно 5-7. Т.е. загрузка не на 100%.

Может следует создать новую тему, и там спросить про нужную функциональность свободных/бесплатных гипервизоров?
Надо будет глянуть функционал xen.

Возможно стоит, если здесь есть специалисты. Так - то я уже поспрашивал-почитал про тот же xen и там не все так хорошо как может казаться. Если вкратце то вывод такой: там нет "связанных клонов" как в vmware workstation, но сделать их можно только через ZFS. При этом у Vmware все в файлах и их бэкапить проще, чем проводить бэкап ZFS. Хотя я может быть и не прав...

[nesk]

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

Может я опять не совсем хорошо понял то, что Вы написали.
Мне кажется надо делать инкремент на уровне файлов (бекапатся ведь файлы)
То есть есть исходный том. Там есть файлы f1 f2 f3. Есть его снимок в котором файл f2' поменялся.
Делаем полный бекап раздела и инкремент снимок-раздел.
В полном бекапе будут файлы f1 f2 f3
А в инкременте f2'
Дальше, если надо восстановиться:
Мы восстанавливаем исходный том с полного бекапа (если это требуется)
Делаем новый снимок.
И заливаем в снимок только инкремент. То есть снимок увеличиться на размер данных в инкрементальной копие.
Размер снимка конечно может оказаться больше чем был, а может оказаться даже меньше

[rfcr]

Мне кажется надо делать инкремент на уровне файлов (бекапатся ведь файлы)

Делаем полный бекап раздела и инкремент снимок-раздел.

Дак, все-таки вы имеете в виду инкрементальный бэкап на уровне раздела или на уровне файлов?
Поясните пожалуйста, чтобы не гадать, что вы имеете в виду под "инкремент снимок-раздел"?

Если имеете в виду бэкап на уровне разделов то ясно, что это сработает и все сбэкапится и восстановится.

[nesk]

Я имею ввиду инкремент на уровне файлов.

У нас есть исходный том - мы с него делаем полный бекап всех файлов.
У нас есть снимок этого тома - через снимок мы видим, что часть файлов не менялась, а часть файлов изменилась. Мы включаем в бекап только те файлы, которые в снимке изменились относительно исходного тома.

С этим этапом понятно?

[rfcr]

Идея понятна. Хотя есть сомнения в её работоспособности. Надо проверять...

[vagrantname]

Я насладился, читая дисскусию nesk'a и уважаемого rfcr

Последний форум, на котором я когда-либо регался был в 2006 года.. такая же атмосфера обучения, гармонии и сарказма ))) я здесь надолго, Yeaaah!

Это все лирика,

Я имею ввиду инкремент на уровне файлов.

У нас есть исходный том - мы с него делаем полный бекап всех файлов.
У нас есть снимок этого тома - через снимок мы видим, что часть файлов не менялась, а часть файлов изменилась. Мы включаем в бекап только те файлы, которые в снимке изменились относительно исходного тома.

С этим этапом понятно?

С этим этапом - понятно! Очень грамотно обозначен сам факт этапа понимания А дальше? Ситуация почти 1 в 1. Тот же уровень понимания, теже взгляды на проблему.
Сама идея - нужна 200% безопасная система. Как одно из решений в стиле "лоооол", хочу при каждом запуске машины возвращаться на свой образ, гг Любые обновления теряют свою значимость при регулярном выключении системы
Интересуют скрипты.

Я очень рад, кстати, окунутся в этот мир никсов на уровне форумов. Знаете, я как-то в детстве очень часто цеплял дистры всякие под LAMP преимущественно и защиту, но по инструкции, с ленью, я не горел... и как-то не привязывался он ко мне..
а тут значит развернул систему, написал чисто свои скриптики, гном 3 с рюшечками - самое то, чтобы появился энтузиазм. Кстати говоря, гном 3 - очень грамотный шаг в сторону популяризации. Остальные и форкам рады )

Ну так вот, продолжим со мной? Ну я очень надеюсь, правда ))