Як копіювати віртуальні машини esxi з vim. Порівняння рішень для backup віртуальних машин від Veeam, Acronis і Symantec. Відновлення VMware з інтерфейсу Bweb Management Suite

Розглянемо і порівняємо два способи резервного копіювання віртуальних машин VMware.

Початкові дані

тестовий стендявляє собою два гипервизора ESXi на сервері Fujitsu Primergy BX2560 M2 підключені по SAN (два порти по 8 Gbit / s) і LAN (два порти по 10 Gbit / s). Версія ESXi і VSCA 6.5. Для ESXi диски презентовані системою зберігання даних Fujitsu ETERNUS DX8700 S2. В якості системи зберігання бекапа використовуємо EMC Data Domain 6300 підключений по SAN (чотири порти по 8 Gbit / s). Для виконання backup, в цілях економії часу, скористаємося готовим інструментом Backup Exec, сервер управління системи встановлено на фізичному сервері HP ProLiant BL460c Gen8 і так само має підключення до мережі по SAN і LAN двома портами.

Для тестування створено три віртуальних машини: VM1 (146Gb), VM2 (157GB) і VM3 (284Gb). Процедура тестування буде виглядати наступним чином: виконаємо три рази FULL Backupкожної системи, після цього обчислимо середню швидкість резервного копіювання (Gb / min) для кожного способу.

Система Backup Exec має чотири способи отримання доступу до даних віртуальної машини, для фізичного сервера це SAN, LAN (NBD), NBDSSL і четвертий, якщо сервер Backup Exec встановлений на віртуальній машині, HotAdd. Протестуємо варіант, коли Backup Exec встановлений на окремому фізичному сервері, порівняємо плюси і мінуси виконання бекапа по SAN і LAN.

Налаштування Backup Exec досить проста і складається з наступних кроків:

Вибрати існуюче або створити нове завдання на виконання бекапа віртуальних машин
Відкрити властивості цього завдання
Перейти на вкладку Virtual Machines> підрозділ VMware
Відзначити потрібний нам спосіб підключення (допустимо активувати відразу всі чотири способи і виставити їх черговість використання)

СПОСІБ ПЕРШИЙ: ЗАПАСНІ КОПІ§ ВІРТУАЛЬНИХ МАШИН ПО SAN

Для того, щоб Backup Server міг виконати бекап віртуальних машінESXi по SAN, йому необхідно в першу чергу презентувати ті ж LUN (-и), які були презентовані ESXi. В цьому випадку Backup Server, використовуючи vStorage API, запитує інформацію у vCenter, в якому LUN знаходиться VMDK віртуальноїмашини, робить моментальний знімок (snapshot) диска і забирає його по SAN.

В результаті цього експерименту середня.

СПОСІБ ДРУГИЙ: ЗАПАСНІ КОПІ§ ВІРТУАЛЬНИХ МАШИН ПО LAN (NBD)

В цьому режимі Backup Server запитує у vCenter відомості про те на якому ESXi знаходиться потрібна нам віртуальна машина, робиться моментальний знімок і виконує його передачу по локальній мережі з ESXi сервера на Backup Server.

В результаті другого експерименту середня.

ВИСНОВКИ, Плюси і мінуси

Якщо будувати з нуля сучасну інфраструктуру використовуючи мережеве обладнанняз пропускною спроможністю 10 Gbit / s, то застосування бекапа в режимі підключення до даних по локальній мережі (NBD) швидше за все, за витратами і часу виявиться більш ефективно. У разі, коли мережу між ESXi і Backup Host становить 1 Gbit / s, а необхідне обладнання для підключення по SAN вже є, то перший спосіб буде більш ефективний і швидкий.

Основний плюс виконання бекапа по SAN полягають в тому, що передача даних не завантажує локальну мережуі виконується на досить високій швидкості, але в разі 10 Gbit / s мережі це вже не є настільки явною перевагою, оскільки навіть при порівняно великих обсягах інформації вікно резервного копіювання займає незначне час.

Основний плюс виконання бекапа по LAN, це можливість використання більш дешевого обладнання в якості системи зберігання даних. І як показав тест, побудова сучасної мережіна 10 Gbit / s обладнанні забезпечить швидший бекап, ніж 8 Gbit / s SAN.

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

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

Використовувана в статті інформація взята з офіційних джерел.

Невеликий тест:
Локальна мережа - гігабіт.
На локальне сховище (апаратний RAID 10 з 4 дисків 10К) - «time dd if = / dev / zero of = / vmfs / volumes / datastore / temp bs = 1M count = 1K» 8 секунд.
На «linux» сховище ( програмний RAID 0 з 3 дисків 7,5К) - «time dd if = / dev / zero of = / vmfs / volumes / linbackup / temp bs = 1M count = 1K» 12 секунд.
На «windows» сховище (апаратний RAID 5 з 10 дисків 10К) - «time dd if = / dev / zero of = / vmfs / volumes / winbackup / temp bs = 1M count = 1K» 1 хвилина 44 секунди (сам в шоці) .

Результати говорять самі за себе. Так, на win-сховище RAID 5, але навряд чи він один винен у такому результаті.

З СГД розібралися, тепер треба автоматизувати резервне копіювання. Кращим безкоштовним засобом є скрипт ghettoVCB, щоб ним скористатися, треба отримати доступ до хосту ESXi по SSH. Як виявилося є дуже простий спосіб включення і виключення доступу прямо з vShere Client: Configuration> Software> Security Profile> Properties ...> Remote Tech Support (SSH)> Options ...> Start або Stop. За цим скриншотам думаю буде наочніше:

викачуємо останню версіюскрипта. Можна піти «тру» шляхом зробити як написано на сторінці скрипта в секції «Setup:», але я вчинив простіше - розпакував архів у себе на комп'ютері, замість редагування конфігураційного файлу - відредагував сам скрипт, скопіював його на локальне сховище (через «Browse Datastore »).

Ось основні параметри:

VM_BACKUP_VOLUME - шлях до папки бекапів, в моєму випадку / vmfs / volumes / linbackup
DISK_BACKUP_FORMAT - формат диска, thin для бекапів підходить найкраще
VM_BACKUP_ROTATION_COUNT - кількість збережених резервних копій (для кожної віртуальної машини), у мене 2
ADAPTER_FORMAT - тип адаптера, у мене lsilogic

Інші параметри можна і не правити, але якщо цікаво - на сторінці скрипта всі параметри докладно описані, правда англійською, майже всі параметри розписані по російськи.

Отже, скрипт скопійований на локальне сховище, підключаємося по ssh, переносимо скрипт куди небудь ближче до кореня, наприклад в /ghettovcb/ghettovcb.sh, якщо вам не потрібно бекапіть все віртуальні машини - необхідно створити файл зі списком бекапіруемих віртуалок:
cd / ghettovcb
vi vmlist
тиснемо «a» вписуємо імена віртуалок, кожне на новому рядку, Натискаємо «esc» і щоб зберегти зміни ": wq" або щоб вийти без збереження ": q"

Перенесення рядків повинні бути "\ n", при перенесення "\ r \ n" скрипт буде видавати помилку, тому не варто створювати список в блокноті, з подальшим копіюванням на сховище, якщо ви жодного разу не користувалися Notepad + або EmEditor і не знаєте що таке "\ n" і "\ r \ n" - краще створюйте список в vi.

Пробуємо запустити скрипт:

./ghettovcb.sh -f ./vmlist -l ./log.txt

./ghettovcb.sh -f ./vmlist -g ./ghettovcb.conf -l ./log.txt
Скрипт відпрацьовує, видаючи багато інформації, якщо в кінці виведення бачимо "###### Final status: All VMs backed up OK! ######" означає все добре, інакше - читаємо log.txt і розбираємося що зробили не так.
Тепер треба створити розклад для бекапів.
cd / var / spool / cron / crontabs
chmod u + w root
vi root
тиснемо «a», пишемо розклад, тільки врахуйте - час вказується в UTC, тобто для Москви це локальне час мінус три часа
00 20 * * * /ghettovcb/ghettovcb.sh -f / ghettovcb / vmlist -l / vmfs / volumes / linbackup / logs / `date +% F`.txt
або якщо ви створили файл конфігурації
00 20 * * * /ghettovcb/ghettovcb.sh -f / ghettovcb / vmlist -g /ghettovcb/ghettovcb.conf -l / vmfs / volumes / linbackup / logs / `date +% F`.txt
тиснемо «esc» і зберігає ": wq"
у підсумку
chmod u-w root

Тепер щодня о 20:00 за UTC (о 23:00 за київським часом) буде запускатися скрипт, логи про його виконанні будуть збережуться на сховище в папці logs, окремий лог на кожен день.

За логам у мене на бекап йде приблизно 4 години, порахував швидкість - приблизно 4 ГБ в хвилину, тобто приблизно 70Мб в секунду, вельми не погано. Сховища в 2,7ТБ вистачає на зберігання двох копій кожної виртуалки, цього цілком достатньо, плюс залишається вільне місце, а воно потрібно, тому що спочатку робиться третя резервна копія і тільки після її створення видаляється найстаріша копія.
Ну і ще один камінь в город «windows» сховища - пробував робити бекапи скриптом на нього, storage просто відвалювався, ну і власне скрипт завершувався з помилкою. Розумію, що вся справа в невірної настройкизаписи по NFS, але настройки були за замовчуванням і розбиратися в «тюнінг» не дуже то й хотілося.

Експеримент пройшов вдало, можна закуповувати сервер з хорошими дисками, Планується RAID 10 на 5ТБ, цього повинно з запасом вистачити і на майбутні виртуалки.

Теги: vmware, vsphere, esxi, backup, резервне копіювання

Існує відмінний безкоштовний скрипт для резервного копіювання віртуальних машин на VMWare ESXi сервері, причому він працює на free версії ESXi 4 і 5 версій без установки будь-яких додаткових приблуд типу VMA і т.п. Проблема тільки в тому, що інструкція там не зовсім точна, тому я довго возився з цим скриптом, щоб він все-таки заробив саме в автоматичному режимі ...

Детально расспісивать як пріконнектіца до ESXi по SSH я не буду, розпишу лише кроки налаштування, з якими все запрацювало у мене.

Спочатку качаємо скрипт за посиланням вище і заливаємо на сервер, заливати потрібно прямо в архіві! Найпростіше це зробити через vSphere Client. У мене на сервері два диска - на одному працюють машини, а на іншому лежать всякі iso-образи і самі бекапи. Називаються диски відповідно datastore1 і datastore2. Все бекапи, скрипт і конфіги лежать в папці backup. Ще зверніть увагу, що назви файлів і папок чутливі до регістру, тому якщо папка називається backup, А ви пишіть в скрипті Backup, То працювати не буде!

Заливаємо архів зі скриптом сюди / Vmfs / volumes / datastore2
Далі в SSH cd / vmfs / volumes / datastore2- переходимо в директорію зі скриптом
Розпаковуємо скрипт з архіву tar -zxvf імя_файла_архіва.tar.gz
Через vSphere перейменуйте розпаковану папку в щось простіше, наприклад просто backup
Тепер зайдемо в цю папку - cd backup
Створимо всередині неї папку для зберігання індивідуальних конфігов mkdir BackupConfig
тепер в BackupConfigзакинемо потрібні індивідуальні конфіги для машин, якщо вони не потрібні і всі машини треба бекапіть з однаковими настройками, Можна залишити її порожній
Поправити через редактор vi змінні в файлі конфігурації, Головне це шляху бекапа, тобто перший рядок змінюємо на таку: VM_BACKUP_VOLUME = / vmfs / volumes / datastore2 / backup, Ну а далі самі дивіться що вам ще потрібно - vi ghettoVCB.conf
створити скрипт StartBackup.sh(2 рядки) - vi StartBackup.sh
2 ю рядок, де виклик самого скрипта, можете переробити під себе
cd / vmfs / volumes / datastore2 / backup
./ghettoVCB.sh -a -g ./ghettoVCB.conf -c BackupConfig -l ghettoVCB.log
виконати chmod + x ghettoVCB.sh
виконати chmod + x StartBackup.sh

1 етап завершено! Тепер якщо запустити StartBackup.sh, То почнеться бекап. На час налагодження можете поміняти 2ю рядок на щось типу ось цього ./ghettoVCB.sh -a -g ./ghettoVCB.conf -c BackupConfig -l ghettoVCB.log -d dryrun- це дозволить запустити скрипт і відстежити хід виконання без самого копіювання дисків. Щоб резервне копіювання проводилося більш ефективно і швидко, рекомендую в налаштуваннях виставити тип диска thin.

Конфігурація Cron (для автоматичного запуску скрипта)

Дати дозвіл на запис в файл chmod + w
Додаємо через vi рядок в / Var / spool / cron / crontabs / root
15 0 * / 3 * * /vmfs/volumes/datastore2/backup/StartBackup.sh
Запуск в 00:15 ночі кожні три дні. У мене часовий пояс +4 Москва, тобто насправді скрипт запускається о 4:15 ранку, це буде видно по даті зміни балки через vSphere. Само собою час і періодичність можете вибрати інші.
Тепер потрібно виконати дві команди, щоб перезапустити cron
kill $ (cat /var/run/crond.pid)
crond
Додати за допомогою vi 3 рядки в самий кінець файлу /etc/rc.local
Це потрібно, тому що після перезавантаження сервера вміст файлу з 2го пункту з запуском нашого скрипта буде відновлено до попереднього стану, Тому в rc.local вказуємо, що після перезавантаження потрібно виконати наступні команди - зупинка cron, додавання рядка для автоматичного запускускрипта і запуск cron.
/ Bin / kill $ (cat /var/run/crond.pid)
/ Bin / echo "15 0 * / 3 * * /vmfs/volumes/datastore2/backup/StartBackup.sh» >> / var / spool / cron / crontabs / root
crond
Тепер виконаємо виконати команду /sbin/auto-backup.sh, Щоб упевнитися, що всі наші зміни збереглися.

Невелике пояснення - чому потрібно створювати скрипт StartBackup.sh, А не просто взяти і його вміст помістити в / Var / spool / cron / crontabs / root? Існує якесь обмеження на розмір цього файлу і частина рядків в ньому просто не буде працювати, хоча можете спробувати зробити і так, спочатку у мене працювало, але потім, мабуть, вийшли якісь патчі і перестало. Більш того, це просто зручніше - якщо буде потрібно змінити розклад резервного копіювання, то ви просто керуєте файл StartBackup.shі не потрібно танців з бубном навколо cron з його перезапуском і внесенням тих же змін у /etc/rc.local.

PS: Час йде, Все змінюється, сам скрипт змінюється, ESXi5 вже вийшов, так що десь, щось може вже і не працювати 🙂

Додаток: Синтаксис cron

Команда cron виглядає ось так:

1 2 3 4 5 /vmfs/volumes/datastore2/backup/StartBackup.sh

де,
1: Хвилини (0-59)
2: Годинники (0-23)
3: Дні (0-31)
4: Місяці (0-12)
5: День тижня (0-7)

Кілька прикладів:

Запуск в 5 хвилин на першу ночі, кожен день
5 0 * * * /vmfs/volumes/datastore2/backup/StartBackup.sh
Запуск о 2:15 кожен перший день місяця
15 14 1 * * /vmfs/volumes/datastore2/backup/StartBackup.sh
Запуск о 22:00 кожного робочого дня
0 22 * * 1-5 /vmfs/volumes/datastore2/backup/StartBackup.sh
Запуск в 23 хвилини після півночі і далі кожні дві години (2:23, 4: 23 ... і т.д.), кожен третій день
23 0-23 / 2 * * * / 3 /vmfs/volumes/datastore2/backup/StartBackup.sh

на даний моментіснує кілька виробників програм для резервного зберігання, як платних, так і безкоштовних. Ми визначилися, що безкоштовні програмиабо незручні у використанні (складна установка, постійна загроза збою, відсутність власних інтерфейсів), або в них відсутні найважливіші опції бекапа. У цьому випадку варто придбати платну програму, Яка, на відміну від безкоштовної, буде повністю працездатною з усіма основними функціями бекапа. Нижче наведено список кращих, на думку експертів, рішень для бекапа:

Veeam BackUp & Replication 5

Ці програми є основними програмами для бекапа, що використовуються більшістю користувачів:

Data Recovery з підтримкою VCenter Server

Як уже писалося в минулому, це найвірніший спосіб створення бекапа машини, якщо куплений VCenter Serverі більш немає ні бажання, ні коштів займатися цим питанням. налаштовується дана технологіядосить легко, повне керівництвоможна знайти за наступним посиланням:

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

Цей продукт зараз досить популярний, так як тип ліцензування даного продукту (ліцензується по сокета) для серверних з малопотужними серверами буде вкрай вигідний. Нижче ми розглянемо декілька комплектацій серверів і розглянемо цінові характеристики. Також цей продукт підтримує опцію миттєвого відновлення даних після збою завдяки своїй технології vPower.

Також з недавнього часу випускає засоби для бекапа в віртуальних середовищах. Крім того, Symantec - єдине з усіх рішень бекапа використовує технологію V2P (конвертація віртуальної середовища на фізичні сервери). Правда, Vcenter володіє такою технологією, але вже не в рамках технології резервного копіювання

Але на цьому можливості акроніс не обмежуються. Компанія Acronisвключіла в пакет Acronis Backup & Recovery 10 AdvancedServer VirtualEdition ще одну функцію, це консолідація серверів для перекладу систем з фізичних на віртуальні платформи, Причому з вбудованим планувальником завдань. У підсумку маємо, що дана програмавиконує 2 основні функції:

Екстрене відновлення систем

консолідація серверів

Основні переваги в порівнянні з іншими технологіями:

Можливість роботи, як з фізичними серверами, так і у віртуальному середовищі, що дозволяє на початкових етапах розвитку компанії поєднати консолідацію при високих оцінках надійності

Широкий спектр підтримуваних пристроїв зберігання резервних копій(Аж до оптичних пристроїв і магнітних стрічок)

Створення розділу Acronis Secure Zone на тому ж сервері ВМ, що дозволяє відновити машину за короткий термін, причому цей розділ буде захищений режимом дедуплікаціі на іншому сервері

Якщо резервне копіювання - це одна з наших основних цілей незалежно від ціни нам, безсумнівно, варто вибирати між рішеннями компаній Veeam, Acronisілі Symantec. Обидва ці продукту є лідерами резервного копіювання та зберігання даних, а також мають ряд індивідуальних переваг.

У виборі між цими технологіями необхідно провести межу по декільком разграничениям:

Тип ліцензування

Характеристики

Обсяг і періодичність бекапа

при різному типіліцензування варто вирішити, який підходить найбільше нам. Якщо у нас потужні сервери з великою кількістюсокетов під процесори, варто схилятися на користь Acronisі Symantec. Якщо у нас багато слабких серверів з невеликою кількістюсокетов, кращим варіантом буде Veeam.

Також необхідно зрозуміти, що нам потрібно, тобто, які вимоги ми будемо пред'являти до резервного копіювання, наявність тих функцій, які особливо важливі для нас.

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

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

Безкоштовний backup (резервне копіювання) віртуальних машин на базі VMware ESXi

для VMware ESXiпитання резервного копіювання віртуальних машинстоїть особливо гостро. Додаткове безкоштовне ПО незручно у використанні через обмежений функціоналу. Тому наш backupбуде заснований на безкоштовному скрипте — ghettoVCB. Це найкращий варіант існуючих скриптів, хоча у нього таке веселе назву і всього проекту в цілому - www.virtuallyghetto.com, автор William Lam. Його алгоритм - створення снапшотов і клонування VM.

Для настройки повноцінної схеми резервного копіювання нам буде потрібно:

NFSсервер для зберігання файлів;
підключення по SSHдо ESXi;
скрипт ghettoVCB.shдодається на сервер ESXi (в корінь або папку майбутнього бекапу). Це робиться через SFTPбудь-яким зручним для вас способом, наприклад, FileZilla;
даємо права на виконання скопійованого скрипта;

Тепер більш детально зупинимося на кожному з пунктів. Для підвищення швидкодії і відмовостійкості файлового сервера / сервера резервного копіювання краще використовувати RAID10. Слід надавати перевагу в даному випадку є ОС Linux (Debian, Ubuntu, «зручна вам») і файлова система XFS, Тому що в такій конфігурації швидкість запису (основний пріоритет для швидкого бекапа) буде вище.

Вже є у нас, але також можна все виконати і в vSphere client: Configuration> Software> Security Profile> Properties ...> Remote Tech Support (SSH)> Options ...> Start або Stop.

Переходимо до конфігурації скрипта ghettoVCB.sh, Основні параметри, які нам знадобляться:

VM_BACKUP_VOLUME - шлях до папки бекапів, в моєму випадку / vmfs / volumes / datastore1 / backup
DISK_BACKUP_FORMAT - формат диска, thin для бекапів підходить найкраще
VM_BACKUP_ROTATION_COUNT - кількість збережених резервних копій (для кожної віртуальної машини), у мене 3
ADAPTER_FORMAT - тип адаптера, в моєму випадку - lsilogic

Інші параметри відповідають за копіювання файлів по мережі і e-mail повідомлення. Детальніше параметри конфігурації описані на сайті розробника.!

Якщо необхідно копіювати не всі віртуальні машини, то створюється файл зі списком VM, включених в бекап. Створюємо такий файл в vi:

переходимо в папку зі скриптом - cd / ghettovcb або backup
vi vmlist
натискаємо «a» вписуємо імена VM (кожне ім'я на новому рядку)
натискаємо «esc» і щоб зберегти зміни - «: wq» (без збереження «: q»)

Запускаємо скрипт:

./ghettovcb.sh -а -l ./log.txt - запуск копіювання всіх машин, запис логфайлів в тій же директорії
./ghettovcb.sh -f ./vmlist -l ./log.txt - запуск копіювання машин, зазначених у файлі vmlist, логи зберігаються в тій же директорії
./ghettovcb.sh -f ./vmlist -g ./ghettovcb.conf -l ./log.txt - аналогочно, тільки з іспользованіем.conf файлу

Про коректному виконанні скрипта буде сигналізувати рядок з написом: «###### Final status: All VMs backed up OK! ###### ». Якщо такого немає - перевіряйте логи, синтаксис команд і шляхів до файлів.

Для того, щоб додати рядок на запуск за розкладом (в cron), необхідно виконати правку файлу «/etc/rc.local.d/local.sh», виконавши наступне:

перейти в каталог /etc/rc.local.d/local.sh
chmod u + w local.sh
відкрити файл редактором - vi local.sh
включити редагування клавищи "i" або "insert»
дописати перед рядком exit0 наступне:

/ Bin / kill $ (cat /var/run/crond.pid)
/ Bin / echo 0 20 * * * /vmfs/volumes/datastore/script/ghettoVCB.sh -a -l /vmfs/volumes/backup/log/log.txt >> / var / spool / cron / crontabs / root
/ Bin / crond

при цьому зазначаємо розклад (час вказується в UTC, тобто для MSK -3 години), тобто «00 20 * * *«
натискаємо «esc» і зберігається - «Shift +:» і «wq»
в кінці виконуємо chmod u-w local.sh

Таким чином, в 23:00 за МСК буде виконуватися резервне копіювання файлів віртуальних машин. У нашому випадку буде залишатися 3 копії.

Налаштування backup для ESXi через ghettoVCB.shзавершена.