VMware Backup - резервне копіювання віртуальних машин
Для створення резервних копій VMware у Handy Backup можуть використовуватися два методи: внутрішній та зовнішній.
Внутрішній метод
Копія Handy Backup встановлюється на віртуальну машину VMware під керуванням Windows або Linux. Експлуатація Handy Backup на віртуальній машині нічим не відрізняється принципово від використання аналогічного рішення на "фізичних" комп'ютерах.
Зовнішній метод
Handy Backup запускається на сервері віртуальних машин VMware для копіювання образів конкретних копій VMware як звичайних файлів. Handy Backup використовує для резервного копіювання машин та масивів VMware спеціальний плагін, що працює в гарячому режимі (без зупинки машини VMware).
Як зберегти образ віртуальної машини VMware
- Відкрийте Handy Backup та створіть нове завдання, натиснувши Ctrl+N або вибравши пункт меню. Виберіть завдання резервного копіювання.
- На Кроку 2 виберіть плагін "VMware Workstation".
- Двічі клацніть на рядку “Нова конфігурація”, щоб вибрати конфігурацію доступу до VMware.
- У діалозі, що відкрився, зробіть вибір між режимами "Hot(резервне копіювання без зупинки машини) та "Enable suspend(з зупинкою віртуальної машини для отримання її точного образу).
- Далі оберіть у діалозі конкретний образ машини, до якого буде застосована ця конфігурація.
Описана вище послідовність дій зупинятиме, а потім перезапускатиме віртуальні машини VMware без будь-якого додаткового втручання.
Рекомендоване рішення
від 29990 ₽ за ліцензію
Handy Backup Server Network
За допомогою рішення Handy Backup Server Network Виконуйте бэкап віртуальних машин VMware на будь-які пристрої. Безкоштовний пробний період – 30 днів!
Спробуйте всю потужність інструменту резервного копіювання VMware, завантаживши найсвіжішу версію Handy Backup зараз. 30-денний безкоштовний період допоможе вам ефективно освоїти бекап ваших даних з Handy Backup!
Версія 8.5.8 від 31 жовтня 2024 року. 118 MB
30-денний повнофункціональний пробний період
Читайте також:
- Резервне копіювання VirtualBox – методи бекапу віртуальних машин VirtualBox.
- Резервне копіювання Hyper-V – створення резервних копій віртуальних машин серед Hyper-V.
- Бекап KVM – резервне копіювання віртуальних машин KVM.
Рейтинг Capterra:
"Проста та ефективна програма, відмінне рішення для бекапу"
Як зробити бекап конфігурацій vmware esxi та баз даних SQL
Всім привіт, раніше я вже розповідав як зробити бекап esxi за допомогою PowerCLi команд, він працює чудово, але днями на просторах інтернету натрапив на чудову утиліту vSphere Configuration Backup, яка повз бекап esxi, вміє ще й робити резервну копію баз даних VMware vCenter Звичайно, якщо у вас MS SQL, то краще таку процедуру налаштувати там. Нижче розглянемо утиліту vSphere Configuration Backup детальніше.
Можливості vSphere Configuration Backup
- Автоматичне резервне копіювання конфігурацій серверів ESXi 5 та 6
- Резервне копіювання будь-якої локальної бази даних та її конфігурації.
- Керування точками відновлення та видалення застарілих бекапів (тільки для бекапів ESXi).
- Для всього бекапу конфігурацій vmware esxi створюється лише один файл.
- В імені архіву бекапу вказаний номер білда vmware esxi.
- Стискає резервні копії конфігурації ESXi для збереження місця на диску.
- Не потребує встановлення.
- Шифрує паролі.
- Налаштовується із GUI через Configuration Manager.exe.
Налаштування vSphere Configuration Backup
Для початку потрібно скачати утиліту, я виклав її на яндекс диск, щоб було зручно її отримати. Розпаковуємо архів із програмою. Перед вами структура файлів, програма не потребує встановлення. Все налаштування здійснюється через файл Configuration Manager.exe
Як зробити бекап конфігурацій vmware esxi та баз даних SQL-02
Насамперед необхідно додати ESXI хост або vCenter. Вводимо логін та пароль для доступу та натискаємо Save.
Додавання vmware esxi
Якщо облікові дані підходять, то ви побачите, що успішно з'єдналося з хостом.
Додавання vmware esxi
Після цього відкриється текстовий файл зі скриптом.
Файл із скриптом з'єднання
На вкладці SQL Database можна вибрати яку базу даних потрібно забекапити, і відразу можна зробити тестове завдання, кнопкою Test backup.
вибір бази даних vmware esxi
Вкладка Settings дозволяє задати місце розташування резервної копії, якщо ви знизу бачите, що у вас відсутні vSphere CLI, то їх потрібно доставити, скачати vSphere CLI можна на тій самій сторінці, що і vSphere Configuration Backup, так само з яндекс диска.
Як зробити бекап конфігурацій vmware esxi та баз даних SQL
Після інсталяції vSphere CLI бачимо, що все ОК.
Встановлення vSphere CLI
Запускаємо vSphere Configuration Backup.exe
esxi запуск резервного копіювання
Почнеться з'єднання з потрібним хостом esxi
Якщо ви отримали ось таку помилку, вся справа в тому, що ваш хост управляється VMware vCenter і бекапити потрібно його, додамо не esxi в утиліті, а vCenter. У результаті будуть зроблені бекапи всіх хостів, якими він керує.
Дуже корисно почитати файл readme, який містить команди як потім відновити резервну копію конфігурації ESXi. Тут теж пишуть про хостів під управлінням vCenter.
Ось така корисна утиліта дозволяє робити резервні копії бд VMware vCenter і конфігурацій ESXI хостів.
Популярні Схожі записи:
- Як увімкнути буфер обміну в vSphere Client (HTML5)
- Помилка Unable to apply DRS resource settings on host
- Помилка видалення диска в ESXI: The resource is in use
- Як скачати та аналізувати дамп ESXI
- Помилка DRS на кластері ESXI
- Помилка запуску VM: File system specific implementation of Ioctl[file] failed
Як зробити бэкап віртуальних машин у vmware esxi veeam
Є безліч способів виконати резервне копіювання окремої інформації або цілих серверів. FREE.
Вступ
Раніше я вже неодноразово розглядав питання резервного копіювання даних або цілих серверів linux.
Але ось відновити його на іншому залозі буде не так просто. темі initramfs і grub. Сам я не дуже розуміюся на нюансах роботи цих інструментів і дуже не люблю з ними возитися.
Деякий час тому з'явився відмінний безкоштовний продукт для бекапу всього сервера. Про це йдеться про Veeam Agent for Linux FREE. на іншому залозі.
Відразу розповім про деякі нюанси роботи безкоштовної версії, з якими зіткнувся у процесі експлуатації чудового продукту від Veeam.
- Бекап можна зробити або всього сервера відразу, або окремого диска, або окремих папок та файлів. При виборі бекапу всього диска чи сервера, не можна встановити винятки для окремих папок або файлів. Це дуже незручно, але на жаль і ах, такий функціонал. Винятки можна зробити лише якщо ви робите бекап на рівні папок.
- Бекап можна покласти локально на сусідній розділ, якщо робите резервну копію розділу, локально до папки - якщо робите бекап файлів та папок. Якщо бекапіте всю систему повністю, то віддалено по smb і nfs. На жаль, ftp або sftp програма не працює.
Як сховище для архівів може бути репозиторій Veeam Backup & Replication. Але я не розглядаю цей варіант, тому що в даному випадку використовую лише безкоштовне рішення.
Мені дуже хотілося налаштувати резервну копію всього сервера на Яндекс.Диск, але, на жаль, це не вийшло через технічні обмеження. Яндекс.Диск підключається до системи через webdav. Для того, щоб зробити резервну копію всієї системи, потрібно бекапит або всю систему відразу, або образ диска. Якщо у вас невеликий веб-сервер, то швидше за все на ньому тільки один розділ. У цьому розділі зберігається кеш, який використовує webdav для передачі файлів. Без кешу він не вміє працювати.
Думаю ви вже зрозуміли, в чому проблема зробити повний backup сервер за допомогою Veeam Agent for Linux на Яндекс.Диск по webdav. Ви не зможете додати у виключення папку з кешем від webdav. У результаті, під час бекапу за допомогою veeam зростатиме папка з кешем webdav, яка, у свою чергу, буде бекапитися.Зрештою, вільне місце на диску закінчиться, бекап перерветься.
Я докладно описав ситуацію з Яндекс.Диском, тому що простір на ньому не дорогий. Я часто використовую його в повсякденному житті, налаштовую бекапи, зберігаю дані і т.д. Загалом, мені він подобається з низки причин. Для того, щоб бекапит весь сервер цілком, вам доведеться знайти місце для архівних копій з доступом по smb або nfs. Таких пропозицій не надто багато на ринку. Практично нема з чого вибирати, я спеціально шукав.
Зупинився на цьому варіанті - KeyDisk. Після оплати, вам дають адресу сервера, логін та пароль. Ви можете відразу підключатися по smb до сховища. Можна прямо в windows через два зворотних слєша зайти або підмонтувати сховище до linux серверу.
KeyDisk коштує приблизно 350 грн. на місяць за 100 гігів. Не дуже дешево, звісно, порівняно з хмарними сервісами, але все одно не дорого. Схожих пропозицій із доступом по smb я особисто взагалі не знайшов у принципі. Цей обсяг дозволить вам забекапити невеликий веб-сервер з глибиною архіву в кілька тижнів або місяців, залежно від того, скільки даних у вас на ньому зберігається.
Далі я докладно на конкретному прикладі розповім як усе налаштувати та відновити чи перенести сервер цілком, якщо знадобиться. Причому переноситиму взагалі на інше залізо. Але про все по порядку.
Установка Veeam Agent for Linux
Для встановлення Veeam Agent for Linux необхідно підключити репозиторій veeam під потрібну вам систему. Це можна зробити або руками, або завантажити файл із репозиторієм у вигляді rpm або deb пакета. Зробити це можна на сторінці з описом продукту.
Щоб отримати доступ до розділу із завантаженнями, доведеться зареєструватися. Вибираєте тип системи та завантажуєте ріпу.
Трохи нижче рекомендую відразу завантажити Veeam Linux Recovery Media. Він нам знадобиться, коли ми переноситимемо сервер на інше залізо або відновлюватимемо з бекапу.
Копіюємо файл з репозиторієм на сервер та встановлюємо його. На момент написання статті файл можна було завантажити за прямим посиланням.
Оновлюємо репозиторії та встановлюємо veeam.
Все, Veeam Agent for Linux встановлений та готовий до роботи.
Налаштування повного бекапу сервера
Зробити бекап за допомогою Veeam Agent for Linux дуже просто. Варіантів налаштувань не так багато, можете самі перевірити і подивитися. Я для прикладу розгляну варіант із створенням повного бекапу всієї системи та перенесення її на інше залізо. Створюємо завдання резервного копіювання сервера на наше сховище по smb.
Нам відразу пропонують вказати файл з ліцензією. Так як у нас ліцензії немає, то відмовляємось. Нас зустрічає головне вікно програми.
Натискаємо C (configure) для налаштування завдання на backup. Задаємо будь-яке ім'я завдання, потім вказуємо, що робитимемо повний бекап сервера.
Як приймач для архіву системи, вказуємо Shared Folder.
Далі потрібно ввести параметри доступу до сховища бекапів. Я використовую свої системи від KeyDisk.
У Restore Points вказується глибина архіву. Це число копій, які зберігатимуться на сервері. Якщо робити бекап щодня і вказати число 14, зберігатимуться резервні копії системи за останні 14 днів. Якщо робитимете через день, то за 28 днів і т.д.
Можна створювати кілька завдань із різною глибиною архіву. Наприклад, кожен день із глибиною 7 копій, раз на тиждень із глибиною 4, і раз на місяць із глибиною в 12. Таким чином у вас завжди будуть останні 7 бекапів системи на цьому тижні.Потім по одному бекапу на тиждень за останній місяць і 12 бекапів по місяцях протягом останнього року.
Якщо отримаєте помилку:
Встановіть пакет CIFs. У CentOS ось так:
І так у Debian/Ubuntu:
Запускайте наново veeam і продовжуйте. Після налаштування Destination, пропонується вказати скрипти для виконання перед та після бекапу. Нам зараз це не треба. Далі налаштовуємо розклад та запускаємо завдання на архівацію в кінці налаштування.
Запустилася архівація. Можна стежити за її прогресом.
Після завершення архівації системи можна перевірити вміст мережевого сховища, зайшовши на нього прямо з вінди.
На цьому налаштування повного бекапу сервера ми завершили. Резервна копія системи лежить у надійному місці. Спробуємо тепер із неї відновитися.
Перенесення чи відновлення linux сервера
Уявимо тепер ситуацію, що наш веб-сайт, або якийсь інший сервер помер, і нам треба відновити систему в іншому місці. Виконаємо повне відновлення всього сервера за допомогою раніше створеної резервної копії. Для цього нам знадобиться Veeam Linux Recovery Media, який ми завантажили раніше.
Для відновлення системи потрібно дотриматись двох обов'язкових умов:
- Готуємо новий сервер з диском, який повинен бути не меншим за диск вихідного сервера. Це обов'язкова умова, інакше відновлення системи навіть не розпочнеться. Veeam скаже, що розмір диска є недостатнім і не запропонує більше ніяких варіантів відновлення.
- Оперативна пам'ять для системи повинна бути не менше 1024 Мб. Якщо менше, завантаження з диска не буде виконано. Система скаже, що вона не може розгорнути кореневий розділ.
Завантажуємося з диска. У розділі Configure network переконуємось, що мережа налаштована, отримано IP адресу, яка має доступ до інтернету.Далі вибираємо Restore volumes -> Add shared folder. Заповнюємо параметри доступу до сховища архівів.
Вибираємо там директорію з нашим архівом системи, яку відновлюватимемо. Далі буде показано список завдань у лівому стовпці та список резервних копій у правому.
У моєму випадку там лише одна копія. Вибираю її. Далі ми бачимо ліворуч список дисків нашого сервера, праворуч диски резервної копії.
У мене ліворуч чистий диск, справа теж один диск, на який встановлений завантажувач і є один розділ із коренем системи. Вибираємо праворуч наш диск (не розділ з коренем.) і тиснемо Restore whole disk to.
Як приймач вибираємо порожній диск на новому сервері.
Натискаємо S (Start restore). Візард покаже список дій, які будуть виконані та попросить їх підтвердити натисканням Enter.
Робимо це та спостерігаємо за процесом відновлення сервера centos з бекапу.
Чекаємо на закінчення перенесення сервера, вибираємо перезавантаження і виймаємо завантажувальний CD. Завантажуємося з жорсткого диска.
Далі може бути багато різних варіантів. Якщо ви переносите сервер на той же гіпервізор, то проблем, швидше за все, не буде, і все заведеться відразу. Якщо гіпервізор інший, то можуть бути варіанти, залежно від ситуації.
Перенесення віртуальної машини з KVM на Hyper-V
У моєму випадку я переношу сервер із KVM на Hyper-V. Після завантаження системи я отримую таку картину.
Сервер починає нескінченно висіти у подібному стані з такими характерними помилками:
Починаю розбиратися, в чому може бути справа. Звичайно, тут вирішення проблеми залежатиме від конкретної ситуації. А успішність вирішення від кваліфікації сисадміну. Я вже трохи поморочився з подібними переносами і приблизно уявляю, в чому тут може бути проблема.Частково я цю тему торкався, коли робив перенесення віртуальних машин із XenServer на Hyper-V. Але там була інша проблема, пов'язана із кастомним ядром від Xen.
У нашій ситуації з перенесенням віртуальної машини з KVM на Hyper-V проблема в іншому. У нас змінилося ім'я диска. Нам потрібно змінити це ім'я у fstab та конфізі grub. До купи я ще зібрав знову initramfs, але не впевнений на 100%, що в даному випадку це потрібно було робити. Я зробив про всяк випадок одразу все за один захід.
Отже, завантажуємося з інсталяційного диска CentOS 7 та вибираємо режим Rescue a CentOS system. Докладно про це розповідав у згаданій раніше статті із перенесенням від xen. Вибираємо перший режим запуску.
Далі працюємо у консолі. Дивимось, як називається наш диск.
У мене це sda, а на минулому сервері він називався vda. Нам потрібно внести ці зміни до 2 файлів:
Диск відновлення на самому початку міг сам змонтувати системний розділ у директорію/mnt/sysimage. Якщо він цього не зробить з якоїсь причини, зробіть це самі:
Тепер нам треба зробити chroot у систему, попередньо змонтувавши туди інформацію про поточну систему. Виконуємо команди:
Ми завантажилися в оточення нашого сервера. Тут можна використовувати встановлений у вас на сервері текстовий редактор. З його допомогою змінюєте імена дисків у файлах /etc/fstab і /boot/grub2/grub.cfg. Можете просто автозаміною поміняти імена.
Тепер зберемо новий initramfs. Ідемо до директорії /boot і дивимося там останню версію ядра.
У разі просто дивимося найвищі цифри. Зберемо новий initramfs відповідно до версії ядра.
На завершення встановимо змінений завантажувач на наш диск:
Перезавантажуємо сервер.Після цих змін, у мене все завантажилося. Перенесення віртуальної машини з KVM на Hyper-V виконане повністю. Причому, ми не мали доступу до образу системи. Хоча подібна помилка швидше за все виникла б, навіть якби ми конвертували і переносили готовий образ.
Висновок
Спочатку планував написати невелику замітку на тему використання Veeam для сервера бекапу. Але в процесі вдалося розібрати ще й перенесення сервера з одного гіпервізора на інший. Ще раз повторюся, кому це здалося надто складним. Якщо ви будете бекапит і відновлювати сервер в рамках одного і того ж гіпервізора, то описаних вище проблем у вас не буде. Все пройде гладко.
При перенесенні із заліза на віртуальну машину чи навпаки, теж швидше за все виникнуть якісь проблеми. Не існує софту або готового рішення, яке дозволило б все це виконати в автоматичному режимі. З проблемами завантаження доведеться розбиратися в ході справи. Але дві основні проблеми я розібрав:
- Невідповідні версії ядер. Після перенесення потрібно буде перевстановити чи оновити ядро.
- Різні імена дисків або позначок розділів. Потрібно буде їх привести у відповідність до нового заліза.
Це найпопулярніші проблеми. З іншими мені не доводилося стикатися. Хоча не сказати, що мені часто доводилося переносити сервер, але деякий досвід є. Думаю, ця стаття буде багатьом корисною, тому що подібне перенесення не дуже розкрите в статтях в інтернеті. Принаймні мені не траплялися добрі гайди на цю тему. Розбираюсь зазвичай сам за допомогою гуглення за англомовним сегментом.
Діліться своїм досвідом та залишайте зауваження до статті або вказуйте на помилки у коментарях.
Онлайн курс "DevOps практики та інструменти"
У цій статті спробуємо розібратися з особливостями резервного копіювання та відновлення конфігурації гіпервізора ESXi. Перш за все, нагадаємо, що резервне копіювання конфігурації серверів ESXi необхідно виконувати при оновленні версії гіпервізора, а також після внесення суттєвих змін у конфігурації (які, відверто кажучи, після початкового настроювання сервера виконуються досить рідко).
Найзручніший і найпростіший спосіб бекапа налаштувань хостів ESXi – скористатися функціоналом Host Profiles, проте цей функціонал доступний тільки для Enterprise Plus і нами докладно не розглядатиметься. Ми зупинимося на керуванні резервним копіюванням за допомогою команд CLI.
Резервне копіювання/відновлення ESXi за допомогою PowerCLI
На наш погляд, найпростіший спосіб створення резервної копії хостової системи VMware ESXi та відновлення з неї – скористатися спеціальними командлетами PowerCLI:
- Get-VMHostFirmware – дозволяє створити резервну копію конфігурації ESXi
- Set-VMHostFirmware - дозволяє відновити конфіг гіпервізора з бекапу
Примітка. Природно, що на машині адміністратора має бути встановлений Powershell та розширення vSphere PowerCLI.
- Відкрийте консоль PowerCLI або запустіть її з PowerShell, виконавши команду:
- Підключіться до нашого сервера ESXi (або vCenter):
Примітка. 1. Необхідно враховувати, що відновлення конфігурації ESXi з бекапу повинно проводитися на таку ж версію ESXi, інакше результат не гарантований.2. Якщо у вказаному каталозі зберігаються бекапи кількох північ, скрипт сам вибере потрібний файл бекапу на ім'я.
Порада.Якщо командою Connect-VIServer ви встановите сесію з сервером VMware vCenter, то наступною командою можна створити резервні копії всіх серверів ESXi, підключених до цього vCenter:
Бекап/відновлення ESXi за допомогою vSphere CLI
Для резервного копіювання/відновлення конфігурації ESXi можна скористатися можливостями vCLI, наприклад, за допомогою клієнта vCLI для Windows або Linux або через vMA Appliance.
Для управління резервними копіями у vCLI існує спеціальна команда: vicfg-cfgbackup
Примітка. Команда vicfg-cfgbackup доступна лише на сервері ESXi, використовувати її при підключенні до сервера vCenter Server не вдасться.
Після виконання команди файл esx05-backup можна завантажити на свій комп'ютер, наприклад WinSCP.
Процедура відновлення ESXi у разі падіння сервера така:
- Встановіть на сервер ту саму версію ESXi, бекап якої було створено. Виконайте початкове налаштування сервера (ім'я, ip адреса management мережі тощо)
- Скопіюйте на північ наявний файл із бекапом.
Резервне копіювання у безкоштовній версії ESXi
Цей неприємний факт обходиться досить просто: при свіжій установці ESXi вам може бути наданий тестовий (trial період) 60 днів, протягом яких ви можете користуватися всім функціоналом ESXi, а команди vSphere CLI будуть відпрацьовувати в режимі читання та запису, що означає можливість відновлення з наявного бекапу.
Apr 3, 2017 13:56 · 868 words · 5 minute read esxi backup
Можливості резервного копіювання віртуальних машин на гіпервізорі під керуванням ESXI з безкоштовною ліцензією суттєво обмежені - наприклад, тут не вдасться використовувати vCenter, а функціональність безкоштовних версій Veeam Backup або VM Explorer значно урізана. Отже, основними можливостями безкоштовної версії Xsibackup є: Переходимо за посиланням для завантаження утиліти Xsibackup, вводимо особисті дані та обов'язково працюючий email - на нього прийде спеціальний SecretKey і скрипт для встановлення. Усі команди необхідно вводити на хості під керуванням ESXI, на якому робитимуться бекапи. Примітка. На ESXI має бути включена служба SSH. Підключаємося до консолі ESXI по ssh і вводимо команди з листа для встановлення Xsibackup (повторюємо цю процедуру на всіх гіпервізорах): Створюємо каталог для зберігання резервних копій: Перевіримо можливість створення бекапів локально: Тест успішний, щоб зробити резервну копію всіх запущених віртуальних машин команду ще раз, але без опції --test-mode=true : Якщо ж необхідно зробити бекап тільки однієї віртуальної машини, то команда виглядатиме так: Тепер можна виконувати резервне копіювання віртуальних машин на віддалений хост, для цього використовуємо наступну команду: Для налаштування крона спочатку потрібно встановити його командою: Докладна інструкція з налаштування періодичного резервного копіювання знаходиться тут , а повний список доступних опцій та приклади їх використання можна переглянути тут. Віртуалізація з використанням рішень від VMware є флагманом спрямування. Тому розглянемо детальніше резервне копіювання віртуальних машин на VMware.Є два основних способи резервного копіювання, це традиційне резервне копіювання за допомогою агента усиновленого у віртуальній машині та безагентне резервне копіювання, коли резервне копіювання виконується на рівні взаємодії VCenter або ESXi із системою резервного копіювання. Бажано, якнайменше використовувати агенти для резервного копіювання гостьових ОС. Системи резервного копіювання мають переходити безпосередньо до рівня віртуалізації. При використанні цього методу гостьова ОС не знає про процес резервного копіювання та не витрачає ресурси хоста. Це набагато ефективніше, оскільки сервер резервного копіювання може монтувати віртуальний диск віртуальних машин безпосередньо зі сховища даних хоста. Для цього VMware розробила спеціальні API-інтерфейси для програм резервного копіювання VMware vStorage API for Data Protection (VADP), які дозволяють програмам резервного копіювання безпосередньо взаємодіяти з хостами та пристроями зберігання.
VADP пропонує ефективніший доступ до файлів віртуального диска. Архітектура віртуалізації надає безліч унікальних способів резервного копіювання віртуальних машин, порівняно з традиційними фізичними середовищами. Тому, перш ніж розпочати створення плану резервного копіювання та аварійного відновлення, необхідно ретельно вивчити ті можливості, які надає віртуалізація.
ПОРАДИ З РЕЗЕРВНОГО КОПІЮВАННЯ ВІРТУАЛЬНИХ МАШИН VMWARE
- По можливості не створювати резервні копії віртуальних машин на рівні гостьової ОС
- Щотижня робити повне резервне копіювання
- Використовувати стандартні API-інтерфейси vStorage
- Не заощаджувати на ресурсах резервного копіювання.Резервне копіювання може значно сповільнитися, якщо сервер резервного копіювання не має достатніх ресурсів.
- Пам'ятати, що Snapshots (миттєві знімки) не є резервними копіями
- Не забувати робити резервну копію налаштувань хостів та vCenter Server
- Резервне копіювання vCenter Server окремо від резервного копіювання віртуальних машин
- При груповому бекапі ВМ, об'єднувати ВМ у групи за однаковими параметрами (файловий / сервер додатків / баз даних)
- Виконувати Off-host backups для зниження навантаження на сервер ESX.
CИСТЕМИ РЕЗЕРВНОГО КОПІЮВАННЯ VMWARE
Резервне копіювання VMware
Починаючи з версії 6.7, VMware припинила підтримку VMware vSphere Data Protection, залишивши завдання резервного копіювання на спеціалізованих виробників систем резервного копіювання.
Чим керуватися під час вибору системи резервного копіювання? Перерахуємо технології та параметри, які мають бути присутніми у сучасній системі резервного копіювання.
ТЕХНОЛОГІЇ та ФУНКЦІЇ РЕЗЕРВНОГО КОПІЮВАННЯ VMWARE
Changed Block Tracking
Резервне копіювання додатків та баз даних
Більшість організацій використовують важливі для бізнесу програми поверх баз даних або інших додатків, що потребують узгодженості транзакцій. Microsoft SQL Server і Microsoft Exchange Server є двома прикладами програм, які вимагають узгодженості транзакцій. Резервні копії VMware, які використовують резервні копії з урахуванням програм, взаємодіють з VSS Microsoft, щоб скинути всі дані в пам'яті або очікують операції дискового введення-виведення на диск, щоб резервні копії включали всі транзакції під час резервного копіювання.В іншому випадку, резервне копіювання може бути непослідовним, коли справа доходить до бази даних програми, і потрібні додаткові кроки, такі як відтворення журналів, з метою привести базу даних у узгоджений стан.
Транспортні режими передачі даних
Для резервного копіювання та передачі файлу VMDK на хост застосовуються такі транспортні режими:
- Hotadd backup - дозволяє використовувати віртуальну машину як проксі-сервер для передачі даних
- SAN – дозволяє передавати VMDK через SAN безпосередньо на сервер резервного копіювання не навантажуючи ESX / ESXi хост.
Off-host backup
Off-host backup дозволяє перенести процес резервного копіювання моментальних знімків одного чи кількох томів із хоста на сервер резервного копіювання. Для забезпечення узгодженого Off-host backup потрібна вбудована підтримка постачальника апаратних знімків Microsoft VSS та прямий доступ до сховища.
Реплікація резервної копії
Можливість реплікації резервних копій є дуже важливою та корисною функцією у випадку, якщо у вас відбулася повна відмова основного ЦОДу і ви втратили виробничі дані, а також резервні копії. Однак, якщо у вас є копія даних резервного копіювання в іншому ЦОДі або у хмарі, це забезпечує відмовостійкість даних резервного копіювання та віртуальних машин відповідно.
Реплікація віртуальних машин
Шифрування резервних копій
Резервні копії часто не беруться до уваги службою інформаційної безпеки в організації. Тим не менш, необхідно пам'ятати що, як правило, це повна копія виробничих даних, і якщо дані резервного копіювання скомпрометовані, зловмисник може отримати повний доступ до цих даних.Багато систем резервного копіювання дозволяють здійснювати шифрування даних, як у момент копіювання, і під час зберігання. І те, й інше важливо, оскільки дані мають бути захищені від зловмисників, оскільки вони передаються через мережу і знаходяться на диску або в резервному сховищі.
Перевірка резервної копії
У сучасних ІТ-технологіях, що швидко розвиваються, організації повинні автоматизувати процеси і процедури резервного копіювання, щоб йти в ногу з зростаючими потребами. Захист даних, безумовно, є одним із повсякденних завдань, що виграє від автоматизації. Багато виробників систем резервного копіювання надаю API-інтерфейси, що дозволяють взаємодіяти з інструментами оркестрування (управління) віртуальному середовищі, що вже існують в організації. Крім того, ланцюжок завдань дозволяє налаштувати робочі процеси у визначеному порядку та часі.
Наведені вище рекомендації дозволять вибрати функціональне рішення системи резервного копіювання для вашої організації.
