На чём и как проще всего автоматизировать создание бэкапов KVM-машин?

Question

[Кирилл]

Есть KVM-гипервизор с 20 виртуальными машинами. Каждый день нужно делать полные бэкапы некоторых машин. Пока приходится вручную с помощью Virsh выключать машины, делать бэкап, а потом включать снова.

Есть ли какое-нибудь средство, помимо скриптов bash, которое может помочь реализовать следующий сценарий ниже?
1. Инициировать выключение виртуальной машины.
2. Сделать полное копирование виртуальной машины (у меня они в формате qcow2 в виде одного единственного файла, очень удобно кстати, взял скопировал файл и всё готово).
3. Включить виртуальную машину.
4. Сделать shrink скопированной виртуальной машины (точнее, её виртуального hdd), чтобы размер стал реальным (делаю с помощью qemu-image).
5. Сжать tar bzip.
6. Запустить создание бэкапа следующей виртуальной машины (пункты с 1 по 5).

Comments

[Vladimir Zhurkin]

а нет желание перейти на готовые , условно бесплатное решение ?
Все из коробки есть в proxmox.com
Работает не один год.

[Vladimir Zhurkin]

Вот тут примерно есть решение на скриптах и без остановки машины.

https://serveradmin.ru/kvm-backup/

[sim3x]

Во всем ТЗ не вижу никаких трудностей написать такое самому

Answer 1

[younghacker]

Соглашусь с 3ton по поводу LVM. Но делать резервную копию по-живому это экстрим.
Можете получить полуобновлённую базу данных, полуживую файловую систему и так далее. За исключением того что сделаете копию не только диска но и памяти и в момент паузы виртуальной машины.
Без доступа внутрь виртуалки нельзя гарантировать что на диск сброшены все данные.
Мой совет - пересмотрите технологию бэкапов.

Я практикую следующий подход:
Перед обновлением системы на сервере делаю полный бэкап по следующей схеме.

1. Остановка виртуалки (виртуалки реагируют на ACPI снаружи)
   
2. Снапшот LV привязанного к виртуалке.
   
3. Старт виртуалки.
   При использовании скриптов (не вручную) даунтайм получится практически равным рестарту виртуалки.
   
4. Обновление (системы) Если обновляется кернел то делаю по аналогичной схеме делаю второй LV снапшот.
   
5. копирование снапшота(ов)
   
6. удаление снапшотов.
   

Имейте ввиду что необходимо иметь запас места для снапшота на время его жизни (копирования) так как свободное место на LVM начнёт быстро таять как только виртуалка начнёт активно изменять данные на своём диске.

Тоесть нет смысла ежедневно делать резервную копию того что не изменялось (система и программы).

А ежедневные бэкапы делаю при помощи скриптов + bareos/bacula.
Такой подход в целом уменьшает размер резервных копий.

Ну и хорошо после создания бэкапа делать его восстановление и проверку.
Для виртуалки обычно хватает разворачивания на другом физическом сервере (чтобы небыло конфликтов) и проверки запущенности всех важных сервисов и доступности баз данных (тестовые скрипты).

Далее можно оптимизировать. Не бэкапить swap виртуалок. Его можно убрать при копировании снапшота. А лучше swap выдавать отдельным LV. Тогда его не нужно и снапшотить.
В виртуалках я также по аналогии с отдельным свапом делаю отдельные диски для DB, логов, и так далее. Всё это позволяет ужать размер бэкапа системы до 3-5 гиг в несжатом виде.

Comments

[Кирилл]

А какой формат виртуальной машины выбрать, чтобы можно было делать снэпшот LV ? У меня сейчас qcow2. Т.е., каждая виртуалка у меня в виде единственного файла. Надо будет перевести из qcow2 в LVM? Если да, то как проще это сделать?

[GermSerg]

Кирилл:
примерно так(остановив машину):
1)qemu-img convert -f qcow2 -O raw файл_диска_виртуалки новый_файл_в _raw
2)dd if=новый_файл_в _raw of=/dev/mapper/ваш_диск_lvm
3)подключить том lvm к машине,попробовать загрузиться

какую платформу виртуализации используете?

[Кирилл]

GermSerg: KVM (на Ubuntu Server)

[younghacker]

Прежде всего ваш сервер должен иметь LVM.
Затем, для перевода виртуалки на LVM там должно быть свободное место. Иначе Вы не сможете сделать новый раздел для виртуалки.
Неопытные или ленивые пользователи Linux часто следуют указаниям инсталятора и используют автоматическую разметку диска, а она распределяет весь доступный объём диска под тома.
Свободного места должно хватать под виртуалку и под снапшот который во время бэкапа растёт от нуля до полного размера LV в худшем случае.
Другими словами если ваша виртуалка уже имеет LV размером 10 гиг то Вам лучше иметь 10 гиг нераспределённого пространства внутри LVM гипервизора.

Также нужно иметь ввиду что LVM для виртуалки это "честное" выделение места. Если вы не используете Thin Provisioning Тоесть если Вы ей выделяете 10 гиг - они будут зарезервинованы для неё. В случае с qcow место расходуется более экономно.

Переход формата можно делать так как показал GemSerg. Хотя я бы попробовал без промежуточного файла.

lvcreate -L 10G -n vm-disk-01 vg-vms
qemu-img convert -f qcow2 -O raw /dev/mapper/vg-vms_vm-disk-01

Размер LV тома должен быть не меньше полного размера qcow диска.

qemu-img info path_to_qcow_file
lvs --units b

А создать виртуалку и подключить LV диск можно через GUI Virtual Machine Manager.

Answer 2

[Алексей Тимофеев]

Смотрите в сторону bdsync и bdsync-manager
Возможно что-то придется доделать, но куда же без этого

Answer 3

[3ton]

В свое время(лет 5-6 назад) тоже задавался таким вопросом, решено было сделать на LVM. Теперь все просто решается клоном LVM и даже не выключаю виртуалки. У меня другой к Вам вопрос, а сколько у вас ядер? Если не ошибаюсь рекомендации к ядрам - не меньше чем кол-во виртуалок+хостовая.