> > Великая просьба - пишите ответ внизу, а не вверху, если не получается > написать вопросы именно под той строкой, к которой вопросы. Мы ж не > менеджеры какие :-) > ок :)
> > Делать снапшот и потом копировать. > 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, но тут тоже хз чего и > как. > пробовал - как то оно сильно не то, как во фрибсд - для продакшена ни в коем случае (для себя сделал вывод) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
