Usare Data Box per eseguire la migrazione da nas (Network Attached Archiviazione) a una distribuzione cloud ibrida usando Sincronizzazione file di Azure

  • Articolo

Questo articolo sulla migrazione è uno dei diversi oggetti che si applicano alle parole chiave NAS, Sincronizzazione file di Azure e Azure Data Box. Controllare se questo articolo si applica allo scenario:

  • Origine dati: network attached Archiviazione (NAS)
  • Route di migrazione: ⇒ NAS Data Box ⇒ condivisione file di Azure ⇒ sincronizzazione con Windows Server
  • Memorizzazione nella cache dei file in locale: Sì, l'obiettivo finale è una distribuzione Sincronizzazione file di Azure

Se lo scenario è diverso, esaminare la tabella delle guide alla migrazione.

Sincronizzazione file di Azure funziona su percorsi daS (Direct Attached Archiviazione). Non supporta la sincronizzazione con percorsi NAS (Network Attached Archiviazione). È quindi necessario eseguire la migrazione dei file. Questo articolo illustra la pianificazione e l'implementazione di tale migrazione.

Si applica a

Tipo di condivisione file SMB NFS
Condivisioni file Standard (GPv2), archiviazione con ridondanza locale/archiviazione con ridondanza della zona Yes No
Condivisioni file Standard (GPv2), archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona Yes No
Condivisioni file Premium (FileStorage), archiviazione con ridondanza locale/archiviazione con ridondanza della zona Yes No

Obiettivi della migrazione

L'obiettivo è spostare le condivisioni presenti nell'appliance NAS in Windows Server. Si useranno quindi Sincronizzazione file di Azure per una distribuzione cloud ibrida. Questa migrazione deve essere eseguita in modo da garantire l'integrità dei dati di produzione e della disponibilità durante la migrazione. Quest'ultimo richiede un tempo di inattività minimo in modo che soddisfi o superi solo leggermente le normali finestre di manutenzione.

Panoramica della migrazione

Il processo di migrazione è costituito da diverse fasi. Dovrai:

  • Distribuire account di archiviazione di Azure e condivisioni file.
  • Distribuire un computer locale che esegue Windows Server.
  • Configurare Sincronizzazione file di Azure.
  • Eseguire la migrazione dei file usando Robocopy.
  • Fai il cutover.

Le sezioni seguenti descrivono in dettaglio le fasi del processo di migrazione.

Suggerimento

Se si torna a questo articolo, usare lo spostamento sul lato destro della schermata per passare alla fase di migrazione in cui si è interrotto.

Fase 1: Determinare il numero di condivisioni file di Azure necessarie

In questo passaggio si determinerà il numero di condivisioni file di Azure necessarie. Una singola istanza di Windows Server (o cluster) può sincronizzare fino a 30 condivisioni file di Azure.

Potrebbero essere presenti più cartelle nei volumi attualmente condivisi in locale come condivisioni SMB per gli utenti e le app. Il modo più semplice per eseguire l'immagine di questo scenario consiste nell'immaginare una condivisione locale che esegue il mapping di 1:1 a una condivisione file di Azure. Se si dispone di un numero sufficiente di condivisioni, inferiore a 30 per una singola istanza di Windows Server, è consigliabile eseguire un mapping 1:1.

Se sono presenti più di 30 condivisioni, il mapping di una condivisione locale 1:1 a una condivisione file di Azure non è spesso necessario. Prendere in considerazione le opzioni seguenti.

Raggruppamento di condivisioni

Ad esempio, se il reparto risorse umane (HR) ha 15 condivisioni, è consigliabile archiviare tutti i dati delle risorse umane in una singola condivisione file di Azure. L'archiviazione di più condivisioni locali in una condivisione file di Azure non impedisce di creare le normali condivisioni SMB da 15 nell'istanza locale di Windows Server. Significa solo che si organizzano le cartelle radice di queste 15 condivisioni come sottocartelle in una cartella comune. Si sincronizza quindi questa cartella comune con una condivisione file di Azure. In questo modo, è necessaria solo una singola condivisione file di Azure nel cloud per questo gruppo di condivisioni locali.

Sincronizzazione dei volumi

Sincronizzazione file di Azure supporta la sincronizzazione della radice di un volume in una condivisione file di Azure. Se si sincronizza la radice del volume, tutte le sottocartelle e i file verranno visualizzati nella stessa condivisione file di Azure.

La sincronizzazione della radice del volume non è sempre l'opzione migliore. La sincronizzazione di più posizioni offre vantaggi. Ad esempio, in questo modo è possibile mantenere inferiore il numero di elementi per ambito di sincronizzazione. Le condivisioni file di Azure vengono testate e Sincronizzazione file di Azure con 100 milioni di elementi (file e cartelle) per condivisione. Ma una procedura consigliata consiste nel cercare di mantenere il numero inferiore a 20 milioni o 30 milioni in una singola quota. La configurazione di Sincronizzazione file di Azure con un numero inferiore di elementi non è utile solo per la sincronizzazione file. Un numero inferiore di elementi offre anche scenari come i seguenti:

  • L'analisi iniziale del contenuto cloud può essere completata più rapidamente, riducendo a sua volta l'attesa che lo spazio dei nomi venga visualizzato in un server abilitato per Sincronizzazione file di Azure.
  • Il ripristino lato cloud da uno snapshot di condivisione file di Azure sarà più veloce.
  • Il ripristino di emergenza di un server locale può accelerare notevolmente.
  • Le modifiche apportate direttamente in una condivisione file di Azure (al di fuori della sincronizzazione) possono essere rilevate e sincronizzate più velocemente.

Suggerimento

Se non si conosce il numero di file e cartelle presenti, consultare lo strumento TreeSize di JAM Software GmbH.

Approccio strutturato a una mappa di distribuzione

Prima di distribuire l'archiviazione cloud in un passaggio successivo, è importante creare una mappa tra le cartelle locali e le condivisioni file di Azure. Questo mapping informerà il numero di risorse del gruppo di sincronizzazione e le Sincronizzazione file di Azure di cui si eseguirà il provisioning. Un gruppo di sincronizzazione collega la condivisione file di Azure e la cartella nel server e stabilisce una connessione di sincronizzazione.

Per decidere il numero di condivisioni file di Azure necessarie, esaminare i limiti e le procedure consigliate seguenti. In questo modo sarà possibile ottimizzare la mappa.

  • Un server in cui è installato l'agente Sincronizzazione file di Azure può eseguire la sincronizzazione con un massimo di 30 condivisioni file di Azure.

  • Una condivisione file di Azure viene distribuita in un account di archiviazione. Questa disposizione rende l'account di archiviazione una destinazione di scalabilità per i numeri di prestazioni come IOPS e velocità effettiva.

    Prestare attenzione alle limitazioni delle operazioni di I/O al secondo di un account di archiviazione durante la distribuzione di condivisioni file di Azure. Idealmente, è consigliabile eseguire il mapping delle condivisioni file 1:1 con gli account di archiviazione. Tuttavia, questo potrebbe non essere sempre possibile a causa di vari limiti e restrizioni, sia dall'organizzazione che da Azure. Quando non è possibile distribuire una sola condivisione file in un account di archiviazione, considerare quali condivisioni saranno altamente attive e quali condivisioni saranno meno attive per garantire che le condivisioni file più a caldo non vengano inserite nello stesso account di archiviazione.

    Se si prevede di trasferire un'app in Azure che userà la condivisione file di Azure in modo nativo, potrebbe essere necessario ottenere prestazioni più elevate dalla condivisione file di Azure. Se questo tipo di uso è una possibilità, anche in futuro, è consigliabile creare una singola condivisione file standard di Azure nel proprio account di archiviazione.

  • È previsto un limite di 250 account di archiviazione per ogni sottoscrizione per ogni area di Azure.

Suggerimento

Data questa informazione, spesso diventa necessario raggruppare più cartelle di primo livello nei volumi in una nuova directory radice comune. Si sincronizza quindi questa nuova directory radice e tutte le cartelle raggruppate in essa in una singola condivisione file di Azure. Questa tecnica consente di rimanere entro il limite di 30 sincronizzazioni di condivisioni file di Azure per server.

Questo raggruppamento in una radice comune non influisce sull'accesso ai dati. Gli ACL rimangono così come sono. È sufficiente modificare i percorsi di condivisione (ad esempio condivisioni SMB o NFS) nelle cartelle del server locale che ora sono state modificate in una radice comune. Nessun'altra modifica.

Importante

Il vettore di scala più importante per Sincronizzazione file di Azure è il numero di elementi (file e cartelle) che devono essere sincronizzati. Per altri dettagli, vedere le Sincronizzazione file di Azure destinazioni di scalabilità.

È consigliabile mantenere basso il numero di elementi per ambito di sincronizzazione. Questo è un fattore importante da considerare nel mapping delle cartelle alle condivisioni file di Azure. Sincronizzazione file di Azure viene testato con 100 milioni di elementi (file e cartelle) per condivisione. Ma spesso è consigliabile mantenere il numero di articoli al di sotto di 20 milioni o 30 milioni in una singola quota. Suddividere lo spazio dei nomi in più condivisioni se si inizia a superare questi numeri. È possibile continuare a raggruppare più condivisioni locali nella stessa condivisione file di Azure se si restano approssimativamente al di sotto di questi numeri. Questa pratica ti fornirà spazio per crescere.

È possibile che, nella situazione in uso, un set di cartelle possa essere sincronizzato logicamente con la stessa condivisione file di Azure (usando il nuovo approccio comune alle cartelle radice menzionato in precedenza). Tuttavia, potrebbe essere preferibile raggruppare le cartelle in modo che vengano sincronizzate con due anziché una condivisione file di Azure. È possibile usare questo approccio per mantenere bilanciato il numero di file e cartelle per condivisione file nel server. È anche possibile suddividere le condivisioni locali e la sincronizzazione tra più server locali, aggiungendo la possibilità di eseguire la sincronizzazione con altre 30 condivisioni file di Azure per ogni server aggiuntivo.

Scenari e considerazioni comuni di sincronizzazione dei file

# Scenario di sincronizzazione Supportata Considerazioni (o limitazioni) Soluzione (o soluzione alternativa)
1 File server con più dischi/volumi e più condivisioni nella stessa condivisione file di Azure di destinazione (consolidamento) No Una condivisione file di Azure di destinazione (endpoint cloud) supporta solo la sincronizzazione con un gruppo di sincronizzazione.

Un gruppo di sincronizzazione supporta solo un endpoint server per ogni server registrato.		 1) Iniziare con la sincronizzazione di un disco (relativo volume radice) alla condivisione file di Azure di destinazione. A partire dal disco/volume più grande sarà utile per i requisiti di archiviazione in locale. Configurare la suddivisione in livelli cloud per suddividere in livelli tutti i dati nel cloud, liberando così spazio sul disco del file server. Spostare i dati da altri volumi o condivisioni nel volume corrente che esegue la sincronizzazione. Continuare i passaggi uno per uno fino a quando tutti i dati non vengono a livelli fino al cloud o alla migrazione.
2) Specificare come destinazione un volume radice (disco) alla volta. Usare la suddivisione in livelli cloud per archiviare in livelli tutti i dati per la condivisione file di Azure. Rimuovere l'endpoint server dal gruppo di sincronizzazione, ricreare l'endpoint con il volume/disco radice successivo, sincronizzare e ripetere il processo. Nota: potrebbe essere necessario reinstallare l'agente.
3) Consigliare l'uso di più condivisioni file di Azure di destinazione (stesso o account di archiviazione diverso in base ai requisiti di prestazioni)
2 File server con volume singolo e più condivisioni nella stessa condivisione file di Azure di destinazione (consolidamento) Sì Non è possibile avere più endpoint server per ogni server registrato che esegue la sincronizzazione con la stessa condivisione file di Azure di destinazione (uguale a quella precedente) Sincronizzare la radice del volume che contiene più condivisioni o cartelle di primo livello. Per altre informazioni, vedere Concetto di raggruppamento di condivisione e Sincronizzazione del volume.
3 File server con più condivisioni e/o volumi in più condivisioni file di Azure con un singolo account di archiviazione (mapping di condivisione 1:1) Sì Una singola istanza di Windows Server (o cluster) può sincronizzare fino a 30 condivisioni file di Azure.

Un account di archiviazione è una destinazione di scalabilità per le prestazioni. Le operazioni di I/O al secondo e la velocità effettiva vengono condivise tra condivisioni file.

Mantenere il numero di elementi per gruppo di sincronizzazione entro 100 milioni di elementi (file e cartelle) per condivisione. Idealmente è meglio rimanere al di sotto di 20 o 30 milioni per azione.		 1) Usare più gruppi di sincronizzazione (numero di gruppi di sincronizzazione = numero di condivisioni file di Azure da sincronizzare).
2) In questo scenario è possibile sincronizzare solo 30 condivisioni alla volta. Se sono presenti più di 30 condivisioni in tale file server, usare il concetto di raggruppamento di condivisione e la sincronizzazione del volume per ridurre il numero di cartelle radice o di primo livello all'origine.
3) Usare server di Sincronizzazione file aggiuntivi in locale e dividere/spostare i dati in questi server per aggirare le limitazioni nel server Windows di origine.
4 File server con più condivisioni e/o volumi in più condivisioni file di Azure in un account di archiviazione diverso (mapping di condivisione 1:1) Sì Una singola istanza di Windows Server (o cluster) può sincronizzare fino a 30 condivisioni file di Azure (stesso o account di archiviazione diverso).

Mantenere il numero di elementi per gruppo di sincronizzazione entro 100 milioni di elementi (file e cartelle) per condivisione. Idealmente è meglio rimanere al di sotto di 20 o 30 milioni per azione.		 Stesso approccio illustrato in precedenza
5 Più file server con un singolo (volume radice o condivisione) alla stessa condivisione file di Azure di destinazione (consolidamento) No Un gruppo di sincronizzazione non può usare l'endpoint cloud (condivisione file di Azure) già configurato in un altro gruppo di sincronizzazione.

Anche se un gruppo di sincronizzazione può avere endpoint server in file server diversi, i file non possono essere distinti.		 Seguire le indicazioni riportate nello scenario 1 precedente con considerazioni aggiuntive sulla destinazione di un file server alla volta.

Creare una tabella di mapping

Diagram that shows an example of a mapping table. Download the following file to experience and use the content of this image.

Usare le informazioni precedenti per determinare il numero di condivisioni file di Azure necessarie e quali parti dei dati esistenti finiranno in quale condivisione file di Azure.

Creare una tabella che registra i pensieri in modo da poterla fare riferimento quando è necessario. Rimanere organizzati è importante perché può essere facile perdere i dettagli del piano di mapping quando si esegue il provisioning di molte risorse di Azure contemporaneamente. Scaricare il file di Excel seguente da usare come modello per creare il mapping.


Excel icon that sets the context for the download. Scaricare un modello di mapping dello spazio dei nomi.

Fase 2: Distribuire le risorse di archiviazione di Azure

In questa fase, consultare la tabella di mapping della fase 1 e usarla per effettuare il provisioning del numero corretto di account di archiviazione e condivisioni file di Azure.

Una condivisione file di Azure viene archiviata nel cloud in un account di archiviazione di Azure. Un altro livello di considerazioni sulle prestazioni si applica qui.

Se sono presenti condivisioni molto attive (condivisioni usate da molti utenti e/o applicazioni), due condivisioni file di Azure potrebbero raggiungere il limite di prestazioni di un account di archiviazione.

Una procedura consigliata consiste nel distribuire gli account di archiviazione con una condivisione file ciascuno. È possibile raggruppare più condivisioni file di Azure nello stesso account di archiviazione se si dispone di condivisioni di archiviazione o si prevede un'attività giornaliera bassa.

Queste considerazioni si applicano maggiormente all'accesso al cloud diretto (tramite una macchina virtuale di Azure) rispetto a Sincronizzazione file di Azure. Se si prevede di usare solo Sincronizzazione file di Azure in queste condivisioni, il raggruppamento di più in un singolo account di archiviazione di Azure è corretto.

Se è stato creato un elenco delle condivisioni, è necessario eseguire il mapping di ogni condivisione all'account di archiviazione in cui si trova.

Nella fase precedente è stato determinato il numero appropriato di condivisioni. In questo passaggio è disponibile un mapping degli account di archiviazione alle condivisioni file. Distribuire ora il numero appropriato di account di archiviazione di Azure con il numero appropriato di condivisioni file di Azure.

Assicurarsi che l'area di ogni account di archiviazione sia la stessa e corrisponda all'area della risorsa del servizio di sincronizzazione Archiviazione già distribuita.

Attenzione

Se si crea una condivisione file di Azure con un limite di 100 TiB, tale condivisione può usare solo l'archiviazione con ridondanza locale o le opzioni di ridondanza dell'archiviazione con ridondanza della zona. Prendere in considerazione le esigenze di ridondanza dell'archiviazione prima di usare 100 condivisioni file TiB.

Le condivisioni file di Azure vengono comunque create con un limite di 5 TiB per impostazione predefinita. Seguire la procedura descritta in Creare una condivisione file di Azure per creare una condivisione file di grandi dimensioni.

Un'altra considerazione quando si distribuisce un account di archiviazione è la ridondanza di Archiviazione di Azure. Vedere Archiviazione di Azure opzioni di ridondanza.

Anche i nomi delle risorse sono importanti. Ad esempio, se si raggruppano più condivisioni per il reparto risorse umane in un account di archiviazione di Azure, è necessario assegnare un nome appropriato all'account di archiviazione. Analogamente, quando si assegna un nome alle condivisioni file di Azure, è consigliabile usare nomi simili a quelli usati per le controparti locali.

Fase 3: Determinare il numero di appliance Azure Data Box necessarie

Avviare questo passaggio solo dopo aver completato la fase precedente. Le risorse di archiviazione di Azure (account di archiviazione e condivisioni file) devono essere create al momento. Quando si ordina Data Box, è necessario specificare gli account di archiviazione in cui Data Box sta spostando i dati.

In questa fase è necessario eseguire il mapping dei risultati del piano di migrazione dalla fase precedente ai limiti delle opzioni di Data Box disponibili. Queste considerazioni consentiranno di pianificare le opzioni di Data Box da scegliere e quante di esse è necessario spostare le condivisioni NAS nelle condivisioni file di Azure.

Per determinare il numero di dispositivi necessari e i relativi tipi, considerare questi limiti importanti:

  • Qualsiasi appliance Azure Data Box può spostare i dati in un massimo di 10 account di archiviazione.
  • Ogni opzione di Data Box è dotata di una propria capacità utilizzabile. Vedere Opzioni di Data Box.

Consultare il piano di migrazione per trovare il numero di account di archiviazione che si è deciso di creare e le condivisioni in ognuno di essi. Esaminare quindi le dimensioni di ognuna delle condivisioni nel NAS. La combinazione di queste informazioni consentirà di ottimizzare e decidere quale appliance deve inviare dati agli account di archiviazione. Due dispositivi Data Box possono spostare i file nello stesso account di archiviazione, ma non suddividere il contenuto di una singola condivisione file tra due data box.

Opzioni di Data Box

Per una migrazione standard, scegliere una o una combinazione di queste opzioni di Data Box:

  • Data Box Disk. Microsoft invierà tra uno e cinque dischi SSD con una capacità di 8 TiB ciascuno, per un totale massimo di 40 TiB. La capacità utilizzabile è circa il 20% inferiore a causa del sovraccarico di crittografia e file system. Per altre informazioni, vedere la documentazione di Data Box Disk.
  • Data Box. Questa opzione è quella più comune. Microsoft invierà un'appliance Data Box resistente che funziona in modo simile a un NAS. Ha una capacità utilizzabile di 80 TiB. Per altre informazioni, vedere la documentazione di Data Box.
  • Data Box Heavy. Questa opzione include un'appliance Data Box resistente su ruote simili a un NAS. Ha una capacità di 1 PiB. La capacità utilizzabile è circa il 20% inferiore a causa del sovraccarico di crittografia e file system. Per altre informazioni, vedere la documentazione di Data Box Heavy.

Fase 4: Effettuare il provisioning di un'istanza di Windows Server appropriata in locale

Mentre si attende l'arrivo dei dispositivi Azure Data Box, è possibile iniziare a esaminare le esigenze di una o più istanze di Windows Server che verranno usati con Sincronizzazione file di Azure.

  • Creare un'istanza di Windows Server 2019 (almeno Windows Server 2012 R2) come macchina virtuale o server fisico. È supportato anche un cluster di failover di Windows Server.
  • Effettuare il provisioning o aggiungere Archiviazione con collegamento diretto. (DAS, anziché NAS, che non è supportato).

La configurazione delle risorse (calcolo e RAM) dell'istanza di Windows Server distribuita dipende principalmente dal numero di file e cartelle che verranno sincronizzati. In caso di problemi, è consigliabile una configurazione con prestazioni più elevate.

Informazioni su come ridimensionare un'istanza di Windows Server in base al numero di elementi da sincronizzare.

Nota

L'articolo collegato in precedenza include una tabella con un intervallo per la memoria server (RAM). È possibile usare i numeri alla fine inferiore dell'intervallo per il server, ma si prevede che la sincronizzazione iniziale richiederà molto più tempo.

Fase 5: Copiare file in Data Box

Quando arriva Data Box, è necessario configurarlo con connettività di rete non implementata all'appliance NAS. Seguire la documentazione di configurazione per il tipo di Data Box ordinato:

A seconda del tipo di Data Box, gli strumenti di copia di Data Box potrebbero essere disponibili. A questo punto, non è consigliabile eseguire le migrazioni alle condivisioni file di Azure perché non copiano i file in Data Box con la massima fedeltà. Usare invece Robocopy.

All'arrivo di Data Box, le condivisioni SMB di cui è stato effettuato il pre-provisioning saranno disponibili per ogni account di archiviazione specificato al momento dell'ordinamento.

  • Se i file vengono inseriti in una condivisione file di Azure Premium, sarà presente una condivisione SMB per ogni account di archiviazione premium "Archiviazione file".
  • Se i file vengono inseriti in un account di archiviazione standard, saranno presenti tre condivisioni SMB per account di archiviazione standard (GPv1 e GPv2). Solo le condivisioni file che terminano con _AzFiles sono rilevanti per la migrazione. Ignorare eventuali condivisioni BLOB di blocchi e pagine.

Seguire la procedura descritta nella documentazione di Azure Data Box:

  1. Connessione a Data Box.
  2. Copiare i dati in Data Box.
    È possibile usare Robocopy (seguire le istruzioni riportate di seguito) o il nuovo servizio di copia dei dati di Data Box.
  3. Preparare Data Box per il caricamento in Azure.

Suggerimento

In alternativa a Robocopy, Data Box ha creato un servizio di copia dei dati. È possibile usare questo servizio per caricare file in Data Box con piena fedeltà. Seguire questa esercitazione sul servizio di copia dei dati e assicurarsi di impostare la destinazione corretta della condivisione file di Azure.

La documentazione di Data Box specifica un comando Robocopy. Questo comando non è adatto per mantenere la fedeltà completa del file e della cartella. Usare invece questo comando:

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>
Commutatore Significato
/MT:n Consente l'esecuzione di Robocopy in multithreading. Il valore predefinito per n è 8. Il massimo è di 128 thread. Anche se un numero elevato di thread consente di saturare la larghezza di banda disponibile, non significa che la migrazione sarà sempre più veloce con più thread. I test con File di Azure indicano tra 8 e 20 prestazioni bilanciate per un'esecuzione di copia iniziale. Le esecuzioni successive /MIR sono progressivamente interessate dal calcolo disponibile rispetto alla larghezza di banda di rete disponibile. Per le esecuzioni successive, il valore del conteggio dei thread dovrà avvicinarsi al numero di core del processore e al conteggio dei thread per core. Valutare se i core devono essere riservati ad altre eventuali attività di un server di produzione. I test con File di Azure hanno dimostrato che fino a 64 thread producono prestazioni ottimali, ma solo se i processori possono mantenerli attivi contemporaneamente.
/R:n Numero massimo di nuovi tentativi per un file che non viene copiato al primo tentativo. Robocopy proverà n volte prima che il file non riesca a copiare in modo permanente nell'esecuzione. È possibile ottimizzare le prestazioni dell'esecuzione: scegliere un valore pari a due o tre se si ritiene che i problemi di timeout abbiano causato errori in passato. Questo può essere più comune rispetto ai collegamenti WAN. Scegliere nessun nuovo tentativo o un valore di uno se si ritiene che il file non sia riuscito a copiare perché era attivamente in uso. Il tentativo di nuovo alcuni secondi dopo potrebbe non essere sufficiente per lo stato in uso del file da modificare. Gli utenti o le app che contengono il file aperto potrebbero richiedere ore più tempo. In questo caso, accettare il file non è stato copiato e intercettarlo in una delle esecuzioni di Robocopy pianificate, potrebbe riuscire a copiare correttamente il file. Ciò consente all'esecuzione corrente di terminare più velocemente senza essere prolungati da molti tentativi che alla fine finiscono nella maggior parte degli errori di copia a causa di file ancora aperti oltre il timeout di ripetizione dei tentativi.
/W:n Specifica il tempo in cui Robocopy rimane in attesa prima di provare a ripetere un'operazione di copia di un file che ha avuto esito negativo in un tentativo precedente. n è il numero di secondi di attesa tra i tentativi. /W:n viene spesso usato insieme a /R:n.
/B Esegue Robocopy nella stessa modalità che verrebbe usata da un'applicazione di backup. Questa opzione consente a Robocopy di spostare i file per cui l'utente corrente non dispone delle autorizzazioni. L'opzione di backup dipende dall'esecuzione del comando Robocopy in una console con privilegi elevati di amministratore o in una finestra di PowerShell. Se si usa Robocopy per File di Azure, assicurarsi di montare la condivisione file di Azure usando la chiave di accesso dell'account di archiviazione e un'identità di dominio. In caso contrario, i messaggi di errore potrebbero non causare una risoluzione del problema in modo intuitivo.
/MIR (Mirror da origine a destinazione.) Consente a Robocopy di copiare solo i delta tra origine e destinazione. Le sottodirectory vuote verranno copiate. Gli elementi (file o cartelle) modificati o non presenti nella destinazione verranno copiati. Gli elementi presenti nella destinazione ma non nell'origine verranno rimossi (eliminati) dalla destinazione. Quando si usa questa opzione, le strutture delle cartelle di origine e di destinazione devono essere identiche. La corrispondenza significa copiare dal livello di origine e cartella corretto al livello di cartella corrispondente nella destinazione. Solo a questo punto una copia "di recupero" può avere esito positivo. Quando l'origine e la destinazione non corrispondono, l'uso /MIR porterà a eliminazioni e ripozioni su larga scala.
/IT Verifica che venga mantenuta la fedeltà in determinati scenari di mirror.
Ad esempio, se un file riscontra una modifica ACL e un aggiornamento dell'attributo tra due esecuzioni robocopy, viene contrassegnato come nascosto. Senza /IT, la modifica dell'elenco di controllo di accesso potrebbe non essere stata rilevata da Robocopy e non trasferita nella posizione di destinazione.
/COPY:[copyflags] La fedeltà della copia del file. Impostazione predefinita: /COPY:DAT. Flag di copia: D= Data, A= Attributes, T= Timestamps, S= Security = NTFS ACL, O= Owner information, U= Auditing information. Le informazioni di controllo non possono essere archiviate in una condivisione file di Azure.
/DCOPY:[copyflags] Fedeltà per la copia delle directory. Impostazione predefinita: /DCOPY:DA. Flag di copia: D= Dati, A= Attributi, T= Timestamp.
/NP Specifica che non verrà visualizzato l'avanzamento della copia per ogni file e cartella. La visualizzazione dell'avanzamento riduce notevolmente le prestazioni di copia.
/NFL Specifica che i nomi dei file non vengono registrati. Aumenta le prestazioni di copia.
/NDL Specifica che i nomi delle directory non vengono registrati. Aumenta le prestazioni di copia.
/XD Specifica le directory da escludere. Quando si esegue Robocopy nella radice di un volume, prendere in considerazione l'esclusione della cartella nascosta System Volume Information . Se usato come progettato, tutte le informazioni contenute in sono specifiche del volume esatto su questo sistema esatto e possono essere ricompilate su richiesta. La copia di queste informazioni non sarà utile nel cloud o quando i dati vengono copiati in un altro volume di Windows. Lasciare il contenuto in ritardo non deve essere considerato perdita di dati.
/UNILOG:<file name> Scrive lo stato nel file di log come Unicode. Sovrascrive il log esistente.
/L Solo per i file di esecuzione
di test devono essere elencati solo. Non verranno copiati o eliminati e non verranno applicati timestamp. Spesso usato con /TEE per l'output della console. I flag dello script di esempio, ad esempio /NP, /NFLe /NDL, potrebbero dover essere rimossi per ottenere risultati di test documentati correttamente.
/LFSM Solo per le destinazioni con archiviazione a livelli. Non supportato quando la destinazione è una condivisione SMB remota.
Specifica che Robocopy opera in "modalità spazio libero insufficiente". Questa opzione è utile solo per le destinazioni con archiviazione a livelli che potrebbero esaurire la capacità locale prima del completamento di Robocopy. È stata aggiunta appositamente per l'uso con una destinazione abilitata per cloud a livelli di Sincronizzazione file di Azure. Può essere usata indipendentemente da Sincronizzazione file di Azure. In questa modalità Robocopy viene sospeso ogni volta che lo spazio libero del volume di destinazione scende al di sotto di un valore minimo a causa di una copia del file. Questo valore può essere specificato dal /LFSM:n formato del flag. Il parametro n viene specificato in base 2: nKB, nMBo nGB. Se /LFSM viene specificato senza alcun valore esplicito, il piano viene impostato sul 10% delle dimensioni del volume di destinazione. La modalità spazio libero insufficiente non è compatibile con /MT, /EFSRAWo /ZB. Il supporto per /B è stato aggiunto in Windows Server 2022. Vedere la sezione Windows Server 2022 e RoboCopy LFSM di seguito per altre informazioni, tra cui informazioni dettagliate su un bug e una soluzione alternativa correlati.
/Z Usare copia con cautela
i file in modalità di riavvio. Questa operazione è consigliata solo in un ambiente di rete instabile. Riduce significativamente le prestazioni di copia a causa della registrazione aggiuntiva.
/ZB Usa con cautela
la modalità di riavvio. Se viene negato l'accesso, questa opzione usa la modalità di backup. Questa opzione riduce significativamente le prestazioni di copia a causa del checkpoint.

Importante

È consigliabile usare Windows Server 2022. Quando si usa Un Windows Server 2019, assicurarsi che sia installato al livello di patch più recente o almeno l'aggiornamento del sistema operativo KB5005103 . Contiene correzioni importanti per determinati scenari Robocopy.

Fase 6: Distribuire la risorsa cloud Sincronizzazione file di Azure

Prima di continuare con questa guida, attendere che tutti i file siano arrivati nelle condivisioni file di Azure corrette. Il processo di spedizione e inserimento dei dati di Data Box richiederà tempo.

Per completare questo passaggio, sono necessarie le credenziali della sottoscrizione di Azure.

La risorsa principale da configurare per Sincronizzazione file di Azure è denominata servizio di sincronizzazione Archiviazione. È consigliabile distribuire solo uno per tutti i server che sincronizzano lo stesso set di file ora o in futuro. Creare più Archiviazione Servizi di sincronizzazione solo se sono presenti set distinti di server che non devono mai scambiare dati. Ad esempio, si potrebbero avere server che non devono mai sincronizzare la stessa condivisione file di Azure. In caso contrario, l'uso di un singolo servizio di sincronizzazione Archiviazione è la procedura consigliata.

Scegliere un'area di Azure per il servizio di sincronizzazione Archiviazione vicino alla località. Tutte le altre risorse cloud devono essere distribuite nella stessa area. Per semplificare la gestione, creare un nuovo gruppo di risorse nella sottoscrizione che ospita risorse di sincronizzazione e archiviazione.

Per altre informazioni, vedere la sezione relativa alla distribuzione del servizio di sincronizzazione Archiviazione nell'articolo sulla distribuzione di Sincronizzazione file di Azure. Seguire solo questa sezione dell'articolo. Nei passaggi successivi saranno disponibili collegamenti ad altre sezioni dell'articolo.

Fase 7: Distribuire l'agente Sincronizzazione file di Azure

In questa sezione si installa l'agente Sincronizzazione file di Azure nell'istanza di Windows Server.

La guida alla distribuzione spiega che è necessario disattivare La configurazione di sicurezza avanzata di Internet Explorer. Questa misura di sicurezza non è applicabile con Sincronizzazione file di Azure. La disattivazione consente di eseguire l'autenticazione in Azure senza problemi.

Aprire PowerShell. Installare i moduli di PowerShell necessari usando i comandi seguenti. Assicurarsi di installare il modulo completo e il provider NuGet quando viene richiesto di farlo.

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

Se si verificano problemi durante il raggiungimento di Internet dal server, è il momento di risolverli. Sincronizzazione file di Azure usa qualsiasi connessione di rete disponibile a Internet. È supportata anche la richiesta di un server proxy per raggiungere Internet. È possibile configurare ora un proxy a livello di computer o, durante l'installazione dell'agente, specificare un proxy che verrà usato solo Sincronizzazione file di Azure.

Se si configura un proxy significa che è necessario aprire i firewall per il server, questo approccio potrebbe essere accettabile per l'utente. Al termine dell'installazione del server, dopo aver completato la registrazione del server, un report di connettività di rete mostrerà gli URL dell'endpoint esatti in Azure che Sincronizzazione file di Azure devono comunicare con per l'area selezionata. Il report indica anche perché è necessaria la comunicazione. È possibile usare il report per bloccare i firewall intorno al server a URL specifici.

È anche possibile adottare un approccio più conservativo in cui non si aprono i firewall. È invece possibile limitare il server a comunicare con spazi dei nomi DNS di livello superiore. Per altre informazioni, vedere Sincronizzazione file di Azure impostazioni proxy e firewall. Seguire le procedure consigliate per la rete.

Al termine dell'installazione guidata del server, verrà aperta una procedura guidata di registrazione del server. Registrare il server nella risorsa di Azure del servizio di sincronizzazione Archiviazione precedente.

Questi passaggi sono descritti in modo più dettagliato nella guida alla distribuzione, che include i moduli di PowerShell da installare per primi: Sincronizzazione file di Azure'installazione dell'agente.

Usare l'agente più recente. È possibile scaricarlo dall'Area download Microsoft: Sincronizzazione file di Azure Agent.

Dopo aver completato correttamente l'installazione e la registrazione del server, è possibile verificare di aver completato correttamente questo passaggio. Passare alla risorsa del servizio di sincronizzazione Archiviazione nella portale di Azure. Nel menu a sinistra passare a Server registrati. Verrà visualizzato l'elenco del server.

Fase 8: Configurare Sincronizzazione file di Azure nell'istanza di Windows Server

L'istanza di Windows Server locale registrata deve essere pronta e connessa a Internet per questo processo.

Questo passaggio collega tutte le risorse e le cartelle configurate nell'istanza di Windows Server durante i passaggi precedenti.

  1. Accedi al portale di Azure.
  2. Individuare la risorsa del servizio di sincronizzazione Archiviazione.
  3. Creare un nuovo gruppo di sincronizzazione all'interno della risorsa del servizio di sincronizzazione Archiviazione per ogni condivisione file di Azure. In Sincronizzazione file di Azure terminologia, la condivisione file di Azure diventerà un endpoint cloud nella topologia di sincronizzazione che si sta descrivendo con la creazione di un gruppo di sincronizzazione. Quando si crea il gruppo di sincronizzazione, assegnargli un nome familiare in modo da riconoscere il set di file sincronizzato. Assicurarsi di fare riferimento alla condivisione file di Azure con un nome corrispondente.
  4. Dopo aver creato il gruppo di sincronizzazione, verrà visualizzata una riga nell'elenco dei gruppi di sincronizzazione. Selezionare il nome (un collegamento) per visualizzare il contenuto del gruppo di sincronizzazione. La condivisione file di Azure verrà visualizzata in Endpoint cloud.
  5. Individuare il pulsante Aggiungi endpoint server. La cartella nel server locale di cui è stato effettuato il provisioning diventerà il percorso per questo endpoint server.

Attivare la funzionalità di suddivisione in livelli nel cloud e selezionare Spazio dei nomi solo nella sezione di download iniziale.

Importante

Il cloud a livelli è la funzionalità di Sincronizzazione file di Azure che consente al server locale di avere una capacità di archiviazione inferiore a quella archiviata nel cloud, ma ha lo spazio dei nomi completo disponibile. I dati interessanti localmente vengono memorizzati nella cache anche in locale per prestazioni di accesso rapido. Il cloud a livelli è facoltativo. È possibile impostarlo singolarmente per ogni endpoint server Sincronizzazione file di Azure. È necessario usare questa funzionalità se non si dispone di capacità del disco locale sufficiente nell'istanza di Windows Server per contenere tutti i dati cloud e si vuole evitare di scaricare tutti i dati dal cloud.

Per tutte le condivisioni file o i percorsi del server di Azure che è necessario configurare per la sincronizzazione, ripetere i passaggi per creare gruppi di sincronizzazione e aggiungere le cartelle server corrispondenti come endpoint server. Attendere il completamento della sincronizzazione dello spazio dei nomi. La sezione seguente illustra come assicurarsi che la sincronizzazione sia stata completata.

Nota

Dopo aver creato un endpoint server, la sincronizzazione funziona. Tuttavia, la sincronizzazione deve enumerare (individuare) i file e le cartelle spostati tramite Data Box nella condivisione file di Azure. A seconda delle dimensioni dello spazio dei nomi, può essere necessario molto tempo prima che lo spazio dei nomi dal cloud venga visualizzato nel server.

Fase 9: attendere che lo spazio dei nomi venga visualizzato completamente nel server

Prima di continuare con i passaggi successivi della migrazione, attendere che il server abbia scaricato completamente lo spazio dei nomi dalla condivisione cloud. Se si inizia a spostare i file nel server troppo presto, si rischia di caricare e persino conflitti di sincronizzazione file non necessari.

Per determinare se il server ha completato la sincronizzazione del download iniziale, aprire Visualizzatore eventi nell'istanza di Windows Server di sincronizzazione e usare il registro eventi di telemetria Sincronizzazione file di Azure. Il registro eventi di telemetria si trova in Visualizzatore eventi in Applicazioni e servizi\Microsoft\FileSync\Agent.

Cercare l'evento 9102 più recente. L'ID evento 9102 viene registrato al termine di una sessione di sincronizzazione. Nel testo dell'evento è presente un campo per la direzione di sincronizzazione del download. (HResult deve essere zero e i file devono essere scaricati.

Si desidera visualizzare due eventi consecutivi di questo tipo, con questo contenuto, per assicurarsi che il server abbia completato il download dello spazio dei nomi. È OK se sono presenti altri eventi tra i due eventi 9102.

Fase 10: Eseguire Robocopy dal NAS

Dopo che il server ha completato la sincronizzazione iniziale dell'intero spazio dei nomi dalla condivisione cloud, è possibile continuare con questo passaggio. Prima di continuare con questo passaggio, è necessario completare la sincronizzazione iniziale. Per informazioni dettagliate, vedere la sezione precedente.

In questo passaggio verranno eseguiti processi Robocopy per sincronizzare le condivisioni cloud con le ultime modifiche apportate al NAS che si sono verificate dopo aver creato il fork delle condivisioni in Data Box. L'esecuzione di Robocopy potrebbe terminare rapidamente o richiedere qualche minuto, a seconda della quantità di varianza che si è verificata nelle condivisioni NAS.

Avviso

A causa del comportamento di Robocopy regresso in Windows Server 2019, l'opzione Robocopy /MIR non è compatibile con le directory di destinazione a livelli. Non è possibile usare il client Windows Server 2019 o Windows 10 per questa fase della migrazione. Usare Robocopy in un'istanza intermedia di Windows Server 2016.

Ecco l'approccio alla migrazione di base:

  • Eseguire Robocopy dall'appliance NAS per sincronizzare l'istanza di Windows Server.
  • Usare Sincronizzazione file di Azure per sincronizzare le condivisioni file di Azure da Windows Server.

Eseguire la prima copia locale nella cartella di destinazione di Windows Server:

  1. Identificare la prima posizione nell'appliance NAS.
  2. Identificare la cartella corrispondente nell'istanza di Windows Server in cui è già stato configurato Sincronizzazione file di Azure.
  3. Avviare la copia usando Robocopy.

Il comando Robocopy seguente copia solo le differenze (file e cartelle aggiornati) dalla risorsa di archiviazione NAS alla cartella di destinazione di Windows Server. L'istanza di Windows Server li sincronizza quindi con le condivisioni file di 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>
Commutatore Significato
/MT:n Consente l'esecuzione di Robocopy in multithreading. Il valore predefinito per n è 8. Il massimo è di 128 thread. Anche se un numero elevato di thread consente di saturare la larghezza di banda disponibile, non significa che la migrazione sarà sempre più veloce con più thread. I test con File di Azure indicano tra 8 e 20 prestazioni bilanciate per un'esecuzione di copia iniziale. Le esecuzioni successive /MIR sono progressivamente interessate dal calcolo disponibile rispetto alla larghezza di banda di rete disponibile. Per le esecuzioni successive, il valore del conteggio dei thread dovrà avvicinarsi al numero di core del processore e al conteggio dei thread per core. Valutare se i core devono essere riservati ad altre eventuali attività di un server di produzione. I test con File di Azure hanno dimostrato che fino a 64 thread producono prestazioni ottimali, ma solo se i processori possono mantenerli attivi contemporaneamente.
/R:n Numero massimo di nuovi tentativi per un file che non viene copiato al primo tentativo. Robocopy proverà n volte prima che il file non riesca a copiare in modo permanente nell'esecuzione. È possibile ottimizzare le prestazioni dell'esecuzione: scegliere un valore pari a due o tre se si ritiene che i problemi di timeout abbiano causato errori in passato. Questo può essere più comune rispetto ai collegamenti WAN. Scegliere nessun nuovo tentativo o un valore di uno se si ritiene che il file non sia riuscito a copiare perché era attivamente in uso. Il tentativo di nuovo alcuni secondi dopo potrebbe non essere sufficiente per lo stato in uso del file da modificare. Gli utenti o le app che contengono il file aperto potrebbero richiedere ore più tempo. In questo caso, accettare il file non è stato copiato e intercettarlo in una delle esecuzioni di Robocopy pianificate, potrebbe riuscire a copiare correttamente il file. Ciò consente all'esecuzione corrente di terminare più velocemente senza essere prolungati da molti tentativi che alla fine finiscono nella maggior parte degli errori di copia a causa di file ancora aperti oltre il timeout di ripetizione dei tentativi.
/W:n Specifica il tempo in cui Robocopy rimane in attesa prima di provare a ripetere un'operazione di copia di un file che ha avuto esito negativo in un tentativo precedente. n è il numero di secondi di attesa tra i tentativi. /W:n viene spesso usato insieme a /R:n.
/B Esegue Robocopy nella stessa modalità che verrebbe usata da un'applicazione di backup. Questa opzione consente a Robocopy di spostare i file per cui l'utente corrente non dispone delle autorizzazioni. L'opzione di backup dipende dall'esecuzione del comando Robocopy in una console con privilegi elevati di amministratore o in una finestra di PowerShell. Se si usa Robocopy per File di Azure, assicurarsi di montare la condivisione file di Azure usando la chiave di accesso dell'account di archiviazione e un'identità di dominio. In caso contrario, i messaggi di errore potrebbero non causare una risoluzione del problema in modo intuitivo.
/MIR (Mirror da origine a destinazione.) Consente a Robocopy di copiare solo i delta tra origine e destinazione. Le sottodirectory vuote verranno copiate. Gli elementi (file o cartelle) modificati o non presenti nella destinazione verranno copiati. Gli elementi presenti nella destinazione ma non nell'origine verranno rimossi (eliminati) dalla destinazione. Quando si usa questa opzione, le strutture delle cartelle di origine e di destinazione devono essere identiche. La corrispondenza significa copiare dal livello di origine e cartella corretto al livello di cartella corrispondente nella destinazione. Solo a questo punto una copia "di recupero" può avere esito positivo. Quando l'origine e la destinazione non corrispondono, l'uso /MIR porterà a eliminazioni e ripozioni su larga scala.
/IT Verifica che venga mantenuta la fedeltà in determinati scenari di mirror.
Ad esempio, se un file riscontra una modifica ACL e un aggiornamento dell'attributo tra due esecuzioni robocopy, viene contrassegnato come nascosto. Senza /IT, la modifica dell'elenco di controllo di accesso potrebbe non essere stata rilevata da Robocopy e non trasferita nella posizione di destinazione.
/COPY:[copyflags] La fedeltà della copia del file. Impostazione predefinita: /COPY:DAT. Flag di copia: D= Data, A= Attributes, T= Timestamps, S= Security = NTFS ACL, O= Owner information, U= Auditing information. Le informazioni di controllo non possono essere archiviate in una condivisione file di Azure.
/DCOPY:[copyflags] Fedeltà per la copia delle directory. Impostazione predefinita: /DCOPY:DA. Flag di copia: D= Dati, A= Attributi, T= Timestamp.
/NP Specifica che non verrà visualizzato l'avanzamento della copia per ogni file e cartella. La visualizzazione dell'avanzamento riduce notevolmente le prestazioni di copia.
/NFL Specifica che i nomi dei file non vengono registrati. Aumenta le prestazioni di copia.
/NDL Specifica che i nomi delle directory non vengono registrati. Aumenta le prestazioni di copia.
/XD Specifica le directory da escludere. Quando si esegue Robocopy nella radice di un volume, prendere in considerazione l'esclusione della cartella nascosta System Volume Information . Se usato come progettato, tutte le informazioni contenute in sono specifiche del volume esatto su questo sistema esatto e possono essere ricompilate su richiesta. La copia di queste informazioni non sarà utile nel cloud o quando i dati vengono copiati in un altro volume di Windows. Lasciare il contenuto in ritardo non deve essere considerato perdita di dati.
/UNILOG:<file name> Scrive lo stato nel file di log come Unicode. Sovrascrive il log esistente.
/L Solo per i file di esecuzione
di test devono essere elencati solo. Non verranno copiati o eliminati e non verranno applicati timestamp. Spesso usato con /TEE per l'output della console. I flag dello script di esempio, ad esempio /NP, /NFLe /NDL, potrebbero dover essere rimossi per ottenere risultati di test documentati correttamente.
/LFSM Solo per le destinazioni con archiviazione a livelli. Non supportato quando la destinazione è una condivisione SMB remota.
Specifica che Robocopy opera in "modalità spazio libero insufficiente". Questa opzione è utile solo per le destinazioni con archiviazione a livelli che potrebbero esaurire la capacità locale prima del completamento di Robocopy. È stata aggiunta appositamente per l'uso con una destinazione abilitata per cloud a livelli di Sincronizzazione file di Azure. Può essere usata indipendentemente da Sincronizzazione file di Azure. In questa modalità Robocopy viene sospeso ogni volta che lo spazio libero del volume di destinazione scende al di sotto di un valore minimo a causa di una copia del file. Questo valore può essere specificato dal /LFSM:n formato del flag. Il parametro n viene specificato in base 2: nKB, nMBo nGB. Se /LFSM viene specificato senza alcun valore esplicito, il piano viene impostato sul 10% delle dimensioni del volume di destinazione. La modalità spazio libero insufficiente non è compatibile con /MT, /EFSRAWo /ZB. Il supporto per /B è stato aggiunto in Windows Server 2022. Vedere la sezione Windows Server 2022 e RoboCopy LFSM di seguito per altre informazioni, tra cui informazioni dettagliate su un bug e una soluzione alternativa correlati.
/Z Usare copia con cautela
i file in modalità di riavvio. Questa operazione è consigliata solo in un ambiente di rete instabile. Riduce significativamente le prestazioni di copia a causa della registrazione aggiuntiva.
/ZB Usa con cautela
la modalità di riavvio. Se viene negato l'accesso, questa opzione usa la modalità di backup. Questa opzione riduce significativamente le prestazioni di copia a causa del checkpoint.

Importante

È consigliabile usare Windows Server 2022. Quando si usa Un Windows Server 2019, assicurarsi che sia installato al livello di patch più recente o almeno l'aggiornamento del sistema operativo KB5005103 . Contiene correzioni importanti per determinati scenari Robocopy.

Se è stato effettuato il provisioning di meno spazio di archiviazione nell'istanza di Windows Server rispetto ai file usati nell'appliance NAS, è stato configurato il cloud a livelli. Man mano che il volume locale di Windows Server diventa pieno, il cloud a livelli eseguirà l'avvio dei file di livello e che sono già stati sincronizzati correttamente. Il cloud a livelli genererà spazio sufficiente per continuare la copia dall'appliance NAS. Il cloud a livelli controlla una volta all'ora per determinare cosa è stato sincronizzato e liberare spazio su disco per raggiungere lo spazio disponibile del 99%.

Robocopy potrebbe dover spostare più file di quanto sia possibile archiviare localmente nell'istanza di Windows Server. Si può aspettare che Robocopy si sposti più velocemente di Sincronizzazione file di Azure può caricare i file e livelli fuori dal volume locale. In questa situazione, Robocopy avrà esito negativo. È consigliabile usare le condivisioni in una sequenza che impedisce questo scenario. Ad esempio, spostare solo le condivisioni che rientrano nello spazio disponibile nell'istanza di Windows Server. In alternativa, evitare di avviare processi Robocopy per tutte le condivisioni contemporaneamente. La buona notizia è che il /MIR cambio garantirà che vengano spostati solo i delta. Dopo che un delta è stato spostato, un processo riavviato non dovrà spostare nuovamente il file.

Eseguire il cutover

Quando si esegue il comando Robocopy per la prima volta, gli utenti e le applicazioni continueranno ad accedere ai file nel NAS e potenzialmente modificarli. Robocopy elabora una directory e quindi passa alla successiva. Un utente nel NAS potrebbe quindi aggiungere, modificare o eliminare un file nella prima directory che non verrà elaborato durante l'esecuzione corrente di Robocopy. Questo comportamento è previsto.

La prima esecuzione consiste nello spostare la maggior parte dei dati in blocchi nell'istanza di Windows Server e nel cloud tramite Sincronizzazione file di Azure. La prima copia può richiedere molto tempo, a seconda di:

  • Larghezza di banda di caricamento.
  • La velocità della rete locale e il numero ottimale di thread Robocopy corrispondenti.
  • Numero di elementi (file e cartelle) che devono essere elaborati da Robocopy e Sincronizzazione file di Azure.

Al termine dell'esecuzione iniziale, eseguire di nuovo il comando .

Robocopy terminerà più velocemente la seconda volta che si esegue per una condivisione. Deve trasportare solo le modifiche apportate dall'ultima esecuzione. È possibile eseguire processi ripetuti per la stessa condivisione.

Quando si considera il tempo di inattività accettabile, è necessario rimuovere l'accesso utente alle condivisioni basate su NAS. È possibile farlo in qualsiasi modo che impedisca agli utenti di modificare la struttura di file e cartelle e il contenuto. Ad esempio, è possibile puntare lo spazio dei nomi DFS a una posizione che non esiste o modificare gli ACL radice nella condivisione.

Eseguire Robocopy un'ultima volta. Raccoglierà tutte le modifiche che sono state perse. Il tempo necessario per questo passaggio finale dipende dalla velocità dell'analisi Robocopy. È possibile stimare il tempo (uguale al tempo di inattività) misurando la durata dell'esecuzione precedente.

Creare una condivisione nella cartella Di Windows Server ed eventualmente modificare la distribuzione DFS-N in modo che punti al file. Assicurarsi di impostare le stesse autorizzazioni a livello di condivisione presenti nella condivisione SMB NAS. Se si dispone di un NAS aggiunto a un dominio di classe enterprise, i SID utente corrisponderanno automaticamente perché gli utenti si trovano in Active Directory e Robocopy copia i file e i metadati a piena fedeltà. Se sono stati usati utenti locali nel NAS, è necessario:

  • Ricreare questi utenti come utenti locali di Windows Server.
  • Eseguire il mapping dei SID esistenti spostati da Robocopy all'istanza di Windows Server ai SID dei nuovi utenti locali di Windows Server.

È stata completata la migrazione di una condivisione o di un gruppo di condivisioni in una radice o un volume comune (a seconda del mapping dalla fase 1).

È possibile provare a eseguire alcune di queste copie in parallelo. È consigliabile elaborare l'ambito di una condivisione file di Azure alla volta.

Opzione deprecata: "Trasferimento dati offline"

Prima di Sincronizzazione file di Azure versione 13 rilasciata, l'integrazione di Data Box è stata eseguita tramite un processo denominato "trasferimento dei dati offline". Questo processo è deprecato. Con l'agente versione 13, è stato sostituito con i passaggi molto più semplici e veloci descritti in questo articolo. Se si sa che si vuole usare la funzionalità deprecata "trasferimento dati offline", è comunque possibile farlo. È ancora disponibile usando un modulo di PowerShell AFS specifico e meno recente:

Install-Module Az.StorageSync -RequiredVersion 1.4.0
Import-module Az.StorageSync -RequiredVersion 1.4.0
# Verify the specific version is loaded:
Get-module Az.StorageSync

Avviso

Dopo il 15 maggio 2022 non sarà più possibile creare un endpoint server in modalità "trasferimento dati offline". Le migrazioni in corso con questo metodo devono terminare prima del 15 luglio 2022. Se la migrazione continua a essere eseguita con un endpoint server abilitato per il trasferimento dei dati offline, il server inizierà a caricare i file rimanenti dal server il 15 luglio 2022 e non userà più i file trasferiti con Azure Data Box alla condivisione di staging.

Risoluzione dei problemi

Il problema più comune è che il comando Robocopy non riesca con "Volume pieno" sul lato Windows Server. Il cloud a livelli agisce una volta ogni ora per evacuare il contenuto dal disco locale di Windows Server sincronizzato. L'obiettivo è raggiungere lo spazio libero del 99% sul volume.

Consenti la sincronizzazione dello stato di avanzamento e del cloud a livelli liberare spazio su disco. È possibile osservare che in Esplora file nell'istanza di Windows Server.

Quando l'istanza di Windows Server ha una capacità sufficiente, eseguire di nuovo il comando per risolvere il problema. Niente si rompe in questa situazione. È possibile procedere con fiducia. L'inconveniente di eseguire di nuovo il comando è l'unica conseguenza.

Per risolvere i problemi di Sincronizzazione file di Azure, vedere l'articolo elencato nella sezione successiva.

Passaggi successivi

Sono disponibili altre informazioni sulle condivisioni file di Azure e sulle Sincronizzazione file di Azure. Gli articoli seguenti consentono di comprendere le opzioni avanzate e le procedure consigliate. Forniscono anche assistenza per la risoluzione dei problemi. Questi articoli contengono collegamenti alla documentazione della condivisione file di Azure, se appropriato.