1. Вступ
2. Який диск вибрати в kvm - lvm, raw (img) або qcow2
3. Бекап віртуальної машини kvm без зупинки
4. Установка qemu-guest-agent
5. Скрипт для автоматичного бекапа віртуальних машин KVM
6. висновок
7. Онлайн курс по Linux

Деякий час назад перейнявся вирішенням питання бекапа віртуальних машин kvm. Коли став розбиратися в темі, з подивом виявив, що якихось зручних, усталених рішень для гарячого бекапа віртуальних машин без зупинки роботи в kvm нема. Ні комерційних рішень не побачив, ні безкоштовних. Довелося самому вникати в суть і розбиратися в темі.

Якщо у вас є бажання навчитися працювати з роутерами мікротік і стати фахівцем в цій галузі, рекомендую за програмою, заснованої на інформації з офіційного курсу MikroTik Certified Network Associate. Курс стоїть, всі подробиці читайте за посиланням. Є безкоштовні курси.

Вступ

З гіпервізором kvm особисто мені доводилося мало працювати. Ще в перше моє знайомство з гіпервізорами, коли я вибирав, який використовувати в своїй роботі, kvm мені не сподобався взагалі сюди через наступні випадки:

1. Ні зручного інструменту для управління гіпервізором під Windows. Для мене це критично, так як моя основна робоча система ОС Windows.
2. Не побачив готового образу, який би дозволив швидко і без зайвих рухів розгорнути гипервизор на новому залозі.

У підсумку я зупинився на Xen там, де потрібно поставити систему на програмний рейд mdadm, і Hyper-V в тих випадках, де рейд або не потрібен зовсім, або він апаратний. У своїй роботі так чи інакше доводиться стикатися з різними системами, тому розбиратися доводиться у всьому, в тому числі і в kvm.

Є 2 різних способу зробити бекап віртуальної машини kvm:

1. Із зупинкою або заморожуванням системи на короткий проміжок часу.
2. Без зупинки системи взагалі.

Для першого випадку все відносно просто, якихось нюансів немає. У другому випадку виникають нюанси і питання. Просто взяти і зробити гарячий бекап віртуальної машини в kvm не вийде. Питання розгляду архівних копій віртуальних машин потрібно починати з вибору типу жорсткого диска, який буде використовуватися. Залежно від цього буде різна стратегія бекапа. З цього ми і почнемо.

Відразу хочу пояснити, що не маю великого досвіду в роботі з kvm і можливо щось роблю неправильно. Дана стаття мій досвід самостійного пошуку рішення і закріплення його для себе і всіх, кому це буде цікавим.

Який диск вибрати в kvm - lvm, raw (img) або qcow2

У kvm є кілька типів дисків, які ви можете використовувати в своїй роботі. Вони мають принципові відмінності як по своїй роботі, так і за способами бекапа. Вибирати той чи інший тип потрібно в залежності від ваших завдань. Розглянемо ці типи докладніше.

LVM. Тут все зрозуміло. Використання lvm томів у вигляді дисків віртуальних машин. Такий диск буде блоковим пристроєм і повинен працювати швидше всіх інших типів, так як немає зайвої прошарку у вигляді файлової системи.

плюси:

• Снепшот засобами самого lvm, з них легко зняти бекап без зупинки віртуальної машини.
• Максимальна швидкодія.
• Легко змінити розмір диска.

мінуси:

• Більш складне управління в порівнянні з дисками у вигляді окремих файлів.
• Менш гнучке управління простором диска. Якщо весь диск розбити на lvm розділи для віртуалок, то місця на ньому не залишиться, навіть якщо віруталкі будуть порожні.
• Більш складний перенесення на інший сервер.

RAW. Це звичайний формат сирих даних. Серед дисків у вигляді файлів це буде самий простий і швидкий варіант. Всі дані пишуться як є без додаткових обробок і службової інформації. Формат є універсальним для більшості популярних гіпервізора.

плюси:

• Максимальна простота і продуктивність серед образів у вигляді файлу.
• Універсальний формат з підтримкою в більшості гіпервізора.
• Легкість перенесення віртуальної машини на інший сервер. Досить просто скопіювати файл.

мінуси:

• Не підтримує снепшот ні в якому вигляді.
• Займає відразу все виділений простір на диску, навіть якщо всередині віртуальної машини місце буде вільно. Через відсутність фрагментації в деяких випадках це може виявитися плюсом.

QCOW2. Рідний формат для гипервизора QEMU. Розшифровується як QEMU Copy-on-write. Цей формат дозволяє створювати динамічні диски для віртуальних машин, а так само підтримує снепшот. Теоретично, швидкість роботи повинна хоч і не сильно, але поступатися RAW. Як йде справа на практиці, я не знаю, не заміряв і докладно цю інформацію не перевіряв.

плюси:

• Підтримка снепшот і динамічних дисків. Як наслідок - більш зручне управління дисковим простором.
• Легкість перенесення віртуальної машини на інший сервер. Досить просто скопіювати файл.

мінуси:

• Більш низька продуктивність, в порівнянні з іншими типами образів.

У кожного типу є свої переваги і недоліки. Lvm найпростіше бекапіть, але їм найскладніше управляти. Для того, хто добре знайомий з lvm це не проблема, якщо стикаєшся вперше, то виникає багато питань. У raw немає снепшот, особисто для мене це великий мінус, я цей формат взагалі не розглядаю. Якщо немає максимального навантаження на дискову підсистему, то QCOW2 мені здається найбільш прийнятним варіантом. Власне, нижче і піде розповідь, як поєднати зручність управління QCOW2 і простоту бекапов і снепшот lvm. Я покажу, як зробити живий бекап віртуальної машини kvm в форматі qcow2 без зупинки віртуальної машини.

Бекап віртуальної машини kvm без зупинки

Перед практичною реалізацією живого бекапа віртуальної машини, знову трохи поговоримо про теорію. Для бекапа віртуальної машини kvm досить просто скопіювати її диски у вигляді файлів. Це можна зробити навіть при працюючій машині. Але якщо в цей момент на виртуалке йде якась дискова активність, ви швидше за все отримаєте непрацюючий образ. І це логічно. Значить нам, щоб гарантовано скопіювати диск, віртуальну машину потрібно вимкнути, або придумати щось ще.

Це «щось ще» є снепшот. Ми можемо зробити під час бекапа снепшот віртуальної машини, зафіксувавши її стан і зробити копію з цього снепшот. Після завершення копіювання снепшот об'єднується з основним файлом і машина продовжує працювати в штатному режимі. Завершувати роботу або заморожувати віртуальну машину в даному випадку немає необхідності.

З самими снепшот теж є нюанси. Є 2 різних типи снепшот. Наприклад, якщо ви зробите снепшот qcow2 засобами virt-manager, то здивуєтеся, не побачивши новий файл снепшот. Виявляється, снепшот буде створений всередині qcow2, а файл як був один, так і залишиться. Це дуже незручно, тому що якщо у вас буде зайнятий весь доступний для файлу обсяг, ви гарантовано отримаєте помилку при старті вашої виртуалки. А контролювати обсяг диска, в якому знаходяться снепшот важко і незручно. І бекапи в такому випадку робити теж не вийде. Хоча вийде, але все одно не зручно. Потрібно буде окремими командами конвертувати стан віртуальної машини до снепшот в окремий файл і його вже забирати для бекапа. Плюс до всього машину в цьому випадку потрібно буде заморозити на момент створення знімка. Замороження буде короткочасною, але все одно без неї не обійтися. Я приведу для прикладу команди, якими це можна робити, але сам я не став використовувати такий спосіб, тому що, по-перше, не зміг знайти команди на об'єднання снепшот і основного файлу, по-друге, мене не влаштовує навіть короткочасна заморозка системи.

Заморожуємо виртуалку:

# Virsh domfsfreeze vm-name

Робимо снепшот:

# Qemu-img create -f qcow2 -b vm-name.qcow2 vm-name-snapshot.qcow2

розморожуємо

# Virsh domfsthaw vm-name

Конвертуємо снепшот в окремий образ:

# Qemu-img convert -O raw vm-name-snapshot.qcow2 /backup-vm/vm-name-snapshot.img

Перетворюємо raw назад в qcow2:

# Qemu-img convert -O qcow2 /backup-vm/vm-name-snapshot.img /backup-vm/vm-name-snapshot.qcow2

Після цього треба об'єднати знімок з іншим файлом. Я не став шукати, як це зробити, так як тут використовується заморозка віртуальної машини, хоч і короткочасна, але я хочу обійтися без неї. Тому я став далі шукати варіанти.

В рунеті я взагалі не знайшов інформації, як все зробити красиво, зручно і швидко. Знайшов інструкцію офіційному сайті libvirt - http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit Далі фактично буде переклад з моїми поясненнями.

Установка qemu-guest-agent

Ми будемо робити снепшот засобами virsh. При цьому зупинки або заморозки системи не буде взагалі. Щоб цей варіант коректно працював, вам необхідно встановити на віртуальну машину qemu-guest-agent. Для цього вам спочатку потрібно додати Channel Device по імені org.qemu.guest_agent.0. Найпростіше це зробити через virt-manager.

Потім в систему треба встановити пакет qemu-guest-agent. Для debian і centos все просто:

# Apt-get install qemu-guest-agent # yum install qemu-guest-agent

Для windows треба з диска virtio-win встановити пакет qemu-ga з папки guest-agent, яка знаходиться в корені диска.

Детальніше про встановлення qemu-guest-agent можна прочитати в документації redhat . Тепер у нас все готово для виконання живого бекапа віртуальної машини в kvm без зупинки цієї виртуалки.

Виконуємо снепшот віртуальної машини:

# Virsh snapshot-create-as --domain vm-name backup-snapshot -diskspec vda, file = / snapshot / vm-name-backup.qcow2 --disk-only --atomic --quiesce --no-metadata vm- name ім'я віртуальної машини backup-snapshot назву снепшот, може бути будь-яким vda ім'я диска, для якого вказуємо адресу снепшот /snapshot/vm-name-backup.qcow2 шлях і ім'я файлу для снепшот

Для того, щоб дізнатися імена дисків віртуальної машини, скористайтеся командою:

# Virsh domblklist vm-name

Звертаю увагу на важливий момент, який я спочатку упустив і довго не міг розібратися в логіці створення снепшот. Параметр diskspec не вказує для якого диска створюється снепшот, а просто позначає шлях до снепшот. Якщо у вас декілька дисків, а в diskspec ви вказали тільки один диск, то снепшот все одно будуть створені для всіх дисків. При цьому для тих дисків, де ви вказали шлях, буде використовуватися вказаний, а для інших буде по-замовчуванню в тій же папці, де лежить вихідний файл ВМ. Цей нюанс серйозно змінює логіку роботи скриптів для автоматизації бекапа в тому випадку, якщо у машин кілька дисків. Написавши скрипт для бекапа машин з одним диском, у мене не вийшло його швидко оптимізувати для кількох.

Після того, як зробили знімок, скопіюйте куди вам потрібно основний файл віртуальної машини. Я вважаю за краще його відразу стискати усіма ядрами процесора за допомогою архіватора pigz:

# Pigz -c /virt/vm-name.qcow2> /backup-vm/vm-name.qcow2.gz

Коли виконання бекапа завершено, об'єднаємо снапшот з основним файлом:

# Virsh blockcommit vm-name vda --active --verbose --pivot

Після цього файл снепшот можна видалити:

# Rm /snapshot/vm-name-backup.qcow2

Для повноти картини забекапіть ще і настройки виртуалки:

# Virsh dumpxml vm-name> /backup-vm/vm-name.xml

І на цьому все. Ми зробили повний бекап працює віртуальної машини kvm без її зупинки. Сама вона навіть не зрозуміла, що з нею щось зробили. Працюючі БД на ній не мають жодних проблем. Перевіряв на postgresql. Термінальні сесії в windows server теж відчувають себе відмінно.

Скрипт для автоматичного бекапа віртуальних машин KVM

За мотивами всього написаного вище я накидав простенький скрипт для автоматичного живого бекапа всіх дисків всіх працюючих в момент виконання скрипта віртуальних машин. Звертаю увагу, що бекап все диски. Скрипт привожу просто для прикладу, не використовуйте його, якщо вам не потрібні повні бекапи всіх дисків. Особисто я бекаплю тільки невеликі системні диски. Все, що багато важить, вважаю за краще архівувати іншими способами вже зсередини віртуальної машини. Якщо це бази даних, то роблю бекапи потрібних баз postgresql , Якщо це файловий сервер, то використовую rsync для створення інкрементних бекапов . Ну і так далі. Кожен вибирає кошти на свій смак.

#! / Bin / bash # Дата рік-місяць-день data = `date +% Y-% m-% d` # Папка для бекапів backup_dir = / backup-vm # Список працюючих VM vm_list =` virsh list | grep running | awk '{print $ 2}' '# Список VM, заданих вручну, через пробіл # vm_list = (vm-1 vm-2) # Лог файл logfile = «/ var / log / kvmbackup.log" # Використовувати цю умову, якщо список VM задається вручну #for activevm in "$ {vm_list [@]}"; # Використовувати цю умову, якщо список працюючих VM береться автоматично for activevm in $ vm_list do mkdir -p $ backup_dir / $ activevm # Записуємо інформацію в лог з секундами echo "` date + "% Y-% m-% d_% H-% m-% S "` Start backup $ activevm ">> $ logfile # бекапіть конфігурацію virsh dumpxml $ activevm> $ backup_dir / $ activevm / $ activevm- $ data.xml echo" `date +"% Y-% m-% d_ % H-% M-% S "` Create snapshots $ activevm ">> $ logfile # Список дисків VM disk_list =` virsh domblklist $ activevm | grep vd | awk '{print $ 1}' '# Адреса дисків VM disk_path = `virsh domblklist $ activevm | grep vd | awk '{print $ 2}' '# Робимо снепшот диск virsh snapshot-create-as --domain $ activevm snapshot --disk-only --atomic --quiesce --no-metadata sleep 2 for path in $ disk_path do echo " `date +"% Y-% m-% d_% H-% m-% S "` Create backup $ activevm $ ​​path ">> $ logfile # виокремлювати ім'я файлу з шляху filename =` basename $ path` # бекапіть диск pigz -c $ path> $ backup_dir / $ activevm / $ filename.gz sleep 2 done for disk in $ disk_list do # Визначаємо шлях до снепшот snap_path = `virsh domblklist $ activevm | grep $ disk | awk '{print $ 2}' `echo" `date +"% Y-% m-% d_% H-% M-% S "` Commit snapshot $ activevm $ ​​snap_path ">> $ logfile # Об'єднуємо снепшот virsh blockcommit $ activevm $ disk --active --verbose --pivot sleep 2 echo "` date + "% Y-% m-% d_% H-% m-% S" `Delete snapshot $ activevm $ ​​snap_path" >> $ logfile # Видаляємо снепшот rm $ snap_path done echo "` date + "% Y-% m-% d_% H-% m-% S" `End backup $ activevm" >> $ logfile done

Звертаю увагу на кілька моментів:

vm_list може або автоматично заповнюватися списком працюючих віртуальних машин, або можна вручну вказати список тільки тих машин, які потрібно бекапіть. Для цього потрібно розкоментувати відповідний рядок на початку скрипта при оголошенні змінної. Потім вибрати відповідний рядок для циклу for. Він буде трохи різним, залежно від списку.

Снепшот будуть створюватися в тій же папці, де зберігається основний файл даних. На час налагодження раджу для початку закомментировать рядок з видаленням снепшот, про всяк випадок. Рекомендую цей крипт прогнати спочатку на тестовому сервері. Я його написав на прикладі одного гипервизора, більше ніде не перевіряв. Але працює він однозначно, я перевірив кілька разів з різними списками VM. У підсумку залишив його у себе на сервері в роботі.

Для регулярного очищення бекапов, якщо вони у вас будуть зберігатися десь в доступному з цього сервера місці, можна додати в самий кінець умова очищення. Для повного бекапа VM мені бачиться нормальної схема зберігання резервних копій в кілька місяців, зі створенням архівів раз в тиждень. Найчастіше бекапіть системні диски не бачу сенсу, там рідко бувають щоденні зміни.

/ Usr / bin / find / backup-vm / * / -type f -mtime +90 -exec rm -rf {} \;

Дана команда видалить всі файли старше 90 днів в папках з назвами віртуальних машин, розташованих в / backup-vm.

висновок

На початку статті я сказав, що не зустрів готового рішення по живому бекапіть kvm. (Upd. Уже після публікації статті мені підказали готове рішення kvmBackup .) Насправді це не зовсім вірно. Є хороша готова збірка на основі kvm - proxmox. Я детально розглядав її в окремому матеріалі - Установка і настройка proxmox . Але все ж це рішення конкретного колективу розробників зі своїми можливостями і помилками. У проксмокс реалізований живою бекап віртуальних машин з коробки. На жаль, я не зміг швидко знайти технічну реалізацію їх вирішення. Можливо, все було б набагато простіше. Але так теж нічого вийшло.

Онлайн курс по Linux

Якщо у вас є бажання навчитися будувати і підтримувати високодоступних і надійні системи, рекомендую познайомитися з онлайн-курсом «Адміністратор Linux» в OTUS. Курс не для новачків, для надходження потрібні базові знання з мереж і установці Linux на виртуалку. Навчання триває 5 місяців, після чого успішні випускники курсу зможуть пройти співбесіди у партнерів. Що дасть вам цей курс:

• Знання архітектури Linux.
• Освоєння сучасних методів та інструментів аналізу і обробки даних.
• Уміння підбирати конфігурацію під необхідні завдання, управляти процесами і забезпечувати безпеку системи.
• Володіння основними робочими інструментами системного адміністратора.
• Розуміння особливостей розгортання, налаштування і обслуговування мереж, побудованих на базі Linux.
• Здатність швидко вирішувати виникаючі проблеми і забезпечувати стабільну і безперебійну роботу системи.

Перевірте себе на вступний тест і дивіться докладніше програму по.

Важливе доповнення в самому кінці. Не забувайте перевіряти можливість відновлення систем з ваших резервних копій. Адже кінцева мета не зробити бекап, а відновитися з нього !!!

Допомогла стаття? Є можливість віддячити автора