Migrace zařízení StorSimple 1200 do Synchronizace souborů Azure

StorSimple 1200 series je virtuální zařízení, které běží v místním datacentru. Data z tohoto zařízení je možné migrovat do Synchronizace souborů Azure prostředí. Synchronizace souborů Azure je výchozí a strategická dlouhodobá služba Azure, do které je možné migrovat zařízení StorSimple. Tento článek obsahuje potřebné základní znalosti a kroky migrace pro úspěšnou migraci do Synchronizace souborů Azure.

Poznámka

Služba StorSimple (včetně Správce zařízení StorSimple pro řady 8000 a 1200 a StorSimple Data Manager) dosáhla konce podpory. Konec podpory storSimple byl publikován v roce 2019 na stránkách Microsoft LifeCycle Policy a Azure Communications . Další oznámení byla odeslána e-mailem a zveřejněny na Azure Portal a v přehledu StorSimple. Další podrobnosti vám poskytne podpora Microsoftu.

Platí pro

Typ sdílené složky	SMB	NFS
Sdílené složky úrovně Standard (GPv2), LRS/ZRS
Sdílené složky úrovně Standard (GPv2), GRS/GZRS
Sdílené složky úrovně Premium (FileStorage), LRS/ZRS

Synchronizace souborů Azure

Synchronizace souborů Azure je cloudová služba Microsoftu založená na dvou hlavních komponentách:

• Synchronizace souborů a vrstvení cloudu.
• Sdílené složky jako nativní úložiště v Azure, ke kterému je možné přistupovat přes několik protokolů, jako je SMB a soubor REST. Sdílená složka Azure je srovnatelná se sdílenou složkou na Windows Serveru, kterou můžete nativně připojit jako síťovou jednotku. Podporuje důležité aspekty věrnosti souborů, jako jsou atributy, oprávnění a časová razítka. Na rozdíl od StorSimple se k interpretaci souborů a složek uložených v cloudu nevyžaduje žádná aplikace ani služba. Ideální a nejflexibilnější přístup k ukládání dat souborového serveru pro obecné účely a některých dat aplikací v cloudu.

Tento článek se zaměřuje na kroky migrace. Pokud se před migrací chcete dozvědět více o Synchronizace souborů Azure, doporučujeme vám následující články:

• Synchronizace souborů Azure – přehled
• Synchronizace souborů Azure – průvodce nasazením

Cíle migrace

Cílem je zaručit integritu produkčních dat a zaručit dostupnost. To druhé vyžaduje minimální prostoje, aby se vešly do nebo jen mírně překročily pravidelná období údržby.

Cesta migrace StorSimple 1200 do Synchronizace souborů Azure

Ke spuštění agenta Synchronizace souborů Azure se vyžaduje místní Windows Server. Windows Server může být minimálně server 2012R2, ale v ideálním případě je to Windows Server 2019.

Existuje mnoho alternativních cest migrace a vytvořilo by příliš dlouhý článek, který by všechny zdokumentoval a ilustroval, proč nesou riziko nebo nevýhody v rámci trasy, kterou doporučujeme v tomto článku jako osvědčený postup.

Předchozí obrázek znázorňuje kroky, které odpovídají oddílům tohoto článku.

Krok 1: Zřízení místního Windows Serveru a úložiště

1. Vytvořte Windows Server 2019 (minimálně 2012R2) jako virtuální počítač nebo fyzický server. Podporuje se také cluster windows serveru s podporou převzetí služeb při selhání.
2. Zřízení nebo přidání úložiště s přímým přístupem (DAS v porovnání s NAS, které se nepodporuje). Velikost úložiště Windows Serveru musí být stejná nebo větší než velikost dostupné kapacity vašeho virtuálního zařízení StorSimple 1200.

Krok 2: Konfigurace úložiště Windows Serveru

V tomto kroku namapujete strukturu úložiště StorSimple (svazky a sdílené složky) na strukturu úložiště Windows Serveru. Pokud plánujete provádět změny ve struktuře úložiště, což znamená počet svazků, přidružení datových složek ke svazkům nebo strukturu podsložek nad nebo pod vašimi aktuálními sdílenými složkami SMB/NFS, je teď čas vzít tyto změny v úvahu. Změna struktury souborů a složek po konfiguraci Synchronizace souborů Azure je těžkopádná a je potřeba se jim vyhnout. Tento článek předpokládá, že mapujete 1:1, takže při postupu v tomto článku musíte vzít změny mapování v úvahu.

• Žádná z vašich produkčních dat by neměla končit na systémovém svazku Windows Serveru. Vrstvení cloudu se na systémových svazcích nepodporuje. Tato funkce je však vyžadována pro migraci i pro průběžné operace jako náhradu StorSimple.
• Na Windows Serveru zřiďte stejný počet svazků, jaký máte na virtuálním zařízení StorSimple 1200.
• Nakonfigurujte všechny role, funkce a nastavení Windows Serveru, které potřebujete. Doporučujeme, abyste se přihlásili k aktualizacím Windows Serveru, aby byl váš operační systém v bezpečí a v aktualizovaném stavu. Podobně doporučujeme, abyste se přihlásili ke službě Microsoft Update, aby byly aplikace Microsoftu aktuální, včetně agenta Synchronizace souborů Azure.
• Před čtením následujících kroků nekonfigurujte žádné složky ani sdílené složky.

Krok 3: Nasazení prvního Synchronizace souborů Azure cloudového prostředku

K dokončení tohoto kroku potřebujete přihlašovací údaje k předplatnému Azure.

Základní prostředek, který se má nakonfigurovat pro Synchronizace souborů Azure, se nazývá služba synchronizace úložiště. Doporučujeme nasadit jenom jeden pro všechny servery, které teď nebo v budoucnu synchronizují stejnou sadu souborů. Více služeb synchronizace úložiště vytvořte jenom v případě, že máte odlišné sady serverů, které si nikdy nesmí vyměňovat data. Můžete mít například servery, které nikdy nesmí synchronizovat stejnou sdílenou složku Azure. V opačném případě je osvědčeným postupem použití jedné služby synchronizace úložiště.

Zvolte oblast Azure pro službu synchronizace úložiště, která je blízko vaší polohy. Všechny ostatní cloudové prostředky musí být nasazené ve stejné oblasti. Pro zjednodušení správy vytvořte ve svém předplatném novou skupinu prostředků, ve které jsou prostředky synchronizace a úložiště.

Další informace najdete v části o nasazení služby synchronizace úložiště v článku o nasazení Synchronizace souborů Azure. Postupujte podle této části článku. V pozdějších krocích budou odkazy na další části článku.

Krok 4: Spárování místního svazku a struktury složek s Synchronizace souborů Azure a prostředků sdílené složky Azure

V tomto kroku určíte, kolik sdílených složek Azure potřebujete. Jedna instance Windows Serveru (nebo cluster) může synchronizovat až 30 sdílených složek Azure.

Na svazcích můžete mít více složek, které aktuálně sdílíte místně jako sdílené složky SMB pro uživatele a aplikace. Nejjednodušší způsob, jak si tento scénář představit, je představit si místní sdílenou složku, která mapuje 1:1 na sdílenou složku Azure. Pokud máte dostatečně malý počet sdílených složek, které jsou nižší než 30 pro jednu instanci Windows Serveru, doporučujeme mapování 1:1.

Pokud máte více než 30 sdílených složek, je mapování místní sdílené složky 1:1 na sdílenou složku Azure často zbytečné. Zvažte následující možnosti.

Sdílení seskupení

Pokud má například vaše oddělení lidských zdrojů 15 sdílených složek, můžete zvážit uložení všech dat lidských zdrojů do jedné sdílené složky Azure. Uložení více místních sdílených složek do jedné sdílené složky Azure vám nebrání ve vytvoření obvyklých 15 sdílených složek SMB v místní instanci Windows Serveru. Znamená to pouze, že uspořádáte kořenové složky těchto 15 sdílených složek jako podsložky pod společnou složku. Pak tuto společnou složku synchronizujete se sdílenou složkou Azure. Tímto způsobem bude pro tuto skupinu místních sdílených složek potřeba jenom jedna sdílená složka Azure v cloudu.

Synchronizace svazků

Synchronizace souborů Azure podporuje synchronizaci kořenového adresáře svazku se sdílenou složkou Azure. Pokud synchronizujete kořenový adresář svazku, všechny podsložky a soubory se přesunou do stejné sdílené složky Azure.

Synchronizace kořenového adresáře svazku není vždy nejlepší volbou. Synchronizace více umístění má výhody. Tento postup například pomůže udržet nižší počet položek na rozsah synchronizace. Testujeme sdílené složky Azure a Synchronizace souborů Azure se 100 miliony položek (soubory a složky) na sdílenou složku. Osvědčeným postupem je ale pokusit se udržet číslo pod 20 miliony nebo 30 miliony v jedné akcii. Nastavení Synchronizace souborů Azure s nižším počtem položek není výhodné jenom pro synchronizaci souborů. Nižší počet položek také prospívá scénářům, jako jsou tyto:

• Počáteční kontrola cloudového obsahu může být dokončena rychleji, což snižuje čekání na zobrazení oboru názvů na serveru povoleném pro Synchronizace souborů Azure.
• Obnovení ze snímku sdílené složky Azure na straně cloudu bude rychlejší.
• Zotavení po havárii místního serveru může výrazně zrychlit.
• Změny provedené přímo ve sdílené složce Azure (mimo synchronizaci) je možné detekovat a synchronizovat rychleji.

Tip

Pokud nevíte, kolik souborů a složek máte, podívejte se na nástroj TreeSize od společnosti JAM Software GmbH.

Strukturovaný přístup k mapě nasazení

Před nasazením cloudového úložiště v pozdějším kroku je důležité vytvořit mapu mezi místními složkami a sdílenými složkami Azure. Toto mapování bude informovat o tom, kolik a jaké Synchronizace souborů Azure prostředků skupiny synchronizace zřídíte. Skupina synchronizace prováže sdílenou složku Azure a složku na vašem serveru a vytvoří synchronizační připojení.

Pokud se chcete rozhodnout, kolik sdílených složek Azure potřebujete, projděte si následující omezení a osvědčené postupy. To vám pomůže optimalizovat mapu.

• Server, na kterém je nainstalovaný agent Synchronizace souborů Azure, se může synchronizovat až s 30 sdílenými složkami Azure.

• Sdílená složka Azure se nasadí v účtu úložiště. Díky tomuto uspořádání je účet úložiště cílem škálování pro čísla výkonu, jako jsou IOPS a propustnost.

  Při nasazování sdílených složek Azure věnujte pozornost omezením IOPS účtu úložiště. V ideálním případě byste měli namapovat sdílené složky v poměru 1:1 k účtům úložiště. To ale nemusí být vždy možné kvůli různým omezením a omezením, a to jak z vaší organizace, tak z Azure. Pokud není možné mít nasazenou jenom jednu sdílenou složku v jednom účtu úložiště, zvažte, které sdílené složky budou vysoce aktivní a které budou méně aktivní, abyste zajistili, že se nejžhavější sdílené složky nebudou dát dohromady do stejného účtu úložiště.

  Pokud plánujete do Azure přesunout aplikaci, která bude sdílenou složku Azure používat nativně, možná budete potřebovat vyšší výkon sdílené složky Azure. Pokud je tento typ použití možné i v budoucnu, je nejlepší vytvořit jednu standardní sdílenou složku Azure ve vlastním účtu úložiště.

• Platí limit 250 účtů úložiště na předplatné na oblast Azure.

Tip

S ohledem na tyto informace je často nutné seskupit několik složek nejvyšší úrovně na svazcích do nového společného kořenového adresáře. Potom tento nový kořenový adresář a všechny složky, které jste do něj seskupili, synchronizujete do jedné sdílené složky Azure. Tato technika umožňuje zůstat v limitu 30 synchronizací sdílených složek Azure na server.

Toto seskupení v rámci společného kořenového adresáře nemá vliv na přístup k vašim datům. Seznamy ACL zůstanou tak, jak jsou. Stačí upravit všechny cesty ke sdíleným složkám (jako jsou sdílené složky SMB nebo NFS), které můžete mít ve složkách místního serveru, které jste teď změnili na společný kořenový adresář. Nic jiného se nemění.

Důležité

Nejdůležitějším vektorem škálování pro Synchronizace souborů Azure je počet položek (souborů a složek), které je potřeba synchronizovat. Další podrobnosti najdete v tématu cíle škálování Synchronizace souborů Azure.

Osvědčeným postupem je udržovat nízký počet položek na rozsah synchronizace. To je důležitý faktor, který je potřeba vzít v úvahu při mapování složek na sdílené složky Azure. Synchronizace souborů Azure se testuje s 100 miliony položek (souborů a složek) na sdílenou složku. Často je ale nejlepší ponechat počet položek pod 20 miliony nebo 30 miliony v jedné sdílené složce. Pokud začnete tato čísla překračovat, rozdělte obor názvů do několika sdílených složek. Pokud zůstanete zhruba pod těmito čísly, můžete i nadále seskupit několik místních sdílených složek do stejné sdílené složky Azure. Tento postup vám poskytne prostor k růstu.

Je možné, že ve vaší situaci se sada složek může logicky synchronizovat se stejnou sdílenou složkou Azure (pomocí nového přístupu ke společné kořenové složce, který jsme zmínili výše). Přesto ale může být lepší složky znovu seskupit tak, aby se synchronizovaly do dvou místo jedné sdílené složky Azure. Tento přístup můžete použít k zachování vyváženého počtu souborů a složek na sdílenou složku na serveru. Můžete také rozdělit místní sdílené složky a synchronizovat je mezi více místních serverů a přidat tak možnost synchronizace s 30 dalšími sdílenými složkami Azure na jeden další server.

Běžné scénáře a důležité informace o synchronizaci souborů

#	Scénář synchronizace	Podporuje se	Důležité informace (nebo omezení)	Řešení (nebo alternativní řešení)
1	Souborový server s více disky/svazky a více sdílenými složkami do stejné cílové sdílené složky Azure (konsolidace)	No	Cílová sdílená složka Azure (koncový bod cloudu) podporuje synchronizaci pouze s jednou skupinou synchronizace. Skupina synchronizace podporuje pouze jeden koncový bod serveru na registrovaný server.	1) Začněte synchronizací jednoho disku (jeho kořenového svazku) do cílové sdílené složky Azure. S požadavky na úložiště v místním prostředí vám pomůže začít s největším diskem nebo svazkem. Nakonfigurujte vrstvení cloudu tak, aby vrstvila všechna data do cloudu, a tím uvolnila místo na disku souborového serveru. Přesuňte data z jiných svazků nebo sdílených složek do aktuálního svazku, který se synchronizuje. Pokračujte v jednotlivých krocích, dokud se všechna data nebudou vrstvit do cloudu nebo migrovat. 2) Cílení na jeden kořenový svazek (disk) najednou. Pomocí vrstvení cloudu můžete vrstvit všechna data tak, aby cílil na sdílenou složku Azure. Odeberte koncový bod serveru ze skupiny synchronizace, znovu vytvořte koncový bod s dalším kořenovým svazkem nebo diskem, proveďte synchronizaci a opakujte proces. Poznámka: Může se vyžadovat opětovná instalace agenta. 3) Doporučujeme používat více cílových sdílených složek Azure (stejný nebo jiný účet úložiště v závislosti na požadavcích na výkon).
2	Souborový server s jedním svazkem a více sdílenými složkami do stejné cílové sdílené složky Azure (konsolidace)	Yes	Na zaregistrovaný server se nemůže synchronizovat více koncových bodů serveru se stejnou cílovou sdílenou složkou Azure (stejné jako výše).	Synchronizujte kořen svazku, který obsahuje více sdílených složek nebo složek nejvyšší úrovně. Další informace najdete v tématu Koncept seskupení sdílení a Synchronizace svazků .
3	Souborový server s více sdílenými složkami nebo svazky do několika sdílených složek Azure v rámci jednoho účtu úložiště (mapování sdílené složky 1:1)	Yes	Jedna instance Windows Serveru (nebo cluster) může synchronizovat až 30 sdílených složek Azure. Účet úložiště je cíl škálování pro zvýšení výkonu. IOPS a propustnost se sdílejí napříč sdílenými složkami. Udržujte počet položek na skupinu synchronizace v rozsahu 100 milionů položek (souborů a složek) na sdílenou složku. V ideálním případě je nejlepší zůstat pod 20 nebo 30 miliony na akcii.	1) Použijte více skupin synchronizace (počet skupin synchronizace = počet sdílených složek Azure, se které se mají synchronizovat). 2) V tomto scénáři je možné synchronizovat pouze 30 sdílených složek najednou. Pokud máte na daném souborovém serveru více než 30 sdílených složek, použijte koncept seskupení sdílených složek a synchronizaci svazků , abyste snížili počet kořenových složek nebo složek nejvyšší úrovně ve zdroji. 3) Použijte další Synchronizace souborů servery v místním prostředí a rozdělte nebo přesuňte data na tyto servery, abyste mohli obejít omezení zdrojového serveru Windows.
4	Souborový server s více sdílenými složkami nebo svazky do více sdílených složek Azure v rámci jiného účtu úložiště (mapování sdílených složek 1:1)	Yes	Jedna instance Windows Serveru (nebo cluster) může synchronizovat až 30 sdílených složek Azure (stejný nebo jiný účet úložiště). Udržujte počet položek na skupinu synchronizace v rozsahu 100 milionů položek (souborů a složek) na sdílenou složku. V ideálním případě je nejlepší zůstat pod 20 nebo 30 miliony na akcii.	Stejný přístup jako výše
5	Více souborových serverů s jedním (kořenovým svazkem nebo sdílenou složkou) do stejné cílové sdílené složky Azure (konsolidace)	No	Skupina synchronizace nemůže používat koncový bod cloudu (sdílenou složku Azure), který je už nakonfigurovaný v jiné skupině synchronizace. I když skupina synchronizace může mít koncové body serveru na různých souborových serverech, soubory nelze odlišit.	Postupujte podle pokynů ve scénáři č. 1 výše s dalšími aspekty cílení na jeden souborový server najednou.

Vytvoření tabulky mapování

Pomocí předchozích informací můžete určit, kolik sdílených složek Azure potřebujete a které části vašich stávajících dat skončí ve které sdílené složce Azure.

Vytvořte tabulku, která zaznamenává vaše myšlenky, abyste na ni mohli odkazovat, když budete potřebovat. Udržování přehledu je důležité, protože při zřizování mnoha prostředků Azure najednou může být snadné ztratit podrobnosti o plánu mapování. Stáhněte si následující excelový soubor, který použijete jako šablonu, která vám pomůže vytvořit mapování.

Stáhněte si šablonu mapování oboru názvů.

Krok 5: Zřízení sdílených složek Azure

Sdílená složka Azure je uložená v cloudu v účtu úložiště Azure. Tady platí další aspekty výkonu.

Pokud máte vysoce aktivní sdílené složky (sdílené složky používané mnoha uživateli nebo aplikacemi), můžou dvě sdílené složky Azure dosáhnout limitu výkonu účtu úložiště.

Osvědčeným postupem je nasadit účty úložiště s jednou sdílenou složkou. Pokud máte archivní sdílené složky nebo u nich očekáváte nízkou každodenní aktivitu, můžete do stejného účtu úložiště sdružovat více sdílených složek Azure.

Tyto aspekty se týkají spíše přímého přístupu ke cloudu (prostřednictvím virtuálního počítače Azure) než Synchronizace souborů Azure. Pokud u těchto sdílených složek plánujete používat jenom Synchronizace souborů Azure, je seskupení několika do jednoho účtu úložiště Azure v pořádku.

Pokud jste vytvořili seznam sdílených složek, měli byste namapovat každou sdílenou složku na účet úložiště, ve který se bude nacházet.

V předchozí fázi jste určili odpovídající počet sdílených složek. V tomto kroku máte namapování účtů úložiště na sdílené složky. Teď nasaďte odpovídající počet účtů úložiště Azure s odpovídajícím počtem sdílených složek Azure.

Ujistěte se, že oblast každého z vašich účtů úložiště je stejná a odpovídá oblasti prostředku služby synchronizace úložiště, který jste už nasadili.

Upozornění

Pokud vytvoříte sdílenou složku Azure s limitem 100 TiB, může tato sdílená složka používat pouze možnosti redundance místně redundantního úložiště nebo zónově redundantního úložiště. Před použitím sdílených složek 100 TiB zvažte své potřeby redundance úložiště.

Sdílené složky Azure se ve výchozím nastavení stále vytvářejí s limitem 5 TiB. Postupujte podle kroků v tématu Vytvoření sdílené složky Azure a vytvořte velkou sdílenou složku.

Dalším aspektem při nasazování účtu úložiště je redundance služby Azure Storage. Viz Možnosti redundance služby Azure Storage.

Důležité jsou také názvy vašich prostředků. Pokud například seskupíte více sdílených složek pro personální oddělení do účtu úložiště Azure, měli byste účet úložiště pojmenovat odpovídajícím způsobem. Podobně platí, že při pojmenování sdílených složek Azure byste měli používat názvy podobné těm, které se používají pro jejich místní protějšky.

Nastavení účtu úložiště

Pro účet úložiště můžete provést řadu konfigurací. Pro konfigurace účtu úložiště byste měli použít následující kontrolní seznam. Po dokončení migrace můžete například změnit konfiguraci sítě.

• Velké sdílené složky: Povoleno – Velké sdílené složky zlepšují výkon a umožňují ukládat do sdílené složky až 100 TiB.
• Brána firewall a virtuální sítě: Zakázáno – nekonfigurujte žádná omezení IP adres ani omezte přístup k účtu úložiště na konkrétní virtuální síť. Během migrace se použije veřejný koncový bod účtu úložiště. Musí být povolené všechny IP adresy z virtuálních počítačů Azure. Po migraci je nejlepší nakonfigurovat všechna pravidla brány firewall pro účet úložiště.
• Privátní koncové body: Podporované – Můžete povolit privátní koncové body, ale veřejný koncový bod se použije k migraci a musí zůstat dostupný.

Krok 6: Konfigurace cílových složek Windows Serveru

V předchozích krocích jste zvážili všechny aspekty, které určují komponenty synchronizačních topologií. Teď je čas připravit server na příjem souborů k nahrání.

Vytvořte všechny složky, které se budou synchronizovat s vlastní sdílenou složkou Azure. Je důležité, abyste postupovali podle struktury složek, kterou jste zdokumentovali dříve. Pokud jste se například rozhodli synchronizovat několik místních sdílených složek SMB do jedné sdílené složky Azure, musíte je umístit do společné kořenové složky na svazku. Na svazku teď vytvořte tuto cílovou kořenovou složku.

Počet zřízených sdílených složek Azure by měl odpovídat počtu složek, které jste vytvořili v tomto kroku, a počtu svazků, které budete synchronizovat na kořenové úrovni.

Krok 7: Nasazení agenta Synchronizace souborů Azure

V této části nainstalujete agenta Synchronizace souborů Azure na instanci Systému Windows Server.

Průvodce nasazením vysvětluje, že je potřeba vypnout konfiguraci rozšířeného zabezpečení aplikace Internet Explorer. Toto bezpečnostní opatření se nevztahuje na Synchronizace souborů Azure. Když ho vypnete, můžete se bez problémů ověřit v Azure.

Otevřete PowerShell. Pomocí následujících příkazů nainstalujte požadované moduly PowerShellu. Po zobrazení výzvy nezapomeňte nainstalovat úplný modul a zprostředkovatele NuGet.

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

Pokud máte nějaké problémy s připojením k internetu ze serveru, je čas je vyřešit. Synchronizace souborů Azure používá jakékoli dostupné síťové připojení k internetu. Podporuje se také vyžadování připojení proxy serveru k internetu. Teď můžete buď nakonfigurovat proxy server na celém počítači, nebo během instalace agenta určit proxy server, který bude používat jenom Synchronizace souborů Azure.

Pokud konfigurace proxy serveru znamená, že potřebujete otevřít brány firewall pro server, může pro vás být tento přístup přijatelný. Na konci instalace serveru po dokončení registrace serveru se v sestavě připojení k síti zobrazí přesné adresy URL koncových bodů v Azure, se kterými Synchronizace souborů Azure musí komunikovat pro oblast, kterou jste vybrali. V sestavě se také dozvíte, proč je potřeba komunikovat. Sestavu můžete použít k uzamčení bran firewall kolem serveru na konkrétní adresy URL.

Můžete také použít konzervativnější přístup, při kterém neotevřete brány firewall na šířku. Místo toho můžete omezit komunikaci serveru s obory názvů DNS vyšší úrovně. Další informace najdete v tématu Synchronizace souborů Azure nastavení proxy serveru a brány firewall. Postupujte podle vlastních osvědčených postupů pro sítě.

Na konci průvodce instalací serveru se otevře průvodce registrací serveru. Zaregistrujte server k prostředku Azure služby synchronizace úložiště z dřívějšího data.

Tyto kroky jsou podrobněji popsané v průvodci nasazením, který obsahuje moduly PowerShellu, které byste měli nainstalovat jako první: Synchronizace souborů Azure instalaci agenta.

Použijte nejnovějšího agenta. Můžete si ho stáhnout z webu Stažení softwaru: Synchronizace souborů Azure Agenta.

Po úspěšné instalaci a registraci serveru můžete potvrdit, že jste tento krok úspěšně dokončili. V Azure Portal přejděte k prostředku služby synchronizace úložiště. V nabídce vlevo přejděte na Registrované servery. Zobrazí se tam váš server.

Krok 8: Konfigurace synchronizace

Tento krok spojuje všechny prostředky a složky, které jste v instanci Windows Serveru nastavili během předchozích kroků.

1. Přihlaste se k webu Azure Portal.
2. Vyhledejte prostředek služby synchronizace úložiště.
3. Vytvořte novou synchronizační skupinu v rámci prostředku služby synchronizace úložiště pro každou sdílenou složku Azure. V Synchronizace souborů Azure terminologii se sdílená složka Azure stane koncovým bodem cloudu v topologii synchronizace, kterou popisujete vytvořením skupiny synchronizace. Když vytváříte skupinu synchronizace, dejte jí známý název, abyste poznali, která sada souborů se tam synchronizuje. Ujistěte se, že odkazujete na sdílenou složku Azure s odpovídajícím názvem.
4. Po vytvoření skupiny synchronizace se v seznamu skupin synchronizace zobrazí řádek pro ni. Výběrem názvu (odkazu) zobrazte obsah skupiny synchronizace. Sdílenou složku Azure uvidíte v části Koncové body cloudu.
5. Vyhledejte tlačítko Přidat koncový bod serveru . Složka na místním serveru, kterou jste zřídili, se stane cestou pro tento koncový bod serveru.

Upozornění

Nezapomeňte zapnout vrstvení cloudu! To je nutné, pokud váš místní server nemá dostatek místa pro uložení celkové velikosti dat v cloudovém úložišti StorSimple. Nastavte zásady vrstvení dočasně pro migraci na 99 % volného místa svazku.

Opakujte kroky vytvoření skupiny synchronizace a přidání odpovídající složky serveru jako koncového bodu serveru pro všechny sdílené složky Azure / umístění serverů, které je potřeba nakonfigurovat pro synchronizaci.

Krok 9: Kopírování souborů

Základním přístupem k migraci je RoboCopy z virtuálního zařízení StorSimple na Windows Server a Synchronizace souborů Azure do sdílených složek Azure.

Spusťte první místní kopii do cílové složky Windows Serveru:

• Identifikujte první umístění na virtuálním zařízení StorSimple.
• Identifikujte odpovídající složku na Windows Serveru, na které už jsou nakonfigurované Synchronizace souborů Azure.
• Spusťte kopírování pomocí nástroje RoboCopy.

Následující příkaz RoboCopy stáhne soubory z úložiště Azure StorSimple do místního StorSimple StorSimple a pak je přesune do cílové složky Windows Serveru. Windows Server ho synchronizuje se sdílenými složkami Azure. Jakmile se místní svazek Windows Serveru zaplní, spustí se vrstvení cloudu a vrství se soubory, které se už úspěšně synchronizovaly. Vrstvení cloudu vygeneruje dostatek místa pro pokračování kopírování z virtuálního zařízení StorSimple. Vrstvení cloudu jednou za hodinu zkontroluje, co se synchronizovalo, a uvolní místo na disku, aby se dosáhlo 99% volného místa na svazku.

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> 

Přepínač	Význam
/MT:n	Umožňuje, aby nástroj Robocopy běžel ve více vláknech. Výchozí hodnota pro n je 8. Maximum je 128 vláken. I když vysoký počet vláken pomáhá nasytit dostupnou šířku pásma, neznamená to, že migrace bude vždy rychlejší s více vlákny. Testy s Azure Files indikují, že hodnota mezi 8 a 20 ukazuje vyvážený výkon při počátečním spuštění kopírování. Další /MIR spuštění jsou postupně ovlivněná dostupnými výpočetními prostředky a dostupnou šířkou pásma sítě. U následných spuštění slaďte hodnotu počtu vláken více s počtem jader procesoru a počtem vláken na jádro. Zvažte, jestli musí být jádra vyhrazená pro jiné úlohy, které může mít produkční server. Testy s Azure Files ukázaly, že až 64 vláken vytváří dobrý výkon, ale pouze v případě, že je vaše procesory dokážou udržet aktivní ve stejnou dobu.
/R:n	Maximální počet opakování pro soubor, který se při prvním pokusu nepodaří zkopírovat. Nástroj Robocopy zkusí n časy, než se soubor trvale nepodaří zkopírovat při spuštění. Výkon spuštění můžete optimalizovat: Pokud se domníváte, že chyby v minulosti způsobovaly problémy s vypršením časového limitu, zvolte hodnotu dvě nebo tři. To může být častější u propojení WAN. Pokud se domníváte, že se soubor nepodařilo zkopírovat, protože se aktivně používal, nevybírejte žádné opakování ani hodnotu jedna. Když to zkusíte znovu o několik sekund později, nemusí být dostatek času na to, aby se změnil stav souboru při použití. Uživatelé nebo aplikace, které mají soubor otevřený, můžou potřebovat hodiny víc času. V tomto případě se přijetí souboru nezkopírovalo a zachytávání v některém z plánovaných následných spuštění nástroje Robocopy může nakonec úspěšně zkopírovat soubor. To pomáhá, aby se aktuální spuštění dokončilo rychleji, aniž by se prodlužovaly mnoha opakovanými pokusy, které nakonec skončí většinou selhání kopírování kvůli souborům, které jsou stále otevřené i po vypršení časového limitu opakování.
/W:n	Specifikuje čas, kdy nástroj Robocopy čeká před pokusem o zkopírování souboru, který se během předchozího pokusu nepodařilo zkopírovat. n je počet sekund čekání mezi opakovanými pokusy. /W:n se často používá společně s /R:n.
/B	Spustí nástroj Robocopy ve stejném režimu jako zálohovací aplikace. Tento přepínač umožňuje nástroji Robocopy přesouvat soubory, pro které nemá aktuální uživatel oprávnění. Přepínač zálohování závisí na spuštění příkazu Robocopy v konzole se zvýšenými oprávněními správce nebo v okně PowerShellu. Pokud pro Azure Files používáte Robocopy, nezapomeňte připojit sdílenou složku Azure pomocí přístupového klíče účtu úložiště a identity domény. Pokud to neuděláte, nemusí vás chybové zprávy intuitivně dovést k vyřešení problému.
/MIR	(Zzrcadlit zdroj na cíl.) Umožňuje nástroji Robocopy kopírovat pouze rozdíly mezi zdrojem a cílem. Zkopírují se prázdné podadresáře. Položky (soubory nebo složky), které se změnily nebo neexistují v cíli, se zkopírují. Položky, které existují v cíli, ale ne ve zdroji, se vyprázdní (odstraní) z cíle. Při použití tohoto přepínače musí být struktury zdrojové a cílové složky naprosto stejné. Shoda znamená kopírování ze správné úrovně zdroje a složky na odpovídající úroveň složky v cíli. Pouze v takovém případě může být zachycené kopírování úspěšné. Pokud se zdroj a cíl neshodují, použití /MIR povede k rozsáhlému odstranění a obnovení rozsahu.
/IT	Zajišťuje zachování věrnosti v určitých scénářích zrcadlení. Pokud například u souboru dojde ke změně seznamu ACL a aktualizaci atributu mezi dvěma spuštěními nástroje Robocopy, označí se jako skrytý. Bez /ITmůže nástroj Robocopy změnu seznamu ACL vynechat a nepřenese se do cílového umístění.
/COPY:[copyflags]	Věrnost kopie souboru. Výchozí: /COPY:DAT. Příznaky kopírování: D= data, A= atributy, T= časová razítka, S= zabezpečení = seznamy ACL ntfs, O= informace o vlastníkovi, U= informace o sadě A. Informace o auditování nelze ukládat ve sdílené složce Azure.
/DCOPY:[copyflags]	Věrnost kopie adresářů. Výchozí: /DCOPY:DA. Příznaky kopírování: D= Data, A= Atributy, T= Časová razítka.
/NP	Specifikuje, že průběh kopírování se nebude zobrazovat pro každý soubor a složku. Zobrazení průběhu výrazně snižuje výkon kopírování.
/NFL	Určuje, že se neprotokolují názvy souborů. Zlepšuje výkon kopírování.
/NDL	Určuje, že se neprotokolují názvy adresářů. Zlepšuje výkon kopírování.
/XD	Určuje adresáře, které mají být vyloučeny. Při spuštění nástroje Robocopy v kořenovém adresáři svazku zvažte vyloučení skryté System Volume Information složky. Pokud se použije podle návrhu, všechny informace v něm jsou specifické pro přesný svazek v tomto systému a dají se znovu sestavit na vyžádání. Kopírování těchto informací nebude užitečné v cloudu ani při kopírování dat zpět na jiný svazek Windows. Ponechání tohoto obsahu by nemělo být považováno za ztrátu dat.
/UNILOG:<file name>	Zapíše stav do souboru protokolu jako Unicode. (Přepíše existující protokol.)
/L	Pouze pro testovací běh Soubory mají být uvedeny pouze v seznamu. Nebudou zkopírovány, nebudou odstraněny a nebudou opatřeny časovým razítkem. Často se používá s /TEE pro výstup konzoly. Příznaky z ukázkového skriptu, jako jsou /NP, /NFLa /NDL, může být potřeba odebrat, abyste dosáhli správně zdokumentovaných výsledků testů.
/LFSM	Pouze pro cíle s vrstveným úložištěm. Nepodporuje se, pokud je cílem vzdálená sdílená složka SMB. Určuje, že nástroj Robocopy pracuje v režimu "málo volného místa". Tento přepínač je užitečný pouze pro cíle s vrstveným úložištěm, kterým může dojít místní kapacita před dokončením nástroje Robocopy. Byl přidán speciálně pro použití s cílem, u kterého je povoleno vrstvení cloudu Synchronizace souborů Azure. Dá se použít nezávisle na Synchronizaci souborů Azure. V tomto režimu se nástroj Robocopy zastaví pokaždé, když kopie souboru způsobí, že volné místo cílového svazku klesne pod hodnotu dolní meze. Tato hodnota může být určena /LFSM:n formou příznaku. Parametr n je zadaný v základu 2: nKB, nMBnebo nGB. Pokud /LFSM zadáte bez explicitní hodnoty floor, nastaví se floor na 10 procent velikosti cílového svazku. Režim málo volného místa není kompatibilní s /MT, /EFSRAWnebo /ZB. Podpora byla /B přidána v systému Windows Server 2022. Další informace včetně podrobností o související chybě a alternativním řešení najdete níže v části Windows Server 2022 a RoboCopy LFSM.
/Z	Používejte opatrně Zkopíruje soubory v režimu restartování. Tento přepínač se doporučuje pouze v nestabilním síťovém prostředí. Výrazně snižuje výkon kopírování z důvodu dodatečného protokolování.
/ZB	Používejte opatrně Používá režim restartování. Pokud se přístup odepře, použije tato možnost režim zálohování. Tato možnost výrazně snižuje výkon kopírování z důvodu kontrolních bodů.

Důležité

Doporučujeme používat Windows Server 2022. Pokud používáte Windows Server 2019, ujistěte se, že je nainstalovaná nejnovější úroveň opravy nebo alespoň aktualizace operačního systému KB5005103 . Obsahuje důležité opravy pro určité scénáře Robocopy.

Při prvním spuštění příkazu RoboCopy vaši uživatelé a aplikace stále přistupují k souborům a složkám StorSimple a potenciálně je mohou změnit. Je možné, že nástroj RoboCopy zpracoval adresář, přejde k dalšímu a uživatel ve zdrojovém umístění (StorSimple) přidá, změní nebo odstraní soubor, který se teď v tomto aktuálním spuštění nástroje RoboCopy nezpracuje. To je v pořádku.

První spuštění se týká přesunu velkého množství dat zpět do místního prostředí, na Windows Server a zálohování do cloudu prostřednictvím Synchronizace souborů Azure. To může trvat dlouho, v závislosti na:

• šířku pásma pro stahování
• rychlost z oběhu cloudové služby StorSimple
• šířka pásma pro nahrávání
• počet položek (souborů a složek), které musí být zpracovány některou ze služeb

Po dokončení počátečního spuštění spusťte příkaz znovu.

Podruhé se dokončí rychleji, protože stačí přenést pouze změny, ke kterým došlo od posledního spuštění. Tyto změny jsou pravděpodobně již pro StorSimple místní, protože jsou nedávné. To dále zkracuje dobu, protože se snižuje potřeba odvolání z cloudu. Během tohoto druhého spuštění se stále můžou nahromadit nové změny.

Tento postup opakujte, dokud nebudete spokojeni s tím, že doba potřebná k dokončení představuje přijatelný výpadek.

Pokud tento výpadek považujete za přijatelný a jste připraveni umístění StorSimple převést do režimu offline, udělejte to teď: Odeberte například sdílenou složku SMB, aby ke složce neměl přístup žádný uživatel, nebo proveďte jakýkoliv jiný vhodný krok, který zabrání změně obsahu v této složce na StorSimple.

Spusťte poslední kolo RoboCopy. Tím se zachytnou všechny změny, které by mohly být vynecháné. Doba trvání tohoto posledního kroku závisí na rychlosti kontroly nástrojem RoboCopy. Dobu (která se rovná výpadku) můžete odhadnout tak, že změříte, jak dlouho trvalo předchozí spuštění.

Vytvořte sdílenou složku ve složce Windows Serveru a případně upravte nasazení DFS-N tak, aby na ni odkazovat. Nezapomeňte nastavit stejná oprávnění na úrovni sdílené složky jako ve sdílené složce SMB StorSimple.

Dokončili jste migraci sdílené složky nebo skupiny sdílených složek do společného kořenového adresáře nebo svazku. (V závislosti na tom, co jste namapovali a rozhodli, že je potřeba přejít do stejné sdílené složky Azure.)

Můžete zkusit spustit několik těchto kopií paralelně. Doporučujeme zpracovávat rozsah jedné sdílené složky Azure najednou.

Upozornění

Jakmile přesunete všechna data ze služby StorSimple do Windows Serveru a migrace bude hotová: Vraťte se ke všem skupinám synchronizace v Azure Portal a upravte procentuální hodnotu volného místa svazku vrstvení cloudu na něco vhodnějšího pro využití mezipaměti, například 20 %.

Zásada volného místa svazku vrstvení cloudu funguje na úrovni svazku s potenciálně více koncovými body serveru, které se z ní synchronizují. Pokud zapomenete upravit volné místo i na jednom koncovém bodu serveru, synchronizace bude i nadále používat nejvíce omezující pravidlo a pokusí se zachovat 99 % volného místa na disku, takže místní mezipaměť nebude fungovat tak, jak byste očekávali. Pokud není vaším cílem mít obor názvů jenom pro svazek, který obsahuje jen zřídka přístupná archivní data.

Řešení potíží

Nejpravděpodobnějším problémem, na který můžete narazit, je, že příkaz RoboCopy selže a na straně Windows Serveru dojde k zaplnění svazku . V takovém případě je rychlost stahování pravděpodobně vyšší než rychlost nahrávání. Vrstvení cloudu funguje jednou za hodinu a evakuuje obsah z místního disku s Windows Serverem, který se synchronizoval.

Nechte průběh synchronizace a vrstvení cloudu uvolnit místo na disku. Můžete si všimnout, že v Průzkumník souborů na Windows Serveru.

Pokud má Windows Server dostatečnou dostupnou kapacitu, problém vyřešíte opětovnou spuštěním příkazu. Když se dostanete do této situace, nic se nepokazí a můžete se s jistotou posunout vpřed. Jediným důsledkem jsou nepříjemnosti při opětovném spuštění příkazu.

Můžete také narazit na jiné Synchronizace souborů Azure problémy. Pokud k tomu dojde, projděte si průvodce odstraňováním potíží Synchronizace souborů Azure.

Rychlost a úspěšnost daného spuštění nástroje RoboCopy závisí na několika faktorech:

• IOPS zdrojového a cílového úložiště
• dostupná šířka pásma sítě mezi zdrojem a cílem
• možnost rychlého zpracování souborů a složek v oboru názvů
• počet změn mezi spuštěními nástroje RoboCopy
• velikost a počet souborů, které potřebujete zkopírovat

Důležité informace o IOPS a šířce pásma

V této kategorii musíte zvážit možnosti zdrojového úložiště, cílového úložiště a sítě , která je připojuje. Maximální možná propustnost je určena nejpomalejší z těchto tří komponent. Ujistěte se, že je síťová infrastruktura nakonfigurovaná tak, aby podporovala optimální přenosové rychlosti podle svých nejlepších schopností.

Upozornění

I když je kopírování co nejrychlejší, často je toužebné, zvažte využití místní sítě a zařízení NAS pro další, často důležité obchodní úlohy.

Kopírování co nejrychleji nemusí být žádoucí, pokud existuje riziko, že by migrace mohla monopolizovat dostupné prostředky.

• Zvažte, kdy je ve vašem prostředí nejlepší spouštět migrace: přes den, mimo pracovní dobu nebo o víkendech.
• Zvažte také síťové technologie QoS na Windows Serveru, abyste omezili rychlost nástroje RoboCopy.
• Vyhněte se zbytečné práci s nástroji pro migraci.

RoboCopy může vkládat zpoždění mezi pakety zadáním /IPG:n přepínače, kde n se měří v milisekundách mezi pakety RoboCopy. Tento přepínač vám pomůže vyhnout se monopolizaci prostředků na zařízeních s omezeným vstupně-výstupním operacím i na přeplněných síťových propojeních.

/IPG:n nelze použít k přesnému omezování sítě na určité Mb/s. Použijte místo toho technologii Windows Server Network QoS. RoboCopy se při všech síťových potřebách plně spoléhá na protokol SMB. Použití protokolu SMB je důvodem, proč nástroj RoboCopy nemůže ovlivnit samotnou propustnost sítě, ale může její používání zpomalit.

Podobný názor platí i pro počet IOPS pozorovaný v NAS. Velikost clusteru na svazku NAS, velikosti paketů a řada dalších faktorů ovlivňují pozorované IOPS. Zavedení zpoždění mezi pakety je často nejjednodušší způsob, jak řídit zatížení NAS. Testuje více hodnot, například přibližně od 20 milisekund (n=20) až po násobky tohoto čísla. Jakmile uvedete zpoždění, můžete vyhodnotit, jestli teď vaše ostatní aplikace můžou fungovat podle očekávání. Tato strategie optimalizace vám umožní najít optimální rychlost nástroje RoboCopy ve vašem prostředí.

Rychlost zpracování

Nástroj RoboCopy projde obor názvů, na který je odkazem, a vyhodnotí jednotlivé soubory a složky pro kopírování. Každý soubor se vyhodnotí během počátečního kopírování a během dochytávání kopií. Například opakované spuštění nástroje RoboCopy /MIR ve stejném zdrojovém a cílovém umístění úložiště. Tato opakovaná spuštění jsou užitečná k minimalizaci výpadků uživatelů a aplikací a ke zlepšení celkové úspěšnosti migrovaných souborů.

Šířku pásma často považujeme za nejvíce omezující faktor migrace – a to může být pravda. Ale možnost vytvořit výčet oboru názvů může ovlivnit celkovou dobu kopírování ještě více u větších oborů názvů s menšími soubory. Vezměte v úvahu, že kopírování 1 TiB malých souborů bude trvat výrazně déle než kopírování 1 TiB menšího, ale většího souboru za předpokladu, že všechny ostatní proměnné zůstanou stejné. Proto při migraci velkého počtu malých souborů může docházet k pomalému přenosu. Toto chování je očekávané.

Příčinou tohoto rozdílu je výpočetní výkon potřebný k procházení oboru názvů. RoboCopy podporuje vícevláknové kopie prostřednictvím parametru /MT:n, kde n představuje počet vláken, která se mají použít. Proto při zřizování počítače speciálně pro Nástroj RoboCopy zvažte počet jader procesoru a jejich vztah k počtu vláken, který poskytují. Nejběžnější jsou dvě vlákna na jádro. Počet jader a vláken počítače je důležitým datovým bodem, abyste mohli rozhodnout, jaké hodnoty /MT:n více vláken byste měli zadat. Zvažte také, kolik úloh RoboCopy plánujete na daném počítači spustit paralelně.

Více vláken bude kopírovat náš 1 TiB příklad malých souborů výrazně rychleji než méně vláken. Zároveň investice do dalších zdrojů do 1 TiB větších souborů nemusí přinést poměrné výhody. Vysoký počet vláken se pokusí zkopírovat více velkých souborů v síti současně. Tato dodatečná síťová aktivita zvyšuje pravděpodobnost omezení propustností nebo IOPS úložiště.

Během prvního spuštění nástroje RoboCopy do prázdného cíle nebo rozdílového spuštění se spoustou změněných souborů jste pravděpodobně omezeni propustností sítě. Při počátečním spuštění začněte s vysokým počtem vláken. Vysoký počet vláken, a to i nad rámec aktuálně dostupných vláken na počítači, pomáhá saturovat dostupnou šířku pásma sítě. Další spuštění /MIR jsou postupně ovlivněna zpracováním položek. Méně změn v rozdílovém běhu znamená menší přenos dat přes síť. Vaše rychlost teď více závisí na vaší schopnosti zpracovávat položky oboru názvů než je přesouvat přes síťové propojení. U následných spuštění porovnáte hodnotu počtu vláken s počtem jader procesoru a počtem vláken na jádro. Zvažte, jestli je potřeba vyhrait jádra pro jiné úlohy, které může mít produkční server.

Tip

Pravidlo: První spuštění Nástroje RoboCopy, které přesune velké množství dat sítě s vyšší latencí, těží z nadměrného zřízení počtu vláken (/MT:n). Další spuštění budou kopírovat menší rozdíly a je pravděpodobnější, že se přesunete z omezené propustnosti sítě na omezené výpočetní prostředky. Za těchto okolností je často lepší porovnat počet vláken RoboCopy se skutečně dostupnými vlákny na počítači. Nadměrné zřizování v tomto scénáři může vést k dalším kontextovým posunům v procesoru, což může zpomalit kopii.

Vyhněte se zbytečné práci

Vyhněte se rozsáhlým změnám v oboru názvů. Například přesun souborů mezi adresáři, změna vlastností ve velkém měřítku nebo změna oprávnění (seznamy ACL systému souborů NTFS). Zejména změny seznamu ACL můžou mít velký dopad, protože často mají kaskádový efekt změn na soubory, které jsou v hierarchii složek níže. Důsledky můžou být:

• prodloužení doby běhu úlohy RoboCopy, protože je potřeba aktualizovat každý soubor a složku ovlivněný změnou seznamu ACL.
• Opakované využití dat přesunutých dříve může být potřeba změnit rozsah. Pokud se například změní struktura složek po zkopírování souborů dříve, bude třeba zkopírovat více dat. Úloha RoboCopy nemůže "přehrát" změnu oboru názvů. Další úloha musí vyprázdnit dříve přenášené soubory do staré struktury složek a znovu nahrát soubory v nové struktuře složek.

Dalším důležitým aspektem je efektivní používání nástroje RoboCopy. Pomocí doporučeného skriptu RoboCopy vytvoříte a uložíte soubor protokolu pro chyby. Může dojít k chybám kopírování , to je normální. Kvůli těmto chybám je často nutné spustit několik cyklů nástroje pro kopírování, jako je RoboCopy. Počáteční spuštění, například z NAS do DataBoxu nebo ze serveru do sdílené složky Azure. A jeden nebo více dalších spuštění s přepínačem /MIR, který zachytává a opakuje soubory, které se nezkopírovaly.

Měli byste být připraveni spustit několik kol Nástroje RoboCopy pro daný obor názvů. Následná spuštění se dokončí rychleji, protože mají méně ke kopírování, ale jsou stále více omezena rychlostí zpracování oboru názvů. Když spustíte více kol, můžete každé kolo urychlit tím, že se nástroj RoboCopy nebude pokoušet příliš tvrdě kopírovat všechno v daném běhu. Tyto přepínače RoboCopy mohou mít významný rozdíl:

• /R:n n = jak často se opakovaně pokoušíte zkopírovat soubor, který selhal, a
• /W:n n = kolik sekund se má čekat mezi opakovanými pokusy

/R:5 /W:5 je rozumné nastavení, které si můžete upravit podle svých představ. V tomto příkladu se neúspěšný soubor bude opakovat pětkrát s pětisekundovým čekáním mezi opakovanými pokusy. Pokud se soubor stále nedaří zkopírovat, zkusí to další úloha RoboCopy znovu. Soubory, které selhaly, protože se používají nebo kvůli problémům s vypršením časového limitu, se můžou často úspěšně zkopírovat tímto způsobem.

Windows Server 2022 a RoboCopy LFSM

Přepínač /LFSM RoboCopy se dá použít k zabránění selhání úlohy RoboCopy s chybou zaplněný svazek . RoboCopy se pozastaví vždy, když kopírování souboru způsobí, že volné místo na cílovém svazku klesne pod hodnotu "floor".

Použití nástroje RoboCopy s Windows Serverem 2022 Pouze tato verze nástroje RoboCopy obsahuje důležité opravy chyb a funkce, díky kterým je přepínač kompatibilní s dalšími příznaky potřebnými pro většinu migrací. Například kompatibilita s příznakem /B .

/B spustí RoboCopy ve stejném režimu, který by používala zálohovací aplikace. Tento přepínač umožňuje nástroji RoboCopy přesunout soubory, ke kterým aktuální uživatel nemá oprávnění.

Nástroj RoboCopy je normálně možné spustit na zdrojovém, cílovém nebo třetím počítači.

Důležité

Pokud máte v úmyslu používat /LFSMnástroj RoboCopy, musí být spuštěný na cílovém Synchronizace souborů Azure serveru Windows Server 2022.

Všimněte si také, že pro /LFSM cíl musíte použít také místní cestu, nikoli cestu UNC. Například jako cílovou cestu byste měli místo cesty UNC jako \\Název_serveru\NázevSložky použít E:\NázevSložky.

Upozornění

Aktuálně dostupná verze Nástroje RoboCopy v systému Windows Server 2022 obsahuje chybu, která způsobuje, že se pozastavení započítávají do počtu chyb jednotlivých souborů. Použijte následující alternativní řešení.

Doporučené /R:2 /W:1 příznaky zvyšují pravděpodobnost, že soubor selže kvůli /LFSM vyvolané pauze. V tomto příkladu se soubor, který nebyl zkopírován po 3, pozastaví kvůli /LFSM tomu, že pozastavení způsobilo, nesprávně způsobí selhání nástroje RoboCopy. Alternativním řešením je použít vyšší hodnoty pro /R:n a /W:n. Dobrým příkladem je /R:10 /W:1800 10 opakování po 30 minutách. Algoritmus vrstvení Synchronizace souborů Azure by tak měl poskytnout čas na vytvoření místa na cílovém svazku.

Tato chyba byla opravena, ale oprava ještě není veřejně dostupná. V tomto odstavci najdete informace o dostupnosti opravy a jejím nasazení.

---

Poznámka

Máte stále dotazy nebo jste narazili na nějaké problémy?
Jsme tu, abychom vám pomohli:

Relevantní odkazy

Obsah migrace:

• Průvodce migrací storSimple řady 8000

Synchronizace souborů Azure obsah:

• přehled Synchronizace souborů Azure
• Nasazení Synchronizace souborů Azure
• Průvodce odstraňováním potíží s Synchronizace souborů Azure