Zrušení zřízení nebo odstranění koncového bodu Synchronizace souborů Azure serveru

Odebrání koncového bodu serveru znamená zastavení synchronizace na a z tohoto umístění serveru s koncovým bodem cloudu (sdílená složka Azure) ve stejné skupině synchronizace. Než zrušíte zřízení koncového bodu serveru, měli byste provést několik kroků, abyste zachovali integritu a dostupnost dat. Tento článek popisuje několik metod zrušení zřízení a příslušné pokyny seřazené podle scénáře. Postupujte podle pokynů pro případ použití, který se vás nejlépe týká.

Pokud je v pořádku trvale ztratit data, která právě synchronizujete, můžete přeskočit k přímému zrušení zřízení koncového bodu serveru.

Upozornění

Nepokoušejte se vyřešit problémy se synchronizací zrušením zřízení koncového bodu serveru. Nápovědu k řešení potíží najdete v tématu Řešení potíží Synchronizace souborů Azure. Pokud odstraníte koncový bod serveru, aniž byste server nebo cloud plně synchronizovali s druhým, může dojít k trvalé ztrátě dat. Odebrání koncového bodu serveru je destruktivní operace a vrstvené soubory v rámci koncového bodu serveru se po opětovném vytvoření koncového bodu serveru znovu nepřipojí ke svým umístěním ve sdílené složce Azure, což způsobí chyby synchronizace. Také vrstvené soubory, které existují mimo obor názvů koncového bodu serveru, mohou být trvale ztraceny. Vrstvené soubory můžou existovat v rámci koncového bodu serveru, i když nikdy nebylo povolené vrstvení cloudu.

Scénář 1: Máte v úmyslu odstranit koncový bod serveru a přestat používat místní server nebo virtuální počítač

Cílem je zajistit, aby vaše data byla v koncovém bodu cloudu aktuální. Pokud chcete mít úplnou sadu souborů v koncových bodech serveru aktuální, přečtěte si článek Scénář 2: Chcete odstranit koncový bod serveru a přestat používat tuto konkrétní sdílenou složku Azure.

Mezi případy použití, které spadají do této kategorie, patří:

  • Migrace do sdílené složky Azure
  • Probíhá bezserverová architektura
  • Ukončení používání konkrétní cesty ke koncovému bodu serveru a zachování zbytku skupiny synchronizace beze změny

V tomto scénáři je potřeba před odstraněním koncového bodu serveru provést tři kroky: odebrat přístup uživatelů, zahájit speciální relaci nahrávání VSS a počkat na dokončení konečné relace synchronizace.

Odebrání přístupu uživatele ke koncovému bodu serveru

Než zrušíte zřízení koncového bodu serveru, musíte zajistit, aby se všechny změny ze serveru mohly synchronizovat do cloudu. Prvním krokem k tomu, aby cloud doháněl krok, je odebrat příležitost k dalším změnám souborů a složek v koncovém bodu serveru.

Odebrání přístupu znamená výpadek. Pokud chcete snížit výpadky, můžete také zvážit přesměrování přístupu uživatelů na koncový bod cloudu.

Poznamenejte si datum a čas, kdy jste odebrali uživatelský přístup k vlastním záznamům, a pak přejděte k další části.

Zahájení speciální relace nahrávání služby VSS (Volume Snapshot Service)

Každý den Synchronizace souborů Azure vytvoří na serveru dočasný snímek VSS, který synchronizuje soubory s otevřenými popisovači. Pokud chcete zajistit, aby vaše konečná relace synchronizace nahrála nejnovější data, a snížit počet chyb u jednotlivých položek, zahajte speciální relaci pro nahrávání VSS. Tím se také aktivuje speciální relace nahrávání synchronizace, která se spustí po pořízení snímku.

Uděláte to tak, že na místním serveru otevřete Plánovač úloh , přejdete na Microsoft\StorageSync, kliknete pravým tlačítkem na VssSyncScheduledTask úlohu a vyberete Spustit.

Důležité

Poznamenejte si datum a čas dokončení tohoto kroku. Budete ho potřebovat v další části.

Snímek obrazovky s plánováním relace nahrávání VSS

Čekání na dokončení poslední relace nahrávání synchronizace

Abyste měli jistotu, že jsou nejnovější data v cloudu, musíte počkat na dokončení konečné relace nahrávání synchronizace.

Pokud chcete zkontrolovat stav relace synchronizace, otevřete Prohlížeč událostí na místním serveru. Přejděte do protokolu událostí telemetrie (Aplikace a služby\Microsoft\FileSync\Agent). Ujistěte se, že se zobrazí událost 9102 se směrem synchronizace = upload, HResult = 0 a PerItemErrorCount = 0, ke které došlo po ručním zahájení relace nahrávání VSS.

Snímek obrazovky s kontrolou, jestli se dokončila konečná relace synchronizace

Pokud je Hodnota PerItemErrorCount větší než 0, soubory se nedaří synchronizovat. Pomocí FileSyncErrorsReport.ps1 můžete zobrazit soubory, které se nedaří synchronizovat. Tento skript PowerShellu se obvykle nachází v této cestě na serveru s nainstalovaným agentem Synchronizace souborů Azure: C:\Program Files\Azure\StorageSyncAgent\FileSyncErrorsReport.ps1

Pokud tyto soubory nejsou důležité, můžete odstranit koncový bod serveru. Pokud jsou tyto soubory důležité, opravte jejich chyby a před odstraněním koncového bodu serveru počkejte na další událost 9102 se směrem synchronizace = nahrání, HResult = 0 a PerItemErrorCount = 0.

Scénář 2: Máte v úmyslu odstranit koncový bod serveru a přestat používat tuto konkrétní sdílenou složku Azure.

Cílem je zajistit, aby vaše data byla na místním serveru nebo virtuálním počítači aktuální. Pokud chcete mít úplnou sadu souborů v koncovém bodu cloudu aktuální, přečtěte si téma Scénář 1: Chcete odstranit koncový bod serveru a přestat používat místní server nebo virtuální počítač.

V tomto scénáři je potřeba před odstraněním koncového bodu serveru provést čtyři kroky: zakázat vrstvení cloudu, odvolat vrstvené soubory, zahájit detekci změn v cloudu a počkat na dokončení konečné relace synchronizace.

Zákaz vrstvení cloudu

Přejděte do části Vrstvení cloudu v části Vlastnosti koncového bodu serveru pro koncový bod serveru, který chcete zrušit a zakázat vrstvení cloudu.

Odvolání všech vrstvených souborů

I když je cloudové vrstvení zakázané, musíte všechny vrstvené soubory odvolat, abyste měli jistotu, že jsou všechny soubory uložené místně.

Než si vzpomenete na jakékoli soubory, ujistěte se, že máte místně dostatek volného místa pro uložení všech souborů. Volné místo musí být přibližně velikost sdílené složky Azure v cloudu minus velikost uložená v mezipaměti na serveru.

Použijte rutinu PowerShellu Invoke-StorageSyncFileRecall a zadejte parametr SyncGroupName pro odvolání všech souborů.

Invoke-StorageSyncFileRecall -SyncGroupName "samplesyncgroupname" -ThreadCount 4

Po dokončení spuštění této rutiny můžete přejít k další části.

Zahájení detekce změn v cloudu

Inicializování detekce změn v cloudu zajistí synchronizaci vašich nejnovějších změn.

Detekci změn můžete zahájit pomocí rutiny Invoke-AzStorageSyncChangeDetection:

Invoke-AzStorageSyncChangeDetection -ResourceGroupName "myResourceGroup" -StorageSyncServiceName "myStorageSyncServiceName" -SyncGroupName "mySyncGroupName" -CloudEndpointName "myCloudEndpointGUID"

Dokončení tohoto kroku může chvíli trvat.

Důležité

Po dokončení této iniciované kontroly detekce změn v cloudu si poznamenejte datum a čas dokončení. Budete ho potřebovat v následující části.

Čekání na dokončení konečné relace synchronizace

Abyste měli jistotu, že jsou vaše data na místním serveru aktuální, musíte počkat na dokončení poslední relace nahrávání synchronizace.

Pokud to chcete zkontrolovat, přejděte na Prohlížeč událostí na místním serveru. Přejděte do protokolu událostí telemetrie (Aplikace a služby\Microsoft\FileSync\Agent). Ujistěte se, že se zobrazí událost 9102 se směrem synchronizace = download, HResult = 0 a PerItemErrorCount = 0, ke které došlo po dokončení detekce změn v cloudu.

Snímek obrazovky s kontrolou, jestli se dokončila konečná relace synchronizace

Pokud je Hodnota PerItemErrorCount větší než 0, soubory se nedaří synchronizovat. Pomocí FileSyncErrorsReport.ps1 můžete zobrazit soubory, které se nedaří synchronizovat. Tento skript PowerShellu se obvykle nachází v této cestě na serveru s nainstalovaným agentem Synchronizace souborů Azure: C:\Program Files\Azure\StorageSyncAgent\FileSyncErrorsReport.ps1

Pokud tyto soubory nejsou důležité, můžete odstranit koncový bod serveru. Pokud jsou tyto soubory důležité, opravte jejich chyby a před odstraněním koncového bodu serveru počkejte na další událost 9102 se směrem synchronizace = download, HResult = 0 a PerItemErrorCount = 0.

Další kroky