Użyj urządzenia Data Box do migracji z magazynu sieciowego (NAS) do wdrożenia chmury hybrydowej przy użyciu usługi Azure File Sync.

Ten artykuł migracji jest jednym z kilku, które dotyczą słów kluczowych NAS, Azure File Sync i Azure Data Box. Sprawdź, czy ten artykuł ma zastosowanie do twojego scenariusza:

• Źródło danych: magazyn dołączony do sieci (NAS)
• Trasa migracji: usługa NAS ⇒ Data Box ⇒ udostępnianie plików platformy Azure ⇒ synchronizacja z systemem Windows Server
• Buforowanie plików lokalnych: Tak, ostatecznym celem jest wdrożenie usługi Azure File Sync

Jeśli twój scenariusz jest inny, zapoznaj się z tabelą przewodników migracji.

Usługa Azure File Sync działa w lokalizacjach pamięci masowej bezpośrednio dołączonych (DAS). Nie obsługuje synchronizacji z lokalizacjami magazynu dołączonego do sieci (NAS). Dlatego należy przeprowadzić migrację plików. Ten artykuł przeprowadzi Cię przez proces planowania i wdrażania tej migracji.

Dotyczy

Typ współdzielenia plików	SMB	NFS
Standardowe udziały plików (GPv2), LRS/ZRS
Udziały plików w warstwie Standardowa (GPv2), GRS/GZRS
Udziały plików w warstwie Premium (FileStorage), LRS/ZRS

Cele migracji

Celem jest przeniesienie udziałów na urządzeniu NAS do systemu Windows Server. Następnie użyjesz usługi Azure File Sync do wdrożenia chmury hybrydowej. Ta migracja musi odbywać się w sposób gwarantujący integralność danych produkcyjnych i dostępności podczas migracji. Ten ostatni wymaga minimalnego przestoju, dzięki czemu spełnia lub tylko nieznacznie przekracza regularne okna obsługi.

Omówienie migracji

Proces migracji składa się z kilku faz. Należy wykonać następujące czynności:

• Wdrażanie kont usługi Azure Storage i udziałów plików.
• Wdróż komputer lokalny z systemem Windows Server.
• Konfigurowanie usługi Azure File Sync.
• Migrowanie plików przy użyciu narzędzia Robocopy.
• Zrób przełączenie.

W poniższych sekcjach szczegółowo opisano fazy procesu migracji.

Napiwek

Jeśli wrócisz do tego artykułu, użyj nawigacji po prawej stronie ekranu, aby przejść do fazy migracji, w której została przerwana.

Faza 1. Określanie liczby potrzebnych udziałów plików platformy Azure

W tym kroku określisz, ilu udziałów plików w Azure potrzebujesz. Pojedyncza instancja systemu Windows Server (lub klaster) może synchronizować maksymalnie 30 udziałów plików platformy Azure.

Być może masz więcej folderów na woluminach, które obecnie udostępniasz lokalnie jako udziały SMB użytkownikom i aplikacjom. Najprostszym sposobem wyobrażenia sobie tego scenariusza jest zobrazowanie sobie udziału lokalnego, który mapuje się 1:1 do udziału plików na Azure. Jeśli masz niewielką liczbę udziałów, poniżej 30 dla jednej instancji systemu Windows Server, zalecamy mapowanie 1:1.

Jeśli masz więcej niż 30 udziałów, mapowanie udziału lokalnego 1:1 na udział plików platformy Azure jest często niepotrzebne. Rozważ następujące opcje.

Grupowanie udziałów

Jeśli na przykład dział kadr (HR) ma 15 udziałów, możesz rozważyć przechowywanie wszystkich danych kadrowych w jednym udziale plików platformy Azure. Przechowywanie wielu udziałów lokalnych w jednym udziale plików na platformie Azure nie uniemożliwia tworzenia zwyczajowych 15 udziałów SMB na lokalnym serwerze Windows Server. Oznacza to tylko, że foldery główne tych 15 udziałów są zorganizowane jako podfoldery w folderze wspólnym. Następnie zsynchronizuj ten wspólny folder z udziałem plików platformy Azure. W ten sposób dla tej grupy udziałów lokalnych jest wymagany tylko jeden udział plików platformy Azure w chmurze.

Synchronizacja woluminów

Usługa Azure File Sync obsługuje synchronizowanie katalogu głównego woluminu z udziałem plików platformy Azure. Jeśli zsynchronizujesz katalog główny woluminu, wszystkie podfoldery i pliki trafią do tego samego udziału plików platformy Azure.

Synchronizowanie głównego katalogu woluminu nie zawsze jest najlepszą opcją. Istnieją korzyści wynikające z synchronizacji wielu lokalizacji. Na przykład pomaga zachować liczbę elementów mniejszą w ramach zakresu synchronizacji. Testujemy udziały plików platformy Azure i usługę Azure File Sync z liczbą 100 milionów elementów (plików i folderów) na każdy udział. Najlepszym rozwiązaniem jest jednak utrzymanie liczby poniżej 20 milionów lub 30 milionów w jednym udziale. Konfigurowanie usługi Azure File Sync z mniejszą liczbą elementów nie jest korzystne tylko w przypadku synchronizacji plików. Mniejsza liczba elementów również przynosi korzyści w takich scenariuszach:

• Wstępne skanowanie zawartości w chmurze może zakończyć się szybciej, co z kolei zmniejsza oczekiwanie na wyświetlenie przestrzeni nazw na serwerze włączonym dla usługi Azure File Sync.
• Przywracanie z poziomu chmury z migawki udostępnionego pliku w Azure będzie szybsze.
• Odzyskiwanie po awarii serwera lokalnego może znacznie przyspieszyć.
• Zmiany wprowadzone bezpośrednio w udziale plików platformy Azure (poza synchronizacją) można wykrywać i synchronizować szybciej.

Napiwek

Jeśli nie wiesz, ile plików i folderów masz, zapoznaj się z narzędziem TreeSize firmy JAM Software GmbH.

Ustrukturyzowane podejście do mapy wdrożenia

Przed wdrożeniem magazynu w chmurze w późniejszym kroku należy utworzyć odwzorowanie między folderami lokalnymi a udostępnionymi zasobami plików Azure. To mapowanie określi, ile i które zasoby grupy synchronizacji usługi Azure File Sync będziesz aprowizować. Grupa synchronizacji łączy łącze plików Azure i folder na serwerze oraz ustanawia połączenie synchronizacji.

Aby zdecydować, ile udziałów plików platformy Azure jest Ci potrzebnych, zapoznaj się z następującymi limitami i najlepszymi praktykami. Pomoże to zoptymalizować mapę.

• Serwer, na którym jest zainstalowany agent usługi Azure File Sync, może synchronizować się z maksymalnie 30 udziałami plików platformy Azure.

• Udział plików platformy Azure jest wdrażany na koncie przechowywania. Takie rozwiązanie sprawia, że konto magazynowe jest celem skalowalności dla wskaźników wydajności, takich jak IOPS i przepływność.

  Zwróć uwagę na ograniczenia IOPS konta magazynu podczas wdrażania udziałów plików Azure. Najlepiej mapować udziały plików 1:1 przy użyciu konta magazynowego. Jednak może to nie zawsze być możliwe ze względu na różne limity i ograniczenia, zarówno z organizacji, jak i z platformy Azure. Jeśli nie jest możliwe wdrożenie tylko jednego udziału plików na jednym koncie magazynu, rozważ, które udziały będą wysoce aktywne i które udziały będą mniej aktywne, aby upewnić się, że najgorętsze udziały plików nie zostaną umieszczone na tym samym koncie magazynu.

  Jeśli planujesz podnieść aplikację na platformę Azure, która będzie używać natywnie udziału plików platformy Azure, może być potrzebna większa wydajność z udziału plików platformy Azure. Jeśli ten typ użycia jest możliwy, nawet w przyszłości, najlepszym rozwiązaniem jest utworzenie pojedynczego standardowego udostępnienia plików platformy Azure na własnym koncie magazynowym.

• Istnieje limit 250 kont magazynu na subskrypcję na region świadczenia usługi Azure.

Napiwek

Biorąc pod uwagę te informacje, często konieczne jest grupowanie wielu folderów najwyższego poziomu w woluminach do nowego wspólnego katalogu głównego. Następnie zsynchronizuj ten nowy katalog główny i wszystkie foldery zgrupowane w nim do pojedynczego udziału plików platformy Azure. Ta technika pozwala nie przekroczyć limitu 30 synchronizacji udziałów plików Azure na serwer.

To grupowanie pod wspólną podstawą nie ma wpływu na dostęp do twoich danych. Listy ACL pozostają tak, jak są. Wystarczy dostosować wszystkie ścieżki udziału (takie jak udziały SMB lub NFS), które mogą być dostępne w folderach serwera lokalnego, które zostały teraz zmienione w wspólny katalog główny. Nic innego się nie zmienia.

Ważne

Najważniejszym wektorem skalowania usługi Azure File Sync jest liczba elementów (plików i folderów), które należy zsynchronizować. Aby uzyskać więcej informacji, przejrzyj cele skalowania usługi Azure File Sync.

Najlepszym rozwiązaniem jest utrzymywanie niskiej liczby elementów na zakres synchronizacji. Jest to ważny czynnik, który należy wziąć pod uwagę podczas mapowania folderów do udziałów plików platformy Azure. Usługa Azure File Sync jest testowana przy użyciu 100 milionów elementów (plików i folderów) na udział. Ale często najlepiej zachować liczbę pozycji poniżej 20 milionów lub 30 milionów w jednym udziale. Podziel przestrzeń nazw na wiele udziałów, jeśli zaczniesz przekraczać te liczby. Możesz nadal grupować wiele udziałów lokalnych w tym samym udziale plików Azure, jeśli mniej więcej pozostaniesz w granicach tych liczb. Ta praktyka zapewni Ci miejsce na rozwój.

Istnieje możliwość, że w twojej sytuacji zestaw folderów może logicznie synchronizować się z tym samym udziałem plików na platformie Azure (przy użyciu wcześniej wymienionej nowej metody wspólnego folderu głównego). Jednak nadal lepiej jest przegrupować foldery, aby synchronizowały się z dwoma zamiast z jednym udziałem plików Azure. Za pomocą tego podejścia można zachować równowagę liczby plików i folderów na udziałach plików na serwerze. Możesz również podzielić udziały lokalne i zsynchronizować je na większej liczbie serwerów lokalnych, umożliwiając synchronizację z 30 dodatkowymi udziałami plików platformy Azure na każdy dodatkowy serwer.

Typowe scenariusze i zagadnienia dotyczące synchronizacji plików

#	Scenariusz synchronizacji	Wspierane	Zagadnienia (lub ograniczenia)	Rozwiązanie (lub obejście)
1	Serwer plików z wieloma dyskami/woluminami i wieloma udziałami do tego samego docelowego udziału plików platformy Azure (konsolidacja)	Nie.	Docelowy zasób plików platformy Azure (punkt końcowy w chmurze) umożliwia tylko synchronizację z jedną grupą synchronizacji. Grupa synchronizacji obsługuje tylko jeden punkt końcowy serwera na zarejestrowany serwer.	1) Rozpocznij od zsynchronizowania jednego dysku (woluminu głównego) z docelowym udziałem plików platformy Azure. Rozpoczęcie od największego dysku/woluminu pomoże spełnić wymagania dotyczące magazynu lokalnego. Skonfiguruj warstwowanie w chmurze, aby przenieść wszystkie dane do chmury, zwalniając tym samym miejsce na dysku serwera plików. Przenieś dane z innych woluminów/udziałów do bieżącego woluminu, który jest synchronizowany. Wykonaj kroki jeden po drugim, dopóki wszystkie dane nie będą warstwowe do chmury/zmigrowane. Skieruj się na jeden wolumin główny (dysk) naraz. Obsługa warstw w chmurze umożliwia warstwowanie wszystkich danych w celu kierowania udziału plików platformy Azure. Usuń punkt końcowy serwera z grupy synchronizacji, a następnie stwórz go ponownie z następnym woluminem głównym lub dyskiem, zsynchronizuj i powtórz proces. Uwaga: Może być wymagane ponowne zainstalowanie agenta. 3) Zaleca się używanie wielu docelowych udziałów plików platformy Azure (tego samego lub innego konta magazynu na podstawie wymagań dotyczących wydajności)
2	Serwer plików z pojedynczym woluminem i wieloma udziałami do tego samego docelowego udziału plików platformy Azure (konsolidacja)	Tak	Nie można mieć wielu punktów końcowych serwera na zarejestrowany serwer synchronizacji z tym samym docelowym udziałem plików platformy Azure (takim samym jak powyżej)	Zsynchronizuj folder główny woluminu zawierającego wiele udziałów lub folderów najwyższego poziomu. Aby uzyskać więcej informacji, zobacz Share grouping concept and Volume sync (Udostępnianie koncepcji grupowania i synchronizacja woluminów).
3	Serwer plików z wieloma udziałami i/lub woluminami do wielu udziałów plików platformy Azure w ramach pojedynczego konta magazynu (mapowanie udziału 1:1)	Tak	Pojedyncze wystąpienie systemu Windows Server (lub klaster) może synchronizować maksymalnie 30 udziałów plików platformy Azure. Konto przechowywania służy jako cel skalowania pod kątem wydajności. Liczba operacji we/wy na sekundę i przepustowość są udostępniane przez udziały plików. Zachowaj liczbę elementów na grupę synchronizacji w obrębie 100 milionów elementów (plików i folderów) na udział. Najlepiej pozostać poniżej 20 lub 30 milionów na akcję.	1) Użyj wielu grup synchronizacji (liczba grup synchronizacji = liczba udziałów plików Azure do zsynchronizowania). 2) W tym scenariuszu można zsynchronizować tylko 30 udziałów. Jeśli masz więcej niż 30 udziałów na tym serwerze plików, użyj koncepcji grupowania udziałów i synchronizacji woluminów, aby zmniejszyć liczbę folderów głównych lub najwyższego poziomu w źródle. 3) Użyj dodatkowych serwerów usługi File Sync w środowisku lokalnym i podziel/przenieś dane na te serwery, aby obejść ograniczenia dotyczące źródłowego serwera z systemem Windows.
100	Serwer plików z wieloma udziałami i/lub woluminami do wielu udziałów plików platformy Azure w ramach innego konta magazynu (mapowanie udziału 1:1)	Tak	Pojedyncze wystąpienie systemu Windows Server (lub klaster) może synchronizować maksymalnie 30 udziałów plików Azure (tego samego lub innego konta magazynowego). Zachowaj liczbę elementów na grupę synchronizacji w obrębie 100 milionów elementów (plików i folderów) na udział. Najlepiej pozostać poniżej 20 lub 30 milionów na akcję.	Takie samo podejście jak powyżej
5	Wiele serwerów plików z jednym (woluminem głównym lub udziałem) do tego samego docelowego udziału plików platformy Azure (konsolidacja)	Nie.	Grupa synchronizacji nie może używać punktu końcowego w chmurze (udziału plików platformy Azure) już skonfigurowanego w innej grupie synchronizacji. Mimo że grupa synchronizacji może mieć punkty końcowe serwera na różnych serwerach plików, pliki nie mogą być odrębne.	Postępuj zgodnie ze wskazówkami w scenariuszu nr 1 powyżej, dodatkowo skupiając się na jednym serwerze plików naraz.

Tworzenie tabeli mapowania

Użyj poprzednich informacji, aby określić, ile udziałów plików platformy Azure potrzebujesz i które części twoich istniejących danych znajdą się w którym udziale plików platformy Azure.

Utwórz tabelę, która rejestruje swoje przemyślenia, aby można było odwoływać się do niej, gdy zajdzie taka potrzeba. Utrzymanie organizacji jest ważne, ponieważ można łatwo utracić szczegóły planu mapowania podczas aprowizowania wielu zasobów platformy Azure jednocześnie. Pobierz następujący plik programu Excel, aby użyć go jako szablonu, aby ułatwić tworzenie mapowania.

Pobierz szablon mapowania przestrzeni nazw.

Faza 2. Wdrażanie zasobów usługi Azure Storage

W tej fazie zapoznaj się z tabelą mapowania z fazy 1 i użyj jej do przygotowania prawidłowej liczby kont magazynu platformy Azure oraz udziałów plików w ramach tych kont.

Udział plików platformy Azure jest przechowywany w chmurze na koncie usługi Azure Storage. W tym miejscu ma zastosowanie kolejny poziom zagadnień dotyczących wydajności.

Jeśli masz wysoce aktywne udziały (udziały używane przez wielu użytkowników i/lub aplikacje), dwa udziały plików platformy Azure mogą osiągnąć limit wydajności konta magazynu.

Najlepszym rozwiązaniem jest wdrożenie konta magazynowego z jednym zasobem plików. Możesz połączyć wiele udziałów plików na platformie Azure z tym samym kontem magazynowania, jeśli masz udziały archiwalne lub spodziewasz się w nich niskiej codziennej aktywności.

Te zagadnienia dotyczą bardziej bezpośredniego dostępu do chmury (za pośrednictwem maszyny wirtualnej platformy Azure) niż do usługi Azure File Sync. Jeśli planujesz używać tylko usługi Azure File Sync w tych udziałach, grupowanie kilku na jednym koncie usługi Azure Storage jest w porządku.

Jeśli utworzono listę udziałów, należy przypisać każdy udział do konta magazynu, w którym będzie się znajdować.

W poprzedniej fazie określono odpowiednią liczbę udziałów. W tym kroku masz mapowanie kont magazynowych do udziałów plików. Teraz wdróż odpowiednią liczbę kont usługi Azure Storage z odpowiednią liczbą udziałów plików Azure.

Upewnij się, że region każdego konta magazynu jest taki sam i odpowiada regionowi wdrożonego już zasobu usługi synchronizacji magazynu.

Uwaga

Jeśli tworzysz udział plików platformy Azure z limitem 100 TiB, ten udział może używać tylko opcji nadmiarowości magazynu lokalnie nadmiarowego lub strefowo nadmiarowego magazynu. Przed użyciem zasobów plikowych o pojemności 100 TiB, należy wziąć pod uwagę potrzeby nadmiarowości przechowywania danych.

Udziały plików platformy Azure są nadal tworzone z limitem 5 TiB domyślnie. Wykonaj kroki opisane w Utwórz udział plików platformy Azure, aby utworzyć duży udział plików.

Innym zagadnieniem podczas wdrażania konta magazynu jest nadmiarowość usługi Azure Storage. Zobacz Opcje nadmiarowości Azure Storage.

Nazwy twoich zasobów są również ważne. Na przykład, jeśli pogrupujesz wiele udziałów dla działu kadr w konto magazynu Azure, należy nazwać to konto magazynu odpowiednio. Podobnie, gdy nadajesz nazwy swoim udziałom plików Azure, powinieneś używać nazw podobnych do tych stosowanych dla ich lokalnych odpowiedników.

Faza 3. Określanie liczby potrzebnych urządzeń Azure Data Box

Rozpocznij ten krok dopiero po zakończeniu poprzedniej fazy. Zasoby usługi Azure Storage (konta magazynu i udziały plików) powinny zostać utworzone w tym momencie. W przypadku zamawiania urządzenia Data Box należy określić konta magazynu, do których urządzenie Data Box przenosi dane.

W tej fazie należy zamapować wyniki planu migracji z poprzedniej fazy na limity dostępnych opcji urządzenia Data Box. Te kwestie pomogą Ci zaplanować, którą opcję urządzenia Data Box wybrać i ile ich potrzebujesz, aby przenieść udziały NAS na udziały plików w Azure.

Aby określić liczbę potrzebnych urządzeń i ich typów, należy wziąć pod uwagę następujące ważne limity:

• Każde urządzenie Data Box może przenosić dane na maksymalnie 10 kont magazynowych.
• Każda opcja urządzenia Data Box ma własną pojemność do wykorzystania. Zobacz Opcje urządzenia Data Box.

Zapoznaj się z planem migracji, aby znaleźć liczbę kont magazynu, które chcesz utworzyć, i udziały w każdym z nich. Następnie przyjrzyj się rozmiarowi poszczególnych udziałów na serwerze NAS. Połączenie tych informacji pozwoli zoptymalizować proces i zdecydować, które urządzenie powinno wysyłać dane do których kont magazynowych. Dwa urządzenia Data Box mogą przemieszczać pliki do tego samego konta magazynu, ale nie dzielą zawartości pojedynczego udziału plików między dwa urządzenia Data Box.

Opcje urządzenia Data Box

W przypadku migracji standardowej wybierz jedną lub kombinację tych opcji urządzenia Data Box:

• Data Box Disk. Firma Microsoft wyśle do Ciebie od jednego do pięciu dysków SSD, które mają pojemność 8 TiB każdy, do maksymalnej łącznej pojemności 40 TiB. Pojemność do wykorzystania wynosi około 20 procent mniej ze względu na obciążenie związane z szyfrowaniem i systemem plików. Aby uzyskać więcej informacji, zobacz dokumentację urządzenia Data Box Disk.
• Data Box. Ta opcja jest najbardziej powszechna. Firma Microsoft wyśle do ciebie ruggedizowane urządzenie Data Box, które działa podobnie jak urządzenie NAS. Ma do wykorzystania pojemność 80 TiB. Aby uzyskać więcej informacji, zobacz dokumentację urządzenia Data Box.
• Data Box Heavy. Ta opcja oferuje odporne urządzenie Data Box na kołach, które działa podobnie jak w przypadku serwera NAS. Ma pojemność 1 PiB. Pojemność do wykorzystania wynosi około 20 procent mniej ze względu na obciążenie związane z szyfrowaniem i systemem plików. Aby uzyskać więcej informacji, zobacz dokumentację urządzenia Data Box Heavy.

Faza 4: Skonfiguruj odpowiednie wystąpienie systemu Windows Server lokalnie

Podczas oczekiwania na przybycie urządzeń Azure Data Box możesz zacząć analizować potrzeby serwera lub serwerów Windows Server, które będą używane z usługą Azure File Sync.

• Utwórz instancję systemu Windows Server 2022 jako maszynę wirtualną lub serwer fizyczny, przy czym minimalna wersja to Windows Server 2012 R2. Klaster trybu failover systemu Windows Server jest również obsługiwany.
• Zaproponuj lub dodaj pamięć masową bezpośrednio podłączoną. NAS nie jest obsługiwany.

Konfiguracja zasobów (mocy obliczeniowej i pamięci RAM) instancji Windows Server, którą wdrażasz, zależy głównie od liczby plików i folderów, które synchronizujesz. Zalecamy konfigurację o wyższej wydajności, jeśli masz jakiekolwiek problemy.

Dowiedz się, jak określić rozmiar wystąpienia systemu Windows Server na podstawie liczby elementów, które należy zsynchronizować.

Uwaga

Wcześniej połączony artykuł zawiera tabelę z zakresem pamięci serwera (RAM). Możesz użyć liczb na dolnym końcu zakresu dla serwera, ale spodziewaj się, że synchronizacja początkowa będzie trwać znacznie dłużej.

Faza 5. Kopiowanie plików na urządzenie Data Box

Po nadejściu urządzenia Data Box należy skonfigurować je z nieskrępowaną łącznością sieciową z urządzeniem NAS. Postępuj zgodnie z dokumentacją konfiguracji dla typu urządzenia Data Box, który zamówiłeś.

• Konfigurowanie urządzenia Data Box.
• Konfigurowanie urządzenia Data Box Disk.
• Konfigurowanie urządzenia Data Box Heavy.

W zależności od typu urządzenia Data Box narzędzia do kopiowania urządzenia Data Box mogą być dostępne. Na tym etapie nie zalecamy użycia ich do migrowania plików do udziałów plików platformy Azure, ponieważ nie kopiują one plików do urządzenia Data Box z pełną dokładnością. Zamiast tego użyj narzędzia Robocopy.

Po nadejściu urządzenia Data Box będą dostępne wstępnie aprowidowane udziały SMB dla każdego konta magazynu określonego podczas jego zamówienia.

• Jeśli Twoje pliki trafią do udziału plików Azure w warstwie Premium, będzie jeden udział SMB na każde konto magazynowe "File Storage" w tej warstwie.
• Jeśli pliki przechodzą do konta magazynu w warstwie Standardowa, będą istnieć trzy udziały SMB na konto magazynu w warstwie Standardowa (GPv1 i GPv2). Tylko udziały plików, które kończą się na _AzFiles, są istotne dla migracji. Ignoruj udziały dotyczące blobów blokowych i stronicowych.

Wykonaj kroki opisane w dokumentacji usługi Azure Data Box:

1. Nawiązywanie połączenia z usługą Data Box.
2. Kopiowanie danych do urządzenia Data Box.
   Możesz użyć narzędzia Robocopy (postępuj zgodnie z poniższymi instrukcjami) lub nowej usługi kopiowania danych Data Box.
3. Przygotuj urządzenie Data Box do przekazania na platformę Azure.

Napiwek

Alternatywą dla narzędzia Robocopy jest usługa Data Box, która utworzyła usługę kopiowania danych. Za pomocą tej usługi można załadować pliki na urządzenie Data Box z pełną wiernością. Postępuj zgodnie z tym samouczkiem dotyczącym kopiowania danych i upewnij się, że ustawiono właściwy docelowy udział plików w usłudze Azure.

Dokumentacja urządzenia Data Box określa polecenie Robocopy. To polecenie nie jest odpowiednie do zachowania pełnej wierności pliku i folderu. Zamiast tego użyj tego polecenia:

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> 

Przełącznik	Znaczenie
/MT:n	Umożliwia wielowątkowe uruchomienie narzędzia Robocopy. Wartość domyślna to n 8. Maksymalna liczba wątków to 128. Chociaż duża liczba wątków pomaga usycić dostępną przepustowość, nie oznacza to, że migracja zawsze będzie szybsza z większą liczbą wątków. Testy z usługą Azure Files wskazują, że pomiędzy 8 a 20 wartości osiągają zrównoważoną wydajność podczas początkowego przebiegu kopiowania. Kolejne /MIR uruchomienia są stopniowo dotknięte dostępną przepustowością obliczeniową oraz sieciową. W przypadku kolejnych przebiegów dokładniej dopasuj liczbę wątków do liczby rdzeni procesora i liczby wątków na rdzeń. Zastanów się, czy trzeba zarezerwować rdzenie dla innych zadań serwera produkcyjnego. Testy w usłudze Azure Files wykazały, że maksymalnie 64 wątki generują dobrą wydajność, ale tylko wtedy, gdy procesory mogą utrzymać je w tym samym czasie.
/R:n	Maksymalna liczba ponownych prób dla pliku, którego nie udało się skopiować przy pierwszej próbie. Narzędzie Robocopy spróbuje czasy n przed trwałym niepowodzeniem kopiowania pliku w przebiegu. Możesz zoptymalizować wydajność działania: wybierz wartość dwóch lub trzech, jeśli uważasz, że przekroczenia limitu czasu spowodowały niepowodzenia w przeszłości. Może to być bardziej typowe w przypadku łączy sieci WAN. Jeśli uważasz, że plik nie skopiował się, ponieważ był aktywnie używany, wybierz opcję bez ponownej próby lub ustaw wartość na jedynkę. Próba ponownie kilka sekund później może nie być wystarczająca do zmiany stanu w użyciu pliku. Użytkownicy lub aplikacje z otwartym plikiem mogą potrzebować więcej godzin. W takim przypadku akceptacja faktu, że plik nie został skopiowany i jego ponowne przetworzenie w jednym z planowanych, późniejszych przebiegów narzędzia Robocopy, może ostatecznie zakończyć się pomyślnym skopiowaniem pliku. Pomaga przyspieszyć bieżący proces bez przedłużania go przez liczne próby ponownego uruchomienia, które ostatecznie kończą się przewagą awarii kopiowania z powodu plików wciąż otwartych po upływie limitu czasu prób ponownych.
/W:n	Określa czas, przez który narzędzie Robocopy czeka, zanim podejmie próbę skopiowania pliku, który nie został pomyślnie skopiowany podczas poprzedniej próby. n to liczba sekund oczekiwania między ponowną próbą. /W:n jest często używany razem z /R:n.
/B	Uruchamia narzędzie Robocopy w tym samym trybie, którego użyłaby aplikacja do tworzenia kopii zapasowych. Ten przełącznik umożliwia narzędziu Robocopy przenoszenie plików, do których bieżący użytkownik nie ma uprawnień. Przełącznik kopii zapasowej zależy od uruchomienia polecenia Robocopy w konsoli z podwyższonym poziomem uprawnień administratora lub w oknie programu PowerShell. Jeśli używasz narzędzia Robocopy dla usługi Azure Files, upewnij się, że udział plików platformy Azure został zamontowany przy użyciu klucza dostępu do konta magazynu zamiast tożsamości domeny. Jeśli tego nie zrobisz, komunikaty o błędach mogą nie prowadzić intuicyjnie do rozwiązania problemu.
/MIR	(Lustrzane źródło do celu.) Umożliwia programowi Robocopy kopiowanie tylko różnic między źródłem a celem. Puste podkatalogi zostaną skopiowane. Elementy (pliki lub foldery), które uległy zmianie lub nie istnieją w miejscu docelowym, zostaną skopiowane. Elementy, które istnieją w miejscu docelowym, ale nie ma ich w źródle, zostaną wyczyszczone (usunięte) z miejsca docelowego. W przypadku korzystania z tego przełącznika dokładnie dopasuj strukturę folderu źródłowego i docelowego. Dopasowanie oznacza skopiowanie z poprawnego poziomu źródła i folderu do odpowiadającego poziomu folderu po stronie docelowej. Tylko wtedy tworzenie kopii na zasadzie „nadrobienia zaległości” może zakończyć się powodzeniem. Gdy źródło i cel są niezgodne, użycie /MIR spowoduje usunięcie i ponowne kopiowanie na dużą skalę.
/IT	Zapewnia zachowanie wierności w pewnych scenariuszach lustrzanych. Jeśli na przykład plik napotyka zmianę listy ACL i aktualizację atrybutu między dwoma przebiegami narzędzia Robocopy, jest on oznaczony jako ukryty. Bez elementu /IT zmiana ACL może zostać pominięta przez narzędzie Robocopy i nie zostać przeniesiona do lokalizacji docelowej.
/COPY:[copyflags]	Wierność kopii pliku. Wartość domyślna: /COPY:DAT. Flagi kopiowania: D= Dane, A= Atrybuty, T= Znaczniki czasu, S= Zabezpieczenia = LISTY ACL NTFS, O= Informacje o właścicielu, U= Informacjeo diting u. W udziale plików platformy Azure nie można przechowywać informacji o inspekcji.
/DCOPY:[copyflags]	Wierność kopii katalogów. Wartość domyślna: /DCOPY:DA. Flagi kopiowania: D= Dane, A= Atrybuty, T= Znaczniki czasu.
/NP	Określa brak wyświetlania postępu kopiowania dla każdego pliku i folderu. Wyświetlanie postępu znacznie obniża wydajność kopiowania.
/NFL	Określa brak rejestrowania nazw plików. Poprawia wydajność kopiowania.
/NDL	Określa brak rejestrowania nazw katalogów. Poprawia wydajność kopiowania.
/XD	Określa katalogi, które mają być wykluczone. Podczas uruchamiania narzędzia Robocopy w katalogu głównym woluminu rozważ wykluczenie ukrytego System Volume Information folderu. Jeśli są one używane zgodnie z projektem, wszystkie informacje w nim są specyficzne dla dokładnego woluminu w tym dokładnym systemie i można je ponownie skompilować na żądanie. Kopiowanie tych informacji nie będzie przydatne w chmurze ani kiedy dane są kiedykolwiek kopiowane z powrotem do innego woluminu systemu Windows. Pozostawienie tej zawartości nie powinno być traktowane jako utrata danych.
/UNILOG:<file name>	Zapisuje stan w pliku dziennika jako Unicode. (Zastępuje istniejący dziennik).
/L	Tylko w przypadku uruchomienia testowego pliki mają być wyświetlane tylko. Nie zostaną one skopiowane, usunięte ani oznaczone sygnaturą czasową. Często używane w /TEE przypadku danych wyjściowych konsoli. Może być konieczne usunięcie flag z przykładowego skryptu, takiego jak /NP, /NFLi /NDL, w celu uzyskania prawidłowych udokumentowanych wyników testu.
/LFSM	Tylko dla miejsc docelowych z magazynem warstwowym. Nieobsługiwane, gdy miejsce docelowe jest zdalnym udziałem SMB. Określa, że narzędzie Robocopy działa w trybie "małej ilości wolnego miejsca". Ten przełącznik jest przydatny tylko w przypadku obiektów docelowych z magazynem warstwowym, który może zabraknąć lokalnej pojemności przed zakończeniem działania narzędzia Robocopy. Został on dodany specjalnie do użytku z miejscem docelowym z obsługą warstw w chmurze usługi Azure File Sync. Można go używać niezależnie od usługi Azure File Sync. W tym trybie działanie narzędzia Robocopy zostanie wstrzymane za każdym razem, gdy skopiowanie pliku spowodowałoby przekroczenie wartości progowej dla wolnego miejsca na woluminie docelowym. Tę wartość można określić za pomocą /LFSM:n formularza flagi. Parametr n jest określony w bazie 2: nKB, nMBlub nGB. Jeśli /LFSM określono wartość bez jawnej podłogi, podłoga jest ustawiona na 10 procent rozmiaru woluminu docelowego. Tryb małej ilości wolnego miejsca nie jest zgodny z elementami /MT, /EFSRAWlub /ZB. /B Dodano obsługę systemu Windows Server 2022. Zobacz sekcję Windows Server 2022 i RoboCopy LFSM poniżej, aby uzyskać więcej informacji, w tym szczegółowe informacje na temat powiązanej usterki i obejścia.
/Z	Ostrożnie kopiuje pliki w trybie ponownego uruchamiania. Ten przełącznik jest zalecany tylko w niestabilnym środowisku sieciowym. Znacznie zmniejsza wydajność kopiowania z powodu nadmiernego rejestrowania.
/ZB	Należy ostrożnie używać trybu ponownego uruchamiania. W przypadku odmowy dostępu ta opcja używa trybu tworzenia kopii zapasowej. Ta opcja znacznie zmniejsza wydajność kopiowania z powodu tworzenia punktów kontrolnych.

Ważne

Zalecamy używanie systemu Windows Server 2022. W przypadku korzystania z systemu Windows Server 2019 upewnij się, że zainstalowano najnowszą wersję poprawki lub co najmniej KB5005103 aktualizacji systemu operacyjnego. Zawiera ważne poprawki dla niektórych scenariuszy narzędzia Robocopy.

Faza 6. Wdrażanie zasobu w chmurze usługi Azure File Sync

Przed kontynuowaniem pracy z tym przewodnikiem poczekaj, aż wszystkie pliki dotarły do odpowiednich udziałów plików platformy Azure. Proces wysyłania i pozyskiwania danych urządzenia Data Box zajmie trochę czasu.

Aby wykonać ten krok, potrzebne są poświadczenia subskrypcji platformy Azure.

Podstawowy zasób do skonfigurowania dla usługi Azure File Sync nazywa się Storage Sync Service. Zalecamy wdrożenie tylko jednego dla wszystkich serwerów, które synchronizują ten sam zestaw plików teraz lub w przyszłości. Utwórz wiele usług synchronizacji magazynu tylko wtedy, gdy masz różne zestawy serwerów, które nigdy nie muszą wymieniać danych. Na przykład mogą istnieć serwery, które nigdy nie muszą synchronizować tego samego udziału plików platformy Azure. W przeciwnym razie, korzystanie z pojedynczej usługi synchronizacji danych jest najlepszą praktyką.

Wybierz region platformy Azure dla usługi synchronizacji magazynu, który znajduje się blisko twojej lokalizacji. Wszystkie inne zasoby w chmurze muszą zostać wdrożone w tym samym regionie. Celem uproszczenia zarządzania, utwórz nową grupę zasobów w ramach subskrypcji, która obejmuje zasoby synchronizacji i przechowywania.

Aby uzyskać więcej informacji, zobacz sekcję dotyczącą wdrażania usługi Storage Sync Service w artykule dotyczącym wdrażania usługi Azure File Sync. Postępuj zgodnie tylko z tą sekcją artykułu. W kolejnych krokach będą dostępne linki do innych sekcji artykułu.

Faza 7. Wdrażanie agenta usługi Azure File Sync

W tej sekcji zainstalujesz agenta usługi Azure File Sync na instancji systemu Windows Server.

W przewodnikuwdrażania wyjaśniono, że należy wyłączyć konfigurację zwiększonych zabezpieczeń programu Internet Explorer. Ta miara zabezpieczeń nie ma zastosowania w usłudze Azure File Sync. Wyłączenie go umożliwia uwierzytelnianie na platformie Azure bez żadnych problemów.

Otwórz program PowerShell. Zainstaluj wymagane moduły programu PowerShell przy użyciu następujących poleceń. Pamiętaj, aby zainstalować pełny moduł i dostawcę pakietu NuGetu, gdy zostaniesz do tego wezwany.

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

Jeśli masz jakiekolwiek problemy z dotarciem do Internetu z serwera, nadszedł czas, aby je rozwiązać. Usługa Azure File Sync używa dowolnego dostępnego połączenia sieciowego z Internetem. Możliwość korzystania z serwera proxy w celu uzyskania dostępu do internetu jest również wspierana. Możesz teraz skonfigurować serwer proxy dla całej maszyny lub podczas instalacji agenta określić serwer proxy, który będzie używany tylko przez usługę Azure File Sync.

Jeśli konfiguracja serwera proxy wymaga otwarcia zapór dla serwera, takie podejście może być dla Ciebie akceptowalne. Na końcu instalacji serwera po zakończeniu rejestracji serwera raport łączności sieciowej wyświetli dokładne adresy URL punktów końcowych na platformie Azure, z którymi usługa Azure File Sync musi komunikować się z wybranym regionem. Raport informuje również, dlaczego komunikacja jest potrzebna. Raport umożliwia zablokowanie zapór wokół serwera pod określonymi adresami URL.

Można również zastosować bardziej konserwatywne podejście, w którym nie otwierasz zapór. Zamiast tego można ograniczyć serwer do komunikowania się z przestrzeniami nazw DNS wyższego poziomu. Aby uzyskać więcej informacji, zobacz Ustawienia serwera proxy i zapory usługi Azure File Sync. Postępuj zgodnie z własnymi najlepszymi praktykami sieciowymi.

Na końcu kreatora instalacji serwera zostanie otwarty kreator rejestracji serwera. Zarejestruj serwer w zasobie Azure swojej usługi Storage Sync wspomnianym wcześniej.

Te kroki opisano bardziej szczegółowo w przewodniku wdrażania, który zawiera moduły programu PowerShell, które należy zainstalować najpierw: instalacja agenta usługi Azure File Sync.

Użyj najnowszego agenta. Możesz pobrać Agenta usługi Azure File Sync z Centrum pobierania Microsoft: Agenta usługi Azure File Sync.

Po pomyślnej instalacji i rejestracji serwera możesz potwierdzić, że ten krok został pomyślnie ukończony. Przejdź do zasobu usługi Storage Sync w portalu Azure. W menu po lewej stronie przejdź do pozycji Zarejestrowane serwery. Zobaczysz tam swój serwer.

Faza 8. Konfigurowanie usługi Azure File Sync na instancji systemu Windows Server

Zarejestrowane lokalne wystąpienie systemu Windows Server musi być gotowe i połączone z Internetem na potrzeby tego procesu.

Ten krok łączy wszystkie zasoby i foldery skonfigurowane w instancji systemu Windows Server podczas poprzednich kroków.

1. Zaloguj się w witrynie Azure Portal.
2. Znajdź zasób usługi Storage Sync Service.
3. Utwórz nową grupę synchronizacji w ramach zasobu Storage Sync Service dla każdego udostępnionego zasobu plików Azure. W terminologii usługi Azure File Sync udział plików platformy Azure stanie się punktem końcowym chmury w topologii synchronizacji, którą opisujesz poprzez utworzenie grupy synchronizacji. Podczas tworzenia grupy synchronizacji nadaj jej znaną nazwę, aby rozpoznać, który zestaw plików jest tam synchronizowany. Upewnij się, że odwołujesz się do udostępnionego katalogu Azure o odpowiedniej nazwie.
4. Gdy utworzysz grupę synchronizacji, pojawi się dla niej wiersz na liście grup synchronizacji. Wybierz nazwę (link), aby wyświetlić zawartość grupy synchronizacji. Zobaczysz udostępnioną przestrzeń plików Azure w obszarze Punkty końcowe chmury.
5. Znajdź przycisk Add Server Endpoint. Folder na serwerze lokalnym, który został zaaprowizowany, stanie się ścieżką dla tego punktu końcowego serwera.

Włącz funkcję tieringu w chmurze i wybierz pozycję Tylko przestrzeń nazw w sekcji początkowego pobierania.

Ważne

Warstwowanie w chmurze to funkcja usługi Azure File Sync, która pozwala serwerowi lokalnemu mieć mniejszą pojemność dysku niż w chmurze, ale nadal mieć pełny dostęp do przestrzeni nazw. Lokalnie interesujące dane są również buforowane lokalnie w celu uzyskania szybkiej wydajności dostępu. Warstwowanie w chmurze jest opcjonalne. Można ustawić je indywidualnie dla każdego punktu końcowego serwera usługi Azure File Sync. Należy użyć tej funkcji, jeśli nie masz wystarczającej pojemności dysku lokalnego w wystąpieniu systemu Windows Server do przechowywania wszystkich danych w chmurze i chcesz uniknąć pobierania wszystkich danych z chmury.

W przypadku wszystkich udziałów plików/lokalizacji serwera platformy Azure, które należy skonfigurować do celów synchronizacji, powtórz kroki tworzenia grup synchronizacji i dodaj pasujące foldery serwera jako punkty końcowe serwera. Poczekaj na ukończenie synchronizacji przestrzeni nazw. W poniższej sekcji wyjaśniono, jak można upewnić się, że synchronizacja została ukończona.

Uwaga

Po utworzeniu punktu końcowego serwera synchronizacja działa. Jednak synchronizacja musi wyliczać (odkrywać) pliki i foldery przeniesione za pośrednictwem urządzenia Data Box do zasobu plików w Azure. W zależności od rozmiaru przestrzeni nazw może upłynąć dużo czasu, zanim przestrzeń nazw z chmury pojawi się na serwerze.

Faza 9. Zaczekaj, aż przestrzeń nazw zostanie w pełni wyświetlona na serwerze

Zanim przejdziesz do następnych kroków migracji, poczekaj, aż serwer w pełni pobierze przestrzeń nazw z udziału w chmurze. Jeśli zaczniesz zbyt wcześnie przenosić pliki na serwer, ryzykujesz niepotrzebne przesyłanie, a nawet konflikty synchronizacji plików.

Aby określić, czy serwer zakończył początkową synchronizację pobierania, otwórz Podgląd zdarzeń w zsynchronizowaniu wystąpienia systemu Windows Server i użyj dziennika zdarzeń telemetrii usługi Azure File Sync. Dziennik zdarzeń telemetrii znajduje się w Podgląd zdarzeń w obszarze Aplikacje i usługi\Microsoft\FileSync\Agent.

Wyszukaj najnowsze zdarzenie 9102. Identyfikator zdarzenia 9102 jest rejestrowany po zakończeniu sesji synchronizacji. W tekście zdarzenia istnieje pole dla kierunku synchronizacji pobierania. (HResult musi mieć wartość zero, a pliki muszą zostać pobrane).

Chcesz zobaczyć dwa kolejne zdarzenia tego typu, z tą zawartością, aby upewnić się, że serwer zakończył pobieranie przestrzeni nazw. Jest to ok, jeśli istnieją inne zdarzenia między dwoma zdarzeniami 9102.

Faza 10. Uruchamianie narzędzia Robocopy z serwera NAS

Po zakończeniu początkowej synchronizacji całej przestrzeni nazw z udziału w chmurze możesz kontynuować ten krok. Przed kontynuowaniem tego kroku należy ukończyć synchronizację początkową. Aby uzyskać szczegółowe informacje, zobacz poprzednią sekcję.

W tym kroku uruchomisz zadania Robocopy, aby zsynchronizować udziały w chmurze z najnowszymi zmianami na serwerze NAS, które zaszły od czasu skopiowania udziałów na urządzenie Data Box. Uruchomienie narzędzia Robocopy może skończyć się szybko lub potrwać dłużej, w zależności od ilości ruchów, które zaszły w udziałach NAS.

Ostrzeżenie

Ze względu na regresję działania narzędzia Robocopy w systemie Windows Server 2019 przełącznik Robocopy /MIR nie jest zgodny z katalogami docelowymi warstwowymi. W tej fazie migracji nie można używać klienta systemu Windows Server 2019 lub Windows 10. Użyj narzędzia Robocopy w pośrednim wystąpieniu systemu Windows Server 2016.

Oto podstawowe podejście do migracji:

• Uruchom narzędzie Robocopy z urządzenia NAS, aby zsynchronizować wystąpienie systemu Windows Server.
• Użyj usługi Azure File Sync, aby synchronizować udziały plików platformy Azure z serwera Windows Server.

Uruchom pierwszą kopię lokalną do folderu docelowego systemu Windows Server:

1. Zidentyfikuj pierwszą lokalizację na urządzeniu NAS.
2. Zidentyfikuj odpowiadający folder w instancji systemu Windows Server, który ma już skonfigurowaną usługę Azure File Sync.
3. Uruchom kopię przy użyciu narzędzia Robocopy.

Następujące polecenie Robocopy skopiuje tylko różnice (zaktualizowane pliki i foldery) z magazynu NAS do folderu docelowego systemu Windows Server. Instancja Windows Server następnie zsynchronizuje je z udziałami plików Azure.

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> 

Przełącznik	Znaczenie
/MT:n	Umożliwia uruchomienie Robocopy w trybie wielowątkowym. Wartość domyślna to n 8. Maksymalna liczba wątków to 128. Chociaż duża liczba wątków pomaga usycić dostępną przepustowość, nie oznacza to, że migracja zawsze będzie szybsza z większą liczbą wątków. Testy z usługą Azure Files wskazują, że liczba między 8 a 20 zapewnia zrównoważoną wydajność początkowego procesu kopiowania. Kolejne /MIR uruchomienia są stopniowo dotknięte porównaniem dostępnej przepustowości obliczeniowej i dostępnej przepustowości sieci. W przypadku kolejnych przebiegów staranniej dopasuj liczbę wątków do liczby rdzeni procesora oraz liczby wątków przypadających na każdy rdzeń. Zastanów się, czy trzeba zarezerwować rdzenie dla innych zadań serwera produkcyjnego. Testy w usłudze Azure Files wykazały, że maksymalnie 64 wątki generują dobrą wydajność, ale tylko wtedy, gdy procesory mogą utrzymać je w tym samym czasie.
/R:n	Maksymalna liczba ponownych prób dla pliku, którego nie udało się skopiować przy pierwszej próbie. Narzędzie Robocopy spróbuje n razy przed ostatecznym niepowodzeniem kopiowania pliku w przebiegu. Możesz zoptymalizować wydajność przebiegu: wybierz wartość dwóch lub trzech, jeśli uważasz, że problemy z przekroczeniem limitu czasu spowodowały błędy w przeszłości. Może to być bardziej typowe w przypadku łączy sieci WAN. Jeśli uważasz, że nie udało się skopiować pliku, ponieważ był on aktywnie używany, wybierz brak ponawiania prób lub wartość jeden. Próba ponownie kilka sekund później może nie być wystarczająca do zmiany stanu w użyciu pliku. Użytkownicy lub aplikacje z otwartym plikiem mogą potrzebować jeszcze kilku godzin. W takim przypadku, brak skopiowania pliku i uwzględnienie go w jednym z planowanych przebiegów narzędzia Robocopy może ostatecznie zakończyć się powodzeniem i skutkować pomyślnym skopiowaniem pliku. Pomaga to w szybszym zakończeniu bieżącego procesu, bez wydłużania go przez liczne ponowne próby, które kończą się głównie błędami kopiowania z powodu plików, które są nadal otwarte po przekroczeniu limitu czasu na ponowne próby.
/W:n	Określa czas, przez który narzędzie Robocopy czeka, zanim podejmie próbę skopiowania pliku, który nie został pomyślnie skopiowany podczas poprzedniej próby. n to liczba sekund oczekiwania między ponowną próbą. /W:n jest często używany razem z /R:n.
/B	Uruchamia narzędzie Robocopy w tym samym trybie, którego użyłaby aplikacja do tworzenia kopii zapasowych. Ten przełącznik umożliwia narzędziu Robocopy przenoszenie plików, do których bieżący użytkownik nie ma uprawnień. Przełącznik kopii zapasowej zależy od uruchomienia polecenia Robocopy w konsoli z podwyższonym poziomem uprawnień administratora lub w oknie programu PowerShell. Jeśli używasz Robocopy dla Azure Files, upewnij się, że zamontujesz udział plików Azure, korzystając z klucza dostępu do konta magazynu zamiast tożsamości domeny. Jeśli tego nie zrobisz, komunikaty o błędach mogą nie prowadzić intuicyjnie do rozwiązania problemu.
/MIR	(Odwzorowuje źródło na miejsce docelowe) Pozwala programowi Robocopy kopiować tylko różnice między źródłem a celem. Puste podkatalogi zostaną skopiowane. Elementy (pliki lub foldery), które uległy zmianie lub nie istnieją w miejscu docelowym, zostaną skopiowane. Elementy, które istnieją w miejscu docelowym, ale nie ma ich w źródle, zostaną wyczyszczone (usunięte) z miejsca docelowego. W przypadku korzystania z tego przełącznika dokładnie dopasuj strukturę folderu źródłowego i docelowego. Dopasowanie oznacza skopiowanie z poprawnego poziomu źródła i folderu do pasującego poziomu folderu w obiekcie docelowym. Tylko wtedy tworzenie kopii na zasadzie „nadrobienia zaległości” może zakończyć się powodzeniem. Gdy źródło i docelowy są niezgodne, użycie /MIR doprowadzi do usunięć i ponownych skopiowań na dużą skalę.
/IT	Zapewnia zachowanie wierności w pewnych scenariuszach lustrzanych. Jeśli na przykład plik napotyka zmianę listy ACL i aktualizację atrybutu między dwoma przebiegami narzędzia Robocopy, jest on oznaczony jako ukryty. Bez /IT zmiana listy ACL może zostać pominięta przez Robocopy i nie przeniesiona do lokalizacji docelowej.
/COPY:[copyflags]	Wierność kopii pliku. Wartość domyślna: /COPY:DAT. Flagi kopiowania: D= Dane, A= Atrybuty, T= Znaczniki czasu, S= Zabezpieczenia = Listy ACL (NTFS), O= Informacje o właścicielu, U= Informacje o audytach. W udziale plików platformy Azure nie można przechowywać informacji o inspekcji.
/DCOPY:[copyflags]	Wierność kopii katalogów. Wartość domyślna: /DCOPY:DA. Flagi kopiowania: D= Dane, A= Atrybuty, T= Znaczniki czasu.
/NP	Określa brak wyświetlania postępu kopiowania dla każdego pliku i folderu. Wyświetlanie postępu znacznie obniża wydajność kopiowania.
/NFL	Określa brak rejestrowania nazw plików. Poprawia wydajność kopiowania.
/NDL	Określa, że nazwy katalogów nie są rejestrowane. Poprawia wydajność kopiowania.
/XD	Określa katalogi, które mają być wykluczone. Podczas uruchamiania narzędzia Robocopy w katalogu głównym woluminu rozważ wykluczenie ukrytego katalogu System Volume Information. Jeśli są używane zgodnie z przeznaczeniem, wszystkie zawarte w nich informacje są specyficzne dla konkretnego wolumenu w tym systemie i można je odbudować na żądanie. Kopiowanie tych informacji nie będzie przydatne w chmurze ani kiedy dane są kiedykolwiek kopiowane z powrotem do innego woluminu systemu Windows. Pozostawienie tej zawartości nie powinno być traktowane jako utrata danych.
/UNILOG:<file name>	Zapisuje status w pliku dziennika jako Unicode. (Zastępuje istniejący dziennik).
/L	Tylko w przypadku uruchomienia testowego pliki mają być wyświetlane tylko. Nie zostaną one skopiowane, usunięte ani oznaczone sygnaturą czasową. Często używane z /TEE do danych wyjściowych konsoli. Może być konieczne usunięcie flag z przykładowego skryptu, takiego jak /NP, /NFLi /NDL, w celu uzyskania prawidłowych udokumentowanych wyników testu.
/LFSM	Tylko dla celów z pamięcią warstwową. Nieobsługiwane jest to, gdy miejsce docelowe jest zdalnym udziałem SMB. Określa, że narzędzie Robocopy działa w trybie małej ilości miejsca. Ten przełącznik jest przydatny tylko dla docelowych urządzeń z warstwowym magazynowaniem, które mogą wyczerpać lokalną pojemność przed zakończeniem działania narzędzia Robocopy. Został on dodany specjalnie do użytku z miejscem docelowym z obsługą warstw w chmurze usługi Azure File Sync. Można go używać niezależnie od usługi Azure File Sync. W tym trybie działanie narzędzia Robocopy zostanie wstrzymane za każdym razem, gdy skopiowanie pliku spowodowałoby przekroczenie wartości progowej dla wolnego miejsca na woluminie docelowym. Tę wartość można określić za pomocą /LFSM:n formularza flagi. Parametr n jest określony w bazie 2: nKB, nMBlub nGB. Jeśli /LFSM określono wartość bez jawnej podłogi, podłoga jest ustawiona na 10 procent rozmiaru woluminu docelowego. Tryb małej ilości wolnego miejsca nie jest zgodny z elementami /MT, /EFSRAWlub /ZB. Dodano obsługę dla /B w Windows Server 2022. Zobacz sekcję Windows Server 2022 i RoboCopy LFSM poniżej, aby uzyskać więcej informacji, w tym szczegółowe informacje na temat powiązanej usterki i obejścia.
/Z	Używaj ostrożnie Kopiuje pliki w trybie ponownego uruchamiania. Ten przełącznik jest zalecany tylko w niestabilnym środowisku sieciowym. Znacznie zmniejsza wydajność kopiowania z powodu dodatkowego rejestrowania.
/ZB	Należy ostrożnie używać trybu ponownego uruchamiania. W przypadku odmowy dostępu ta opcja używa trybu tworzenia kopii zapasowej. Ta opcja znacznie zmniejsza wydajność kopiowania z powodu tworzenia punktów kontrolnych.

Ważne

Zalecamy używanie systemu Windows Server 2022. W przypadku korzystania z systemu Windows Server 2019 upewnij się, że zainstalowano najnowszą wersję poprawki lub co najmniej KB5005103 aktualizacji systemu operacyjnego. Zawiera ważne poprawki dla niektórych scenariuszy narzędzia Robocopy.

Jeśli aprowizowaliśmy mniej miejsca w wystąpieniu systemu Windows Server niż pliki używane na urządzeniu NAS, skonfigurowano obsługę warstw w chmurze. W miarę jak lokalny wolumin systemu Windows Server staje się pełny, tiering w chmurze zacznie działać i przenosić pliki, które zostały już pomyślnie zsynchronizowane. Obsługa warstw w chmurze spowoduje wygenerowanie wystarczającej ilości miejsca, aby kontynuować kopiowanie z urządzenia NAS. Sprawdzanie warstw w chmurze co godzinę w celu określenia, co zostało zsynchronizowane, i zwolnienia miejsca na dysku, aby osiągnąć 99 procent wolnego miejsca na woluminie.

Narzędzie Robocopy może wymagać przeniesienia większej liczby plików, niż można przechowywać lokalnie w wystąpieniu systemu Windows Server. Możesz oczekiwać, że narzędzie Robocopy będzie działać szybciej niż usługa Azure File Sync może przesłać twoje pliki i przenieść je z lokalnego woluminu do odpowiedniej warstwy. W takiej sytuacji narzędzie Robocopy zakończy się niepowodzeniem. Zalecamy pracę z udziałami w sekwencji, która zapobiega takiemu scenariuszowi. Na przykład przenieś tylko te udziały, które mieszczą się w dostępnej przestrzeni na instancji systemu Windows Server. Unikaj uruchamiania zadań Robocopy dla wszystkich udziałów w tym samym czasie. Dobrą wiadomością jest to, że /MIR przełącznik zapewni, że tylko różnice są przenoszone. Po przeniesieniu zmiany ponownie uruchomione zadanie nie będzie musiało przenosić pliku.

Wykonaj migrację jednorazową

Po uruchomieniu polecenia Robocopy po raz pierwszy użytkownicy i aplikacje będą nadal uzyskiwać dostęp do plików na serwerze NAS i potencjalnie je zmieniać. Narzędzie Robocopy przetworzy katalog, a następnie przejdzie do następnego. Użytkownik na serwerze NAS może następnie dodać, zmienić lub usunąć plik w pierwszym katalogu, który nie zostanie przetworzony podczas bieżącego uruchomienia narzędzia Robocopy. To zachowanie jest oczekiwane.

Pierwszy etap polega na przeniesieniu większości przetworzonych danych do instancji Windows Server oraz do chmury za pomocą usługi Azure File Sync. Ta pierwsza kopia może zająć dużo czasu, w zależności od:

• Przepustowość wysyłania.
• Szybkość sieci lokalnej i stopień, w jakim liczba wątków Robocopy jest do niej optymalnie dopasowana.
• Liczba elementów (plików i folderów), które należy przetworzyć za pomocą narzędzia Robocopy i usługi Azure File Sync.

Po zakończeniu początkowego przebiegu ponownie uruchom polecenie.

Robocopy zakończy się szybciej przy drugim uruchomieniu go dla zasobu. Musi transportować tylko zmiany, które wystąpiły od czasu ostatniego uruchomienia. Można uruchamiać powtarzające się zadania dla tego samego udziału.

Jeśli akceptujesz przestój, musisz usunąć dostęp użytkowników do udziałów opartych na NAS. Można to zrobić w dowolny sposób, co uniemożliwia użytkownikom zmianę struktury plików i folderów oraz zawartości. Można na przykład wskazać przestrzeń nazw systemu plików DFS do lokalizacji, która nie istnieje lub zmienić główne listy ACL w udziale.

Uruchom narzędzie Robocopy po raz ostatni. Zostaną wykryte wszelkie zmiany, które zostały pominięte. Czas wykonywania tego ostatniego kroku zależy od szybkości skanowania za pomocą narzędzia Robocopy. Możesz oszacować czas (który jest równy przestojowi), mierząc długość poprzedniego przebiegu.

Utwórz udostępnienie w folderze na serwerze Windows i ewentualnie dostosuj wdrożenie systemu plików DFS-N, aby na niego wskazywało. Pamiętaj, aby ustawić te same uprawnienia na poziomie udziału, które są na twoim udziale SMB w NAS. Jeśli masz serwer NAS klasy korporacyjnej połączony z domeną, identyfikatory SID użytkownika będą automatycznie zgodne, ponieważ użytkownicy znajdują się w usłudze Active Directory, a Robocopy kopiuje pliki i metadane z pełną dokładnością. Jeśli używasz użytkowników lokalnych na serwerze NAS, musisz:

• Utwórz ponownie tych użytkowników jako użytkowników lokalnych systemu Windows Server.
• Zmapuj istniejące identyfikatory SID przeniesione przez Robocopy do Twojego wystąpienia systemu Windows Server na identyfikatory SID nowych lokalnych użytkowników systemu Windows Server.

Zakończono migrację udziału lub grupy udziałów do wspólnego katalogu głównego lub woluminu (w zależności od mapowania z fazy 1).

Możesz spróbować uruchomić kilka z tych kopii równolegle. Zalecamy przetwarzać jeden udostępniony zakres plików na platformie Azure jednocześnie.

Przestarzała opcja: "transfer danych w trybie offline"

Przed wydaniem agenta usługi Azure File Sync w wersji 13 integracja urządzenia Data Box została wykonana za pośrednictwem procesu o nazwie "transfer danych w trybie offline". Ten proces jest przestarzały i nie można już utworzyć punktu końcowego serwera w trybie "transferu danych offline". Agent w wersji 13 został zastąpiony znacznie prostszą i szybszą procedurą opisaną w tym artykule.

Rozwiązywanie problemów

Najczęstszym problemem jest niepowodzenie polecenia Robocopy z komunikatem "Wolumin pełny" po stronie systemu Windows Server. Warstwowanie chmury działa raz na godzinę, aby przenieść zawartość z lokalnego dysku Windows Server, który został zsynchronizowany. Jego celem jest osiągnięcie 99 procent wolnego miejsca na woluminie.

Niech postęp synchronizacji i warstwowanie chmury zwolnią miejsce na dysku. Możesz zauważyć, że w Eksplorator plików w wystąpieniu systemu Windows Server.

Gdy wystąpienie systemu Windows Server ma wystarczającą ilość dostępnej pojemności, uruchom ponownie polecenie, aby rozwiązać problem. Nic się nie łamie w tej sytuacji. Możesz iść do przodu z ufnością. Niedogodności związane z ponownym uruchomieniem polecenia są jedyną konsekwencją.

Aby rozwiązać problemy z usługą Azure File Sync, zobacz artykuł wymieniony w następnej sekcji.

Następne kroki

Poniższe artykuły ułatwią zrozumienie zaawansowanych opcji i najlepszych rozwiązań dotyczących usług Azure Files i Azure File Sync.

• Omówienie migracji
• Planowanie wdrażania usługi Azure File Sync
• Utwórz udział plików
• Rozwiązywanie problemów z usługą Azure File Sync