LINUX.ORG.RU

[KVM][QEMU][backup]Резервное копирование без остановки.

 , ,


0

1

Таки возможно ли делать полное резервное копирование QEMU/KVM'овской машины без остановки ея?

Вот например, если мы размещаем машину на LVM/RAW, то можем делать снимки LV, но в этом случае мы будем делать резервные копии блочного устройства. Состояние ОЗУ и кэшей записи не учитывается.

Насколько я понял, если мы будем делать QEMU snapshot'ы, то состояние ОЗУ опять не будет сохранено, но все отложенные дисковые операции будут совершены.

И наконец бэкап псевдомиграцией. Так вообще можно делать резервные копии? Кроме того, в описании алгоритма миграции:
--------------------------

  1. Setup

    • Start guest on destination, connect, enable dirty page logging and more
  2. Transfer Memory
    • Guest continues to run
    • Bandwidth limitation (controlled by the user)
    • First transfer the whole memory
    • Iteratively transfer all dirty pages (pages that were written to by the guest).
  3. Stop the guest

    • And sync VM image(s) (guest's hard drives).
  4. Transfer State

    • As fast as possible (no bandwidth limitation)
    • All VM devices' state and dirty pages yet to be transferred
  5. Continue the guest

    • On destination upon success
    • Broadcast «I'm over here» Ethernet packet to announce new location of NIC(s).
    • On source upon failure (with one exception).


--------------------------
Меня смущает пункт 3. Если мы размещаем образы блочных устройств как требуют:

VM image is accessible on both source and destination hosts (located on a shared storage, e.g. using nfs).

, то зачем нам синхронизация? Что с чем синхронизируется?

Ещё вопрос, если мы делаем бэкап псевдомиграцией в файл. То что будет в этом файле? Можно ли из него вытащить dump памяти и смонтировать файловую систему только для чтения? Могу ли я собрать такой файл состояния из имеющегося дампа памяти и директории с файлами? Если это возможно, то я смогу делать инкрементальные бэкапы. Алгоритм копирования такой:

  1. Делаю псевдомиграцию в файл.
  2. Вытаскиваю из получившегося файла дамп памяти и файлы файловой системы.
  3. Копирую дамп и файлы Bacul'ой на ленту.
  4. Удаляю всё что стало ненужным.

Восстановление:

  • Вытаскиваю из Bacul'ы дамп памяти и файлы
  • Собираю из дампа и файлов файл состояния виртуальной машины.
  • Запускаю виртуальную машину используя файл состояния
  • Удаляю всё что стало ненужным.
★★★★★

Ответ на: комментарий от crick

Синхронность же.

так а кто мешает сохранять дампы памяти?

Никто не мешает, но надо же снимать дамп ОЗУ одновременно с дампом всего остального, иначе дамп блочного устройства с файловой системой не будет соответствовать дампу ОЗУ.

Camel ★★★★★
() автор топика
Ответ на: комментарий от AnDoR

=8-[ ]

Нахрена? Твои виртуалки грузятся по 30 минут?

Паранойя. Я всё больше склоняюсь, что мне это нафиг не надо.

Camel ★★★★★
() автор топика
Ответ на: =8-[ ] от Camel

а вот это правильно. «Правильный» бэкап всё равно только с выключенных виртуалок :)

crick
()
Ответ на: комментарий от crick

Unsuspend.

С suspend'ом-то каждый сможет, а я хотел усилить стремление бэкапить с нулевым даунтаймом.

Camel ★★★★★
() автор топика
Ответ на: комментарий от crick

Нэ канает.

одна нода работает, вторую бэкапишь

КЭП.

Не канает. Есть, например, одна виртуальная машинка с Windows Server и сервисом проверки лицензий одной вендовой программки на пользовательских машинах. Программа проверки лицензий не кластеризуется, да платить килобакс за ещё один Windows Server желания нет.

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

Camel ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.