Миграция с устройств 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 Files
• Обзор инструмента и процесса миграции StorSimple Data Manager

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

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

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

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

Запасы

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

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

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

Миграция данных в файловые хранилища Azure из томов StorSimple посредством заданий миграции в ресурсе "Data Manager 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 File Sync включает синхронизацию корневого каталога тома с облаком файлов Azure. При синхронизации корня тома все вложенные папки и файлы будут отправлены в одно и то же файловое хранилище Azure.

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

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

Совет

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

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

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

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

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

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

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

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

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

Совет

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

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

Внимание

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

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

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

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

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

Учетная запись хранилища

Имя учетной записи хранения станет частью 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 с перечнем элементов пространства имен, которые были успешно скопированы, и элементов, которые не удалось скопировать. Ошибки будут разделены на категории, описанные ранее. В расположении файла журнала можно найти записи о сбоях файлов, ищя "failed". Так можно сформировать список журналов для файлов, которые не удалось скопировать. Отсортируйте эти логи по размеру. Могут быть дополнительные логи размером 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
• Прямой доступ к общему ресурсу
• Развертывание Azure File Sync
• Развертывание облачного ресурса службы синхронизации файлов Azure
• Развертывание локального экземпляра Windows Server
• Подготовка экземпляра Windows Server для Azure File Sync
• Настройка синхронизации файлов Azure на экземпляре Windows Server
• Мониторинг начальной синхронизации
• Тестирование синхронизации файлов Azure
• Создание общих папок SMB

Развертывание службы Azure File Sync

Пора развернуть часть службы "Синхронизация файлов 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
• Настройка общедоступных и частных конечных точек
• Настройка S2S VPN
• Настройка P2S VPN для Windows
• Настройка P2S VPN для Linux
• Настройка переадресации DNS
• Настройка DFS-N

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

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

Этап 5. Переход пользователя

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

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

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

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

Планируйте ваше свободное время

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

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

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

Определите, когда пространство имен полностью синхронизировано с вашим сервером

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

Портал Azure

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

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

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

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

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

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

Последний RoboCopy

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

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

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

Robocopy в Windows Server 2019 столкнулась с проблемой, которая приводила к тому, что файлы, управляемые с помощью Azure File Sync на целевом сервере, повторно копировались из источника и повторно отправлялись в 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 Files показывают, что диапазон от 8 до 20 демонстрирует сбалансированную производительность для начального копирования. На последующие запуски /MIR всё больше влияет соотношение между доступными вычислительными ресурсами и доступной полосой пропускания сети. Для последующих запусков указываемое количество потоков нужно привести в соответствие с числом ядер процессора и количеством потоков, приходящихся на каждое ядро. Определите, нужно ли зарезервировать ядра для других задач рабочего сервера. Тесты с Azure Files показали, что до 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, 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 указан без явного минимального значения, минимальное значение устанавливается на уровне 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 будут зависеть от нескольких факторов:

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

Причиной этой разницы является вычислительная мощность, необходимая для прохода по пространству имен. Средство RoboCopy поддерживает многопоточные копии с помощью параметра /MT:n, где n означает количество используемых потоков. Поэтому при подготовке компьютера специально для RoboCopy рассмотрите количество ядер процессора и количество потоков, которое они предоставляют. Наиболее распространенный вариант — два потока на ядро. Ключевыми параметрами для определения необходимых многопоточных значений /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 File Sync под управлением Windows Server 2022.

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

Внимание

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

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

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

Переключение пользователей

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

При наличии развертывания DFS-N можно указать пространства имен DFS-N для новых расположений папок на сервере. Если у вас нет развертывания DFS-N и вы использовали локально Windows Server для подключения устройства 8100 или 8600, вы можете отключить этот сервер от домена. Затем присоедините к домену новый экземпляр 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 по разным причинам может произойти сбой всего задания миграции или отдельных файлов. В разделе о точности файлов содержатся дополнительные сведения о поддерживаемых и неподдерживаемых сценариях. В следующих таблицах перечислены коды ошибок, сведения об ошибках и, где это возможно, варианты устранения рисков.

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

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