Поделиться через


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

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

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

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

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

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

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

Вот как 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 Redistributable (x64) версии 12.0.40660, режим запуска службы теневого копирования томов (VSS) изменяется на автоматический, и добавляется служба Windows IaaSVmProvider.

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

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

На схеме показана архитектура резервного копирования виртуальных машин Azure.

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

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

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

    Шифрование дисков Azure интегрируется с ключами шифрования BitLocker (BEK), которые хранятся в хранилище ключей в качестве секретов. Шифрование дисков Azure также интегрируется с ключами шифрования Azure Key Vault (KEKs).
    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 выполняет полное резервное копирование с использованием VSS (при этом во время резервного копирования журналы таких приложений, как SQL Server, усекаются для обеспечения согласованности на уровне приложения). Если вы используете базу данных SQL Server на виртуальной машине Azure, для которой выполняется резервное копирование, то можно изменить настройки, чтобы выполнить резервное копирование VSS Copy (для сохранения журналов). Дополнительные сведения см. в этой статье.

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

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

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

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

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

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

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

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

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

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

    Примечание.

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

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

    Рассмотрение Сведения
    Диск Создание резервной копии дисков виртуальной машины выполняется одновременно. Например, если у виртуальной машины четыре диска, то служба резервного копирования попытается выполнить его для всех четырех дисков одновременно. Резервное копирование инкрементное (только измененные данные).
    Планирование Чтобы уменьшить трафик резервного копирования, резервное копирование разных виртуальных машин следует выполнять в разное время суток и убедиться, что эти времена не совпадают. Резервное копирование виртуальных машин в одно и то же время создает заторы в сети.
    Подготовка резервных копий Учитывайте время подготовки для резервного копирования. Время подготовки может включать установку или обновление расширения резервного копирования и активацию моментального снимка в соответствии с расписанием резервного копирования.
    Передача данных Учитывайте время, необходимое службе 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 ГБ) служит основой для ежемесячного счета. По мере роста объема данных на виртуальной машине, соответствующим образом изменяется размер защищенного экземпляра, используемый для выставления счетов.

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