Резервное копирование гостей qcow2 kvm


13

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

Есть ли лучший способ, чем:

  1. приостановить virt_machine # приостановить виртуальную машину
  2. rsync --sparse /home/vm/image.qcow2 /tmp/image.dec_14_2010.qcow2 # скопировать образ на тот же диск
  3. резюме virt_machine
  4. rsync --sparse /tmp/image.dec_14_2010.qcow2 ssh: // backup @ backupmachine: / vmbackups

У этого есть несколько недостатков. Во-первых, копирование огромного файла изображения занимает (относительно) много времени. Во-вторых, я всегда должен убедиться, что у меня достаточно места для резервного копирования моих машин. Это не идеально. Существуют ли другие лучшие способы управления резервными копиями KVM?

Благодарю.

Ответы:


7

Я хотел бы предложить функцию снимка qemu-nbd:

qemu-nbd --snapshot --connect=/dev/nbd0 image.qcow2

затем смонтируйте / dev / nbd0p1 (раздел 1), rsync, размонтируйте и, наконец, отключите:

qemu-nbd --disconnect / dev / nbd0


5

Грязное изображение с этим (ваша пауза, вероятно, может помочь, но все еще может не быть полностью последовательной):

Сделайте снимок в файловой системе LVM, содержащей разреженный файл qcow2 (опять же, при условии, что у вас есть место для снимка LVM)

Смонтируйте снимок LVM.

Смонтируйте пульт с помощью sshfs.

Копировать в точку монтирования sshfs, используя разреженное копирование (cp --sparse = всегда src dest)

Меньше времени на копирование, но оно все равно займет полное время, если изображение в основном заполнено.

Резервное копирование данных из виртуальной машины, вероятно, является лучшей идеей (меньше места / времени). Относитесь к отдельным виртуальным машинам как к обычным хостам, для которых необходимо выполнить резервное копирование / восстановление - то есть просто получите то, что вам нужно, и сохраните набор виртуальных машин-заглушек без данных для быстрого восстановления и работы.


Интересно, спасибо. У меня нет LVM поверх моей файловой системы, для простоты. Я бы предпочел скопировать весь образ, потому что это позволило бы мне подготовить аварийное переключение при сбое в случае отказа машины в любой момент.
Восемьдесят восемь

1
Нет проблем. LVM просто избавит вас от необходимости приостанавливать работу виртуальной машины и позволит вам делать снимок, пока она продолжает работать.
ax25

3

Лично у меня было ОЧЕНЬ трудное время с этой проблемой, и я обнаружил, что даже в состоянии покоя резервные копии гостя часто бывают ненадежными. Помните - если вы регулярно не пытаетесь восстановить эти резервные копии, вы действительно не знаете, работают ли они.

После долгих экспериментов я полностью остановился на резервном копировании образа и выбрал традиционное сетевое решение для резервного копирования, которое можно использовать для серверов с «голым железом». В моем случае мы пошли с BackupPC, который старый, но супер надежный. На каждом сервере я настраивал решение для резервного копирования для конкретного используемого приложения. Например, sqldump для MySQL, плагин для Joomla и т. Д.

Это PIA, но это гораздо быстрее и очень надежно.


Спасибо @hdave. Я чувствую, что при таком подходе я теряю одно из основных преимуществ виртуальных машин - сдерживание. Чтобы восстановить, мне пришлось бы переустановить все вручную и настроить. Не совсем подход, который я хочу использовать. Тем не менее, в любом случае, спасибо, это верный метод.
Восемьдесят восемь

100% согласны, что это королевская боль. Если вы когда-нибудь взломали этот орех, дайте нам знать, как вы это сделали!
hdave

@EightyEight: я настоятельно рекомендую программное обеспечение для управления конфигурацией, такое как Chef или Puppet. Это гораздо более гибко и менее болезненно, если вы хотите настроить идентичный второй сервер (физический или виртуальный, не имеет значения). Chef имеет плагины практически для всех гипервизоров и может помочь вам подготовить и настроить хост. Таким образом, вы получаете преимущество, заключающееся в использовании меньшего пространства для резервных копий (целая виртуальная машина больше по сравнению с конкретными наборами данных) и более быстрое время развертывания в новых средах. Кроме того, CM похож на инфраструктурную документацию в коде.
Рафаэль Бугаевский

2

Независимо от того, где вы делаете снимок - LVM или qcow2, виртуальная машина все еще должна быть приостановлена, прежде чем вы ее сделаете. В противном случае вы получите потерянные данные и поврежденные изображения.


не больше, чем если бы вы выдернули шнур питания?

1
не больше и не меньше конечно :)
дясный

если подумать об этом еще больше, то успокоение домена ничего не добавляет - в любом случае снимок является «устойчивым к сбоям», ни больше, ни меньше, я прав?

ошибиться, определить "устойчивый к сбоям". Гостевая ОС может иметь некоторые данные в полете, предназначенные для V-диска, которые будут потеряны, если вы отключите питание. Теоретически, эти данные могут быть записаны в моментальный снимок после того, как он будет запущен, но есть веская причина, что моментальные снимки на всех платформах virt включают в себя приостановку / оттаивание в гостевых агентах. Более того, если данные не будут потеряны, они все равно окажутся в моментальном снимке вместо базового изображения, что
противоречит

«устойчивый к сбоям» означает просто «такой непротиворечивый, как вы ожидаете в случае сбоя» iiuc - то есть полагаетесь на журналы и т. д. и допускаете некоторую потерю данных из-за отсутствия своевременного fsync. «есть веская причина, по которой живые снимки на всех платформах virt-in включают в себя приостановку / оттаивание в гостевых агентах», как я понимаю, веская причина точно такая же, как при создании снимка LVM - знаете ли вы по-другому? Похоже, что KVM не успевает fsync раньше, чем снимок LVM? Конечно, если вы не используете LVM для создания моментальных снимков, вам будет глупо не успокаиваться - но это не так, как вы говорите.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.