Резервное копирование необработанных образов KVM

Резервное копирование необработанных образов KVM

Я запускаю qemu-img-0.12.1.2-2.355.0.1.el6 на CentOS 6.3, используя raw-образы для моих виртуальных машин. Есть ли способ безопасного резервного копирования гостей, не останавливая их? Я попытался сделать снимок на тестовом госте, который не был запущен, но получил ошибку: «live disk snapshot not supported with this qemu binary». Означает ли это, что raw-формат не подходит для любого типа снимков, или это что-то с моим пакетом KVM? Я читал, что приостановки гостя достаточно для выполнения операции dd, так ли это? Пожалуйста, поделитесь некоторыми из ваших лучших практик в этой области?

решение1

Если вы используетесыройизображениефайлыто единственный способ получить согласованный снимок — приостановить или завершить работу виртуальной машины.

Вы можете сделать снимок с помощью файлов образа qcow2 без приостановки работы виртуальной машины, но снимок станет частью этого файла. Это может быть уместным или нет, в зависимости от вашей ситуации.

У вас будет больше возможностей, если вы используете CentOS 7 или текущий гипервизор Fedora, например, тома LVM snapshottable или ZFS zvols. В этих современных системах вы бы virsh domfsfreezeгость, сделали снимок, virsh domfsthawгость, а затем сделали резервную копию снимка. Для этого требуется qemu-guest-agent, запущенный в госте.

решение2

Приостановка работы виртуальных машин virsh suspend <domain>просто замораживает виртуальную машину; согласно документации, все дисковые и сетевые операции ввода-вывода приостанавливаются, при этом виртуальная машина продолжает потреблять оперативную память хоста.

Если у вас Centos, то есть большая вероятность, что у вас там также есть раздел LVM и поверх него раздел XFS. Если утверждение верно, то вы можете сделать его резервную копию следующим образом:

  • удалить кэш на виртуальной машине и приостановить ее,
  • удалить кэш на хосте и сделать снимок LVM,
  • смонтируйте снимок LVM где-нибудь на хосте и выполните резервное копирование по расписанию.

У меня это работает даже с серверами баз данных. Даже резервное копирование файлового сервера (например, Samba) совершенно безопасно, без сброса кэша на хосте или виртуальной машине, при условии, что параметры ядра на хосте и guset заданы по умолчанию. Потеря данных минимальна. Например, Ext4 фиксирует грязные страницы в оперативной памяти каждые 5 секунд (настройка по умолчанию). Это может привести к потере данных, которые были зафиксированы менее чем за 5 секунд до заморозки. Такая потеря данных была приемлемой для меня.

Каждый метод резервного копирования имеет некоторые недостатки. Простой или потенциальная потеря данных. Многие администраторы баз данных предполагают, что потеря данных может привести к повреждению данных, когда ядро ​​базы данных (например, MS SQL) обязательно должно фиксировать каждую транзакцию в файловой системе перед принятием изменения. С другой стороны, они соглашаются восстанавливать данные из резервной копии и соглашаются с потерей данных.

Связанный контент