Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описывается резервное копирование виртуальных машин Azure (ВМ) с помощью службы Azure Backup.
Azure Backup создает независимые, изолированные резервные копии для защиты от непреднамеренного уничтожения данных на виртуальных машинах. Резервные копии хранятся на складе служб восстановления со встроенным управлением точками восстановления. Конфигурация и масштабирование просты, резервное копирование оптимизировано, а восстановление выполняется легко.
В рамках процесса резервного копирования создается моментальный снимок, и данные передаются в хранилище служб восстановления без влияния на производственные нагрузки. Моментальный снимок предоставляет различные уровни согласованности, как описано здесь. Вы можете выбрать резервное копирование на основе агента, согласованное с приложением или файлом, или безагентное резервное копирование с согласованностью при сбое в рамках политики резервного копирования.
Azure Backup также имеет специализированные предложения для нагрузок рабочих процессов баз данных, таких как SQL Server и SAP HANA, которые учитывают особенности рабочих нагрузок, предлагают 15-минутное RPO и позволяют выполнять резервное копирование и восстановление отдельных баз данных.
Теперь вы также можете создать резервную копию виртуальных машин с помощью Azure Backup в расширенных зонах Azure (предварительная версия). Расширенные зоны Azure (предварительная версия) обеспечивают повышенную устойчивость путем распределения ресурсов в нескольких физических расположениях в регионе Azure. Этот подход сводит к минимуму влияние потенциальных сбоев для критической инфраструктуры. Используя расширенные зоны, организации могут обеспечить более высокую доступность и отказоустойчивость для своих приложений. Узнайте, как создать резервную копию виртуальной машины Azure в расширенных зонах Azure (предварительная версия).
Процесс резервного копирования
Вот как Azure Backup выполняет резервное копирование для виртуальных машин Azure.
Для виртуальных машин Azure, выбранных для резервного копирования, Azure Backup запускает задание резервного копирования согласно заданному расписанию архивации.
Если вы выбрали резервное копирование, согласованное с приложением или файловой системой, виртуальная машина должна иметь установленное расширение резервного копирования для координации процесса моментального снимка.
Если вы выбрали резервное копирование, согласованное с сбоями, агенты не требуются на виртуальных машинах.
Во время первой архивации на запущенной виртуальной машине устанавливается расширение резервного копирования.
- Для виртуальных машин Windows устанавливается расширение VMSnapshot .
- Для виртуальных машин Linux устанавливается расширение VMSnapshotLinux .
Для виртуальных машин Windows, находящихся в работе, Azure Backup координирует работу со службой теневого копирования томов Windows (VSS), чтобы создать моментальный снимок виртуальной машины, согласованный с данными приложения.
- По умолчанию служба Backup создает полные резервные копии VSS.
- Если службе Backup не удается сделать моментальный снимок с согласованием приложений, тогда она делает моментальный снимок с согласованием файлов базового хранилища (так как во время пребывания виртуальной машины в остановленном состоянии операции записи приложения не происходят).
На виртуальных машинах Linux выполняется файл-консистентное резервное копирование с помощью службы Backup. Для создания моментальных снимков с согласованием приложений необходимо вручную настроить предварительные и последующие сценарии.
Для виртуальных машин Windows устанавливается распространяемый компонент Microsoft Visual C++ 2015 (x64) версии 14.40.33810.0 , запуск службы теневого копирования томов (VSS) изменяется на автоматически, а служба Windows IaaSVmProvider добавляется.
После создания моментального снимка служба Backup передает данные в хранилище.
- В целях оптимизации резервное копирование дисков виртуальных машин осуществляется параллельно.
- Azure Backup считывает блоки с каждого диска, для которого создается резервная копия, после чего определяет и передает только те блоки данных, в которых с момента предыдущего резервного копирования произошли изменения (дельта).
- Данные мгновенного снимка могут быть не сразу скопированы в хранилище. Это может занять несколько часов при высокой нагрузке. Общее время архивации виртуальной машины при ежедневном резервном копировании составляет менее 24 часов.
Шифрование резервных копий виртуальных машин Azure
При создании резервных копий виртуальных машин Azure с помощью Azure Backup виртуальные машины шифруются в неактивном состоянии с использованием Шифрования службы хранилища. Azure Backup также может выполнять резервное копирование виртуальных машин Azure, зашифрованных с помощью шифрования дисков Azure.
| Encryption | Details | Support |
|---|---|---|
| SSE | Благодаря SSE служба хранилища Azure обеспечивает шифрование неактивных данных, автоматически шифруя данные перед их сохранением. Служба хранилища Azure также расшифровывает данные перед извлечением. Azure Backup поддерживает резервное копирование виртуальных машин с двумя типами шифрования службы хранилища: |
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 служба резервного копирования координируется с VSS, чтобы создать моментальный снимок дисков виртуальной машины, согласованный с приложением. По умолчанию Azure Backup выполняет полное резервное копирование с использованием VSS (при этом во время резервного копирования журналы таких приложений, как SQL Server, усекаются для обеспечения согласованности на уровне приложения). Если вы используете базу данных SQL Server на виртуальной машине Azure, для которой выполняется резервное копирование, то можно изменить настройки, чтобы выполнить резервное копирование VSS Copy (для сохранения журналов). Дополнительные сведения см. в следующей статье.
Виртуальные машины Linux: Для создания моментальных снимков виртуальных машин Linux, согласованных с приложениями, используйте платформу предварительного скрипта Linux и платформу после скриптов для создания собственных пользовательских скриптов для обеспечения согласованности.
- Azure Backup вызывает только написанные вами пре/пост-скрипты.
- Если предварительный и последующий скрипты будут успешно выполнены, служба Azure Backup пометит точку восстановления как согласованную с приложениями. Однако при использовании пользовательских сценариев ответственность за согласованность с приложениями несете именно вы.
- Узнайте больше о настройке скриптов.
Note
Процесс создания моментального снимка начинается с вызова расширения для резервного копирования с использованием агента, применяя такие средства, как VSS для Windows или фриз для Linux, для обеспечения целостности данных. При согласованности коллекция точек восстановления отслеживает расширение и инициирует создание моментального снимка. После этого метаданные обновляются, и пути точки восстановления, а также сведения о фиксации добавляются для завершения резервного копирования с целью восстановления.
Согласованность моментальных снимков
В следующей таблице описываются различные типы согласованности снимков.
| Snapshot | Details | Recovery | Consideration |
|---|---|---|---|
| Application-consistent | Это параметр по умолчанию в политике резервного копирования виртуальных машин. Согласованные с приложениями резервные копии включают содержимое памяти и ожидающие операции ввода-вывода. Для согласованных с приложениями моментальных снимков используется VSS-ридер (или сценарии до/после для Linux), который обеспечивает согласованность данных приложения перед выполнением резервного копирования. | При восстановлении виртуальной машины с использованием моментального снимка с учетом приложения виртуальная машина загружается. В этом случае не происходит потери или повреждения данных. Приложения запускаются в согласованном состоянии. | Windows: Все модули записи VSS выполнены успешно Linux. Предварительные и последующие сценарии настроены и выполнены успешно |
| Согласованность файловой системы | Это параметр по умолчанию в политике резервного копирования виртуальных машин. Согласованные с файловой системой резервные копии обеспечивают согласованность за счет создания одновременного моментального снимка всех файлов. |
При восстановлении виртуальной машины с помощью моментального снимка, согласованного с файловой системой, виртуальная машина загружается. В этом случае не происходит потери или повреждения данных. Чтобы гарантировать согласованность восстановленных данных, в приложениях необходимо реализовать собственный механизм исправления. | Windows: некоторые службы VSS не работают Linux. По умолчанию (если сценарии предварительного и последующего выполнения не настроены или дали сбой) |
| Crash-consistent | Моментальный снимок, согласованный по аварийному состоянию, является настраиваемым параметром в политике резервного копирования виртуальных машин. Azure Backup также выполняет аварийно-согласованное резервное копирование, если виртуальная машина не работает во время резервного копирования и когда резервное копирование, согласованное с приложением/файлом, не удается. Только данные, уже существующие на диске во время операции резервного копирования, фиксируются и резервируются; данные в кэше узла чтения и записи не записываются. |
Сначала выполняется процесс загрузки виртуальной машины, за которым следует проверка диска для исправления ошибок повреждения. Все данные в памяти или операции записи, которые не были переданы на диск перед сбоем, теряются. В приложениях должна быть реализована собственная проверка данных. Например, приложение базы данных может использовать свой журнал транзакций для проверки. Если журнал транзакций содержит записи, которых нет в базе данных, то программное обеспечение базы данных выполняет откат транзакций до согласованного состояния данных. | Если вы выбрали резервное копирование приложения или файловой системы, и виртуальная машина находится в состоянии завершения работы (остановлено или освобождено), и если моментальный снимок повторно создается. Вы выбрали консистентные при сбое резервные копии без агента |
Note
Если состояние подготовки выполнено успешно, Azure Backup принимает согласованные резервные копии файловой системы. Если состояние развертывания недоступно или ошибка, создаются резервные копии с учетом сбоев. Если состояние подготовки создание или удаление, это означает, что Azure Backup повторно выполняет операции.
Вопросы резервного копирования и восстановления
| Consideration | Details |
|---|---|
| Disk | Создание резервной копии дисков виртуальной машины выполняется одновременно. Например, если у виртуальной машины четыре диска, то служба резервного копирования попытается выполнить его для всех четырех дисков одновременно. Резервное копирование инкрементное (только измененные данные). |
| Scheduling | Чтобы уменьшить трафик резервного копирования, резервное копирование разных виртуальных машин следует выполнять в разное время суток и убедиться, что эти времена не совпадают. Резервное копирование виртуальных машин в одно и то же время создает заторы в сети. |
| Подготовка резервных копий | Учитывайте время подготовки для резервного копирования. Время подготовки может включать установку или обновление расширения резервного копирования и активацию моментального снимка в соответствии с расписанием резервного копирования. |
| Передача данных | Учитывайте время, необходимое службе Azure Backup для определения добавочных изменений из предыдущей резервной копии. Чтобы определить изменения в инкрементном резервном копировании, Azure Backup вычисляет контрольную сумму блока. Если блок изменен, он помечается для перемещения в хранилище. Служба анализирует идентифицированные блоки, чтобы сократить объем передаваемых данных. После завершения оценки всех измененных блоков Azure Backup передает изменения в хранилище. Возможна небольшая задержка между созданием моментального снимка и его копированием на хранилище. В пиковые периоды для передачи моментальных снимков в хранилище может потребоваться до 8 часов. Общее время резервного копирования виртуальной машины составляет менее 24 часов для ежедневного резервного копирования. |
| Начальное резервное копирование | Общее время резервного копирования для добавочных резервных копий меньше 24 часов, что может быть не так для первой резервной копии. Время, необходимое для создания первой резервной копии, зависит от размера данных и времени обработки резервной копии. |
| Восстановление очереди | Azure Backup обрабатывает задания восстановления от нескольких учетных записей хранения одновременно, и ставит запросы на восстановление в очередь. |
| Восстановление копии | Во время восстановления данные копируются из хранилища в учетную запись хранения. Общее время восстановления зависит от количества операций ввода-вывода в секунду (IOPS) и пропускной способности учетной записи хранения. Чтобы сократить время копирования, выберите учетную запись хранения, которая не загружена другими операциями чтения и записи приложений. |
Note
Azure Backup теперь позволяет создавать резервные копии виртуальных машин Azure несколько раз в день с помощью расширенной политики. С помощью этой возможности можно также определить длительность запуска заданий резервного копирования и выровнять расписание резервного копирования с рабочими часами, когда существуют частые обновления в Azure Виртуальные машины. Подробнее.
Производительность резервного копирования
На общее время резервного копирования могут повлиять следующие распространенные сценарии:
- Добавление нового диска в защищенную виртуальную машину Azure. Если виртуальная машина проходит добавочное резервное копирование и добавляется новый диск, то время архивации увеличится. Общее время резервного копирования может превышать 24 часа из-за начальной репликации нового диска и разностной репликации существующих дисков.
- Фрагментированные диски: Операции резервного копирования выполняются быстрее, когда изменения диска являются непрерывными. Если изменения распределены по всему диску, резервное копирование будет выполняться медленнее.
- Отток дисков: Если защищенные диски, проходящие добавочное резервное копирование, имеют ежедневный объем обработки более 200 ГБ, резервное копирование может занять много времени (более восьми часов).
- Версии резервного копирования: Последняя версия резервного копирования (известная как версия мгновенного восстановления) использует более оптимизированный процесс, чем сравнение контрольной суммы для выявления изменений. Но если вы используете "Мгновенное восстановление" и удалили снимок резервной копии, тогда процесс резервного копирования переходит на сравнение контрольных сумм. В этом случае время выполнения операции резервного копирования превысит 24 часа (или даст сбой).
Восстановление производительности
Эти распространенные сценарии могут повлиять на общее время восстановления:
- Общее время восстановления зависит от количества операций ввода-вывода в секунду (IOPS) и пропускной способности учетной записи хранения.
- Общее время восстановления может измениться, если у целевой учетной записи хранения будет дополнительная нагрузка в виде операций чтения и записи, выполняемых другим приложением. Чтобы ускорить выполнение операции восстановления, выбирайте ту учетную запись хранения, которая не нагружена данными других приложений.
Лучшие практики
Ниже приведены рекомендации, которые следует учитывать при настройке резервного копирования виртуальных машин.
- Измените время расписания по умолчанию, установленное в политике. Например, если время по умолчанию в политике установлено на 12:00, увеличьте его на несколько минут, чтобы обеспечить оптимальное использование ресурсов.
- При восстановлении виртуальных машин из одного хранилища резервных копий настоятельно рекомендуется использовать разные хранилища общего назначения версии 2, чтобы гарантировать, что целевая учетная запись хранения не будет подвергнута ограничению. Например, каждая виртуальная машина должна иметь отдельную учетную запись хранения. Например, если восстанавливается 10 виртуальных машин, используйте 10 разных учетных записей хранения.
- Для резервного копирования виртуальных машин, использующих хранилище класса Premium с мгновенным восстановлением, рекомендуется выделить 50% свободное пространство общего выделенного места хранения, которое требуется только для первой резервной копии. 50 % свободного пространства не является обязательным требованием для создания резервных копий после завершения первой операции архивации.
- Ограничение на количество дисков в учетной записи хранения зависит от того, как часто к дискам обращаются приложения, работающие на виртуальной машине с поддержкой инфраструктуры как услуги (IaaS). В общем случае, если в одной учетной записи хранения есть от 5 до 10 дисков, сбалансируйте нагрузку, переместив некоторые диски в отдельные учетные записи хранения.
- Чтобы восстановить виртуальные машины с управляемыми дисками с помощью PowerShell, укажите дополнительный параметр TargetResourceGroupName , чтобы указать группу ресурсов, в которую будут восстановлены управляемые диски, дополнительные сведения см. здесь.
Оплата резервного копирования
В отношении виртуальных машин Azure, резервное копирование которых выполняется с помощью службы Azure Backup, действует прейскурант на использование службы Azure Backup.
Выставление счетов начинается только после завершения первого успешного резервного копирования. На этом этапе начинается выставление счетов за хранение и защищенные виртуальные машины. Выставление счетов продолжается, пока в хранилище есть резервные копии данных для виртуальной машины. Если вы остановите защиту виртуальной машины, но данные резервного копирования виртуальной машины остаются в хранилище, выставление счетов продолжится.
Выставление счетов для определенной виртуальной машины прекращается, только если останавливается защита и удаляются все данные резервных копий. Когда защита останавливается и нет активных заданий резервного копирования, размер виртуальной машины во время последнего успешного резервного копирования становится размером защищенного экземпляра, на основе которого выставляется ежемесячный счет.
Если вы решили использовать согласованные с агентом резервные копии приложений или файловой системы, расчет размера защищенного экземпляра зависит от фактического размера виртуальной машины. Размер виртуальной машины — это сумма всех данных в виртуальной машине, за исключением временного хранилища. Цены основаны на фактических данных, которые хранятся на дисках данных, а не на максимальном поддерживаемом размере для каждого диска данных, подключенного к виртуальной машине.
Note
Общедоступна функция резервного копирования виртуальных машин без агента с поддержкой нескольких дисков, обеспечивающая согласованность при аварийном завершении. Этот выпуск включает изменения в выставление счетов; см. сведения о ценах.
Аналогичным образом, счет за хранилище службы архивации основан на объеме данных, хранящихся в службе архивации Azure, который представляет собой сумму фактических данных в каждой точке восстановления.
Например, возьмем виртуальную машину A2 стандартного размера с двумя дополнительными дисками данных максимальным объемом по 32 ТБ каждый. В следующей таблице приводятся фактические данные, хранящиеся на каждом из этих дисков:
| Disk | Максимальный размер | Присутствующие фактические данные |
|---|---|---|
| Диск операционной системы | 32 ТБ | 17 ГБ |
| Локальный или временный диск | 135 ГБ | 5 ГБ (не учитывается для архивации) |
| Диск данных 1 | 32 ТБ | 30 ГБ |
| Диск данных 2 | 32 ТБ | 0 ГБ |
Фактический размер виртуальной машины в этом случае составляет 17 ГБ + 30 ГБ + 0 ГБ = 47 ГБ. Этот размер защищенного экземпляра (47 ГБ) служит основой для ежемесячного счета. По мере роста объема данных на виртуальной машине, соответствующим образом изменяется размер защищенного экземпляра, используемый для выставления счетов.