Пожалуй, начну с того, что если вы хотите бэкапы на VMWare, то готовьтесь платить. Бесплатный VMWare - это бесплатно до тех, пока речь не идет о миграциях, бэкапах и тому подобное. На этом месте можно начать бесконечный холивар, но без моего участия. Мои повествования будут только о Hyper-V на Windows Server 2012R2. Хотя часть статьи можно применить и к VMWare, но, вероятно, будут подводные камни.
Бэкапить на Hyper-V мы можем бесплатно, а точнее, теми средствами Windows, за которые мы уже заплатили, приобретая лицензии Windows Server. Для удобства работы с нашими бэкапами (к тому же за это мы тоже заплатили) будем использовать WDS и дедупликацию (может и групповые политики).
1. Бэкап изнутри виртуальных машин
1.1. Бэкап сегодняшнего дня
Насколько мы знаем, любой Windows умеет делать бэкап. Причем, любые настройки бэкапа Windows через интерфейс сводятся, в конечном счете, к фоновому использованию утилиты wbadmin. А что, собственно, умеет wbadmin? А умеет она делать как бэкап образа с системным разделом, так и бэкап отдельных папок. В данной части статьи нас интересует только бэкап образ (системного раздела). Остальное - это специфичные данные виртуальных машин и бэкапить нужно отдельно. Отсюда вывод: Не храните на системном разделе виртуальных машин (и на обычных компьютерах тоже) никакой ценной информации и баз данных, отдельных приложений. MS SQL Server / MS Exchange / «Сервер приложений 1С» и другое ставим только на не системные разделы или на отдельные диски.Итак, что же нужно, чтобы бэкап отработал? А нужна всего лишь одна команда:
Wbadmin.exe start backup -backupTarget:\\СерверБэкапа\ПапкаДляБэкапаВнутреннего -allCritical -quiet
На самом деле, для этой команды нужны особые права, но о них позже. Сейчас важно понять одну вещь. Данная команда делает не просто бэкап. Она делает инкрементальный бэкап. Причем, для серверных и настольных (клиентских) Windows бэкапы формируются разные. И разница заключается в том, что для серверных ОС у нас получатся снимки каждого бэкапа, а вот для настольных - снимок останется всегда только последний. Спросите, а что это за такой инкрементальный бэкап? А «инкрементальный» он остается, потому что бэкапим мы не весь образ, а только изменившуюся часть со времени последнего бэкапа (а значит и меньше трафика и быстрее создается бэкап).
Те, кто сталкивался с аналогичной ситуацией заметят, что бэкап всегда будет «инкрементальный» (полный). Так как бэкап происходит в нашем случае на сетевой диск. То есть для серверной Windows снимки остаются тоже только последние.
Позже, выявил, что нет никакой разницы в работе wbadmin на серверной и клиентской ОС. Разве, что разница есть в интерфейсе. wbadmin производит инкрементальный бэкап (кроме первого бэкапа), если указан жесткий диск в ключе -backupTarget (команда использует ключ по умолчанию -vssСopy). Или производит полный бэкап, если добавить ключ -vssFull.
1.2. Бэкап с историей предыдущих снимков
На данный момент, мы сделали бэкап образов виртуальных машин. Но это же у нас бэкап снимков только сегодняшнего дня. Завтра он будет совершенно другой… Но что будет, если бэкапить бэкапы? Да и ещё по-настоящему инкрементально. Так и поступим.Wbadmin.exe start backup -backupTarget:e: -allCritical -include:d: -quiet
#где диск D - бэкапы на сегодня, а диск E - бэкапы с историей
Но мне было этого недостаточно и я сделал так:
(echo select vdisk file="\\СерверБэкапа2\ПапкаДляБэкапа2\ИмяБэкапаДляЭтогоСервера2.vhdx"
echo attach vdisk) | diskpart
Скрипт подключает виртуальный диск из сети. После бэкапа подобный же скрипт отключает диск. ОС помнит, что у диска определена буква E. Но не дай бог подсунуть чужой диск с той же буквой E, бэкап отработает уже по полной (не инкрементально и на чужой диск). Имейте это в виду и используйте, букву, ближе к концу алфавита (X, Y, Z)…
Замечу сразу, если бэкап сегодняшний будет производиться параллельно с бэкапом с историей, то получим в итоге бэкап, который невозможно поднять.
Чтобы достать бэкап предыдущих дней можно воспользоваться интерфейсом (GUI) сервера, на котором производятся бэкапы с историей. Более того, все запуски команды wbadmin в консоли Windows знает и помнит. Служба восстановления даст возможность вам выбрать нужный архив в бэкапах с историей.
2. Бэкап файлов vhdx виртуальных машин
Производится легко и непринужденно:Wbadmin start backup -backupTarget:$BackupPath -hyperv:$VMList -Quiet
Но с некоторыми особенностями. Эта команда должна выполняться в PowerShell и с предварительным получением списка виртуальных машин в переменную. За подробным примером обращаемся в Google.
Бэкап виртуальных машин в Windows Server 2012 R2 идет с помощью моментальных снимков Hyper-V. Также замечу, что происходят приостановка работы виртуальных машин, если на них ядро Linux или отсутствуют Hyper-V драйвера. Я лично отказался бэкапить виртуальные машины таким способом. Причина в том, что на Windows Server 2012 (не R2) требовалось останавливать виртуальные машины до бекапа. Да и сейчас на Windows Server 2012 R2 приостановки Linux меня не устраивают, когда есть первый неплохой способ бэкапа. (в комментариях к данной статье есть замечание). После очередного обновления в Windows Server 2012 R2 бэкап любых виртуальных машин проходит без приостановок. ОС Linux также можно бэкапить «изнутри» с помощь Dump (CentOS, Ubuntu), но это отдельная тема с puppet"ами и другим ПО в моем случае.
3. Восстановление бэкапа и WDS
А теперь, по-моему мнению, самая полезная часть этой статьи про бэкапы.WDS - это Windows Deployment Services (службы развертывания Windows) и часть функционала Windows Server 2012R2. Раньше эта служба называлась RIS, но я с ней не сталкивался. Вообщем, суть WDS проста. Прописались в DHCP (автоматически для DHCP Windows Server) в виде отдельных параметров и далее загружаем на компьютер по сети (такая настройка BIOS компьютера для загрузки по сети) через TFTP загрузчик WDS. Далее загрузчик WDS позволяет выбрать из доступных на ней образов «загрузчиков» Windows. Загрузчики бывают разные - это и образы загрузчиков установщика, и PE, и RE образы. Для загрузчика установщика ещё нужны образы самих Windows в WDS, но это в случае, если нужно установить Windows по сети. Нас интересуют RE образы, которые позволяют поднять машину из бэкапа.
Как и что работает в WDS подробно объяснять не буду. Но вот важные заметки:
- Если у вас загрузчик RE загружается на Hyper-V виртуальной машине по сети, но не работает клавиатура в ней. Поздравляю, ваш RE образ для WinXP или древнее и не знает о существовании Hyper-V драйверов.
- Если у вас система начинает восстанавливать бэкап, но останавливается. Удалите все разделы на жестком (на котором восстанавливается бэкап) и попробуйте заново. Только не забывайте, что бэкап может быть битый и после удаления всех разделов на жестком у вас может ничего не остаться от старой информации.
- Если бэкап с загрузкой UEFI, а вы хотите восстановить на комп без UEFI, то не стоит тратить время. Скорее всего развернуть бэкап не получится.
- Бэкап с загрузкой UEFI и разделами GPT можно восстанавливать на машины с другим процессором / материнкой, а вот с разделами MBR формата и с загрузкой обычного BIOS на другой машине развернуть вряд ли получится. Ну у меня точно не получалось.
- Если бэкап пытаться развернуть на диск с меньшим объемом, то сделать это не получится. Даже если диск в бэкапе был почти пуст. В этом случае помогает восстановление на виртуальную машину с динамическим диском. Далее уменьшение этого диска и создание нового бэкапа. Но такое можно только с загрузчиком UEFI в бэкапе (почему, читаем предыдущий пункт).
- Стоит перед восстановлением бэкапа отключить лишние диски, чтобы не затереть информацию на них.
4. Особенности дедупликации
Можно дедуплицировать работающие виртуальные машины. Можно дедуплицировать бэкапы сегодняшнего дня и можно дедуплицировать бэкапы с историей. Все это дает большой положительный плюс к объему жестких дисков (как для HDD, так и SSD). Но не стоит забывать о некоторых вещах:- Если дедупликация будет работать с дисками с объемом более чем 1 ТБ, то оптимизатор дедупликации будет использовать очень много памяти.
- Если дедупликация будет работать с сжатыми данными, но с объемом сжатого более чем 10 ТБ, то длительность работы оптимизатора дедупликации будет слишком большим. Такое может получиться, если просто копировать данные ежедневно на дедуплицированный диск в разные папки.
- Бэкапы на HDD хранить можно и даже нужно, а вот рабочие виртуальные машины хранить на HDD в количестве больше 5-10 не стоит. К дедупликации это относиться с той лишь стороны, что дедупликация таких рабочих виртуальных машин сведет производительность HDD в ноль.
5. Групповые политики
Вот тут можно долго и по-разному реализовывать установку скрипта бэкапа с помощью GPO. Но хотелось бы обратить внимание на важные моменты:- Бэкап проводить только от имени отдельной учетной записи пользователя.
- Не хранить скрипты с паролям в групповых политиках.
- Запускать скрипт с особыми правами на чтение всей информации системы.
Для создания резервных копий VMware в Handy Backup могут использоваться два метода: внутренний и внешний.
Внутренний метод
Копия Handy Backup устанавливается на виртуальную машину VMware под управлением ОС Windows или Linux. Эксплуатация Handy Backup на виртуальной машине ничем не отличается принципиально от использования аналогичного решения на “физических” компьютерах.
Внешний метод
Handy Backup запускается на сервере виртуальных машин VMware, чтобы скопировать образы конкретных копий VMware как обычные файлы. Handy Backup использует для резервного копирования машин и массивов VMware специальный плагин, работающий в "горячем" режиме (без остановки машины VMware).
Как сохранить образ виртуальной машины VMware
Копирование образа VMware backup производится с помощью специализированного инструмента. С помощью настроек плагина VMware может быть достигнут также останов копируемой машины VMware и её последующий перезапуск для "холодного" копирования.
- Откройте Handy Backup и создайте новую задачу, нажав Ctrl+N или выбрав пункт меню. Выберите задачу резервного копирования.
- На Шаге 2 выберите плагин "VMware Workstation ".
- Дважды щёлкните на строчке “Новая конфигурация” для выбора конфигурации доступа к VMware.
- В открывшемся диалоге сделайте выбор между режимами "Hot " (резервное копирование без остановки машины) и "Enable suspend " (с остановкой виртуальной машины для получения её точного образа).
- Далее выберите в диалоге конкретный образ машины, к которому будет применена данная конфигурация.
- Нажмите "ОК" и продолжайте создание задачи, как обычно.
Описанная выше последовательность действий будет останавливать, а затем перезапускать виртуальные машины VMware без всякого дополнительного вмешательства.
VirtualBox – полезное приложение от Oracle для создания виртуальных машин. Простыми словами, вы можете запустить несколько операционных систем на вашем компьютере одновременно, например Windows, Android, или . Это оболочка, которая эмулирует работу реального компьютера с определенными характеристиками (процессор, ОЗУ, видеопамять). Но если вы читаете данную статью, то наверное знаете, зачем используется VirtualBox. Мы ответим на вопрос, который часто задают пользователи Oracle VM – “Как перекинуть файлы на виртуальную машину VirtualBox ”
Для примера, я пользуюсь Windows 10 и установил старый добрый Windows XP на “виртуалку”. Как осуществить обмен файлами между реальной и дополнительной ОС? Очень просто.
Способ 1 – Общие папки
Прежде всего нужно установить Гостевые дополнения VirtualBox. Без них вы не сможете работать с общими папками. Запустите виртуалку, в меню выберите “Устройства”, “Подключить образ диска Дополнений гостевой ОС”.
Начнется установка, после которой нужно будет перезагрузить машину. Установили? Можно продолжать.
Запустите VirtualBox, выберите нужную виртуальную машину и нажмите “Настроить”.
Перейдите во вкладку “Общие папки”. Нажмите на значок добавления новой папки, укажите ее название и местоположение. Также не забудьте поставить галочку напротив “Авто-подключение”, чтобы гостевая ОС автоматически подключала эту папку.
Запустите виртуальную ОС. В проводнике Windows XP появился сетевой диск, который является общей папкой, которой можно пользоваться как с гостевой ОС так и с реальной. Теперь можно спокойно перенести нужные файлы на виртуальную машину VirtualBox.
Способ 2 – Функция Drag’n’Drop
Oracle VM имеет очень полезную функцию под названием Drag’n’Drop. Она позволяет перекидывать файлы с помощью мыши, перетаскивая их в нужное место. В настройках вирт. машины зайдите в “Общие”, “Дополнительно” и активируйте эту функцию. Режим – двунаправленный.
Многие предприятия, а также домашние пользователи все чаще и чаще используют виртуальные машины для выполнения различного рода задач и повышения эффективности своей деятельности. Если раньше виртуальные машины применялись, в основном, энтузиастами, то теперь качество настольных и серверных платформ виртуализации позволило использовать их профессионалам в крупных масштабах. Возможность запуска нескольких виртуальных систем на одном физическом компьютере имеет множество достоинств, среди которых: экономия на аппаратном обеспечении, упрощение обслуживания и снижение затрат на электроэнергию в крупных датацентрах. Кроме того, важным достоинством виртуальных машин является их простая переносимость на другую физическую платформу и простая процедура их резервного копирования. Но также как и обычные операционные системы, виртуальные среды требуют высокого внимания к созданию резервных копий критически важных данных. При работе виртуальных машин в производственной среде предприятия многие компании планируют целые стратегии по архивации и восстановлению виртуальной инфраструктуры после сбоев, которые получили название Disaster Recovery.
Многие поставщики коммерческих платформ виртуализации предлагают корпоративным пользователям встроенные средства архивации виртуальных машин, такие как VMware Consolidated Backup (VCB) для платформы ESX Server. Однако в секторе SMB (Small and Medium Business), где число используемых виртуальных машин невелико, практически отсутствуют предоставляемые производителем платформ средства резервного копирования. Вследствие этого, небольшим компаниям приходится привлекать системных администраторов для написания различных скриптов, а также использования стандартных утилит операционных систем, обеспечивающих архивацию и восстановление файлов и папок с жизненно важными данными.
Общие сведения о резервном копировании данных
Одновременно с процессом планирования виртуальной инфраструктуры необходимо также инициировать процесс по разработке плана архивации и восстановления после сбоев (Disaster Recovery Plan). Прежде всего, нужно выделить наиболее критические элементы ИТ-инфраструктуры, которые потенциально подвержены повреждениям со стороны внутренних и внешних источников, таких как отключение электропитания, неисправности жестких дисков, вирусная угроза и прочие. После этого, необходимо продумать частоту резервного копирования виртуальных машин различных категорий в зависимости от степени критичности. Виртуальные продакшен-сервера компании, которые работают в режиме полной публичной доступности, должны архивироваться довольно часто и регулярно и обладать свойством быстрой восстанавливаемости в случае сбоя. Внутренние сервера организации, не требующие столь высокого внимания и быстрого восстановления, могут архивироваться реже, с бoльшим временем восстановления. Затем нужно определить, какие устройства хранения будут использоваться для архивации (IDE или SCSI диски других серверов, устройства SAN и т. п.).
При выборе частоты архивации необходимо учитывать, что некоторые виды резервного копирования обладают свойством быстрого создания резервных копий, но более медленного восстановления. И наоборот, возможно проведение более длительной архивации с меньшим временем восстановления. Ниже перечислены основные виды резервного копирования данных, которые могут также применяться к виртуальным машинам:
- Обычная (полная) архивация (full backup)
При этом типе архивации создается полная копия всех сохраняемых данных. Процесс создания такой резервной копии достаточно продолжителен, однако требует не так много времени на восстановление, поскольку не требуется выполнять несколько задач восстановления. Полная архивация сбрасывает маркеры архивации файлов и папок, которые используются для определения того, какие файлы следует копировать. Эти маркеры применяются для проверки состояний файлов при добавочной и разностной архивации. - Добавочная архивация (incremental backup)
Этот вид архивации подразумевает копирование файлов и папок, которые изменились со времени создания последней резервной копии. Поэтому, если последовательно выполнить две добавочных архивации и не изменять файл между ними, в образ восстановления он добавлен не будет. - Разностная архивация (differential backup)
Такая архивация включает в себя все изменения, произошедшие в файлах и папках, со времени последней полной архивации. Соответственно, при двух последовательных разностных архивациях файл, который не изменился между ними, но изменился со времени последней полной архивации будет помещен в архив оба раза.
Для того чтобы пояснить, чем отличаются эти типы архивации, приведем пример комбинирования видов резервного копирования. При использовании полной и добавочной архивации существенно уменьшается время резервного копирования, однако увеличивается время восстановления. К примеру, если мы сделали полную архивацию в понедельник и ежедневно накатывали добавочную архивацию, а в пятницу система была повреждена, нам необходимо будет восстановить полную архивную копию понедельника и последовательно все добавочные копии до пятницы, что займет весьма длительное время. Комбинирование полной и разностной активации, наоборот, требует большее время на проведение архивации, однако меньшее на восстановление, поскольку потребуется восстановить только полную архивную копию данных понедельника и накатить на нее разностный архив пятницы.
Это, конечно же, не все типы архивации, которые могут быть использованы при резервном копировании данных, однако перечисленные виды - одни из самых часто используемых. Очевидно, что для серверов с высокой критичностью к времени восстановления целесообразнее использовать разностную архивацию в комбинации с полной, нежели добавочную. Первая подойдет для внешних серверов организации, вторая - для внутренних, которым позволительно большее время простоя.
Поскольку, в основном, виртуальная машина представляет собой папку с файлами, то можно применять встроенные средства резервного копирования хостовой операционной системы, в случае если используется платформа виртуализации поверх хостовой системы такая как, например Microsoft Virtual Server или VMware Server. В Microsoft Windows для этих целей можно применять утилиту ntbackup . При использовании bare-metal платформ (класса «голое железо»), таких как ESX Server или Virtual Iron, необходимо воспользоваться средствами производителя системы виртуализации или продуктами сторонних разработчиков.
Кроме того, резервное копирование виртуальных машин может осуществляться путем создания образов гостевых систем с помощью программного обеспечения, такого как Acronis True Image. Стоит отметить также, что бывают ситуации, когда необходимо осуществить архивацию не всей виртуальной машины, а некоторых данных в гостевой системе. В этом случае, при написании пакетных сценариев архивации можно использовать утилиты для монтирования виртуальных дисков в хостовую систему. Для платформ VMware такой утилитой является приложение VMware Disk Mount.
Архивация и восстановление виртуальных машин на платформе VMware ESX Server
Пилотный продукт компании VMware, платформа ESX Server, является ключевым элементом виртуальной инфраструктуры в производственной среде предприятия. Виртуальная инфраструктура VI3 (Virtual Infrastructure 3) представляет собой совокупность продуктов и средств, позволяющих парку виртуальных машин эффективно выполнять свои задачи и бесперебойно функционировать в различных условиях, включая такие форс-мажорные факторы как резкие всплески нагрузки, отключение питания и порча оборудования. Одним из самых важных средств по реализации стратегии Disaster Recovery является средство резервного копирования VMware Consolidated Backup (VCB). VCB может использоваться для создания резервных копий отдельных ESX-серверов, а также в совокупности со средством управления парками виртуальных серверов VMware Virtual Center. VCB предоставляет реализует следующие возможности:
- создание архивных копий виртуальных машин с различным типом архивации посредством специального прокси-сервера VCB Proxy Host, который снимает нагрузку по созданию резервных копий с production-сервера компании, где запущены виртуальные машины
- не требует установки дополнительных агентов на ESX-серверы
- предоставляет широкие возможности по интеграции с продуктами сторонних производителей средств резервного копирования, поддержка различных пакетов уже встроена в VCB
- поддерживает архивацию на уровне файлов для гостевых систем Windows (можно создавать архивные копии отдельных файлов и папок внутри гостевой системы), а также архивацию на уровне образов виртуальных машин для любых гостевых ОС
Создание резервных копий виртуальных машин с помощью VCB происходит путем создания мгновенных снимков виртуальных машин без остановки их работы. VCB поддерживает также сети хранения SAN. Если виртуальные машины расположены на устройстве хранения SAN, процедура резервного копирования выглядит следующим образом:
Созданные в процессе работы снимки состояний виртуальных машин с помощью агента, расположенного на прокси-сервере VCB сохраняются на резервном носителе, откуда затем могут быть восстановлены в случае сбоя запущенной гостевой системы или порчи оборудования. В этом случае, бэкап-агент имеет прямой доступ к логическим единицам LUN (Logical Unit Number) в устройствах SAN. Для сетей SAN средства VCB поддерживают протокол Fibre Channel, а также ленточные носители для сохранения архивных копий. VCB тесно использует возможности VMware Tools, запущенных внутри гостевой системы, для создания резервных копий данных гостевой ОС.
VMware Consolidated Backup на данный момент поддерживает следующие пакеты (список включает в себя только официально оттестированное ПО с продуктом ESX Server):
- Symantec Backup Exec 10.0
- Symantec Backup Exec 10d
- Veritas Netbackup 5.0
- Veritas Netbackup 5.0 MP4
- Veritas Netbackup 5.1
- Veritas Netbackup 5.1 MP2
- Veritas Netbackup 5.1 MP3
- Veritas Netbackup 6.0
- Tivoli Storage Manager v 5.2.1
- Tivoli Storage Manager v 5.2.3
- Tivoli Storage Manager v 5.3
- EMC Networker v 7.0
- EMC Networker v 7.1.x
- EMC Networker v 7.2
- EMC Networker v 7.3
- CA BrightStor ARCServe r11
- CA BrightStor ARCServe r11.1
- CA BrightStor ARCServe r11.5
- Commvault Galaxy v 5.9
- Commvault Galaxy v 6.1
Работу по созданию архивных копий виртуальных машин в общем случае можно представить так:
- Программное обеспечение для создания резервных копий запускает сценарий подготовки к архивации, который выполняет следующие задачи:
- убеждается в том, что внутри гостевой системы не происходят операции чтения-записи в сохраняемые папки и файлы (только для гостевых ОС Windows)
- переключает виртуальную машину в режим «снапшота», создает снимок состояния виртуальной машины и делает его доступным для приложения, использующего VCB
- монтирует снимок виртуальной машины с SAN на прокси-сервер
- Производится создание резервной копии снимка виртуальной машины на уровне образа, либо на уровне файлов и папок гостевой системы (полное, разностное или инкрементальное копирование).
- ПО для архивации вызывает post-backup сценарий, который завершает резервное копирование (демонтирует снимки виртуальных машин с прокси-сервера и выводит виртуальную машину из режима снимка).
В процессе создания резервных копий средства VCB используют компоненты виртуальной инфраструктуры, представленные ниже: 
Подводя итоги можно сказать, что VMware Consolidated Backup представляет собой мощное средство для создания резервных копий виртуальных машин и дает возможность применять стандартное ПО резервного копирования, используемое в организации для создания архивных копий данных.
Резервное копирование с помощью Vizioncore esxRanger
Продукт esxRanger компании Vizioncore, контролируемой сейчас компанией Quest Software, на данный момент является одним из самых популярных решений для создания архивных копий виртуальных машин на платформе ESX Server. esxRanger не требует установки никаких дополнительных агентов на серверы ESX и создает архивные копии виртуальных машин с одного сервера либо группы серверов за счет интеграции с продуктом Virtual Center. Процесс создания резервных копий происходит на одном Windows-сервере, откуда архивные образы виртуальных систем могут быть сохранены на различных устройствах хранения в производственной среде организации.
esxRanger обладает как GUI-интерфейсом, так и интерфейсом командной строки, что позволяет использовать обычный планировщик задач Windows для запуска работ резервного копирования по расписанию, что отменяет необходимость написания дополнительных скриптов. Главное окно продукта esxRanger представлено ниже:
Подключившись к VMware Virtual Center, при наличии соответствующих разрешений, можно выбрать отдельные виртуальные машины серверов датацентра для резервного копирования. Копируемые образы автоматически сжимаются при архивировании и распаковываются при восстановлении, что позволяет экономить время системным администраторам.
esxRanger интегрируется с VMware Consolidated Backup при использовании в сетях хранения данных SAN и позволяет создавать полные или дифференциальные копии виртуальных машин, а также отдельных файлов и папок в гостевых ОС Windows. Кроме того, в процессе резервного копирования esxRanger собирает различную информацию о метриках архивации (таких как время, затраченное на архивацию и восстановление), хранит ее в базе данных и позволяет использовать ее для построения трендов стратегии Disaster Recovery. В дополнение к этому, esxRanger имеет механизм политик, которые позволяют строить стратегию архивации данных на основе шаблонов и интегрировать его с другими компонентами ИТ-инфраструктуры организации, максимально снизив загрузку системных администраторов.
Процедура резервного копирования с помощью esxRanger выглядит так:
- Создается точка сохранения виртуальной машины и сохраняется в базе данных.
- При помощи VMware API происходит «разлочка» файлов виртуальных дисков на чтение (по умолчанию они заблокированы) и создание.REDO файлов, которые будут хранить изменения виртуальных дисков с момента точки сохранения.
- Файлы виртуальных дисков сжимаются.
- Происходит резервное копирование сжатых файлов и применение.REDO файлов к VMDK файлам виртуальных машин.
- После того, как изменения будут применены, VMDK файлы возвращаются в исходное заблокированное состояние.
- Системный администратор добавляет комментарии к архивным копиям виртуальных машин, содержащие указания на случай сбоя виртуальных машин.
В целом, esxRanger является удобным, надежным и простым в использовании средством создания архивных копий виртуальных машин в Virtual Infrastructure 3, которое обладает возможностями интеграции с VMware Consolidated Backup, что позволяет использовать его в сетях хранения данных SAN компаний любого масштаба.
Создание резервных копий виртуальных машин на платформе Microsoft Virtual Server
К сожалению, компания Microsoft, являющая владельцем и разработчиком продукта для виртуализации серверов Virtual Server 2005, не предоставляет пользователям столь мощного средства резервного копирования и восстановления, как VMware Consolidated Backup. В данный момент, Microsoft сосредоточилась, в основном, на разработке встроенной в следующую версию платформы Windows Server поддержки виртуализации на основе гипервизора под кодовым названием Viridian. Однако Microsoft постоянно откладывает дату окончательного релиза Windows Virtualization, а также урезает его анонсируемые возможности, поэтому сейчас трудно что-то определенное сказать о возможностях резервного копирования в готовящейся платформе виртуализации. С достаточно большой вероятностью можно сказать, что встроенная поддержка «живой» архивации будет, однако неясно пока в каком виде. На сегодняшний день, резервные копии виртуальных машин в Virtual Server могут быть созданы «двумя с половиной способами», включающими в себя:
- использование стандартных средств резервного копирования образов операционных систем, которые могут быть созданы агентами, работающими внутри гостевых систем, например, Symantec Backup Exec.
- написание специализированные скриптов, которые сохраняют состояние виртуальной машины, копируют ее данные на резервный носитель и запускают виртуальную машину снова
- применение служб теневого копирования тома (Volume Shadow Service, VSS), поддержка которых в Virtual Server появилась совсем недавно и пока не поддерживается производителями систем резервного копирования данных
Для того чтобы произвести архивацию запущенных виртуальных машин на платформе Virtual Server можно использовать ее COM-интерфейс, написав сценарий, к примеру, с помощью Visual Basic Scripting (vbs). При создании резервной копии виртуальной машины необходимо сначала перевести ее в сохраненное состояние (Saved State), затем скопировать ее файлы в заданное место и, после этого, снова запустить ее. Ниже приведен пример скрипта на vbs, который делает эти необходимые действия для копирования одной виртуальной машины. Его можно запускать по расписанию с помощью стандартного планировщика задач Windows. " backupvm.vbs " автор: John Savill " использование: backupvm.vbs Option Explicit On Error Resume Next Dim objFSO, objVirtualServer, objVM, objSaveTask, objVHD "Соединение с объектом файловая система set objFSO=CreateObject("Scripting.FileSystemObject") "Соединение с Virtual Server set objVirtualServer = CreateObject("VirtualServer.Application") "Поиск виртуальной машины set objVM = objVirtualServer.FindVirtualMachine(WScript.Arguments(0)) "Сохранение состояния виртуальной машины set objSaveTask = objVM.Save "Пауза для выполнения операции сохранения while not objSaveTask.isComplete WScript.Sleep 1000 wend "Копирование виртуальных дисков и UNDO-дисков for each objVHD in objVM.HardDiskConnections If objFSO.FileExists(objVHD.HardDisk.file) Then "Wscript.Echo objVHD.HardDisk.file & " " & WScript.Arguments(1) objFSO.CopyFile objVHD.HardDisk.file, WScript.Arguments(1) End If If objFSO.FileExists(objVHD.undoHardDisk.file) Then "Wscript.Echo objVHD.undoHardDisk.file & " " & WScript.Arguments(1) objFSO.CopyFile objVHD.undoHardDisk.file, WScript.Arguments(1) End If Next "Копирование vsv и vmc файлов objFSO.CopyFile objVM.File, WScript.Arguments(1) objFSO.CopyFile objVM.SavedStateFilePath, WScript.Arguments(1) "Запуск виртуальной машины objVM.Startup
Этот скрипт необходимо использовать следующим образом:
C: emp>cscript backupvm.vbs
Нужно отметить, что компания Microsoft официально не поддерживает такой процесс создания резервных копий, поскольку целостность виртуальной машины, скопированной в сохраненном состоянии, может быть нарушена из-за того, что часть ее памяти не сохраняется в этом случае в файлах vsv и vhd.
Использование службы Volume Shadow Service
Поддержка служб VSS появилась в недавно вышедшем релизе Virtual Server 2005 R2 SP1. Использование служб теневого копирования в Virtual Server предполагает создание резервных копий запущенных виртуальных машин за счет создания образов, что должно существенно упростить и ускорить процедуру резервного копирования и восстановления. Однако недостаточно, чтобы программное обеспечение для резервного копирования поддерживало VSS, необходимо также, чтобы оно поддерживало еще и новый Virtual Server VSS Writer Service (VS Writer), обнаружить поддержку которого, на данный момент, не удалось ни у одной из систем архивации. В соответствии с информацией Microsoft, средства резервного копирования могут использовать VS Writer для архивации и восстановления виртуальных машин следующим образом: они нотифицируют Virtual Server о том, что процесс архивации начался, Virtual Server отвечает на это созданием снимка виртуальной машины, после чего начинается процесс копирования. На данный момент утилита NTBackup также не поддерживает этот механизм.
Резервное копирование виртуальных машин Xen
Компания XenSource, занимающаяся поддержкой Open-Source проекта Xen, а также распространением коммерческой платформы виртуализации XenEnterprise, предлагает не так много вариантов архивации виртуальных машин на платформе Xen. Один из них приведен ниже с использованием устройств хранения данных в файловой системе NFS (Network File System).
Исходная информация:
- Хост XenServer (в примере процедуры бэкапа его IP 192.168.1.10)
- Компьютер, используемый в качестве сервера хранения архивных копий (в примере его IP 192.168.1.1)
- Виртуальная машина XenVM (в примере ее IP 192.168.1.12)
Процедура резервного копирования:
- Установите NFS сервер путем добавления в файл /etc/exports следующей строчки:
/ *(rw,sync,no_root_squash) - На хосте XenServer пропишите в файл /etc/xen/xmexample1 следующее:
kernel /boot/xenkernel
name = "ExampleDomain"Root = /dev/nfs
Nfs_server = "192.168.1.1"
nfs_root = "/ ip=192.168.1.10:192.168.1.1:192.168.1.1:255.255.255.0:::" - Сохраните копию файла /etc/fstab и добавьте в него следующие строчки:
192.168.1.1:rootdevice / nfs rw,hard,intr 1 1
192.168.1.1:swapdevice swap swap defaults 0 0
192.168.1.1:usrpartition /usr nfs rw,hard,intr 1 1
192.168.1.1:varpartition /var nfs rw,hard,intr 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0 - Скопируйте /lib/modules/2.6.16.29-xen с хоста XenServer на устройство резервного копирования
- Выполните следующую команду на сервере архивных копий:
#scp 192.168.1.10:/lib/modules/2.2.16.29-xen /lib/modules/ - Для активации консоли, используя udev, выполните следующие команды на сервере архивных копий:
mkdir /tmp/dev
mount --move /dev /tmp/dev
sbin/MAKEDEV null console zero
mount --move /tmp/dev /dev - Выполните следующую команду для монтирования устройства резервного копирования на хост Xen:
#xm create -c xmexample1 - Сохраните резервную копию файла xenstore-ls и скопируйте содержимое файловой системы (за исключением директорий /proc и /sys) в другую папку:
#rsync -a -e ssh --exclude="/proc/*" --exclude="/sys/*" 192.168.1.10:/ /backupdir
Заключение
Составление и реализация плана резервному копированию и восстановлению после сбоев (Disaster Recover Plan) наиболее важных серверов и рабочих станций организации является необходимой составляющей ее деятельности. Виртуальные машины, даже больше чем физические, требуют высокого внимания к архивации данных, поскольку обычно несколько виртуальных систем консолидировано на одном физическом хосте. Ведущие производители платформ виртуализации стремятся к тому, чтобы предоставить мощные и удобные средства резервного копирования, однако на данный момент это удалось только компании VMware. Стратегию резервного копирования можно проводить двумя способами: один из самых простых путей, делать это в рамках стандартной стратегии по архивации данных в ИТ-инфраструктуре компании, за счет установки в гостевых системах агентов резервного копирования и создания образов. Другой, более удобный и быстрый путь - использование встроенных средств платформ, таких как VMware Consolidated Backup или написание скриптов системными администраторами. В любом случае, никогда нельзя забывать, что отказ оборудования или иные форс-мажорные обстоятельства не должны существенно влиять на критически важную деятельность компании.
Согласованность (консистентность) данных резервной копии - это сумма валидности, точности и целостности данных по отношению к файлам, данным приложений и операционной системе компьютера или виртуальной машины. Согласованность данных критична для любой системы резервного копирования, независимо от ее размера и политик безопасности компании. В этой статье я расскажу, как удостовериться, что ваша резервная копия согласована и может быть восстановлена в любой момент времени без каких-либо повреждений данных.
Уровни согласованности файлов резервного копирования
В файлах резервной копии есть несколько уровней согласованности данных. Уровни определяются по следующим критериям:
- тип системы (была ли сделана резервная копия «живой» или выключенной системы)
- учет файлов (могут ли взаимозависимые файлы быть четко определены относительно друг друга)
- учет приложений (была ли использована защита для предотвращения потерь данных на разных уровнях, в том числе уровне транзакций)
Рассмотрим все типы согласованности по порядку.
Несогласованная резервная копия
Первый и самый старый тип резервного копирования - использование несогласованных копий. Его можно представить как операцию копирования всех данных компьютера в процессе его работы на USB-флешку или сетевое хранилище. Если в течение копирования изменится хотя бы один файл, резервная копия станет несогласованной. Это значит, что сумма данных резервной копии будет отличаться от актуального состояния системы, а восстановление данных произойдет неточно или не полностью. Этот тип также не предполагает сохранение дампа оперативной памяти и может испытывать трудности с файлами, доступными «только для чтения».
Резервная копия без учета состояния приложений
Следующий тип резервных копий - так называемые копии без учета состояния приложений. Основное отличие от несогласованных копий заключается в том, что эта резервная копия создана в определенный промежуток времени. Такую копию можно представить как мгновенный снимок всего содержимого жесткого диска – как будто вы сделали фотографию.
Тем не менее, восстановление образа системы из такой копии приблизительно равносильно включению компьютера после сбоя в электропитании. Данные открытых на момент сбоя приложений и активные (на момент сбоя) операции ввода-вывода не могут быть восстановлены. В некоторых случаях при запуске приложений после восстановления нужно произвести специальные операции для восстановления их работоспособности. Особенно опасен такой случай для приложений баз данных. Например, Microsoft Exchange сервер может потребовать установки специальной группы восстановления и отдельной интеграции логов. Приложения Microsoft SQL или Oracle потребуют восстановления состояния баз данных с точностью до определенной транзакции, так как сбой в их работе нарушил последовательность операций, и некоторые транзакции нужно выполнить заново, чтобы они были зафиксированы системой.
Резервная копия, согласованная на уровне файлов
Согласованность на уровне файлов означает, что содержимое всех открытых на время начала резервного копирования файлов должно быть зафиксировано на жестком диске. Однако, даже в таком случае система по-прежнему не имеет представления о происходящих транзакциях с базами данных приложений.
Резервная копия, согласованная на уровне транзакций
У такой копии нет недостатков, описанных выше, и все данные ВМ точно определенного момента времени сохранены в резервную копию. Проблема создания такой копии в том, что операции согласования файлов и приложений необходимо проводить, когда нужная ВМ находится в работе и доступ к ней должен быть непрерывным для клиентов.
Для ВМ, работающих под управлением Windows, Veeam помогает сделать резервную копию полностью согласованной, используя службу теневых копий (VSS). Эта служба разработана компанией Microsoft и включена во все редакции операционных систем Windows, начиная с Windows Server 2003. Служба теневых копий координирует процессы, подготавливающие систему к заморозке. Она позволяет временно приостановить операции ввода-вывода на жесткий диск и, таким образом, помогает программному обеспечению для резервного копирования.
«Резервное копирование с учетом состояния приложений» (application-aware image processing) –технология Veeam, которая гарантирует успешное полное восстановление ВМ и данных приложений ВМ без потерь данных.
Veeam Backup & Replication не устанавливает программные агенты на ВМ. Вместо этого на гостевой машине запускается сервисное приложение для координации резервного копирования гостевой ОС. По окончании копирования приложение автоматически удаляется. Механизм разработан таким образом, чтобы предотвратить потенциальные трудности с предустановкой, поиском неисправностей и обновлением программных агентов.
Veeam Backup & Replication инициирует запуск службы теневых копий и посылает запрос на создание согласованного содержимого диска ВМ перед тем, как снять снимок ВМ. Затем провайдер службы теневых копий координирует подготовку приложений к резервному копированию. Так обеспечивается согласованность данных в точно определенный промежуток времени. Таким образом, гарантируется отсутствие незаконченных и неподтвержденных операций в базе данных или неполных файлов приложений в момент копирования содержимого ВМ.
Как убедиться, что резервная копия согласована?
На этапе конфигурирования задания резервного копирования или репликации нужно убедиться, что на вкладке “guest processing” активирована опция “enable application-aware processing” для ВМ, которые выбраны в это задание. Затем можно запускать задание в работу и проверять статус его выполнения.
Использование механизма «резервного копирования с учетом состояния приложений» для особенно критично в случае резервных копий SQL или Exchange серверов, так как позволяет контролировать рост логов транзакций и усекать их при необходимости. В противном случае контроль за ростом логов происходит в ручном режиме.
Служба теневых копий прекрасно работает для современных машин под управлением ОС Windows, но в случае Linux окружения необходимо использовать другой метод.
Функция заморозки (quiescence) от VMware
Например, для виртуальных машин, работающих на VMware ESXi серверах, VMware предоставляет опцию «заморозки» (quiescence). Эта функция позволяет заранее замораживать операции ввода-вывода гостевой ОС, когда сервер готовится снять копию виртуальной машины. Подробную инструкцию по работы с этой опцией можно прочитать в .
В заданиях резервного копирования Veeam можно использовать одновременно опции «Резервное копирование с учетом состояния приложений» и «заморозку» от VMware. В таком случае Veeam Backup & Replication по умолчанию будет использовать первую опцию, а в случае неудачи или невозможности её использования переключится на другую.
Проверить возможность восстановления данных из резервной копии можно с помощью .
Полезные ресурсы
- Блог Veeam: (англ.яз)
- Справочное руководство: « » (англ.яз)
GD Star Rating
a WordPress rating system
