Миграция с устройств StorSimple 8100 и 8600 в службу "Синхронизация файлов Azure"

Серия StorSimple 8000 включает либо 8100, либо физические 8600, локальные устройства и их компоненты облачной службы. В этом руководстве по миграции также есть виртуальные модули StorSimple 8010 и 8020. Данные можно перенести из любого из этих устройств в общие папки Azure с помощью дополнительной функции Синхронизации файлов Azure. Синхронизация файлов Azure представляет собой стратегически долгосрочную службу Azure по умолчанию, которая заменяет функции локальной службы StorSimple. Эта статья содержит необходимые основные сведения и информацию об этапах миграции для успешного переноса в службу "Синхронизация файлов Azure".

Примечание.

Служба StorSimple (включая диспетчер устройств StorSimple для серии 8000 и 1200 и диспетчера данных StorSimple) достигла конца поддержки. Конец поддержки StorSimple был опубликован в 2019 году на страницах политики Microsoft LifeCycle и Azure Communications . Дополнительные уведомления были отправлены по электронной почте и размещены на портал Azure и в обзоре StorSimple. Обратитесь служба поддержки Майкрософт для получения дополнительных сведений.

В этом видео представлен обзор:

• Файлы Azure
• Служба синхронизации файлов Azure
• Сравнение StorSimple и Файлы Azure
• Обзор средства миграции и процесса Диспетчера данных StorSimple

Этап 1. Подготовка к миграции

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

В этом видео рассматриваются следующие темы:

• Выбор уровня хранилища
• Выбор параметров избыточности хранилища
• Выбор прямого доступа и Синхронизация файлов Azure
• Ключ шифрования данных службы StorSimple и серийный номер
• Миграция резервного копирования томов StorSimple
• Сопоставление томов и общих папок StorSimple с общими папками Azure
• Группирование общих папок в общих папках Azure
• Рекомендации по сопоставлению
• Лист планирования миграции
• Электронная таблица сопоставления пространства имен

Запасы

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

• Для физических устройств StorSimple (серии 8000) воспользуйтесь этим руководством по миграции.
• Виртуальные устройства StorSimple (серия 1200) используют другое руководство по миграции.

Сводка по стоимости миграции

Миграция в общие папки Azure из томов StorSimple с помощью заданий миграции в ресурсе "Диспетчер данных StorSimple" осуществляется бесплатно. Другие затраты могут возникнуть во время миграции и после нее:

• Исходящий трафик сети. Ваши файлы StorSimple находятся в учетной записи хранения в определенном регионе Azure. Если вы подготавливаете общие папки Azure, которые вы переносите в учетную запись хранения в том же регионе Azure, расходы на исходящий трафик не возникают. Однако при перемещении файлов в учетную запись хранения в другом регионе в рамках этой миграции будут применены затраты на исходящий трафик.
• Транзакции в общей папке Azure. При копировании файлов в общую папку Azure (в рамках миграции или за ее пределами) по мере записи файлов и метаданных взимается плата за транзакции. Во время миграции рекомендуется запускать общую папку Azure на уровне, оптимизированном для транзакций. По завершении миграции переключитесь на нужный уровень. Этапы, описанные в этой статье, вызывают это на соответствующем этапе.
• Изменение уровня общей папки Azure. Изменение уровня затрат на транзакции в общей папке Azure. В большинстве случаев это более экономично, чтобы следовать советам с предыдущей точки.
• Стоимость хранения. После начала копирования файлов в общую папку Azure во время миграции начинается использование места в хранилище и за него выставляется счет. Перенесенные резервные копии становятся моментальными снимками общей папки Azure. Моментальные снимки общей папки используют емкость хранилища только для различий, которые они содержат.
• StorSimple: пока вы не отмените подготовку устройств StorSimple и учетных записей хранения, затраты StorSimple на хранение, резервные копии и устройства будут продолжаться.

Сравнение прямого доступа к общим папкам и службы "Синхронизация файлов Azure"

Общие папки Azure открывают новый мир возможностей для структурирования развертывания файловых служб. Общая папка Azure — это общий ресурс SMB в облаке, к которому можно настроить доступ пользователей непосредственно через протокол SMB с помощью знакомой проверки подлинности Kerberos и существующих разрешений NTFS (списки управления доступом к файлам и папкам). Узнайте больше о доступе к общим папкам Azure на основе удостоверений.

Альтернативой для прямого доступа является Синхронизация файлов Azure — непосредственный аналог возможности StorSimple для локального кэширования часто используемых файлов.

Синхронизация файлов Azure — это облачная служба Майкрософт на базе двух основных компонентов:

• Синхронизация файлов и распределение по уровням в облаке для создания кэша доступа к производительности на любом сервере Windows Server.
• Общие папки как собственные хранилища в Azure, к которым можно получить доступ по нескольким протоколам, таким как SMB и файловый REST.

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

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

• Руководство по планированию Синхронизация файлов Azure
• Руководство по развертыванию службы "Синхронизация файлов Azure"

Ключ шифрования данных службы StorSimple

При первой настройке устройства StorSimple он создал ключ шифрования данных службы и поручил безопасно хранить ключ. Этот ключ используется для шифрования всех данных в связанной учетной записи хранения Azure, где устройство StorSimple хранит ваши файлы.

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

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

Изменение ключа шифрования данных службы

Ключи шифрования данных службы используются для шифрования конфиденциальных данных клиентов, например учетных данных учетной записи, которые отправляются из службы StorSimple Manager к устройству StorSimple. Необходимо будет периодически менять эти ключи, если у ИТ-организации есть политика ротации ключей на устройствах хранения. Процесс изменения ключа может немного отличаться в зависимости от того, имеется ли одно или несколько устройств, управляемых службой StorSimple Manager. Дополнительные сведения см. в статье Защита устройства StorSimple и данных.

Процесс изменения ключа шифрования данных службы включает 3 шага.

1. С помощью скриптов Windows PowerShell для Azure Resource Manager авторизуйте устройство, чтобы изменить ключ шифрования данных службы.
2. С помощью Windows PowerShell для StorSimple инициируйте изменение ключа шифрования данных службы.
3. Если у вас более одного устройства StorSimple, обновите ключ шифрования данных службы на других устройствах.

Шаг 1. Использование скрипта Windows PowerShell для авторизации изменения ключа шифрования данных службы на устройстве

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

Этот шаг выполняется с помощью скрипта на основе Azure Resource Manager. Администратор служб может выбрать устройство для авторизации. Устройство авторизуется для начала изменения ключа шифрования данных службы.

Дополнительные сведения об использовании скрипта см. в статье Authorize-ServiceEncryptionRollover.ps1

Какие устройства можно авторизовать для изменения ключей шифрования данных службы?

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

• Устройство должно быть подключено к сети для авторизации изменения ключа шифрования данных службы.
• Одно устройство можно авторизовать еще раз через 30 минут, если изменение ключа не было запрошено.
• Можно авторизовать другое устройство, если изменение ключа не было инициировано ранее авторизованным устройством. После авторизации нового устройства старое не сможет инициировать изменение.
• Невозможно авторизовать устройство во время смены ключа шифрования данных службы.
• Можно авторизовать устройство, если некоторые из зарегистрированных в службе устройств изменили шифрование, а другие — нет.

Шаге 2. Использование Windows PowerShell для StorSimple для изменения ключа шифрования данных службы

Этот шаг выполняется в интерфейсе Windows PowerShell для StorSimple на авторизованном устройстве StorSimple.

Примечание.

До завершения смены ключей на портале Azure службы StorSimple Manager не могут выполняться никакие операции.

Если вы используете последовательную консоль устройства выполните следующие действия для подключения к интерфейсу Windows PowerShell.

Запуск изменения ключа шифрования данных службы

1. Выберите вариант 1, чтобы войти на устройство с правами на полный доступ.

2. В командной строке введите:

   Invoke-HcsmServiceDataEncryptionKeyChange

3. После успешного завершения работы командлета вы получите новый ключ шифрования данных службы. Скопируйте и сохраните этот ключ для использования на шаге 3. Этот ключ будет использоваться для обновления всех остальных устройств, зарегистрированных в службе StorSimple Manager.

   Примечание.

   Этот процесс должен быть запущен в течение четырех часов авторизации устройства StorSimple.

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

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

Шаг 3. Обновление ключа шифрования данных службы на других устройствах StorSimple

Эти действия необходимо выполнить в интерфейсе Windows PowerShell устройства StorSimple при наличии нескольких устройств, зарегистрированных в службе StorSimple Manager. Ключ, полученный на шаге 2, следует использовать для обновления остальных устройств StorSimple, зарегистрированных в службе StorSimple Manager.

Выполните следующие действия для обновления шифрования данных службы на устройстве.

Обновление ключа шифрования данных службы на физических устройствах

1. Используйте Windows PowerShell для StorSimple, чтобы подключиться к консоли. Выберите вариант 1, чтобы войти на устройство с правами на полный доступ.
2. В командной строке введите следующий текст: Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey.
3. Укажите ключ шифрования данных службы, полученный на Шаге 2. Использование Windows PowerShell для StorSimple для изменения ключа шифрования данных службы.

Обновление ключа шифрования данных службы на всех облачных устройствах 8010/8020

1. Скачайте и установите сценарий PowerShell Update-CloudApplianceServiceEncryptionKey.ps1.
2. Откройте PowerShell и введите следующую команду в командной строке: Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

Этот сценарий гарантирует, что ключ шифрования служебных данных будет установлен на всех облачных устройствах 8010/8020 в диспетчере устройств.

Внимание

Выбирая способ подключения к устройству StorSimple, примите во внимание следующие аспекты:

• Наиболее безопасным и рекомендуемым способом подключения является подключение через сеанс HTTPS.
• Подключение непосредственно к последовательной консоли устройства безопасно, но подключение к последовательной консоли через сетевые коммутаторы не выполняется.
• Соединения в рамках сеанса HTTP возможны, но не шифруются. Они не рекомендованы, если только не используются в рамках закрытой и доверенной сети.

Известные ограничения

Диспетчер данных StorSimple и общие папки Azure имеют несколько ограничений, которые следует учитывать перед началом работы, так как они могут предотвратить миграцию:

• Поддерживаются только тома NTFS из вашего устройства StorSimple. Тома ReFS не поддерживаются.
• Любой том, размещенный на динамических дисках Windows Server, не поддерживается.
• Служба не работает с томами, зашифрованными с помощью BitLocker, или томами, для которых включена дедупликация данных.
• Поврежденные резервные копии StorSimple перенести невозможно.
• Специальные сетевые параметры, такие как брандмауэры или связь только с частной конечной точкой, не могут быть включены ни в исходной учетной записи хранения, где хранятся резервные копии StorSimple, ни в целевой учетной записи хранения, в которой хранятся общие папки Azure.

Точность файлов

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

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

Файлы Azure поддерживают подмножество свойств файла NTFS. Списки управления доступом Windows, общие метаданные и некоторые метки времени переносятся.

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

• Метки времени: время изменения файла не будет задано. В настоящее время он доступен только для чтения по протоколу REST. Метка времени последнего доступа в файле не будет перемещена, так как это не поддерживаемый атрибут файлов, хранящихся в общей папке Azure.
• Альтернативные потоки данных не могут храниться в общих папках Azure. Файлы, в которых хранятся альтернативные потоки данных, будут скопированы, но альтернативные потоки данных удаляются из файла в процессе.
• Символьные ссылки, жесткие ссылки, соединения и точки повторного анализа пропускаются во время миграции. Журналы копирования миграции перечисляют каждый пропущенный элемент и причину.
• Не удалось скопировать зашифрованные файлы EFS. Журналы копирования показывают, что элемент не удалось скопировать с сообщением "Доступ запрещен".
• Поврежденные файлы пропускаются. Журналы копирования могут выводить различные ошибки для каждого элемента, поврежденного на диске StorSimple: "Сбой запроса из-за неустранимой ошибки оборудования устройства" или "Файл или каталог поврежден или нечитаем" или "Структура списка управления доступом (ACL) недопустима".
• Пропускаются отдельные файлы размером более 4 ТиБ.
• Длина пути к файлу должна быть равна или меньше 2048 символов. Файлы и папки с более длинными путями пропускаются.
• Точки повторного анализа пропускаются. Любые точки дедупликации данных Майкрософт или точки повторного анализа SIS или сторонние пользователи не могут быть разрешены подсистемой миграции и предотвратит миграцию затронутых файлов и папок.

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

Резервные копии томов StorSimple

StorSimple предлагает возможность создания разностных резервных копий на уровне тома. Общие папки Azure также обеспечивают такую возможность под названием "моментальные снимки общей папки".

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

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

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

• Последняя резервная копия.
• Одна резервная копия в месяц в течение 12 месяцев.
• Одна резервная копия в год в течение трех лет.

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

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

Внимание

Выбор более 50 резервных копий томов StorSimple не поддерживается.

Сопоставление существующих томов StorSimple с общими папками Azure

На этом шаге выполняется определение количества необходимых общих папок Azure. Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure.

Тома могут содержать большее количество папок, к которым вы в настоящее время предоставляете локальный доступ как к общим папкам SMB пользователям и приложениям. Самый простой способ изобразить этот сценарий — представить локальную общую папку, которая имеет сопоставление 1:1 с общей папкой Azure. При наличии достаточно небольшого количества общих папок (менее 30) для одного экземпляра Windows Server рекомендуется использовать сопоставление 1:1.

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

Группирование общих папок

Например, если у отдела кадров (HR) 15 общих папок, возможно, стоит хранить все данные HR в одной общей папке Azure. Хранение нескольких локальных общих папок в одной общей папке Azure не мешает создать 15 обычных общих папок SMB на локальном экземпляре Windows Server. Это лишь означает, что корневые папки этих 15 общих папок должны представлять собой вложенные папки в составе общей папки. Затем выполняется синхронизация этой общей папки с общей папкой Azure. Таким образом, для этой группы локальных общих папок требуется только одна общая папка Azure в облаке.

Синхронизация томов

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

Синхронизация корня тома не всегда представляет собой лучшее решение. Синхронизация нескольких расположений имеет свои преимущества. Например, она позволяет сократить количество элементов в одной области синхронизации. Тестирование общих папок Azure и службы синхронизации файлов Azure выполняется при 100 миллионах элементов (файлов и папок) в одной общей папке. Однако рекомендуется использовать не более 20–30 миллионов элементов в одной общей папке. Настройка Синхронизации файлов Azure с меньшим количеством элементов выгодна не только для синхронизации файлов. Уменьшение количества элементов также полезно в перечисленных ниже сценариях.

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

Совет

Если вы не знаете, сколько у вас файлов и папок, воспользуйтесь инструментом TreeSize от JAM Software GmbH.

Структурированный подход к сопоставлению развертывания

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

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

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

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

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

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

• Одна подписка в одном регионе Azure может содержать не более 250 учетных записей хранения.

Совет

При этом в томах зачастую требуется сгруппировать несколько папок верхнего уровня в общий новый корневой каталог. Затем выполняется синхронизация этого нового корневого каталога и всех папок, сгруппированных в него, в одну общую папку Azure. Эта методика позволяет не превышать ограничения по количеству синхронизаций общих папок Azure на одном сервере (не более 30).

Такое группирование в общем корне не влияет на доступ к данным. Списки управления доступом остаются неизменными. Вам потребуется лишь скорректировать все пути к общим папкам (например, к общим папкам SMB или NFS) в локальных папках сервера, которые теперь имеют общий корень. Больше ничего не меняется.

Внимание

Самое важное направление масштабирования для Синхронизации файлов Azure — число элементов (файлов и папок), которые необходимо синхронизировать. Дополнительные сведения см. в статье Целевые показатели масштабируемости службы синхронизации файлов Azure.

В одной области синхронизации рекомендуется использовать небольшое количество элементов. Это важный фактор, который следует учитывать при сопоставлении папок с общими папками Azure. Тестирование службы синхронизации файлов Azure выполняется при 100 миллионах элементов (файлов и папок) в одной общей папке. Однако, как правило, рекомендуется использовать не более 20–30 миллионов элементов в одной общей папке. В случае превышения этих цифр разделите пространство имен на несколько общих папок. Если в общем и целом эти цифры не превышены, вы можете продолжить группирование локальных общих папок в одну и ту же общую папку Azure. Такая методика оставляет пространство для роста.

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

Распространенные сценарии синхронизации файлов и рекомендации

#	Сценарий синхронизации	Поддерживается	Рекомендации (или ограничения)	Решение (или обходное решение)
1	Файловый сервер с несколькими дисками и томами и несколькими общими ресурсами для одной целевой общей папки Azure (консолидация)	No	Целевая файловая папка Azure (конечная точка облака) поддерживает синхронизацию только с одной группой синхронизации. Группа синхронизации поддерживает только одну конечную точку сервера на зарегистрированный сервер.	1. Начните с синхронизации одного диска (корневого тома) для целевого файлового ресурса Azure. Начиная с самого большого диска или тома, требования к хранилищу будут соответствовать локальным требованиям. Настройте распределение по уровням в облаке для распределения всех данных в облако, тем самым освобождая место на диске файлового сервера. Переместите данные из других томов или общих папок в текущий том, который синхронизируется. Продолжайте шаги по одному до тех пор, пока все данные не будут многоуровневы до облака или перенесены. 2) Нацелив один корневой том (диск) за раз. Используйте распределение по уровням облака для распределения всех данных для целевого файлового ресурса Azure. Удалите конечную точку сервера из группы синхронизации, повторно создайте конечную точку со следующим корневым томом или диском, синхронизацией и повторите процесс. Примечание. Может потребоваться повторная установка агента. 3. Рекомендуется использовать несколько целевых общих папок Azure (одну или другую учетную запись хранения на основе требований к производительности).
2	Файловый сервер с одним томом и несколькими общими ресурсами для одной целевой общей папки Azure (консолидация)	Да	Не удается синхронизировать несколько конечных точек сервера на зарегистрированный сервер, синхронизированный с одной целевой общей папкой Azure (аналогично приведенной выше).	Синхронизировать корневой каталог тома, включающего несколько общих папок или папок верхнего уровня. Дополнительные сведения см. в разделе "Общие понятия группирования" и синхронизации томов.
3	Файловый сервер с несколькими общими папками и (или) томами для нескольких общих папок Azure в рамках одной учетной записи хранения (сопоставление общих папок 1:1)	Да	Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure. Учетная запись хранения — это целевой объект масштабирования для производительности. Операции ввода-вывода в секунду и пропускная способность получают общий доступ между общими файловыми ресурсами. Сохраняйте количество элементов для каждой группы синхронизации в пределах 100 миллионов элементов (файлов и папок) на общую папку. В идеале лучше всего остаться ниже 20 или 30 миллионов на акцию.	1) Использование нескольких групп синхронизации (число групп синхронизации = количество общих папок Azure для синхронизации). 2) Синхронизировано только 30 общих папок в этом сценарии одновременно. Если на этом файловом сервере более 30 общих папок, используйте концепцию группирования общих ресурсов и синхронизацию томов, чтобы уменьшить количество корневых или верхних папок в источнике. 3) Использование дополнительных Синхронизация файлов серверов локальной среды и разделения и перемещения данных на эти серверы для обхода ограничений на исходном сервере Windows.
4	Файловый сервер с несколькими общими ресурсами и (или) томами для нескольких общих папок Azure в разных учетных записях хранения (сопоставление общих папок 1:1)	Да	Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure (одной или другой учетной записи хранения). Сохраняйте количество элементов для каждой группы синхронизации в пределах 100 миллионов элементов (файлов и папок) на общую папку. В идеале лучше всего остаться ниже 20 или 30 миллионов на акцию.	Тот же подход, что и выше
5	Несколько файловых серверов с одним (корневым томом или общим ресурсом) для одной целевой общей папки Azure (консолидация)	No	Группа синхронизации не может использовать облачную конечную точку (общую папку Azure), уже настроенную в другой группе синхронизации. Хотя группа синхронизации может иметь конечные точки сервера на разных файловых серверах, файлы не могут отличаться.	Следуйте указаниям в сценарии 1 выше с дополнительным вниманием к тому, чтобы нацелить один файловый сервер одновременно.

Создание таблицы сопоставления

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

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

Скачайте шаблон сопоставления пространства имен.

Количество учетных записей хранения

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

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

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

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

Внимание

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

Параметры учетной записи хранения

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

• Брандмауэр и виртуальные сети: отключен. Не настраивайте ограничения IP-адресов или не ограничивает доступ учетной записи хранения к определенной виртуальной сети. Во время миграции используется общедоступная конечная точка учетной записи хранения. Все IP-адреса виртуальных машин Azure должны быть разрешены. Лучше всего настроить все правила брандмауэра в учетной записи хранения после миграции. Настройте исходные и целевые учетные записи хранения таким образом.
• Частные конечные точки: поддерживается. Вы можете включить частные конечные точки, но общедоступная конечная точка используется для миграции и должна оставаться доступной. Это относится как к исходным, так и к целевым учетным записям хранения.

Сводка по этапу 1

В конце этапа 1:

• У вас есть хороший обзор устройств и томов StorSimple.
• Служба Data Manager готова получить доступ к томам StorSimple в облаке, так как вы получили ключ шифрования данных службы для каждого устройства StorSimple.
• У вас есть план, для которого необходимо перенести тома и резервные копии (при их наличии после последней).
• Вы знаете, как сопоставить тома с соответствующим количеством общих папок Azure и учетных записей хранения.

Этап 2. Развертывание ресурсов миграции и хранилища Azure

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

В этом видео рассматривается развертывание:

• Учетные записи хранения
• Подписки и группы ресурсов
• Учетные записи хранения
• Типы и имена
• Размер производительности и общего ресурса
• Типы расположения и репликации
• общие папки Azure
• Служба диспетчера данных StorSimple

Развертывание учетных записей хранения

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

Внимание

Не настраивайте параметры сети и брандмауэра для учетных записей хранения до или во время миграции. В случае выполнения таких конфигураций на этом этапе миграция станет невозможной. Общедоступная конечная точка должна быть доступна в исходной и целевой учетных записях хранения. Ограничение на определенные диапазоны IP-адресов или виртуальные сети не поддерживается. После завершения миграции можно изменить конфигурации сети учетной записи хранения.

Отток подписок

Вы можете использовать ту же подписку, которую вы использовали для развертывания StorSimple, или использовать другую. Единственное ограничение заключается в том, что подписка должна находиться в том же клиенте Microsoft Entra, что и подписка StorSimple. Перед началом миграции следует переместить подписку StorSimple в соответствующий клиент. Вы можете переместить только всю подписку, так как отдельные ресурсы StorSimple нельзя переместить в другой клиент или подписку.

Группа ресурсов

Группы ресурсов в Azure помогают организации ресурсов и разрешений управления администраторами. Подробнее.

Storage account name

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

Расположение

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

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

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

Вы можете выбрать хранилище класса Premium (SSD) для общих папок Azure или стандартное хранилище. Стандартное хранилище включает несколько уровней для общей папки. Для большинства клиентов, выполняющих миграцию из StorSimple, подходит стандартное хранилище.

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

Репликация

Доступно несколько параметров репликации. Выберите только один из следующих двух вариантов:

• Локально избыточное хранилище (LRS).
• Хранилище, избыточное между зонами (ZRS), которое доступно не во всех регионах Azure.

Примечание.

Геоизбыточное хранилище (GRS) и геозонное избыточное хранилище не поддерживаются.

общие папки Azure

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

Имя
Может содержать строчные буквы, цифры и дефисы.

Квота
Квоту здесь можно сравнить с жесткой квотой SMB в экземпляре Windows Server. Здесь не рекомендуется устанавливать квоту из-за вероятности сбоя во время миграции и работы других служб при достижении квоты.

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

Диспетчер данных StorSimple

Ресурс Azure, содержащий задания миграции, называется диспетчером данных StorSimple. Выберите Новый ресурс и найдите его. Затем выберите Создать.

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

Служба синхронизации файлов Azure

С помощью службы "Синхронизация файлов Azure" можно добавить локальное кэширование чаще всего используемых файлов. Подобно кэшированию в StorSimple, возможность распределения по уровням в облаке в рамках службы синхронизации файлов Azure обеспечивает задержку локального доступа в сочетании с улучшенным контролем доступной емкости кэша в экземпляре Windows Server и синхронизацией нескольких сайтов. Если вы планируете использовать локальный кэш, то в локальной сети необходимо подготовить виртуальную машину Windows Server (физические серверы и отказоустойчивые кластеры также поддерживаются) с достаточной емкостью хранилища с прямым подключением.

Внимание

Пока не настраивайте службу синхронизации файлов Azure. К развертыванию службы "Синхронизация файлов Azure" не следует приступать раньше 4-го этапа миграции.

Сводка по этапу 2

К концу 2-го этапа вы развернете учетные записи хранения и все общие папки Azure в них. У вас также появится ресурс "Диспетчер данных StorSimple". Он понадобится позже на этапе 3 во время настройки заданий миграции.

Этап 3. Создание и выполнение задания миграции

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

В этом видео рассматриваются следующие темы:

• Создание задания миграции
• Итоги
• Исходный код
• Выбор резервных копий томов для миграции
• Назначение
• Сопоставление каталогов
• Семантические правила
• Выполнение задания миграции
• Выполнение определения задания
• Просмотр состояния задания
• Параллельное выполнение заданий
• Интерпретация файлов журнала

Чтобы приступить к работе, перейдите в Диспетчер данных StorSimple, найдите Определения заданий в меню и выберите + Определение задания. По умолчанию выбран правильный тип целевого хранилища: Общая папка Azure.

Имя определения задания
Это имя должно указывать на набор перемещаемых файлов. Рекомендуется дать ему такое же имя, как и у общей папки Azure.

Расположение, в котором выполняется задание
При выборе региона необходимо выбрать тот же регион, в котором размещена учетная запись хранения StorSimple, или, если он недоступен, регион, который находится рядом с ним.

Исходный код

Исходная подписка
Выберите подписку, в которой хранится ресурс "Диспетчер устройств StorSimple".

Ресурс StorSimple
Выберите Диспетчер устройств StorSimple, в котором зарегистрировано ваше устройство.

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

Устройство
Выберите устройство StorSimple, на котором хранится том, куда необходимо выполнить миграцию.

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

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

Назначение

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

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

В посвященном разделе этой статьи рассмотрены все соответствующие сведения.

Выбор резервных копий томов для миграции

Существует ряд важных аспектов, связанных с выбором резервных копий, которые необходимо перенести:

• Задания миграции могут перемещать только резервные копии, а не данные работающего тома. Поэтому последняя резервная копия является ближайшей к динамическим данным и всегда должна быть включена в список резервных копий, перемещаемых при миграции. При открытии диалогового окна выбора резервного копирования он выбирается по умолчанию.
• Убедитесь, что последняя резервная копия актуальна, чтобы обеспечить минимально возможный размер разностного файла в общей папке. Перед созданием задания миграции можно вручную активировать и завершить другую резервную копию тома. Небольшая разница в динамической общей папке улучшает возможности миграции. Если эта разность может быть нулевой, то есть больше изменений в томе StorSimple не произошло после создания последней резервной копии в списке, то вырезка пользователя будет значительно упрощена и ускоряется.
• Резервные копии должны воспроизводиться в общей папке Azure от самой старой до самой новой. Устаревшая резервная копия не может быть "отсортирована в" список резервных копий в общей папке Azure после выполнения задания миграции. Поэтому перед созданием задания необходимо убедиться, что список резервных копий завершен.
• Этот список резервных копий в задании нельзя изменить после создания задания, даже если задание никогда не выполнялось.
• Для выбора резервных копий необходимо, чтобы переносимый том StorSimple был подключен.

Чтобы выбрать резервные копии тома StorSimple для задания миграции, щелкните Выбрать резервные копии томов в форме создания задания.

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

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

Внимание

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

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

Внимание

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

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

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

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

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

Внимание

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

Семантические элементы

Сопоставление выражается слева направо: [\исходный путь] > [\целевой путь].

Семантический символ	Значение
\	Индикатор корневого уровня.
>	Операторы [source] (источник) и [Target-mapping] (сопоставление целевого объекта).
| или RETURN (новая строка)	Разделитель двух инструкций по сопоставлению папок. Кроме того, этот символ можно пропустить и нажать клавишу ВВОД, чтобы получить следующее выражение сопоставления в отдельной строке.

Примеры

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

\User data > \

Перемещает содержимое всего тома по новому пути в целевую общую папку:

\ > \Apps\HR tracker

Перемещает содержимое исходной папки по новому пути в целевую общую папку:

\HR resumes-Backup > \Backups\HR\resumes

Сортирует несколько исходных расположений в новую структуру каталога:

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

Семантические правила

• Всегда указывайте пути к папкам относительно корневого уровня.
• Начинайте каждый путь к папке с индикатора корневого уровня "\".
• Не включайте буквы дисков.
• При указании нескольких путей исходные или целевые пути не могут перекрываться:
  Пример недопустимого перекрытия исходного пути:
  \folder\1 > \folder
  \folder\1\2 > \folder2
  Пример недопустимого перекрытия целевого пути:
  \folder > \
  \folder2 > \
  
• Исходные папки, которые не существуют, игнорируются.
• Создаются структуры папок, которые не существуют в целевом объекте.
• Как и в случае с Windows, имена папок не чувствительны к регистру, но сохраняют его.

Примечание.

Содержимое папки \System Volume Information и $Recycle.Bin на томе StorSimple не будет скопировано в рамках задания миграции.

Выполнение задания миграции

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

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

Изначально задание миграции будет иметь состояние: Never ran (Никогда не запускалось).
Когда вы будете готовы, запустите задание миграции. Выберите изображение для версии с более высоким разрешением.
При успешной миграции резервной копии будет выполнен автоматический моментальный снимок общей папки Azure. Исходная дата резервного копирования резервного копирования StorSimple помещается в раздел "Комментарии" моментального снимка общей папки Azure. Использование этого поля позволяет увидеть, когда данные изначально были резервное копирование по сравнению с временем создания моментального снимка общей папки.

Внимание

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

Ошибки для каждого элемента

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

• Ошибки копирования
  В этом столбце перечислены файлы или папки, которые нужно было скопировать, но это не удалось. Эти ошибки часто можно устранить. Если в резервной копии перечислены проблемы с элементом в этом столбце, просмотрите журналы копирования. Если вам нужно перенести эти файлы, выберите Retry backup (Повторить операцию резервного копирования). Этот параметр становится доступным после завершения обработки резервного копирования. В разделе Управление заданием миграции приведены подробные сведения о доступных вам параметрах.
• Неподдерживаемые файлы
  В этом столбце перечислены файлы или папки, которые нельзя перенести. В службе хранилища Azure действует ряд ограничений на имена файлов, длину путей и типы файлов, которые на данный момент или логически не могут храниться в общей папке Azure. Задание миграции не приостанавливается для этих типов ошибок. При повторном переносе резервной копии результат не изменится. Если в резервной копии перечислены проблемы с элементом в этом столбце, просмотрите журналы копирования сделайте необходимые записи. Если такие проблемы возникают в последней резервной копии, и вы обнаружили в журнале копирования, что сбой был вызван именем файла, длиной пути или другой проблемой, с которой вы повлияли, может потребоваться устранить проблему в томе StorSimple, выполнить резервное копирование тома StorSimple и создать новое задание миграции только с этой резервной копией. Затем вы можете перенести это исправленное пространство имен и стать самой последней или динамической версией общей папки Azure. Этот процесс выполняется вручную и отнимает много времени. Внимательно просмотрите журналы копирования и оцените, стоит ли выполнять его.

Эти журналы представляют собой файлы *.csv с перечнем элементов пространства имен и элементов, которые не удалось скопировать. Ошибки будут разделены на категории, описанные ранее. В расположении файла журнала можно найти журналы файлов со сбоями по словам "Не удалось". Так можно сформировать список журналов для файлов, которые не удалось скопировать. Отсортируйте эти журналы по размеру. Могут быть дополнительные журналы, созданные в размере 17 байт. Они пустые, и их можно пропустить. Путем сортировки можно выделить журналы, содержащие данные.

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

Управление заданием миграции

Задания миграции имеют следующие состояния:

• Никогда не выполнялось
  новое задание, которое было определено, но никогда не выполнялось.
• Ожидание
  задания в этом состоянии ожидает подготовки ресурсов в службе миграции. Когда все будет готово, оно автоматически перейдет в другое состояние.
• 
  Сбой неудачного задания попал в неустранимую ошибку, которая предотвращает обработку дополнительных резервных копий. Задание не должно входить в это состояние. Оптимальным вариантом действий в таком случае является отправка запроса на поддержку.
• Отменено / Отмена
  Можно отменить все задание миграции или отдельные резервные копии в рамках задания. Отмененные резервные копии не будут обработаны, так как отмененное задание миграции перестанет обрабатывать резервные копии. Имейте в виду, что отмена задания займет много времени. Это не помешает вам создать новое задание. Лучший курс действий — позволить заданию полностью прибыть в состояние "Отменено ". Можно либо игнорировать неудачные или отмененные задания, либо удалить их позже. Вам не нужно удалять задания, прежде чем удалять ресурс Диспетчера данных в конце миграции StorSimple.

Выполнение

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

Приостановленное

задание миграции приостановлено при необходимости принятия решения. Это условие включает две кнопки команд в верхней части колонки:
Выберите Retry backup (Повторить операцию резервного копирования), если в резервной копии отображаются файлы, которые нужно было переместить, но они не были перемещены (столбец Ошибка копирования).
Выберите Не архивировать, если резервная копия отсутствует (удалена политикой в результате создания задания миграции) или повреждена. Подробные сведения об ошибках можно найти в колонке, которая открывается, если щелкнуть резервную копию, завершившуюся сбоем.

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

Завершено и Завершено с предупреждениями

Задание миграции указано с состоянием Завершено, если все резервные копии в этом задании успешно обработаны.
Полный с предупреждениями — это состояние, возникающее при следующих случаях :

• Во время резервного копирования возникла устранимая проблема. Это резервное копирование помечается как частично выполнено или сбой.
• Вы решили продолжить приостановленное задание, пропустив операцию резервного копирования с указанными проблемами. (Вы выбрали Не архивировать вместо Retry backup (Повторить операцию резервного копирования))

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

Параллельное выполнение заданий

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

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

• Одновременно можно выполнить только одно задание миграции с одним и тем же исходным томом StorSimple.
• Одновременно можно выполнить только одно задание миграции с одной и той же целевой общей папкой Azure.
• Перед началом следующего задания убедитесь, что все предыдущие задания находятся в copy stage состоянии и отображают ход перемещения файлов по крайней мере на 30 минут.
• Вы можете выполнять до четырех заданий миграции параллельно на диспетчер устройств StorSimple, если вы соблюдаете предыдущие правила.

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

Совет

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

Сводка по этапу 3

К концу третьего этапа вы выполнили по крайней мере одно из заданий миграции с томов StorSimple в общие папки Azure. После выполнения будут перенесены указанные резервные копии в моментальные снимки общей папки Azure. Теперь вы можете сосредоточиться на настройке Синхронизации файлов Azure для общей папки (по завершении заданий миграции для нее) или на управлении общим доступом для информационных работников и приложений к общей папке Azure.

Этап 4. Доступ к общим папкам Azure

Существует две основные стратегии доступа к общим папкам Azure:

• Синхронизация файлов Azure: развертывание синхронизации файлов Azure на локальном экземпляре Windows Server. Синхронизация файлов Azure обладает всеми преимуществами локального кэша, как и StorSimple.
• Прямой общий доступ: развертывание прямого доступа к общей папке. Используйте эту стратегию, если ваш сценарий доступа для определенного файлового ресурса Azure не будет использовать локальную кэширование или если у вас больше нет возможности разместить локальный экземпляр Windows Server. В этом случае пользователи и приложения и дальше будут получать доступ к общим папкам SMB по протоколу SMB. Эти общие папки теперь размещены не на локальном сервере, а непосредственно в облаке.

Вы уже должны были выбрать наиболее подходящий вариант на этапе 1 этого руководства.

Далее в этом разделе приведены инструкции по развертыванию.

В этом видео рассматриваются следующие темы:

• Подходы к доступу к общим папкам Azure
• Служба синхронизации файлов Azure
• Direct-share-access
• Развертывание службы синхронизации файлов Azure (предварительная версия)
• Развертывание облачного ресурса службы синхронизации файлов Azure
• Развертывание локального экземпляра Windows Server
• Подготовка экземпляра Windows Server для Синхронизация файлов Azure
• Настройка Синхронизация файлов Azure в экземпляре Windows Server
• Мониторинг начальной синхронизации
• Тестирование Синхронизация файлов Azure
• Создание общих папок SMB

Как развернуть службу синхронизации файлов Azure (предварительная версия)

Пора развернуть часть службы "Синхронизация файлов Azure".

1. Создайте облачный ресурс службы "Синхронизация файлов Azure".
2. Разверните агент службы "Синхронизация файлов Azure" на локальном сервере.
3. Зарегистрируйте сервер в облачном ресурсе.

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

Развертывание облачного ресурса службы синхронизации файлов Azure

На этом шаге вам понадобятся учетные данные подписки Azure.

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

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

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

Совет

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

Развертывание локального экземпляра Windows Server

• Создайте Windows Server 2019 (как минимум 2012 R2) как виртуальную машину или физический сервер. Отказоустойчивый кластер Windows Server также поддерживается. Не используйте повторно сервер, внешний по отношению к StorSimple 8100 или 8600.
• Подготовьте к работе или добавьте хранилище, подключенное напрямую. Запоминающее устройство, подключаемое к сети, не поддерживается.

Рекомендуется присвоить новому экземпляру Windows Server значение, не меньшее объема хранилища, которое локально доступно для кэширования на устройстве StorSimple 8100 или 8600. Экземпляр Windows Server используется точно так же, как и устройство StorSimple. При наличии такого же объема хранилища, что и на устройстве, процесс кэширования должен быть похожим, а то и аналогичным. По желанию вы можете добавить или удалить хранилище из экземпляра Windows Server. Эта возможность позволяет масштабировать размер локального тома и объем локального хранилища, доступного для кэширования.

Подготовка экземпляра Windows Server к синхронизации файлов

В этом разделе вам предстоит установить агент Синхронизации файлов Azure на экземпляре Windows Server.

Руководство по развертыванию объясняет необходимость отключения конфигурации усиленной безопасности Internet Explorer. Эта мера безопасности неприменима к Синхронизации файлов Azure. Ее отключение позволяет выполнять проверку подлинности в Azure без каких бы то ни было проблем.

Откройте средство PowerShell. Установите необходимые модули PowerShell с помощью следующих команд. При появлении соответствующего запроса обязательно установите полный модуль и поставщик NuGet.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

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

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

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

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

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

Используйте последнюю версию агента. Его можно скачать в Центре загрузки Майкрософт: Агент Синхронизации файлов Azure.

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

Настройка службы синхронизации файлов Azure на экземпляре Windows Server

Зарегистрированный локальный экземпляр Windows Server должен быть готов к работе и подключен к Интернету для этого процесса.

Внимание

Прежде чем продолжать, необходимо завершить миграцию файлов и папок StorSimple в общую папку Azure. Убедитесь, что в общую папку не вносились изменения.

На этом этапе выполняется связывание всех ресурсов и папок, настроенных на экземпляре Windows Server в ходе выполнения предыдущих этапов.

1. Войдите на портал Azure.
2. Найдите ресурс службы синхронизации хранилища.
3. Создайте новую группу синхронизации в ресурсе службы синхронизации хранилища для каждой общей папки Azure. В терминологии Синхронизации файлов Azure общая папка Azure станет облачной конечной точкой в топологии синхронизации, которую вы описываете при создании группы синхронизации. При создании группы синхронизации присвойте ей знакомое имя, чтобы определить, какой набор файлов будет здесь синхронизироваться. Убедитесь, что вы ссылаетесь на общую папку Azure с таким же именем.
4. После создания группы синхронизации в списке групп синхронизации появится строка для нее. Выберите имя (ссылку), чтобы показать содержимое группы синхронизации. Общая папка Azure появится в разделе Облачные конечные точки.
5. Найдите кнопку Добавить конечную точку сервера. Подготовленная вами папка на локальном сервере станет путем для этой конечной точки сервера.

Внимание

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

Развертывание прямого доступа к общей папке

В этом видео показано, как безопасно предоставлять общие папки Azure непосредственно информационным работникам и приложениям за пять простых шагов.
Видео ссылается на выделенную документацию по следующим темам. Обратите внимание, что Azure Active Directory теперь является идентификатором Microsoft Entra. Дополнительные сведения см. в статье "Новое имя" для Azure AD.

• Общие сведения об удостоверениях Azure Stack
• Как присоединить учетную запись хранения к домену
• Общие сведения о сетевых возможностях для общих папок Azure
• Настройка общедоступных и частных конечных точек
• Настройка S2S VPN
• Настройка P2S VPN для Windows
• Настройка P2S VPN для Linux
• Настройка переадресации DNS
• Настройка DFS-N

Сводка по этапу 4

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

Этап 5. Прямая миграция пользователя

На этом этапе вы завершите миграцию:

• Планирование простоев.
• Синхронизация любых изменений, внесенных пользователями и приложениями на стороне StorSimple во время выполнения заданий миграции на этапе 3.
• Выполнение обработки отказов пользователей на новом экземпляре Windows Server с помощью службы "Синхронизация файлов Azure" или общих папок Azure через прямой доступ к общим папкам.

В этом видео рассматриваются следующие темы:

• Действия, которые необходимо выполнить перед сокращением рабочей нагрузки
• Выполнение вырезания
• Этапы после перереза

Планирование простоев

Этот подход к миграции требует определенного времени простоя для пользователей и приложений. Цель — сократить простои до минимума. Обратите внимание на такие рекомендации:

• Обеспечьте доступ к томам StorSimple во время выполнения заданий миграции.
• По завершении заданий миграции данных для общей папки можно закрыть доступ пользователей (по крайней мере, доступ для записи) к томам или общим папкам StorSimple. Окончательная команда RoboCopy выполнит синхронизацию общей папки Azure. Затем вы можете выполнить прямую миграцию пользователей. Место выполнения команды RoboCopy зависит от того, выбрано ли использование службы "Синхронизация файлов Azure" или прямой доступ к общей папке. В предстоящем разделе рассматривается эта тема.
• По завершении синхронизации командой RoboCopy вы сможете предоставить пользователям доступ к новому расположению непосредственно в общей папке Azure или в общей папке SMB на экземпляре Windows Server с помощью службы "Синхронизация файлов Azure". Зачастую развертывание DFS-N поможет быстро и эффективно выполнить прямую миграцию. Это обеспечит согласованность существующих общих адресов и перенаправление в новое расположение, в котором содержатся перенесенные файлы и папки.

Для архивных данных это полностью жизнеспособный подход для простоя тома StorSimple (или вложенной папки), создания еще одного резервного копирования томов StorSimple, миграции, а затем открытия назначения миграции для доступа пользователей и приложений. Это поможет вам сэкономить на догоняющем RoboCopy. Однако цена такого подхода — продолжительное окно простоя, которое может длиться несколько дней или дольше в зависимости от количества файлов и резервных копий, которые необходимо перенести. Скорее всего, этот вариант подходит только для архивных рабочих нагрузок, которые могут обойтись без доступа к записи продолжительное время.

Определение полной синхронизации пространства имен с сервером

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

Портал Azure

Вы можете узнать, когда пространство имен полностью перенесено, с помощью портала Azure.

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

Теперь можно выполнить локальную команду RoboCopy.

Средство просмотра событий Windows Server

Чтобы определить, когда пространство имен полностью перенесено, можно также использовать средство просмотра событий на экземпляре Windows Server.

1. Откройте средство Просмотр событий и перейдите в раздел Приложения и службы.
2. Перейдите по пути Microsoft\FileSync\Agent\Telemetry.
3. Найдите последнее событие 9102, соответствующее завершенному сеансу синхронизации.
4. Выберите Сведения и найдите событие, в котором для значения SyncDirection указано Загрузка.
5. По завершении загрузки пространства имен в списке будет существовать одно событие, в котором для значения Сценарий указано FullGhostedSync, а значение HResult = 0.
6. Если этого события нет, можно также найти другие события 9102, в которых значение SyncDirection = Загрузка, а значение Сценарий = "RegularSync". Если вы нашли одно из этих событий, это также указывает, что загрузка пространства имен завершена, а синхронизация перешла на этап обычных сеансов синхронизации, независимо от того, существуют данные для синхронизации на текущий момент или нет.

Окончательная команда RoboCopy

На этом этапе существуют различия между локальным экземпляром Windows Server и устройством StorSimple 8100 или 8600.

1. Необходимо синхронизировать изменения, которые пользователи или приложения создавали на стороне StorSimple, пока выполнялась миграция.
2. В некоторых случаях используется служба "Синхронизация файлов Azure". Кэш устройства StorSimple заполнен, в отличии от экземпляра Windows Server, на котором есть только пространство имен, в котором на данный момент локально не хранится содержимое файлов. Окончательная команда RoboCopy поможет быстро перенести локальный кэш службы "Синхронизация файлов Azure" за счет вытягивания всего доступного локально кэшированного содержимого файла и разместить его на сервере синхронизации файлов Azure.
3. Некоторые файлы могли быть пропущены при выполнении заданий миграции из-за недопустимых символов. Если это так, скопируйте их на экземпляр Windows Server с поддержкой службы "Синхронизация файлов Azure". Позже их можно настроить таким образом, чтобы они могли синхронизироваться. Если для определенной общей папки не используется Синхронизация файлов Azure, лучше переименовать файлы с недопустимыми символами в томе StorSimple. Затем выполните команду RoboCopy непосредственно в общей папке Azure.

Предупреждение

Robocopy в Windows Server 2019 столкнулась с проблемой, которая приводила к тому, что файлы, многоуровневые по Синхронизация файлов Azure на целевом сервере, будут повторно загружены из источника и повторно отправлены в Azure при использовании /MIR функции. Рекомендуется запустить Robocopy на сервере Windows Server, отличном от 2019 года, например Windows Server 2016.

Предупреждение

Не выполняйте команду RoboCopy, до того как пространство имен для общей папки Azure полностью загрузится на сервер. Дополнительные сведения см. в разделе Определение полной синхронизации пространства имен с сервером.

Вам нужно скопировать только те файлы, которые были изменены после последнего запуска задания миграции, и файлы, еще не перемещенные в рамках таких заданий. По завершении миграции вы можете решить проблему, из-за которой они не были перемещены на сервер. Дополнительные сведения см. в статье Устранение неполадок службы "Синхронизация файлов Azure".

Команда RoboCopy имеет несколько параметров. В примере ниже показана законченная команда и список причин для выбора этих параметров.

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName> 

Коммутатор	Значение
/MT:n	Разрешает выполнение Robocopy в многопоточном режиме. По умолчанию параметр n имеет значение 8. Максимум — 128 потоков. Хотя большое количество потоков помогает повысить доступную пропускную способность, это не означает, что ваша миграция всегда будет выполняться быстрее. Тесты с Файлами Azure демонстрируют, что использование диапазона от 8 до 20 потоков обеспечивает сбалансированную производительность для выполнения исходного копирования. На последующие запуски /MIR влияют доступные вычислительные ресурсы и доступная полоса пропускания. Для последующих запусков указываемое количество потоков нужно привести в соответствие с числом ядер процессора и количеством потоков, приходящихся на каждое ядро. Определите, нужно ли зарезервировать ядра для других задач рабочего сервера. Тесты с Файлы Azure показали, что до 64 потоков дают хорошую производительность, но только если процессоры могут поддерживать их в то же время.
/R:n	Максимальное число повторных попыток для файла, который не удалось скопировать с первого раза. Robocopy повторит попытку определенное количество раз (n), после чего объявит невозможность скопировать этот файл во время этого выполнения. Вы можете оптимизировать производительность выполнения: выберите значение "2" или "3", если вы считаете, что проблемы с истечением времени ожидания вызывали сбои в прошлом. Это может быть типичной проблемой для связи по каналам WAN. Выберите вариант "Без повторных попыток" или значение "1", если вы считаете, что файл не удалось скопировать, так как он активно использовался. Повторная попытка через несколько секунд не всегда позволяет дождаться изменения состояния использования для файла. Возможно, пользователям или приложениям, которые удерживают этот файл открытым, потребуется больше времени. Если вы просто зафиксируете, что файл не был скопирован, и вернетесь к нему в одном из следующих запланированных запусков Robocopy, это может позволить успешно его скопировать. В этом случае текущее выполнение завершится быстрее, без затрат времени на повторные попытки, которые все равно в большинстве случаев завершаются сбоем копирования из-за того, что файлы остаются открытыми по истечении времени ожидания повторных попыток.
/W:n	Указывает время ожидания Robocopy перед попыткой копирования файла, который не был успешно скопирован во время предыдущей попытки. n — это количество секунд ожидания между повторными попытками. /W:n часто используется вместе с /R:n.
/B	Выполняет команду Robocopy в том же режиме, что и приложение резервного копирования. Этот параметр позволяет Robocopy перемещать файлы, для которых у текущего пользователя нет разрешений. Параметр резервного копирования зависит от выполнения команды Robocopy в консоли с повышенными привилегиями администратора или в окне PowerShell. Если вы используете Robocopy с Файлами Azure, убедитесь, что вы подключаете общую папку Azure с помощью ключа доступа к учетной записи хранения, а не удостоверения домена. В противном случае сообщения об ошибках могут не позволить найти очевидное решение проблемы.
/MIR	(Зеркалирование источника в целевом объекте.) Позволяет Robocopy скопировать только изменения между исходным и целевым объектом. Будут скопированы пустые подкаталоги. Элементы (файлы или папки), которые были изменены или не существуют в целевой папке, будут скопированы. Элементы, которые существуют в назначении, но не в источнике, будут удалены из целевого объекта. При использовании этого параметра структуры исходной и целевой папок должны соответствовать друг другу. Соответствие означает, что вы выполняете копирование с правильного уровня источника и папки на соответствующий уровень папки в целевом объекте. Только тогда зеркальное копирование будет успешным. Если объекты источника и назначения не совпадают, использование /MIR приведет к увеличению числа операций удаления и повторного копирования.
/IT	Обеспечивает сохранение точности данных в определенных зеркальных сценариях. Например, если в файле происходит изменение ACL и между двумя выполнениями Robocopy обновляется атрибут, он помечается как скрытый. Без параметра /IT команда Robocopy может упустить изменение ACL и не передать его в целевое расположение.
/COPY:[copyflags]	Точность копирования файла. По умолчанию: /COPY:DAT. Флаги копирования: D = данные, A = атрибуты, T = метки времени, S = безопасность = NTFS ACL, O = информация о владельце, U = данные аудита. Данные аудита не могут храниться в общей папке Azure.
/DCOPY:[copyflags]	Точность для копии каталогов. По умолчанию: /DCOPY:DA. Флаги копирования: D = данные, A = атрибуты, T = метки времени.
/NP	Указывает, что ход копирования каждого файла и папки не отображается. Отображение хода выполнения значительно снижает производительность копирования.
/NFL	Указывает, что имена файлов не регистрируются. Улучшается производительность копирования.
/NDL	Указывает, что имена каталогов не регистрируются. Улучшается производительность копирования.
/XD	Указывает исключаемые каталоги. При выполнении Robocopy в корне тома рассмотрите возможность исключения скрытой папки System Volume Information. Если она используется по назначению, вся информация в ней относится к конкретному тому в этой конкретной системе и может быть легко восстановлена ​​по требованию. Копирование этой информации не принесет никакой пользы ни в облаке, ни при последующем копировании обратно на другой том Windows. Отказ от хранения этого содержимого не должен считаться потерей данных.
/UNILOG:<file name>	Записывает состояние в файл журнала в формате Юникод. (Перезаписывает существующий журнал.)
/L	Только для тестового запуска файлы должны быть перечислены только. Они не копируются, не удаляются, и в них не добавляются мети времени. Зачастую используется вместе с /TEE для вывода консоли. Флаги из примера скрипта (такие как /NP, /NFL и /NDL) потребуется удалить, чтобы добиться обеспечить надлежащее документирование результатов теста.
/LFSM	Только для целевых объектов с многоуровневым хранилищем. Не поддерживается, если назначение является удаленной общей папкой SMB. Указывает, что Robocopy работает в "режиме низкого свободного пространства". Этот параметр полезен только для целевых объектов с многоуровневыми хранилищами, которые могут выйти из локальной емкости до завершения Robocopy. Он был добавлен специально для использования с целевым объектом, для которого установлено распределение по уровням в облаке в Синхронизации файлов Azure. Его можно использовать независимо от Синхронизации файлов Azure. В этом режиме средство Robocopy будет приостановлено всякий раз, когда копирование файла приведет к тому, что свободное место на целевом томе опустится ниже предельного значения. Это значение может быть задано в форме /LFSM:n флага. Параметр n указывается в системе отсчета с базой 2: nKB, nMB или nGB. Если параметр /LFSM указан без явного значения floor, для него устанавливается значение 10 процентов от размера целевого тома. Режим нехватки свободного места несовместим с /MT, /EFSRAW или /ZB. Поддержка /B была добавлена в Windows Server 2022. Дополнительные сведения о связанных ошибках и обходных решениях см. в разделе о Windows Server 2022 и RoboCopy LFSM ниже.
/Z	Используйте осторожно копирует файлы в режиме перезапуска. Этот параметр рекомендуется использовать только в нестабильной сетевой среде. Он значительно сокращает производительность копирования из-за дополнительных записей в журнал.
/ZB	Используйте осторожный режим перезапуска. Если доступ запрещен, то для этого параметра используется режим резервного копирования. Этот параметр значительно сокращает производительность копирования из-за дополнительных контрольных точек.

Внимание

Мы рекомендуем использовать Windows Server 2022. При использовании Windows Server 2019 убедитесь, что установлено последнее исправление или хотя бы обновление ОС KB5005103. Оно содержит важные исправления для определенных сценариев Robocopy.

При настройке исходного и целевого расположений для команды RoboCopy просмотрите структуру источника и целевого объекта, чтобы убедиться, что они совпадают. Если вы использовали возможность сопоставление каталогов в задании миграции, структура корневого каталога может отличаться от структуры тома StorSimple. В этом случае может потребоваться несколько заданий команды RoboCopy, по одному для каждого подкаталога. Если вы не уверены в выполнении команды должным образом, можно использовать параметр /L, который будет имитировать команду, не внося никаких изменений.

Эта команда RoboCopy используется /MIR, поэтому она не будет перемещать файлы, которые одинаковы (многоуровневые файлы, например). Но если вы получите неправильный исходный и целевой путь, /MIR также очищает структуры каталогов в экземпляре Windows Server или общей папке Azure, которые отсутствуют в пути к источнику StorSimple. Они должны точно совпадать, чтобы задание команды RoboCopy достигло предполагаемой цели обновления перенесенного содержимого с учетом последних изменений, внесенных во время миграции.

Просмотрите файл журнала команды RoboCopy, чтобы узнать, пропущены ли файлы. При наличии проблем исправьте их и повторно выполните команду RoboCopy. Не отзывайте никакие ресурсы StorSimple, прежде чем устраните нерешенные проблемы с интересующими вас файлами и папками.

Если вы не используете службу "Синхронизация файлов Azure" для кэширования определенной общей папки Azure, а вместо этого решили предоставить прямой доступ к общей папке:

1. Подключите общую папку Azure как сетевой диск к локальному компьютеру Windows.
2. Выполните команду RoboCopy между устройством StorSimple и подключенной общей папкой Azure. Если файлы не копируются, исправьте их имена на стороне StorSimple, удалив недопустимые символы. Затем повторно запустите команду RoboCopy. Ранее указанную команду RoboCopy можно выполнять несколько раз, не вызывая ненужного отзыва в StorSimple.

Устранение неполадок и оптимизация

Скорость и частота успешных запусков RoboCopy будут зависеть от нескольких факторов:

• число операций ввода-вывода в исходном и целевом хранилищах;
• доступная пропускная способность сети между источником и назначением;
• возможность быстрой обработки файлов и папок в пространстве имен;
• число изменений между запусками средства Robocopy.
• размер и количество файлов, которые необходимо скопировать.

Рекомендации по числу операций ввода-вывода в секунду и пропускной способности сети

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

Внимание

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

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

• Подумайте, когда в вашей среде лучше выполнять миграцию: в течение дня, в нерабочее время или в выходные дни.
• Также рассмотрите возможность того, что качество обслуживания сети на сервере Windows Server может ограничить скорость копирования.
• Избегайте ненужной работы для средств миграции.

Средство RoboCopy дает возможность вставлять задержки между пакетами, указывая параметр /IPG:n, где n измеряется в миллисекундах между пакетами RoboCopy. Использование этого параметра позволяет избежать монополизации ресурсов на устройствах с ограниченным доступом к данным и перегруженных сетевых соединений.

/IPG:n не может использоваться для точного регулирования пропускной способности сети вплоть до определенных значений в Мбит/с. Используйте вместо этого качество обслуживания сети Windows Server. Средство RoboCopy полностью полагается на протокол SMB для всех сетевых нужд. Использование SMB — это причина, по которой средство RoboCopy не может влиять на пропускную способность сети, но может замедлить ее использование.

Аналогичная логика справедлива для операций ввода-вывода, наблюдаемых на NAS. Размер кластера на томе NAS, размеры пакетов и ряд других факторов влияют на наблюдаемые значения числа операций ввода-вывода в секунду. Появление задержки между пакетами часто является самым простым способом управления нагрузкой на NAS. Протестируйте несколько значений, например от 20 миллисекунд (n = 20) до кратных этому числу. После создания задержки можно оценить, могут ли другие приложения работать должным образом. Эта стратегия оптимизации позволит вам найти оптимальную скорость работы RoboCopy в вашей среде.

Скорость обработки

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

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

Причиной этой разницы является вычислительная мощность, необходимая для прохода по пространству имен. Средство RoboCopy поддерживает многопоточные копии с помощью параметра /MT:n, где n означает количество используемых потоков. Поэтому при подготовке компьютера специально для RoboCopy рассмотрите количество ядер процессора и количество потоков, которое они предоставляют. Наиболее распространенный вариант — два потока на ядро. Число ядер и потоков компьютера — важная точка данных, позволяющая решить, какое значение n в /MT:n следует указать. Также определите, сколько заданий RoboCopy планируется выполнять параллельно на определенном компьютере.

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

Во время первого сеанса работы RoboCopy с пустым целевым объектом или при выполнении задания по определению отличий с большим количеством измененных файлов возможно ограничение производительности из-за пропускной способности сети. Для первоначального запуска рекомендуется использовать большое количество потоков. Большое количество потоков, даже превышающее количество потоков, доступных в текущий момент времени на компьютере, позволяет получить максимальный уровень доступной пропускной способности сети. На последующих запусках с параметром /MIR постепенно отражается влияние обрабатываемых элементов. Меньшее количество изменений при выполнении задания по определению отличий означает уменьшение объема транспорта данных по сети. Теперь скорость больше зависит от способности обрабатывать элементы пространства имен, чем от перемещения их по сетевому каналу. Для последующих запусков указываемое число потоков нужно привести в соответствие с числом ядер процессора и числом потоков, приходящихся на каждое ядро. Определите, нужно ли зарезервировать ядра для других задач, которые может иметь рабочий сервер.

Совет

Главное правило: первый запуск RoboCopy, при котором перемещается большой объем данных из сети с более высокой задержкой, рекомендуется подготовить избыточное количество потоков (/MT:n). При последующих запусках копируется меньше различий, и, скорее всего, будет выполняться переход от ограничений пропускной способности к ограничению вычислений. В этих обстоятельствах часто лучше сопоставить количество потоков RoboCopy с фактически доступными потоками на компьютере. Избыточная подготовка в этом сценарии может привести к увеличению количества сдвигов контекста в процессоре, что, в свою очередь, может снизить скорость копирования.

Устранение лишней работы

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

• Возросшее время выполнения задания RoboCopy, так как каждый файл и папка, затрагиваемые изменением ACL, нуждаются в обновлении
• При повторном использовании данных, перемещенных ранее, может потребоваться повторное копирование. Например, придется заново копировать данные при изменении структуры папок после того, как файлы из них уже были скопированы. Задание RoboCopy не может, подобно проигрывателю, "воспроизводить" изменения в пространстве имен. Следующее задание должно очистить файлы, которые ранее были перенесены в старую структуру папок, и снова передать файлы в новую структуру папок.

Другим важным аспектом является эффективное использование средства RoboCopy. С помощью рекомендуемого скрипта RoboCopy вы создадите и сохраните файл журнала для ошибок. Возможно, возникновение ошибок копирования — это нормально. Ввиду этих ошибок часто необходимо выполнение нескольких циклов копирования для средства вроде RoboCopy. Начальное выполнение, скажем, из NAS в DataBox или от сервера к общему файловому ресурсу Azure. И один или несколько дополнительных запусков с параметром /MIR для перехвата и повторного копирования файлов, которые не были скопированы.

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

• /R:n n = периодичность повторного копирования невыполненного файла и
• /W:n n = интервал в секундах между повторными попытками

/R:5 /W:5 является разумным параметром, который можно изменить в соответствии с ситуацией. В этом примере копирование неудачного файла будет повторяться пять раз, с интервалом в 5 секунд между повторными попытками. Если не удается скопировать файл в этом запуске, в следующем RoboCopy повторит попытку. Часто файлы не удается скопировать из-за того, что они использовались или из-за ошибок времени ожидания, но они могут быть успешно скопированы с помощью этого подхода.

Windows Server 2022 и RoboCopy LFSM

Параметр /LFSM RoboCopy можно использовать, чтобы избежать сбоя задания RoboCopy с ошибкой заполнения тома. RoboCopy будет приостанавливаться всякий раз, когда копирование файла будет приводить к уменьшению свободного пространства на целевом томе ниже минимального значения.

Используйте RoboCopy с Windows Server 2022. Только эта версия RoboCopy содержит важные исправления ошибок и возможности, которые делают параметр совместимым с дополнительными флагами, требуемыми для большинства миграций. Например, совместимость с флагом /B.

/B запускает RoboCopy в том же режиме, что и приложение резервного копирования. Этот параметр позволяет RoboCopy перемещать файлы, для которых у текущего пользователя нет разрешений.

Как правило, RoboCopy можно запустить на исходном, целевом или стороннем компьютере.

Внимание

Если вы планируете использовать /LFSM, убедитесь, что RoboCopy работает на целевом сервере Синхронизации файлов Azure с Windows Server 2022.

Обратите внимание, что при работе с /LFSM также необходимо использовать локальный путь для назначения, а не UNC-путь. Например, в качестве пути назначения следует использовать E:\Foldername, а не UNC-путь, например \\ServerName\FolderName.

Внимание

Текущая доступная версия RoboCopy в Windows Server 2022 содержит ошибку, которая приводит к приостановке подсчета количества ошибок на файл. Используйте следующее обходное решение.

Рекомендуемые флаги /R:2 /W:1 увеличивают вероятность сбоя файла из-за вызываемой приостановки /LFSM. В этом примере использование файла, который не был скопирован после трех приостановок из-за приостановки /LFSM, ошибочно приведет к тому, что RoboCopy не обработает этот файл. Обходным решением является использование более высоких значений для /R:n и /W:n. Хорошим примером является /R:10 /W:1800 (10 повторных попыток по 30 минут каждая). В этом случае у алгоритма распределения по уровням для Синхронизации файлов Azure будет достаточно времени на создание пространства на целевом томе.

Эта ошибка была исправлена, но исправление пока недоступно. Просмотрите приведенные в этом абзаце обновления, связанные с доступностью исправления, и способы развертывания.

Прямая миграция пользователей

Если вы используете службу "Синхронизация файлов Azure", скорее всего, потребуется создать общие папки SMB на этом экземпляре Windows Server с поддержкой службы "Синхронизация файлов Azure", которые соответствуют общим папкам на томах StorSimple. Чтобы не терять времени, вы можете выполнить фронтальную загрузку на этом этапе заранее. Но необходимо убедиться, что до этого момента никто не имел доступа для внесения изменений на экземпляре Windows Server.

При наличии развертывания DFS-N можно указать пространства имен DFN для новых расположений папок сервера. Если у вас нет развертывания DFS-N и устройство 8100 или 8600 подключено локально с помощью экземпляра Windows Server, этот сервер можно отключить от домена. Затем присоедините к домену новый экземпляр Windows Server с поддержкой службы «Синхронизация файлов Azure». Во время этого процесса присвойте серверу то же имя сервера и имена общих папок, как и на старом сервере, чтобы прямая миграция оставалась прозрачной для пользователей, групповых политик и сценариев.

Узнайте больше о DFS-N.

Этап 6. Отзыв

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

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

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

1. Отзовите ресурс Диспетчера данных StorSimple с помощью портала Azure. Вместе с ним будут удалены все задания служб DTS. Получить журналы копирования будет не так легко. Если они важны для ваших записей, извлеките их перед отзывом.
2. Убедитесь, что физические устройства StorSimple перенесены, а затем отмените их регистрацию. Если вы не уверены, что они перенесены, не продолжайте. Отозвав эти ресурсы, пока они все еще нужны, вы не сможете восстановить данные или их конфигурацию.
   При необходимости можно сначала отозвать ресурс тома StorSimple, в результате чего будут очищены данные на устройстве. Этот процесс может занять несколько дней и не потребует экспертного обнуления данных на устройстве. Если это важно, выполните обнуление диска отдельно от отзыва ресурса и в соответствии с вашими политиками.
3. Если в Диспетчере устройств StorSimple не осталось зарегистрированных устройств, можно приступить к удалению самого ресурса Диспетчера устройств.
4. Теперь пора удалить учетную запись хранения StorSimple в Azure. Опять же, остановитесь и убедитесь, что миграция завершена и никто и ничто не зависит от этих данных, прежде чем продолжать.
5. Отсоедините физическое устройство StorSimple от центра обработки данных.
6. Если вы владеете устройством StorSimple, вы можете отправить его на переработку. Если устройство арендовано, проинформируйте арендодателя и верните устройство должным образом.

Миграция завершена.

---

Примечание.

У вас по-прежнему есть вопросы или возникли проблемы?
Мы здесь, чтобы помочь:

Устранение неполадок

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

Ошибки уровне задания

Этап	Ошибка	Сведения о проблеме и устранение рисков
Azure Backup	Не удалось найти резервную копию для указанных параметров	Резервная копия, выбранная для выполнения задания, не найдена во время оценки или копирования. Убедитесь, что резервная копия по-прежнему присутствует в каталоге резервных копий StorSimple. Иногда политики автоматического хранения резервных копий удаляют резервные копии между их выбором для миграции и фактическим выполнением задания миграции для этой резервной копии. Перед началом миграции рекомендуем отключить расписания хранения резервных копий.
Оценка Настройка вычислений	Сбой установки ключей шифрования	Неправильный ключ шифрования данных службы. Дополнительные сведения, которые помогут получить правильный ключ, см. в разделе о ключе шифрования в этой статье.
	Ошибка пакетной службы	Возможно, что при запуске всей внутренней инфраструктуры, необходимой для выполнения миграции, возникла проблема. В этом процессе участвуют несколько других служб. Эти проблемы обычно устраняются при попытке повторного выполнения задания.
	В StorSimple Manager произошла внутренняя ошибка. Подождите несколько минут и повторите попытку. Если проблема будет повторяться, обратитесь в службу поддержки Майкрософт. (Код ошибки: 1074161829)	Эта общая ошибка имеет несколько причин, но одна из возможных причин заключается в том, что диспетчер устройств StorSimple достиг ограничения в 50 устройств. Проверьте, начала ли эта ошибка возникать в последних заданиях в диспетчере устройств — это может указывать на проблему с ограничением. Для устранения этой проблемы нужно удалить все автономные устройства StorSimple 8001, созданные и используемые службой Data Manager. Вы можете отправить запрос в службу поддержки или удалить их вручную на портале. Удаляйте только автономные устройства серии 8001.
Оценка файлов	Сбой задания клонирования тома	Эта ошибка, скорее всего, указывает на то, что вы указали резервную копию, которая была каким-то образом повреждена. Служба миграции не может подключить или прочитать ее. Вы можете попробовать выполнить резервное копирование вручную или отправить запрос в службу поддержки.
	Не удалось продолжить, так как том находится в формате, отличном от NTFS	Служба миграции может использовать только тома NTFS без поддержки дедупликации. Если у вас есть том в другом формате, например ReFS или в стороннем формате, служба миграции не сможет перенести этот том. См. раздел Известные ограничения.
	Обратитесь в службу поддержки. На диске не найден подходящий раздел	Диск StorSimple, на котором должен быть том, указанный для миграции, не имеет раздела для указанного тома. Это необычная ситуация. Она может указывать на повреждение или ошибку управления. Единственный вариант для дальнейшего изучения этой проблемы — отправить запрос в службу поддержки.
	Истекло время ожидания	Сбой этапа оценки из-за превышения времени ожидания обычно вызван проблемой с устройством StorSimple или медленным выполнением резервного копирования исходного тома, а иногда даже его повреждением. Если повторное выполнение резервного копирования не работает, отправьте запрос в службу поддержки — это лучший вариант.
	Не удалось найти <путь> к файлу Не удалось найти часть пути	Определение задания позволяет указать исходный вложенный путь. Эта ошибка отображается, если этот путь не существует. Например: \Share1 \Share1 > \Share\Share1 В этом примере вы указали \Share1 в качестве подпуть в источнике, сопоставляя другой вложенный путь в целевом объекте. Однако исходный путь не существует (возможно, опечатка?). Примечание. Windows сохраняет регистр, но не учитывает его. Это означает, что \Share1 и \share1 эквивалентны. Кроме того: целевые пути, которые не существуют, будут созданы автоматически.
	Этот запрос не авторизован для выполнения этой операции	Эта ошибка показывает, что у исходной учетной записи хранения StorSimple или целевой учетной записи хранения с общей папкой Azure включен параметр брандмауэра. Необходимо разрешить трафик через общедоступную конечную точку и не ограничивать его дополнительными правилами брандмауэра. В противном случае служба преобразования данных не сможет получить доступ к учетной записи хранения, даже если вы авторизованы. Отключите все правила брандмауэра и повторно запустите задание.
Копирование файлов	Учетная запись, к которой осуществляется доступ, не поддерживает HTTP	Отключите маршрутизацию через Интернет в целевой учетной записи хранения или используйте конечную точку маршрутизации Майкрософт.
	Указанная общая папка заполнена	Если целевой ресурс — это общая папка Azure уровня "Премиум", убедитесь, что вы подготовили достаточную емкость для общей папки. Временная подготовка с избытком является распространенной практикой.

Ошибки уровне элемента

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

Этап	Ошибка	Меры по снижению риска
Копировать	-2146233088 Сервер занят.	Если сбоев слишком много, запустите задание повторно. Если число ошибок невелико, можно повторить попытку выполнения задания, но часто быстрее будет вручную скопировать элементы, для которых возникла ошибка. Затем возобновите миграцию, перейдя сразу к обработке следующей резервной копии.
	-2146233088 Не удалось выполнить операцию за отведенное время.	Если сбоев слишком много, запустите задание повторно. Если число ошибок невелико, можно повторить попытку выполнения задания, но часто быстрее будет вручную скопировать элементы, для которых возникла ошибка. Затем возобновите миграцию, перейдя сразу к обработке следующей резервной копии.
	Время ожидания отправки или копирование не запущено	Если сбоев слишком много, запустите задание повторно. Если число ошибок невелико, можно повторить попытку выполнения задания, но часто быстрее будет вручную скопировать элементы, для которых возникла ошибка. Затем возобновите миграцию, перейдя сразу к обработке следующей резервной копии.
	-2146233029 операция была отменена.	Если сбоев слишком много, запустите задание повторно. Если число ошибок невелико, можно повторить попытку выполнения задания, но часто быстрее будет вручную скопировать элементы, для которых возникла ошибка. Затем возобновите миграцию, перейдя сразу к обработке следующей резервной копии.
	1920 Системе не удалось получить доступ к файлу.	Это распространенная ошибка, которая возникает, когда подсистема миграции сталкивается с точкой повторного анализа, связью или соединением. Они не поддерживаются. Эти типы файлов нельзя скопировать. Ознакомьтесь с разделом Известные ограничения и Точность файлов в этой статье.
	-2147024891 Доступ запрещен	Это ошибка возникает для файлов, зашифрованных таким образом, что к ним не получается получить доступ на диске. Файлы, которые можно считать с диска, но которые просто содержат зашифрованное содержимое, эта ошибка не затрагивает — их можно скопировать. Единственный вариант — скопировать их вручную. Такие элементы можно найти, установив затронутый том и выполнив следующую команду: get-childitem <path> [-Recurse] -Force -ErrorAction SilentlyContinue | Where-Object {$_.Attributes -ge "Encrypted"} | format-list fullname, attributes
	Недопустимое значение Win32 FileTime. Имя параметра: fileTime	В этом случае доступ к файлу можно получить, но его нельзя оценить для копирования, так как метка времени, от которой зависит подсистема миграции, повреждена или написана приложением в неправильном формате. Варианты решения проблемы ограничены, так как вы не можете изменить метку времени в резервной копии. Если сохранение этого файла важно, возможно, из последней версии (последней резервной копии, содержащей этот файл), можно вручную скопировать файл, исправить метку времени, а затем переместить его в целевую общую папку Azure. Это решение не очень хорошо масштабируется, но это хороший вариант для самых важных файлов, для которых нужно сохранить хотя бы одну версию в целевом объекте.
	-2146232798 Дескриптор SafeHandle был закрыт	Это часто лишь временная проблема. Если сбоев слишком много, запустите задание повторно. Если число ошибок невелико, можно повторить попытку выполнения задания, но часто быстрее будет вручную скопировать элементы, для которых возникла ошибка. Затем возобновите миграцию, перейдя сразу к обработке следующей резервной копии.
	-2147024413 Неустранимая ошибка оборудования устройства	Это редкая ошибка, которая не сообщается для физического устройства, а только для виртуальных модулей серии 8001, используемых службой миграции. Устройство столкнулось с проблемой. Файлы с этой ошибкой не помешают миграции на следующую резервную копию. Это затрудняет выполнение копирования вручную и повторения операции резервного копирования, содержащей файлы с этой ошибкой. Если оставшиеся файлы очень важны или ошибка возникла для большого количества файлов, может потребоваться снова начать миграцию всех резервных копий. Откройте запрос в службу поддержки для дальнейшего изучения.
Удаление (очистка зеркального отображения)	Указанный каталог не пуст.	Эта ошибка возникает, если в качестве режима миграции задано зеркальное отображение, и процесс удаления элементов из общей папки Azure столкнулся с проблемой, которая не позволила ему удалить элементы. Удаление выполняется только в текущей общей папке, а не из предыдущих моментальных снимков. Удаление необходимо, так как затронутые файлы не находятся в текущей резервной копии, поэтому их необходимо удалить из общей папки перед следующим моментальным снимком. Существует два варианта. Вариант 1: подключите целевую общую папку Azure и удалите файлы с этой ошибкой вручную. Вариант 2. Эти ошибки можно игнорировать и продолжить обработку следующей резервной копии с ожиданием того, что целевой объект не идентичен источнику и содержит некоторые дополнительные элементы, которые не были в исходной резервной копии StorSimple.
	Недопустимый запрос	Эта ошибка означает, что исходный файл имеет определенные характеристики, которые не удалось скопировать в общую папку Azure. В частности, в имени файла или в пути к файлу могут быть невидимые управляющие символы или символ в однобайтовой или двухбайтовой кодировке. Вы можете с помощью журналов копирования получить имена путей, скопировать файлы во временное расположение, переименовать пути, чтобы удалить неподдерживаемые символы, а затем повторно скопировать их в общую папку Azure. Затем можно возобновить миграцию, пропустив обработку следующей резервной копии.

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

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