Acronis резервное копирование виртуальных машин
Сегодня многие говорят о том, как облачные вычисления меняют наш взгляд на мир. Постоянно появляются новые технологии, которые упрощают нам жизнь, повышают эффективность работы, уменьшают расходы и избавляют от головной боли. На самом деле их уже так много, что становится все труднее держать руку на пульсе и выбирать из них наиболее полезные для себя. Я попытаюсь немного упростить эту задачу и расскажу о том, как организовать службу резервного копирования для среды vCloud (будь то публичное или частное облако) с помощью Acronis Backup and Recovery (ABR) for vCloud.
Давайте я коротко расскажу о преимуществах данной системы.
BaaS и регулярное резервное копирование
Рассмотрим среду VMware vCloud — она позволяет работать по модели IT-as-a-Service с арендаторами публичного облака или филиалами/отделами крупной компании, обеспечивая централизованный контроль и управление инфраструктурой, и в то же время дает клиентам возможность самостоятельно управлять своими пулами ресурсов. Резервное копирование — важнейшая часть ИТ-мира, так почему бы не использовать для него тот же подход? Владельцы облака могли бы централизованно управлять инфраструктурой резервного копирования и хранения, в тоже время давая конечным пользователям самостоятельно рулить бэкапом и восстановлением своих ресурсов. Это позволяет снизить затраты и время администраторов облака на восстановление пользовательских ресурсов по запросу и разработку различных политик резервного копирования в соответствии с разными потребностями арендаторов.
ABR for vCloud позволяет владельцам облака развернуть решение для резервного копирования в своем датацентре, конечным пользователям возможность пользоваться веб-интерфейсом со своими учетными данными vCloud Director, просматривать список своих ресурсов vCloud (виртуальных машин и vApp’ов) и устанавливать собственные расписания резервного копирования и правила хранения. Конечный пользователь также может самостоятельно выполнять восстановление, сохраняя все настройки vCloud, включая конфигурацию сетей и другие метаданные виртуальных машин и vApp’ов. Сервис провайдер может определять квоты хранилища для организаций и устанавливать права доступа, предоставляя арендаторам полный контроль над расписаниями резервного копирования и восстановлением, либо ограничивая их только предустановленными расписаниями. Можно даже ограничить конечного пользователя, позволяя ему выполнять только восстановление. И, конечно, пользователи смогут отслеживать состояние резервного копирования и получать уведомления по электронной почте об успешном завершении или сбое процесса.
Перед командой разработчиков этого продукта стояла весьма непростая задача — создать такое решение, которое предоставит конечным пользователям платформы vCloud четкую и понятную консоль управления, а владельцам облака — мощный набор функционала, позволит снизить расходы на управление и даст публичным облачным сервисам источник прибыли, в то время как администраторы облака смогут развернуть и настроить решение менее чем за час. Нам пришлось множество раз пересматривать архитектуру, разрабатывать и внедрять новые элементы, каждый раз валидируя их с вышеупомянутыми требованиями. Кроме того, решение должно быть легко масштабируемым и достаточно надежным, чтобы отвечать стандартам круглосуточного сервиса, предлагаемого конечным пользователям.
На скриншотах ниже показан веб-интерфейс для конечных пользователей:
Технология
Традиционный метод бэкапа с агентом внутри гостевой ОС накладывает определенные ограничения для сервис провайдера (всё-таки нужно как-то деплоить/обновлять агенты внутри ОС, принадлежащих арендатору), поэтому Acronis использует существующее API vSphere для резервного копирования виртуальных машин на уровне vSphere и API vCloud Director для аутентификации в vCloud Director и взаимодействия с ним. Мы также собираем все метаданные, связанные с объектами vCD с тем, чтобы в дальнейшем не потерять эту информацию при восстановлении. Используя технологию VMware CBT (Change Block Tracking), мы ускоряем процесс инкрементного резервного копирования, а компонент программной дедупликации Acronis вместе с алгоритмом сжатия позволяет уменьшить сетевой трафик и место, занимаемое резервными копиями в хранилище.
В качестве агента резервного копирования можно использовать либо виртуальный аплаянс на базе Linux, развернутый на ESX(i) хосте, либо прокси-агент на Windows. Решение легко масштабируется путем добавления или удаления бэкап-агентов. С помощью централизованного интерфейса управления можно выполнять мониторинг агентов, хранилища и состояния бэкапов а также настраивать автоматическое распределение нагрузки или прямую привязку агентов к виртуальным машинам.
Если на виртуальных машинах установлены VMware Tools, то резервное копирование машин с работающими VSS-совместимыми приложениями не будет проблемой, поскольку агент использует VSS в виртуальной машине для создания консистентного снапшота.
ABR for vCloud поддерживает все типы хранилищ, которые могут использоваться в вашем дата-центре — NFS, SMB, FTP, FC или iSCSI LUN, даже ленточные устройства. Вы также можете настроить сценарий с репликацией резервных копий из основного хранилища в дополнительное. Резервное копирование без использования сети выполняется подключением LUN непосредственно к агенту, что позволяет не загружать продакшен сеть лишним трафиком.
Как показывают многочисленные опросы, безопасность данных — одна из основных причин, по которой люди не переходят на облачные сервисы. Хотя решение для резервного копирования не может гарантировать защиту данных в работающих виртуальных машинах (для этой цели существует множество других средств), ABR for vCloud обеспечивает шифрование данных в резервных копиях как при передаче по сети, так и при нахожении бэкапов в хранилище. Функция шифрования доступна для конечных пользователей, так что при необходимости они могут надежно защитить свои резервные копии с помощью стандартного алгоритма AES-256.
Disaster Recovery as a Service (DRaaS)
- У конечного пользователя есть резервные копии в облаке сервис провайдера и веб-интерфейс самообслуживания для восстановления этих копий на виртуальные машины в среде vCloud.
- У конечного пользователя есть копии его локальных серверов уже поднятые в виде виртуальных машин в среде vCloud — работающих или отключенных.
Ребрендинг и интеграция
Вы легко можете изменить цвета веб-интерфейса и поместить на него свой логотип или даже интегрировать решение для резервного копирования в вашу собственную консоль или портал управления с помощью REST API на основе JSON, предоставляемого Acronis.
Лицензирование
Для этого решения доступно две базовых схемы лицензирования — одна для провайдеров публичных облачных сервисов, другая больше подойдет предприятиям с частным облаком vCloud. Первая схема предусматривает оплату по мере использования, на основе ежемесячных счетов. Встроенные отчеты по использованию, в которых собрана статистика по нескольким показателям, доступны как для провайдеров, так и для арендаторов. Их можно интегрировать в биллинговую систему провайдера. Вторая схема предполагает фиксированную стоимость по количеству защищаемых ESX(i) хостов.
Мотивация
Работая над этим решением, специалисты Acronis не просто создавали еще один коммерческий продукт: мы относились к нему как к собственному начинанию, хотели видеть, как проект развивается и привлекает все больше внимания, хотели показать его своим коллегам, друзьям и клиентам и гордиться своей работой. В процессе разработки мы опросили многих провайдеров и владельцев частных облаков, чтобы узнать их требования, демонстрировали им продукт на разных стадиях разработки и, получив отзывы, вносили необходимые изменения.
Если вас заинтересовала эта работа, вы можете быстро оценить часть нашего решения, касающуюся интерфейса самообслуживания, на нашей странице: (требуется регистрация). Дополнительную информацию о продукте ABR for vCloud см. на сайте Acronis.
Acronis Backup & Recovery 10 Advanced Server Virtual Edition позволяет выполнять резервное копирование виртуальных машин с хоста.
В Windows 2008 Server x64 (любой выпуск) или Microsoft Hyper-V Server 2008:
- Установите агент для Hyper-V на хосте Hyper-V. должны быть установлены на гостевых системах.
На VMware ESX/ESXi:
- Установите агент для ESX/ESXi на хосте ESX или ESXi. Агент поставляется как виртуальное устройство.
- ПО VMware Tools должно быть установлено на гостевых системах.
После того как агент установлен на хосте, а на гостевых машинах установлены необходимые службы, можно выполнить следующее.
- Резервное копирование виртуальной машины или нескольких виртуальных машин, расположенных на сервере, без необходимости установки агента на каждой виртуальной машине.
- Восстановление виртуальной машины на ту же, другую или новую виртуальную машину, расположенную на том же сервере или другом сервере виртуализации, где установлен агент для виртуальных машин. Конфигурация виртуальной машины, которая хранится в резервной копии виртуальной машины, будет предложена по умолчанию при восстановлении содержимого резервной копии на новую виртуальную машину.
- Резервное копирование и восстановление отдельных дисков и томов виртуальной машины.
В процессе резервного копирования виртуальная машина может быть в оперативном режиме (запущена), в автономном режиме (остановлена), приостановлена или переключаться между этими тремя состояниями.
В процессе восстановления на виртуальную машину она должна работать автономно (остановлена). Машина будет автоматически остановлена перед восстановлением. При необходимости можно выбрать ручную остановку машин.
Резервное копирование виртуальной машины подразумевает резервное копирование всех ее дисков и ее конфигурации. Используя этот тип источника, можно создавать резервные копии нескольких машин. Это удобно при наличии небольших (с точки зрения размера виртуального диска), но многочисленных унаследованных серверов, например созданных в результате консолидации рабочей нагрузки. Для каждой машины будет создан отдельный архив.
Резервное копирование томов в виртуальной машине похоже на резервное копирование томов физической машины. Для этого типа источника сначала нужно выбрать машину, а затем диски/тома, резервную копию которых нужно создать. Это удобно, если операционная система и приложения, например сервер баз данных, работают на виртуальном диске, а данные, например базы данных, хранятся на физическом диске большого объема на той же машине. Для виртуальных дисков и физических хранилищ можно будет применять разные стратегии резервного копирования. Также будет выполнено резервное копирование конфигурации виртуальной машины.
Резервное копирование виртуальной машины Hyper-V, которая использует хотя бы один диск прямого доступа (физический диск, локальный или SAN-LUN, подключенный к виртуальной машине), не может быть выполнено с хоста. Чтобы выполнить резервное копирование такой машины или ее дисков, необходимо установить на машину агент для Windows или агент для Linux.
Резервное копирование невозможно выполнить с данного хоста, если виртуальная машина ESX/ESXi, находящаяся в оперативном режиме (запущенная), содержит независимый диск или RDM-диск, подключенные в режиме физической совместимости. Для резервного копирования такой машины или ее дисков необходимо остановить виртуальную машину или установить на машину агент для Windows или агент для Linux.
Резервное копирование всей виртуальной машины или ее томов приводит к стандартному резервному копированию диска. Наличие агента Acronis Backup & Recovery 10 для Windows или для Linux позволяет подключать ее тома, восстанавливать из этой резервной копии отдельные файлы, а также восстанавливать из резервной копии диски и тома на физическую машину.
Подобным образом можно восстанавливать диски или тома из резервной копии физической машины, созданной с помощью агента для Windows или агента для Linux, на новую или существующую виртуальную машину, используя любой из агентов для виртуальных машин. Таким образом, становится доступной миграция физических машин на виртуальные, а виртуальных — на физические.
Поддерживаются следующие гостевые операционные системы.
Платформа Microsoft Windows :
- Microsoft Windows 2000
- Microsoft Windows XP
- Microsoft Windows Server 2003
- Microsoft Windows Server 2003 R2
- Microsoft Vista
- Microsoft Windows Server 2008
- Microsoft Windows Server 2008 R2
- Microsoft Windows 7
Поддерживаются следующие конфигурации виртуальных дисков.
Стиль разделов: MBR.
Типы томов: базовые и динамические тома.
Динамические тома (LDM в Windows и LVM в Linux) поддерживаются в той же степени, что и на физических машинах. Перед восстановлением необходимо создать структуру LDM/LVM, если необходимо сохранить LDM/LVM. Для этого понадобится загрузить целевую виртуальную машину с загрузочного носителя или его ISO-образа и воспользоваться программой Acronis Disk Director Lite для реконструкции LDM или утилитами командной строки Linux для реконструкции LVM. Другой способ — восстановить динамические тома как базовые.
Агент. Агент для Hyper-V.
Проблема. Резервное копирование подключенной виртуальной машины выполнить не удается из-за ошибки службы теневого копирования томов (VSS). Ошибку можно увидеть в журнале событий приложений (идентификатор события = 8193).
Причина. Это происходит из-за отсутствия раздела реестра:
Решение. Добавьте этот раздел в реестр. Для этого создайте и запустите следующий сценарий (xxx.reg):
В этой статье я пошагово опишу работу сервиса резервного копирования Acronis Backup Cloud (ранее известный как «Acronis Backup as a Service»), разработанный инженерами компании Acronis. Расскажу, что представляет собой «бекапы как сервис» изнутри, и как все это работает. Перехожу непосредственно к описанию работы самого сервиса.
Права огласите, пожалуйста!
Администраторы IT-Lite имеют доступ к управлению группами и учетными записями пользователей.
Администраторы компаний конечных пользователей имеют права, позволяющие управлять пользователями, находящимися только в их группе! А конечные пользователи в свою очередь получают доступ к консоли, в которой можно добавлять компьютеры и создавать расписание автоматического резервного копирования. Сервис интегрирован с сайтом поставщика услуги, что позволяет пользователям сразу же по заполнению формы на этой странице проходить автоматическую регистрацию.
Бэкапить локально – да, быстрее, но менее надежно
Забыл упомянуть про особенность использования бекапов как сервиса – в случае возникновения аварийной ситуации необходимо восстанавливать компьютер (виртуальную машину) целиком. Да, действительно, если сравнивать скорость восстановления сервера, то локальный бекап, конечно, сделать быстрее. Но в данном случае надо сделать выбор – либо в пользу скорости, но без гарантии от косяков, либо в пользу надежности решения, но придется немного пожертвовать скоростью.
Подытожу так – я пришла к выводу, что вопрос о надежности/простоте локальных бекапов и использования BaaS, – это, скорее, вопрос ценностный. Тот, кому информация действительно ценна, скорее выберет сервис, а остальные – первый вариант. Но это уже мое личное мнение, непосредственно к делу не относится.
Сравнение с локальными бекапами
Данные пользователей сервиса BaaS хранятся на серверах, которые расположены в сертифицированном дата-центре класса TIER-3.
Благодаря используемой архитектуре обеспечивается защита от сбоя на уровне отдельных серверов и отдельных дисков, что, заметим, невозможно при использовании RAID-массивов, которые используются для создания отказоустойчивых хранилищ. В системе также используется полная проверка целостности данных. Уровень избыточности конфигурируется в консоли управления хранилища. Используемый при разработке хранилища самовосстанавливающийся дизайн позволяет избежать типичных для RAID-массивов потерь в производительности системы.
В случае выхода из строя одного из дисков или даже целого сервера система произведёт автоматическую перебалансировку, что позволяет избежать немедленной замены вышедших из строя компонентов.
Про серверную часть
Давайте рассмотрим, как устроена серверная часть. Серверная часть сервиса состоит из двух компонентов – управление системой и хранение резервных копий.
Управляющий компонент доступен через интернет и позволяет с помощью веб-браузера управлять резервным копированием удаленных машин и уже созданными резервными копиями; создавать, редактировать и удалять политики резервного копирования и политики хранения; настраивать шифрование создаваемых резервных копий, используя AES или ГОСТ стандарт, и в случае необходимости сохранять отдельные резервные копии локально; следить за состоянием удаленных машин; восстанавливать отдельные файлы/папки, диски/разделы или же целиком машины из облака прямо на «голое железо». Одной из наиболее отличительных и полезных возможностей является создание иерархии подчиненных администраторских и пользовательских учетных записей, в рамках которых распределяются доступ к данным и удаленным машинам. Администраторы могут следить за состоянием подчиненных учетных записей и в случае необходимости оказывать помощь.
Компонент хранения позволяет развернуть масштабируемое, дешевое и при этом надежное хранилище данных. Хранилище для резервных копий состоит из группы серверов, на которые записываются клиентские данные. Для обеспечения достаточного уровня надежности всех хранимых пользовательских данных каждый входящий файл разбивается на «K» блоков и затем добавляются «N-K» (где N – некоторое число большее K) блоков избыточности с использованием алгоритма коррекции ошибок Рида-Соломона. Все блоки хранятся независимо друг от друга, и сохранность любых «K» блоков из записанных «N» гарантирует восстановление хранящихся пользовательских данных.
Серверные роли
Система хранения данных Acronis строится на физических серверах. Но при этом серверные роли назначаются непосредственно дискам.
Существуют три серверные роли: Сервер Метаданных (Metadata Server (MDS)), Сервер Хранилища (Storage Server (STS)) и Front-end Server (FES).
Сервер Метаданных отвечает за хранение информации о фрагментах, на которые разбит файл, и расположение этих фрагментов на серверах. Это наиболее критический компонент системы.
Для обеспечения высокого уровня доступности и отказоустойчивости хранилища рекомендуется иметь несколько серверов с ролью MDS. Один из серверов становится основным, и метаданные периодически реплицируются с остальными серверами с ролью MDS.
Кроме того, на каждый сервер, имеющий роль MDS, также устанавливается и компонент управления системой (MGMT). В случае если основной сервер MDS перестает работать, компонент управления системой автоматически включается на другом сервере с ролью MDS, таким образом, web-консоль управления хранилищем постоянно доступна.
Сервер Хранилища (STS) предназначен для хранения фрагментов данных.
Front-End сервер позволяет клиентам сервиса Acronis Backup Cloud получать доступ к хранилищу и осуществлять передачу данных между пользовательской стороной и хранилищем данных Acronis.
Как устроен сервис
Сервис состоит из серверной и клиентской части. Используются «агентная» и «безагентная» технологии, в зависимости от инфраструктуры. На клиентском компьютере или хост-сервере виртуализации устанавливается агент, задачей которого является соединение клиентского компьютера/хоста с сервером Acronis Backup Cloud и осуществление задач резервного копирования и восстановления.
Резюме
Резюмируя все изложенное выше, хотела бы добавить, что, как говорится, лучше один раз увидеть, чем сто раз услышать. Поэтому лучше поработать с сервисом самостоятельно и сделать свои выводы, благо есть бесплатный тест.
Про моментальные снимки (снапшоты) виртуальных машин было написано великое множество статей, где чрезмерно подробно описана теоретическая часть сего действа. В своей статье я сфокусируюсь на практической стороне вопроса и исключительно на платформе VMware vSphere.
Так зачем нужны «quiesced» * снапшоты, с чем их едят, и какие типичные проблемы с ними возникают? Взгляд на снапшоты будет представлен в первую очередь с точки зрения резервного копирования, но постараюсь в какой-то мере раскрыть и другие аспекты использования.
* Если кто готов подсказать подходящий русскоязычный термин — милости прошу в комментарии, будет хороший вариант — заменю в тексте англицизм.
Использование снапшотов для резервного копирования
- Снапшот включающий состояние памяти виртуальной машины
- Снапшот предваряемый так называемым quiescing-ом гостевой файловой системы
Собственно, альтернативный вариант и есть наша вторая опция — quiescing. Она представляет намного больший интерес и суть её в том, чтобы подготовить гостевую операционную систему (файловую систему в первую очередь) к снятию бэкапа.
Что же представляет из себя quiescing?
«Это процесс приведения данных на виртуальном диске в состояние „подходящее“ для резервного копирования. Данный процесс может включать в себя операции по „сливу грязных буферов“ (flushing dirty buffers) из памяти операционной системы на диск или другие высокоуровневые операции специфичные для конкретных приложений.»
Из данного описания о том, что с виртуальномй машиной происходит на самом деле понятнее не стало. Давайте разбираться сами.
Quiesced = ON, Memory = OFF
Quiesced = OFF, Memory = OFF
Вторую комбинацию мы рассматривать в данной статье не будем и сфокусируемся на процессе quiescing.
Зачем нужен quiescing?
Самый наглядный пример — это проблема USN rollback при восстановлении домен контроллера из бэкапа. Возникает она, если виртуализованный домен контроллер был забэкаплен без использования VSS (то есть без опции quiescing или других средств, которые обеспечивают запись транзакций на диск).
Никаких дополнительных действий и танцев с бубном производить не потребуется, если восстанавливать бэкап, сделанный с опцией quiescing. InvocationID будет корректно сброшен и вы увидите следующую запись в Event Log на загруженном после восстановления домен контроллере:
Event ID 1109: Active Directory has been restored from backup media, or has been configured to host an application partition. The invocationID attribute for this domain controller has been changed.
Поодобное корректное поведение можно наблюдать при использовании Acronis vmProtect 9. Собственно, его мы специально тестировали в рамках резервного копирования и восстановления виртуальных машин с домен контроллером внутри.
USN rollback, очевидно, не единственная возможная проблема при использовании «сырых» снапшотов и другие приложения (например Exchange/SQL — приложения в явном виде поддерживающие VSS) могут быть подвержены сбоям при восстановлении из таких снапшотов.
Как проверить, что снапшот создается корректно с использованием VSS?
Существует несколько способов определения корректности создания консистентного (до уровня приложения) снапшота:
Самый простой способ: войти в гостевую операционную систему и проверить «Просмотр Событий» (надо же было так перевести бедный Event Viewer). После создания снапшота с опциями quiesced=ON, snapshot memory=OFF (см скриншот в начале статьи) должны присутствовать события от соответствующих VSS writers в логах приложений:
Прим.: Ошибка от VSS с Event ID 12289, которую можно заметить на скриншоте, в реальности не является проблемой. Она относится к 3.5'' диску и, чтобы от нее избавиться, достаточно убрать флопик из конфигурации виртуальной машины:
Способ посложнее: использовать компонент Datastore Browser из vSphere клиента: в папке виртуальной машины на датасторе после создания quiesced снапшота должен появиться файл***vss_manifests*.zip.
Внутри файла содержится backup.xml с описанием всех найденных VSS writers в гостевой системе + метаданные по каждому райтеру в writerX.xml.
ВАЖНО: если в vss_manifests.zip содержится только backup.xml — это как правило означает, что снапшот по факту был сделан без использования VSS. Таким образом мы плавно подходим к самому интересному: исследованию проблем со снапшотами. Ниже я перечислю основные причины неработающих снапшотов. Стоит отметить, что основную опасность представляют не неработающие снапшоты (их легко детектировать), а именно те, которые VMware рапортует как успешные, в то время как данные снапшоты не являются таковыми.
Требования к окружению
Если с полезностью опции quiescing все более менее понятно, то при практическом использовании часто возникают проблемы, как правило связанные с некорректностью изначальной конфигурации окружения. Официальное описание части требований находится здесь, и я попытаюсь раскрыть их более наглядно, чтобы было понятно куда смотреть, когда вы столкнетесь с проблемами на практике:
Во-первых, убедитесь, что ваша комбинация vSphere + гостевой ОСи поддерживается для снапшотинга с консистентностью на уровне приложений по данной табличке (взята отсюда).
Данные актуальны для vSphere 5.0 и выше. Как вы можете заметить, для самых популярных на данный момент ОС (Windows 2008 и выше) стоят звездочки — в них то и зарыта главная собака, раскопками которой мы сейчас займемся.
Во-вторых, для того, чтобы quiescing реально работал, необходимо убедиться, что VSS компоненты VMware Tools действительно установлены (и естественно VMware Tools должны быть самой актуальной версии).
На старых версиях vSphere (3.5 и ранее) для quiescing использовался в том числе Legato Sync Driver, который гарантировал консистентность на уровне файловой системы, но не на уровне приложений (для чего как раз и нужны VSS компоненты). В настоящее время этот драйвер практически не используется и повсеместно заменен на VMware Snapshot Provider. Корректность установки можно проверить в гостевой операционной системе (на виртуальной машине) по наличию сервиса VMware Snapshot Provider + соответствующего COM+ компонента.
Какие могут быть косяки на данном этапе?
Если сервис VMware Snapshot Provider отключен, либо совсем не установлен, то VMware при снятии снапшота с опциями quiescing = ON, snapshot memory = OFF отрапортует, что он успешен, однако по факту снапшот будет произведен без использования VSS внутри системы, то есть посредством Legato Sync драйвера.
Заметьте, что в случае Windows 2008 и выше поведение отличается — там подобных событий в логе не наблюдается, а просто сервис Volume Shadow Copy переходит в запущенное, а затем в остановленное состояние.
В-третьих, одной из типичных проблем настройки quiescing'а является параметр disk.EnableUUID=true в конфигурации .vmx виртуальной машины.
Эта настройка имеет смысл только для гостевых систем под управлением Windows 2008 и выше (для Windows 2003 настройка игнорируется). Дополнительной особенностью является тот факт, что данный параметр автоматически прописывается при создании новой виртуальной машины только начиная с vSphere 4.1. Другими словами если виртуальная машина была смигрирована с более старой версии vSphere, то настройки может и не быть.
При отсутствии параметра, или же если он выставлен в «false», поведение при создании снапшота будет аналогично предыдущему случаю: снапшот создастся успешно, но по факту VSS будет не задействован и в результате мы можем получить неконсистентный бэкап. Второй симптом отключенного параметра — это пустой backup.xml (без описания VSS райтеров) в vss_manifests.zip.
В-четвёртых, проверьте наличие динамических дисков внутри гостевой машины. Если внутри гостевой системы будет присутствовать хоть один динамический диск — не важно системный он или нет, то VSS задействован не будет. Снапшот будет создаваться успешно, но vss_manifests.zip будет пустым, как и логи событий внутри гостевой ОСи. Это правило действует для гостевых ОСей Windows 2008 и выше.
То же самое касается IDE дисков — их не должно быть в конфигурации виртуальной машины (но наличие IDE CD-ROM устройств допустимо и на снапшоты не влияет). При этом надо учитывать, что количество свободных SCSI слотов на одном SCSI контроллере должно быть равно количеству дисков. Например: если на SCSI1 уже присутствуют 8 SCSI дисков, то слотов не хватит.
В-пятых: Неработающий VSS внутри гостевой машины. Это основной пункт вызывающий тонны негодования и обращений в техподдержку VMware. Часто люди, видящие неудачный снапшот, грешат на VMware, хотя винить стоит совсем другого гиганта мысли — Microsoft. Примерно такую картину я получил при попытке создать quiesced снапшот машины после неудачной установки новой базы SQL (виртуальный .iso привод был отмонтирован в процессе установки, что очень не понравилось установщику. :-\
Данная проблема была решена банальной перезагрузкой виртуальной машины, и хотя такой метод помогает очень часто, бывают запущенные случаи, когда VSS внутри сломан чуть менее, чем полностью. В этих случаях самый простой способ выяснить, действительно ли Microsoft виноват — это запустить Windows Backup и сделать резервную копию системного состояния (Backup of System State, если кто привык к английским терминам). Windows Backup (или NTBackup) работает — то проблема на стороне VMware, не работает — косяк Microsoft.
У VMware на эту тему есть несколько официальных статей: например тут и тут. Но есть интересная особенность — для упрощения себе жизни (возможно есть и какие-нибудь другие причины) во второй статье VMware в явном виде рекомендует выставить disk.EnableUUID в «false», что означает отказ от использования VSS при создании quiesced снапшота («quiesced-то не настоящий!»). В общем случае такой метод является не решением, а только временным обходным путем, так как последствия подобного подхода могут проявить себя при восстановлении, то есть именно тогда, когда консистентность приложений является ключевой (вспомнить хотя бы тот же USN rollback).
Подводим итоги
По моему опыту, самыми частыми проблемами при создании снапшотов (их неконсистентность) являются пункты 2, 3 и 5, в то время как IDE или динамические диски встречаются гораздо реже.
Конечно же, не исключены и совершенно мистические случаи: например снапшот не создавался (VMware рапортовала невнятную ошибку) по причине того, что iSCSI LUN (датастор), на котором располагалась проблемная виртуальная машина, был подключен физически через 2 сетевые карты в режиме teaming и при этом одна работала на 100MBit, а вторая на 1Gbit.
Тему quiesced снапшотов можно копать чуть ли не вечность — чего стоит хотя бы факт того, что Windows 2008 при создании quiesced снапшота создает не одну, а две дельты на датасторе и по факту пишет в уже созданный снапшот (это, кстати, одна из корневых причин звездочек напротив данных ОСей в табличке выше); или наличие возможности отключать определенные VSS райтеры через конфигурацию vmbackup.conf на гостевой системе. Мир чудесен и удивителен, но граблей хватит на всех. Если будет желание — я с радостью напишу что-нибудь ещё на эту тему. Как обычно, комментарии привествуются, уточнения — тоже, об ошибках и опечатках — в личку, на вопросы постараюсь ответить asap.
Не забывайте подписываться на наш Хаб, у нас запланировано огромное количество статей на тему бэкапа и восстановления данных, быть может, именно наши статьи помогут вам решить определённые проблемы (а лучше — избежать их). Спасибо за внимание. :)
Acronis Backup Advanced for Hyper-V предоставляет современные возможности защиты и восстановления для вашей среды Hyper-V Server (включая кластерные конфигурации Hyper-V).
Технология Acronis AnyData сочетает резервное копирование нового поколения на основе образов дисков без использования агентов внутри систем и глубокую интеграцию с Windows, что обеспечивает скорость операций резервного копирования, а также гибкое и надежное восстановление.
Теперь вы можете быстро и просто восстановить отдельные файлы, данные приложений, полную виртуальную машину или всю среду Hyper-V Server из одной и той же резервной копии. Кроме того, универсальность технологии позволяет восстанавливать сервер как в изначальное местоположение, так и на совершенно новое оборудование. Вы можете даже восстановить виртуальную машину на совершенно другой гипервизор!
- Специализированное резервное копирование для Hyper-V. Решение Acronis Backup Advanced for Hyper-V тесно интегрировано с технологией Hyper-V для балансировки резервных копий внутри среды Hyper-V. Кроме того, использование инкрементного резервного копирования на уровне блоков сокращает объем данных для резервного копирования, что гарантирует быстроту и успешность резервного копирования виртуальных машин.
- Резервное копирование ВМ без использования агентов. Резервное копирование без агентов Acronis исключает необходимость устанавливать агенты на каждую виртуальную машину, тем самым сокращая использование ресурсов и устраняя сложности в управлении.
- Интеграция с Windows Hyper-V. Так как решение Acronis полностью интегрировано с системой Windows Hyper-V, мы можем автоматически идентифицировать все виртуальные машины. Для резервного копирования можно выбрать все виртуальные машины, группы виртуальных машин или отдельные виртуальные машины — определение и восстановление осуществляется за считанные минуты.
- Восстановление сервера в качестве виртуальной машины. Решения Acronis позволяют быстро восстановить любой сервер в качестве виртуальной машины, а также легко клонировать резервную копию в качестве виртуальной машины для разработки или тестирования.
- Резервное копирование непосредственно на ленту. В отличие от других продуктов для резервного копирования Hyper-V, Acronis Backup Advanced for Hyper-V позволяет выполнять резервное копирование напрямую на ленту. В действительности, можно сохранять до 4 дополнительных резервных копий на диск, ленту и облако для доступа к расширенным возможностям восстановления и для большей надежности.
- Управление производительностью напрямую. Гарантируется оптимальная производительность виртуальных машин при выполнении операций резервного копирования. Acronis Backup Advanced for Hyper-V позволяет управлять средой за счет балансировки резервных копий виртуальных машин на сервере Windows. Кроме того, решения Acronis позволяют регулировать пропускную способность и скорость записи диска для поддержания высокой производительности системы во время резервного копирования.
- Эффективное инкрементное резервное копирование. При инкрементном резервном копировании сохраняются только измененные данные, что позволяет значительно сократить время резервного копирования, а также ресурсы сети и хранилища данных.
- Дедупликация. Встроенная дедупликация данных на уровне блоков может выполняться на стороне исходной машины или целевого архива, чтобы уменьшить передвижение данных. Это позволяет уменьшить расходы на хранение дополнительных данных и снизить загрузку сети.
- Модульная архитектура. Гибкая модульная архитектура Acronis позволяет в любое время добавлять в основное решение дополнительные продукты Acronis Backup Advanced для расширенного резервного копирования. Начните с самых важных компонентов, а затем, по мере расширения организации, просто добавляйте дополнительные продукты для защиты новых серверов или рабочих станций — вам не потребуется устанавливать новые выделенные сервера под нужды резервного копирования
- Миграция сервера. Переносите сервер между любыми физическими и виртуальными платформами с помощью запатентованной технологии Acronis Unified Backup Format, которая позволяет восстанавливать любые резервные копии на любых серверах.
- Аварийное восстановление. В случае сбоя оборудования или природной катастрофы запатентованные решения Acronis для резервного копирования образа диска гарантируют быстрое восстановление всего сервера на "голое железо" за считанные минуты с минимальным временем простоя.
- Централизованное управление и отчетность. Продукты пакета Acronis Backup Advanced поддерживаются системой централизованного управления и отчетности. Управляйте всеми операциями резервного копирования на всех физических и виртуальных машинах с единой консоли и просматривайте отчеты с помощью единой панели мониторинга.
Технология Acronis AnyData предоставляет полную защиту всех устройств, операционных систем, виртуальных сред, приложений и хранилищ данных. Одновременное использование продуктов из набора Acronis Backup Advanced в различных сочетаниях позволяет создать единую платформу для защиты данных с понятным пользовательским интерфейсом, унифицированными политиками и централизованным управлением.
Про клиентскую часть
Вот какие Агенты (Клиенты) разработаны:
-
Клиенты резервного копирования для Windows, Linux и Mac – отвечают за резервное копирование данных на машинах под управлением ОС Windows/Linux/Mac.
Работа с сервисом
А теперь рассмотрим, как это работает на практике. Администраторам компании IT-Lite (поставщика услуги) и компаний конечных пользователей предоставляется доступ к управлению сервисом через web-консоль. На приведенной ниже диаграмме показана стандартная архитектура сервиса резервного копирования. Синие стрелки обозначают взаимодействие между компонентами программного обеспечения. Черные стрелки показывают, как администраторы и конечные пользователи получают доступ к сервису резервного копирования.
Acronis Backup Cloud глазами пользователя
Для конечного пользователя работа с системой проста и наглядна. После создания учетной записи пользователя и входа в Личный кабинет необходимо указать компьютер, для которого будет сконфигурировано задание на резервное копирование. Для этого нужно нажать на «+» и выбрать ОС, на которую будет установлен агент. Следующим шагом нужно сконфигурировать задание для резервного копирования.
В консоли управления пользователя отображаются все Задачи, которые выполнялись ранее для конкретного компьютера, помимо этого есть функция «Создать новую Задачу» и «Восстановить данные из облака». Кроме того, доступен просмотр текущего статуса бэкапа для заданного компьютера.
Читайте также: