Общие сведения о резервном копировании виртуальной машины Azure

  • Статья

В этой статье описывается резервное копирование виртуальных машин Azure (ВМ) с помощью службы Azure Backup.

Azure Backup создает независимые, изолированные резервные копии для защиты от непреднамеренного уничтожения данных на виртуальных машинах. Резервные копии хранятся на складе служб восстановления со встроенным управлением точками восстановления. Конфигурация и масштабирование просты, резервное копирование оптимизировано, а восстановление выполняется легко.

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

Azure Backup также предоставляет особые предложения при рабочих нагрузках в виде баз данных, таких как SQL Server и SAP HANA, которые следят за рабочей нагрузкой, обеспечивают 15-минутную RPO (цель точки восстановления) и позволяют выполнять резервное копирование и восстановление отдельных баз данных.

Процесс резервного копирования

Вот как Azure Backup выполняет резервное копирование для виртуальных машин Azure.

  1. Для виртуальных машин Azure, выбранных для резервного копирования, Azure Backup запускает задание резервного копирования согласно заданному расписанию архивации.

  2. Если вы выбрали резервное копирование, согласованное с приложением или файловой системой, виртуальная машина должна установить расширение резервного копирования для координации процесса моментального снимка.

    Если вы выбрали резервное копирование, согласованное с сбоями, агенты не требуются на виртуальных машинах.

  3. Во время первой архивации на запущенной виртуальной машине устанавливается расширение резервного копирования.

  4. Для виртуальных машин Windows, работающих, Azure Backup координирует работу со службой теневого копирования томов Windows (VSS), чтобы создать моментальный снимок виртуальной машины, согласованный с приложением.

    • По умолчанию служба Backup создает полные резервные копии VSS.
    • Если службе Backup не удается сделать моментальный снимок с согласованием приложений, тогда она делает моментальный снимок с согласованием файлов базового хранилища (так как во время пребывания виртуальной машины в остановленном состоянии операции записи приложения не происходят).

  5. На виртуальных машинах Linux служба Backup выполняет резервную копию с согласованием файлов. Для создания моментальных снимков с согласованием приложений необходимо вручную настроить такие сценарии.

  6. Для виртуальных машин Windows устанавливается распространяемый компонент Microsoft Visual C++ 2013 (x64) версии 12.0.40660, запуск службы теневого копирования томов (VSS) изменяется на автоматически, а служба Windows IaaSVmProvider добавляется.

  7. После создания моментального снимка служба Backup передает данные в хранилище.

    • В целях оптимизации резервное копирование дисков виртуальных машин осуществляется параллельно.
    • Azure Backup считывает блоки с каждого диска, для которого создается резервная копия, после чего определяет и передает только те блоки данных, в которых с момента предыдущего резервного копирования произошли изменения (дельта).
    • Данные моментального снимка могут копироваться в хранилище не сразу. Это может занять несколько часов при высокой нагрузке. Общее время архивации виртуальной машины при ежедневном резервном копировании составляет менее 24 часов.

Diagram shows the Azure Virtual Machine backup architecture.

Шифрование резервных копий виртуальных машин Azure

При создании резервных копий виртуальных машин Azure с помощью Azure Backup виртуальные машины шифруются в неактивном состоянии с использованием Шифрования службы хранилища. Azure Backup также может выполнять резервное копирование виртуальных машин Azure, зашифрованных с помощью шифрования дисков Azure.

Шифрование Сведения Поддержка
SSE Благодаря SSE служба хранилища Azure обеспечивает шифрование неактивных данных, автоматически шифруя данные перед их сохранением. Служба хранилища Azure также расшифровывает данные перед извлечением. Azure Backup поддерживает резервное копирование виртуальных машин с двумя типами шифрования службы хранилища:
  • SSE с ключами, управляемыми платформой. Это шифрование по умолчанию для всех дисков на виртуальных машинах. Дополнительные сведения см. здесь.
  • SSE с ключами, управляемыми клиентом. С помощью ключей, управляемых клиентом, производится управление ключами, используемыми для шифрования дисков. Дополнительные сведения см. здесь.
    		•  Azure Backup использует SSE для шифрования неактивных данных виртуальных машин Azure.
    Дисковое шифрование Azure Шифрование дисков Azure шифрует диски операционной системы и дисков данных для виртуальных машин Azure.

    Шифрование дисков Azure интегрируется с ключами шифрования BitLocker (BEK), которые хранятся в хранилище ключей в качестве секретов. Шифрование дисков Azure также интегрируется с ключами шифрования ключей Azure Key Vault (KEK).    		 Azure Backup поддерживает резервное копирование управляемых и неуправляемых виртуальных машин Azure, зашифрованных только с использованием ключей BEK или ключей BEK вместе с ключами KEK.

    Как ключи BEK, так и KEK сохраняются в виде резервной копии и шифруются.

    Так как выполняется резервное копирование ключей KEK и BEK, пользователи с необходимыми разрешениями могут восстановить ключи и секреты в хранилище ключей, если это необходимо. Эти пользователи также могут восстановить зашифрованную виртуальную машину.

    Зашифрованные ключи и секреты недоступны для чтения неавторизованными пользователями или для Azure.

    Для управляемых и неуправляемых виртуальных машин Azure служба архивации поддерживает как виртуальные машины, зашифрованные только с помощью ключей BEK, так и виртуальные машины, зашифрованные с помощью ключей BEK вместе с ключами KEK.

    Резервные копии ключей BEK (секретов) и KEK (ключей) шифруются. Их можно будет считать и использовать только после того, как они будут восстановлены обратно в хранилище ключей полномочными пользователями. Как неполномочные пользователи, так и Azure не могут читать или использовать резервные копии ключей или секретов.

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

    Создание моментального снимка

    Azure Backup создает моментальные снимки в соответствии с расписанием резервного копирования.

    Если вы выбрали резервное копирование, согласованное с файловой системой, виртуальная машина должна установить расширение резервного копирования для координации процесса моментального снимка. Для резервного копирования без агента, согласованного с несколькими дисками, агент виртуальной машины не требуется для моментальных снимков.

    • Виртуальные машины Windows. Для виртуальных машин Windows служба резервного копирования координируется со службой теневого копирования томов, что позволяет создать моментальный снимок дисков виртуальной машины с согласованием приложений. По умолчанию Azure Backup создает полную резервную копию службы теневого копирования томов (она производит усечение журналов приложения, таких как SQL Server во время резервного копирования, чтобы получить резервное копирование, обеспечивающее единообразие на уровне приложения). Если используется база данных SQL Server в резервной копии виртуальной машины Azure, можно изменить этот параметр, чтобы создать резервную копию копии службы теневого копирования томов (для сохранения журналов). Дополнительные сведения см. в этой статье.

    • Виртуальные машины Linux. Чтобы создавать моментальные снимки виртуальных машин Linux с согласованием приложений, используйте платформу Linux со сценариями, выполняющимися до и после создания моментальных снимков, для написания собственных пользовательских сценариев для обеспечения согласованности.

      • Служба Azure Backup вызывает только созданные вами сценарии, выполняемые до и после создания моментального снимка.
      • Если предварительный и последующий скрипты будут успешно выполнены, служба Azure Backup пометит точку восстановления как согласованную с приложениями. Однако при использовании пользовательских сценариев ответственность за согласованность с приложениями несете именно вы.
      • Ознакомьтесь с дополнительными сведениями о настройке сценариев.

    Согласованность моментального снимка

    В следующей таблице описываются различные типы согласованности.

    Моментальный снимок Сведения Восстановление Рассмотрение
    Согласованность с приложениями Это параметр по умолчанию в политике резервного копирования виртуальных машин. Согласованные с приложениями резервные копии включают содержимое памяти и ожидающие операции ввода-вывода. Для согласованных с приложениями моментальных снимков используется модуль записи VSS (либо предварительный или последующий сценарий для Linux), который обеспечивает согласованность данных приложения перед началом резервного копирования. При восстановлении виртуальной машины с использованием согласованного с приложениями моментального снимка выполняется загрузка виртуальной машины. В этом случае не происходит потери или повреждения данных. Приложение запускается в согласованном состоянии. Windows. Все модули записи VSS выполнены успешно

    Linux. Предварительные и последующие сценарии настроены и выполнены успешно
    Согласованность с файловой системой Это параметр по умолчанию в политике резервного копирования виртуальных машин. Согласованные с файловой системой резервные копии обеспечивают согласованность за счет создания одновременного моментального снимка всех файлов.

    		 При восстановлении виртуальной машины с помощью моментального снимка, согласованного с файловой системой, выполняется загрузка виртуальной машины. В этом случае не происходит потери или повреждения данных. Чтобы гарантировать согласованность восстановленных данных, в приложениях необходимо реализовать собственный механизм исправления. Windows: сбой некоторых писателей VSS

    Linux. По умолчанию (если сценарии предварительного и последующего выполнения не настроены или дали сбой)
    Отказоустойчивость Моментальный снимок, согласованный с аварийной ошибкой, является параметром согласия в политике резервного копирования виртуальных машин. Azure Backup также выполняет резервное копирование, согласованное с сбоями, если виртуальная машина не выполняется во время резервного копирования, а также при сбое резервного копирования, согласованного с приложением или файлом.

    Только данные, уже существующие на диске во время операции резервного копирования, фиксируются и резервируются; данные в кэше узла чтения и записи не записываются.    		 Сначала выполняется процесс загрузки виртуальной машины, за которым следует проверка диска для исправления ошибок повреждения. Все данные в памяти или операции записи, которые не были переданы на диск перед сбоем, теряются. В приложениях должна быть реализована собственная проверка данных. Например, приложение базы данных может использовать свой журнал транзакций для проверки. Если журнал транзакций содержит записи, которых нет в базе данных, то программное обеспечение базы данных выполняет откат транзакций до согласованного состояния данных. Если вы выбрали резервное копирование приложения или файловой системы, а виртуальная машина находится в состоянии завершения работы (остановлено или освобождено) и при извлечении моментального снимка.

    Вы выбрали отказоустойчивые резервные копии без агента

    Примечание.

    Если состояние подготовки успешное, Azure Backup создает резервные копии, согласованные с файловой системой. Если состояние подготовки недоступное или завершившееся сбоем, создаются резервные копии, согласованные с аварийным завершением. Если состояние подготовки — создание или удаление, это означает, что Azure Backup пытается повторить операции.

    Вопросы резервного копирования и восстановления

    Рассмотрение Сведения
    Диск Создание резервной копии дисков виртуальной машины выполняется одновременно. Например, если у виртуальной машины четыре диска, то служба резервного копирования попытается выполнить его для всех четырех дисков одновременно. Резервное копирование является добавочным (только измененные данные).
    Планирование Чтобы уменьшить трафик резервного копирования, резервное копирование разных виртуальных машин следует полностью разнести во времени и убедиться, что время копирования не перекрывается. Резервное копирование виртуальных машин в одно и то же время создает перегрузку.
    Подготовка резервных копий Учитывайте время подготовки для резервного копирования. Время подготовки может включать установку или обновление расширения резервного копирования и активацию моментального снимка в соответствии с расписанием резервного копирования.
    Передача данных в службы Azure и обратно Учитывайте время, необходимое службе Azure Backup для определения добавочных изменений из предыдущей резервной копии.

    Чтобы определить добавочные изменения, служба Azure Backup вычисляет контрольную сумму блоков. Если блок изменен, он помечается для перемещения в хранилище. Служба анализирует идентифицированные блоки, чтобы сократить объем передаваемых данных. После завершения оценки всех измененных блоков Azure Backup передает изменения в хранилище.

    Возможна небольшая задержка между созданием моментального снимка и его копированием в хранилище. В пиковые моменты для передачи моментальных снимков в хранилище может потребоваться до 8 часов. Общее время резервного копирования виртуальной машины составляет менее 24 часов для ежедневного резервного копирования.
    Начальное резервное копирование Общее время резервного копирования для добавочных резервных копий меньше 24 часов, что может быть не так для первой резервной копии. Время, необходимое для создания первой резервной копии, зависит от размера данных и времени обработки резервной копии.
    Очередь восстановления Azure Backup обрабатывает задания восстановления от нескольких учетных записей хранения одновременно, и ставит запросы на восстановление в очередь.
    Копирование при восстановлении Во время восстановления данные копируются из хранилища в учетную запись хранения.

    Общее время восстановления зависит от количества операций ввода-вывода в секунду (IOPS) и пропускной способности учетной записи хранения.

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

    Примечание.

    Azure Backup теперь позволяет создавать резервные копии виртуальных машин Azure несколько раз в день с помощью расширенной политики. С помощью этой возможности можно также определить длительность запуска заданий резервного копирования и выровнять расписание резервного копирования с рабочими часами, когда существуют частые обновления в Azure Виртуальные машины. Подробнее.

    Производительность резервного копирования

    На общее время резервного копирования могут повлиять следующие распространенные сценарии:

    • Добавление нового диска в защищенную виртуальную машину Azure. Если виртуальная машина проходит добавочное резервное копирование и добавляется новый диск, то время архивации увеличится. Общее время резервного копирования может превышать 24 часа из-за начальной репликации нового диска и разностной репликации существующих дисков.
    • Фрагментированные диски. Операции резервного копирования выполняются быстрее, когда изменения на диске размещены последовательно. Если изменения распределены по всему диску, резервное копирование будет выполняться медленнее.
    • Отток с диска. Если защищенные диски, для которых выполняется добавочное резервное копирование, испытывают отток в объеме более 200 ГБ в день, завершение резервного копирования может занять много времени (более 8 часов).
    • Версии резервных копий. В последней версии Backup (известной как версия "Мгновенного восстановления") используется более оптимальный процесс, в отличие от сравнения контрольных сумм для выявления изменений. Но если используется "Мгновенное восстановление" и был удален моментальный снимок резервной копии, резервное копирование переключится на сравнение контрольных сумм. В этом случае время выполнения операции резервного копирования превысит 24 часа (или даст сбой).

    Производительность восстановления

    Эти распространенные сценарии могут повлиять на общее время восстановления:

    • Общее время восстановления зависит от количества операций ввода-вывода в секунду (IOPS) и пропускной способности учетной записи хранения.
    • Общее время восстановления может измениться, если у целевой учетной записи хранения будет дополнительная нагрузка в виде операций чтения и записи, выполняемых другим приложением. Чтобы ускорить выполнение операции восстановления, выбирайте ту учетную запись хранения, которая не нагружена данными других приложений.

    Рекомендации

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

    • Измените запланированное время по умолчанию в политике. Например, если время по умолчанию в политике — 12:00, увеличьте его шагами по несколько минут, чтобы обеспечить оптимальное использование ресурсов.
    • При восстановлении виртуальных машин из одного хранилища настоятельно рекомендуется использовать разные учетные записи хранения общего назначения версии 2, чтобы гарантировать, что целевая учетная запись хранения не будет подвергнута регулированию рабочей нагрузки. Например, каждая виртуальная машина должна иметь отдельную учетную запись хранения. Например, если восстанавливается 10 виртуальных машин, используйте 10 разных учетных записей хранения.
    • Для резервного копирования виртуальных машин, использующих хранилище класса "Премиум" с "Мгновенным восстановлением", рекомендуется выделить 50 % свободного пространства от общего выделенного пространства хранилища, которое требуется только для создания первой резервной копии. 50 % свободного пространства не является обязательным требованием для создания резервных копий после завершения первой операции архивации.
    • Ограничение на количество дисков в учетной записи хранения зависит от того, как часто к дискам обращаются приложения, работающие на виртуальной машине с поддержкой инфраструктуры как услуги (IaaS). В общем случае, если в одной учетной записи хранения есть от 5 до 10 дисков, сбалансируйте нагрузку, переместив некоторые диски в отдельные учетные записи хранения.
    • Чтобы восстановить виртуальные машины с управляемыми дисками при помощи PowerShell, укажите дополнительный параметр TargetResourceGroupName, чтобы определить группу ресурсов, в которую будут восстановлены управляемые диски. Подробнее см. здесь.

    Оплата резервного копирования

    В отношении виртуальных машин Azure, резервное копирование которых выполняется с помощью службы Azure Backup, действует прейскурант на использование службы Azure Backup.

    Выставление счетов начинается только после завершения первого успешного резервного копирования. На этом этапе начинается выставление счетов за службу хранилища и защищенные виртуальные машины. Выставление счетов продолжается, пока в хранилище есть резервные копии данных для виртуальной машины. Если вы остановите защиту виртуальной машины, но данные резервного копирования виртуальной машины остаются в хранилище, выставление счетов продолжится.

    Выставление счетов для определенной виртуальной машины прекращается, только если останавливается защита и удаляются все данные резервных копий. Когда защита останавливается и нет активных заданий резервного копирования, размер виртуальной машины во время последнего успешного резервного копирования становится размером защищенного экземпляра, на основе которого выставляется ежемесячный счет.

    Если вы решили использовать согласованные с агентом резервные копии приложений или файловой системы, расчет размера защищенного экземпляра зависит от фактического размера виртуальной машины. Размер виртуальной машины — это сумма всех данных в виртуальной машине, за исключением временного хранилища. Цены основаны на фактических данных, которые хранятся на дисках данных, а не на максимальном поддерживаемом размере для каждого диска данных, подключенного к виртуальной машине.

    Примечание.

    Для резервных копий без сбоев, согласованных с агентом, в настоящее время взимается плата за 0,5 защищенного экземпляра (PI) на виртуальную машину во время предварительной версии.

    Аналогичным образом, счет за хранилище службы архивации основан на объеме данных, хранящихся в службе архивации Azure, который представляет собой сумму фактических данных в каждой точке восстановления.

    Например, возьмем виртуальную машину A2 стандартного размера с двумя дополнительными дисками данных максимальным объемом по 32 ТБ каждый. В следующей таблице приводятся фактические данные, хранящиеся на каждом из этих дисков:

    Диск Максимальный размер Присутствующие фактические данные
    Диск ОС 32 ТБ 17 ГБ
    Локальный или временный диск 135 ГБ 5 ГБ (не учитывается для архивации)
    Диск данных 1 32 ТБ 30 ГБ
    Диск данных 2 32 ТБ 0 ГБ

    Фактический размер виртуальной машины в этом случае составляет 17 ГБ + 30 ГБ + 0 ГБ = 47 ГБ. Этот размер защищенного экземпляра (47 ГБ) служит основой для ежемесячного счета. По мере роста объема данных на виртуальной машине, соответствующим образом изменяется размер защищенного экземпляра, используемый для выставления счетов.

    Следующие шаги