Re: Производительность KVM на LVM
>
> Великая просьба - пишите ответ внизу, а не вверху, если не получается
> написать вопросы именно под той строкой, к которой вопросы. Мы ж не
> менеджеры какие :-)
>
ок :)
>
> Делать снапшот и потом копировать.
> dd if=/dev/VG/LVM-snap of=/mnt/backup/virt-`date +%F`.img
> Остальные опции по вкусу.
>
> Размер снапшота зависит от того, сколько данных понапишет виртуалка,
> пока ты его копируешь. Но бекапы так не делаются, ибо при накрывании
> системы медным тазом фиг чего восстановишь обычно. Бекапы делаются
> через копирование снапшота в другое место.
>
> Остановить виртуалку и записать в lvm-том старое содержимое
> практически также, как копировал его.
>
т.е. опять через dd влить напрямую в lvm-том?
еще вопрос - я так понимаю при копировании через dd lvm-тома размером 300гб (даже если полезной инфы там 50гб) на сетевую шару (другой сервер) мы получим файл-образ размером 300гб?... я так понимаю это долгая и неэффективная процедура((
Это получается единственный вариант бэкапа системы целиком в случае использования lvm?.. или может еще есть какие то варианты? Мне еще приходит в голову только сжатие этого образа при копировании, что еще более увеличит время создания образа и непонятно насколько уменьшит его размер(
Если так, то получается бэкап акронисом (в случае windows-систем) эффективнее гораздо... :(
>
> Во-первых, для _бекапов_ достаточно одного снапшота на время бекапа.
> Во-вторых, как-то проверял - скорость при одном снапшоте и при
> нескольких одинакова.
>
а без снапшотов вообще и с одним снапшотом? на XGU именно такой тест был - скорость отличается в разы :(
> Есть такое дело... Можно попробовать zfs через fuse, но тут тоже хз чего и как.
>
пробовал - как то оно сильно не то, как во фрибсд - для продакшена ни в коем случае (для себя сделал вывод)
Reply to: