Condividi tramite

Usare RoboCopy per eseguire la migrazione alle condivisioni file di Azure

  • Articolo

Questo articolo sulla migrazione descrive l'uso di RoboCopy per spostare o migrare file in una condivisione file di Azure SMB. RoboCopy è un'utilità di copia file attendibile e nota con un set di funzionalità che lo rende adatto per le migrazioni. Usa il protocollo SMB, che lo rende ampiamente applicabile a qualsiasi combinazione di origine e destinazione che supporta SMB.

  • Origini dati: qualsiasi origine che supporta il protocollo SMB, ad esempio NAS (Network Attached Storage), server Windows o Linux, un'altra condivisione file di Azure e molto altro
  • Route di migrazione: dal computer Windows di archiviazione di origine ⇒ con RoboCopy ⇒ condivisione file di Azure
  • Nessun file di memorizzazione nella cache locale: poiché l'obiettivo finale consiste nell'usare le condivisioni file di Azure direttamente nel cloud, non è previsto l'uso di Sincronizzazione file di Azure.

Esistono molte route di migrazione diverse per diverse combinazioni di origine e distribuzione. Vedere la tabella delle guide alla migrazione per trovare la migrazione più adatta alle proprie esigenze.

Si applica a

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

Confronto tra AzCopy e RoboCopy

AzCopy e RoboCopy sono due strumenti di copia file fondamentalmente diversi. RoboCopy usa qualsiasi versione del protocollo SMB. AzCopy è uno strumento "born-in-the-cloud" che può essere usato per spostare i dati purché la destinazione si trova nell'archiviazione di Azure. AzCopy dipende da un protocollo REST.

RoboCopy, come strumento di copia affidabile basato su Windows, ha il vantaggio del "feudo" quando si tratta di copiare i file a piena fedeltà. RoboCopy supporta molti scenari di migrazione grazie al suo ricco set di funzionalità e alla possibilità di copiare file e cartelle in piena fedeltà. Vedere la sezione relativa alla fedeltà dei file nell'articolo della panoramica della migrazione per altre informazioni sull'importanza della copia dei file con la massima fedeltà possibile.

AzCopy, d'altra parte, è stato espanso solo di recente per supportare la copia di file con una certa fedeltà e ha aggiunto le prime funzionalità necessarie per essere considerate come uno strumento di migrazione. Tuttavia, esistono ancora lacune e possono verificarsi facilmente errori di funzionalità durante il confronto dei flag AzCopy con i flag RoboCopy.

Un esempio: RoboCopy /MIR eseguirà il mirroring dell'origine nella destinazione. Ciò significa che vengono considerati i file aggiunti, modificati ed eliminati. Una differenza importante nell'uso di AzCopy -sync consiste nel fatto che i file eliminati nell'origine non vengono rimossi nella destinazione. Ciò rende disponibile un set di funzionalità di copia differenziale incompleto. AzCopy continuerà a evolversi. Al momento, non è consigliabile usare AzCopy per gli scenari di migrazione con condivisioni file di Azure come destinazione.

Obiettivi della migrazione

L'obiettivo è spostare i dati da percorsi di condivisione file esistenti ad Azure. In Azure si archivieranno i dati in condivisioni file di Azure native che è possibile usare senza la necessità di windows Server. Questa migrazione deve essere eseguita in modo da garantire l'integrità dei dati di produzione e della disponibilità durante la migrazione. Quest'ultimo aspetto richiede un tempo di inattività minimo, in modo da poter rientrare o superare leggermente le normali finestre di manutenzione.

Panoramica della migrazione

Il processo di migrazione è costituito da diverse fasi. Prima di tutto, è necessario distribuire gli account di archiviazione di Azure e le condivisioni file. Successivamente, si configurerà la rete, si considererà una distribuzione dello spazio dei nomi DFS (DFS-N) o si aggiornerà quella esistente. Quando è il momento della copia dei dati effettiva, è necessario prendere in considerazione le esecuzioni ripetute e differenziali di RoboCopy per ridurre al minimo i tempi di inattività e infine tagliare gli utenti alle nuove condivisioni file di Azure create. Le sezioni seguenti descrivono in dettaglio le fasi del processo di migrazione.

Fase 1: Distribuire le risorse di archiviazione di Azure

In questa fase si eseguirà il provisioning degli account di archiviazione di Azure e delle condivisioni file di Azure SMB all'interno di essi.

Tenere presente che una condivisione file di Azure è distribuita nel cloud in un account di archiviazione di Azure. Per le condivisioni file standard, questa disposizione rende l'account di archiviazione una destinazione di scalabilità per i numeri correlati alle prestazioni come operazioni di I/O al secondo e velocità effettiva. Se si inseriscono più condivisioni file in un singolo account di archiviazione, si crea un pool condiviso di operazioni di I/O al secondo e velocità effettiva per queste condivisioni.

Come regola generale, è 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. Tuttavia, se si hanno condivisioni molto attive (condivisioni usate da molti utenti e/o applicazioni), è consigliabile distribuire gli account di archiviazione con una condivisione file ciascuno. Queste limitazioni non si applicano agli account di archiviazione FileStorage (Premium), in cui le prestazioni vengono sottoposte a provisioning esplicito e garantite per ogni condivisione.

Nota

Esiste un limite di 250 account di archiviazione per sottoscrizione e area di Azure. Con un aumento di quota, è possibile creare fino a 500 account di archiviazione per area. Per altre informazioni, vedere Aumentare le quote dell'account di archiviazione di Azure.

Un'altra considerazione quando si distribuisce un account di archiviazione riguarda la ridondanza. Vedere Ridondanza di File di Azure.

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

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.

A questo punto, distribuire il numero appropriato di account di archiviazione di Azure con il numero appropriato di condivisioni file di Azure, seguendo le istruzioni in Creare una condivisione file SMB. Nella maggior parte dei casi è necessario assicurarsi che l'area di ogni account di archiviazione sia la stessa.

Fase 2: Preparazione all'uso delle condivisioni file di Azure

Con le informazioni in questa fase, sarà possibile decidere in che modo i server e gli utenti in Azure e all'esterno di Azure potranno usare le condivisioni file di Azure. Le decisioni più critiche sono:

  • Rete: abilitare le reti per instradare il traffico SMB.
  • Autenticazione: configurare gli account di archiviazione di Azure per l'autenticazione Kerberos. L'uso dell'autenticazione basata su identità e dell'aggiunta al dominio dell'account di archiviazione consentirà alle app e agli utenti di usare l'identità di Ad per l'autenticazione.
  • Autorizzazione: gli ACL a livello di condivisione per ogni condivisione file di Azure consentirà a utenti e gruppi di ACTIVE Directory di accedere a una determinata condivisione. All'interno di una condivisione file di Azure, gli ACL NTFS nativi assumeranno il controllo. L'autorizzazione basata su ACL di file e cartelle funziona quindi come per le condivisioni SMB locali.
  • Continuità aziendale: L'integrazione di condivisioni file di Azure in un ambiente esistente comporta spesso la conservazione degli indirizzi di condivisione esistenti. Se non si usa già DFS-Namespaces, valutare la possibilità di stabilire tale valore nell'ambiente in uso. Sarà possibile mantenere gli indirizzi di condivisione usati dagli utenti e dagli script, senza modifiche. DFS-N fornisce un servizio di routing dello spazio dei nomi per SMB reindirizzando i client alle condivisioni file di Azure.

Questo video è una guida e una demo su come esporre in modo sicuro le condivisioni file di Azure direttamente agli information worker e alle app in cinque semplici passaggi.
Il video fa riferimento alla documentazione dedicata per gli argomenti seguenti. Tenere presente che Azure Active Directory è ora Microsoft Entra ID. Per altre informazioni, vedere Nuovo nome di Azure AD.

Montaggio di una condivisione file di Azure

Prima di poter usare RoboCopy, è necessario rendere accessibile la condivisione file di Azure tramite SMB. Il modo più semplice consiste nel montare la condivisione come unità di rete locale nel server Windows che si prevede di usare per RoboCopy.

Importante

Assicurarsi di montare la condivisione file di Azure usando la chiave di accesso dell'account di archiviazione. Non usare un'identità di dominio. Prima di poter montare correttamente una condivisione file di Azure in un server Windows locale, è necessario aver completato la fase 2: Preparazione all'uso delle condivisioni file di Azure.

Quando si è pronti, vedere Usare una condivisione file di Azure con Windows. Montare quindi la condivisione file di Azure per cui si vuole avviare RoboCopy.

Fase 3: RoboCopy

Il comando RoboCopy seguente copia solo le differenze (file e cartelle aggiornati) dall'archiviazione di origine alla condivisione 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. L’impostazione predefinita per n è 8. Il massimo è di 128 thread. Anche se un numero elevato di thread facilita la saturazione della larghezza di banda disponibile, non è detto che la migrazione sarà sempre più veloce con più thread. I test con File di Azure tra 8 e 20 dimostrano prestazioni bilanciate per l'esecuzione di una copia iniziale. Le esecuzioni successive di /MIR sono progressivamente influenzate dal rapporto tra calcolo disponibile e la 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 definitivamente 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. Ciò può essere più comune rispetto ai collegamenti WAN. Scegliere nessun nuovo tentativo o un valore di uno se si ritiene che la copia del file non sia riuscita perché era attivamente in uso. Un nuovo tentativo dopo alcuni secondi 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 più ore. In questo caso, accettando che il file non è stato copiato e recuperandolo in una delle successive esecuzioni di Robocopy pianificate, la copia del file potrebbe avvenire correttamente. Ciò consente all'esecuzione corrente di terminare più velocemente senza ritardi dovuti a molti tentativi che alla fine finiscono nella maggior parte in 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 di Robocopy in una console con privilegi elevati di amministratore o in una finestra di PowerShell. Se si usa Robocopy per File di Azure, accertarsi di montare le condivisioni file di Azure usando la chiave di accesso dell'account di archiviazione e non usare un'identità di dominio. In caso contrario, i messaggi di errore potrebbero impedire 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. Corrispondenza significa copiare dal livello corretto di origine e cartella 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 di /MIR causerà eliminazioni e creazione di nuove copie su larga scala.
/IT Verifica che venga mantenuta la fedeltà in determinati scenari di mirror.
Ad esempio, se si verifica un cambiamento di ACL e un aggiornamento degli attributi in un file tra due esecuzioni di Robocopy, il file viene contrassegnato come nascosto. Senza /IT, Robocopy potrebbe non rilevare il cambiamento di ACL e la modifica potrebbe non essere trasferita alla posizione di destinazione.
/COPY:[copyflags] La fedeltà della copia del file. Impostazione predefinita: /COPY:DAT. Flag di copia: D= Dati, A= Attributi, T= Timestamp, S= Sicurezza = NTFS ACL, O= Informazioni sul proprietario, U= Informazioni di controllo. 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, considerare l'esclusione della cartella System Volume Information nascosta. Se usato come progettato, tutte le informazioni contenute sono specifiche del volume esatto su questo sistema esatto e possono essere rigenerare 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 questo contenuto dietro non deve essere considerato come perdita di dati.
/UNILOG:<file name> Scrive lo stato nel file di log come Unicode. (Sovrascrive il log esistente.)
/L Solo per un'esecuzione di test
I file devono essere solo elencati. Non verranno copiati o eliminati e non verranno applicati timestamp. Spesso usato con /TEE per l'output della console. Potrebbe essere necessario rimuovere i flag dello script di esempio, come /NP, /NFL e /NDL, per ottenere risultati di test correttamente documentati.
/Z Usare con cautela
Copia 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 Usare con cautela
Usa 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 l'uso di Windows Server 2022. Quando si usa Windows Server 2019, accertarsi che sia installato il livello di patch più recente o almeno l’aggiornamento del sistema operativo KB5005103. Contiene correzioni importanti per determinati scenari di Robocopy.

Suggerimento

Consultare la sezione Risoluzione dei problemi se RoboCopy influisce sull'ambiente di produzione, segnala un numero elevato di errori o non avanza velocemente come previsto.

Fase 4: Cutover utente

Quando si esegue il comando RoboCopy per la prima volta, gli utenti e le applicazioni accedono ancora ai file nell'origine della migrazione e possono essere modificati. È possibile che RoboCopy abbia elaborato una directory, passi alla successiva e che quindi un utente nel percorso di origine aggiunga, modifichi o elimini un file che ora non verrà elaborato in questa esecuzione corrente di RoboCopy. Si tratta di un comportamento previsto.

La prima esecuzione consiste nello spostare il blocco dei dati inattivi nella condivisione file di Azure. La prima copia può richiedere un po' di tempo. Per altre informazioni su ciò che può influire sulle velocità di RoboCopy, consultare la sezione Risoluzione dei problemi.

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

La seconda che si esegue RoboCopy per la stessa condivisione, finirà più velocemente, perché dovrà trasportare solo le modifiche apportate dopo l'ultima esecuzione. È possibile eseguire processi ripetuti per la stessa condivisione.

Dopo aver considerato la quantità di tempo di inattività accettabile, è necessario rimuovere l'accesso utente alle condivisioni di origine. A tale scopo, è possibile eseguire qualsiasi procedura che impedisca agli utenti di modificare la struttura e il contenuto di file e cartelle. Un esempio consiste nel puntare DFS-Namespace a una posizione non esistente o modificare gli ACL in ogni condivisione.

Eseguire un ultimo round di RoboCopy. Raccoglierà eventuali modifiche che potrebbero essere 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.

Nella fase 2, gli utenti sono stati configurati per accedere alla condivisione con la propria identità e devono aver stabilito una strategia per gli utenti per usare percorsi stabiliti per le nuove condivisioni file di Azure (DFS-N).

È possibile provare a eseguire alcune di queste copie tra diverse condivisioni di origine e di destinazione in parallelo. In questo caso, tenere presente che la velocità effettiva di rete e il numero di core al numero di thread non superano il sovraccarico del sistema.

Risoluzione di problemi e ottimizzazione

La velocità e la frequenza di successo di una determinata esecuzione RoboCopy dipenderanno da diversi fattori:

  • Operazioni di I/O al secondo nell'archiviazione di origine e di destinazione;
  • Larghezza di banda di rete disponibile tra origine e destinazione;
  • Possibilità di elaborare rapidamente file e cartelle in uno spazio dei nomi;
  • Numero di modifiche tra le esecuzioni di RoboCopy;
  • Dimensioni e numero di file che è necessario copiare;

Considerazioni sulle operazioni di I/O al secondo e sulla larghezza di banda

In questa categoria è necessario prendere in considerazione le capacità dell'archiviazione di origine, l'archiviazione di destinazione e la rete che le connette. La velocità effettiva massima possibile è determinata dal più lento di questi tre componenti. Assicurarsi che l'infrastruttura di rete sia configurata per supportare velocità di trasferimento ottimali alle migliori capacità.

Attenzione

Mentre la copia il più veloce possibile è spesso più desiderabile, prendere in considerazione l'utilizzo della rete locale e dell'appliance NAS per altre attività, spesso critiche per l'azienda.

La copia più veloce possibile potrebbe non essere auspicabile quando esiste un rischio che la migrazione possa monopolizzare le risorse disponibili.

  • Valutare quando è preferibile nell'ambiente eseguire le migrazioni: durante il giorno, negli orari di minore attività o durante i fine settimana.
  • Prendere in considerazione anche QoS di rete in Windows Server per limitare la velocità di RoboCopy.
  • Evitare operazioni non necessarie per gli strumenti di migrazione.

RoboCopy può inserire ritardi tra pacchetti specificando l'opzione /IPG:n in cui n viene misurata in millisecondi tra i pacchetti RoboCopy. L'uso di questo commutatore consente di evitare il monopolio delle risorse su dispositivi vincolati di I/O e collegamenti di rete affollati.

/IPG:n non può essere usato per una limitazione di rete precisa a un determinato Mbps. Usare invece QoS di rete di Windows Server. RoboCopy si basa interamente sul protocollo SMB per tutte le esigenze di rete. L'uso di SMB è il motivo per cui RoboCopy non può influenzare la velocità effettiva di rete stessa, ma può rallentarne l'uso.

Una linea di pensiero simile si applica alle operazioni di I/O al secondo osservate sul NAS. Le dimensioni del cluster nel volume NAS, le dimensioni dei pacchetti e una matrice di altri fattori influenzano le operazioni di I/O al secondo osservate. L'introduzione del ritardo tra pacchetti è spesso il modo più semplice per controllare il carico sul NAS. Testare più valori, ad esempio da circa 20 millisecondi (n=20) a multipli di tale numero. Dopo aver introdotto un ritardo, è possibile valutare se le altre app possono ora funzionare come previsto. Questa strategia di ottimizzazione consentirà di trovare la velocità ottimale di RoboCopy nell'ambiente in uso.

Velocità di elaborazione

RoboCopy attraverserà lo spazio dei nomi a cui punta e valuterà ogni file e cartella per la copia. Ogni file verrà valutato durante una copia iniziale e durante le copie di recupero. Ad esempio, esecuzioni ripetute di RoboCopy /MIR nelle stesse posizioni di archiviazione di origine e di destinazione. Queste esecuzioni ripetute sono utili per ridurre al minimo i tempi di inattività per utenti e app e migliorare la percentuale complessiva di successo dei file migrati.

Spesso si considera la larghezza di banda come fattore più limitante in una migrazione e ciò può essere vero. Tuttavia, la possibilità di enumerare uno spazio dei nomi può influenzare il tempo totale per copiare ancora di più per spazi dei nomi più grandi con file più piccoli. Si consideri che la copia di 1 TiB di file di piccole dimensioni richiederà molto più tempo rispetto alla copia di 1 TiB di meno file più grandi, presupponendo che tutte le altre variabili rimangano invariate. Pertanto, è possibile che si verifichi un trasferimento lento se si esegue la migrazione di un numero elevato di file di piccole dimensioni. Si tratta di un comportamento previsto.

La causa di questa differenza è la potenza di elaborazione necessaria per esaminare uno spazio dei nomi. RoboCopy supporta copie multithread tramite il parametro /MT:n in cui n indica il numero di thread da usare. Pertanto, quando si effettua il provisioning di un computer in particolare per RoboCopy, prendere in considerazione il numero di core del processore e la relazione con il numero di thread fornito. Nella maggior parte dei casi è di due thread per core. Il numero di core e thread di un computer è un punto dati importante per decidere quali valori multithread /MT:n è necessario specificare. Considerare anche il numero di processi RoboCopy che si prevede di eseguire in parallelo in un determinato computer.

Più thread copieranno l'esempio di 1 TiB di file di piccole dimensioni in modo notevolmente più veloce rispetto a un numero inferiore di thread. Allo stesso tempo, l'investimento di risorse aggiuntive sui nostri 1 TiB di file più grandi potrebbe non produrre benefici proporzionali. Un numero elevato di thread tenterà di copiare più file di grandi dimensioni in rete contemporaneamente. Questa attività di rete aggiuntiva aumenta la probabilità di essere vincolati dalla velocità effettiva o dalle operazioni di I/O al secondo di archiviazione.

Durante un primo RoboCopy in una destinazione vuota o in un'esecuzione differenziale con molti file modificati, è probabile che la velocità effettiva della rete sia vincolata. Iniziare con un conteggio elevato dei thread per un'esecuzione iniziale. Un numero elevato di thread, anche oltre i thread attualmente disponibili nel computer, consente di saturare la larghezza di banda di rete disponibile. Le esecuzioni /MIR successive influiscono progressivamente sull'elaborazione degli elementi. Meno modifiche in un'esecuzione differenziale significano meno trasporto di dati in rete. La velocità dipende ora dalla capacità di elaborare gli elementi dello spazio dei nomi piuttosto che spostarli tramite il collegamento di rete. Per le esecuzioni successive, associare il valore del numero di thread al numero di core del processore e al numero di thread per core. Valutare se i core devono essere riservati per altre attività che un server di produzione potrebbe avere.

Suggerimento

Regola generale: la prima esecuzione di RoboCopy, che sposterà molti dati di una rete a latenza più elevata, trae vantaggio dal provisioning eccessivo del numero di thread (/MT:n). Le esecuzioni successive copiano meno differenze e probabilmente si passa dalla velocità effettiva di rete vincolata ai vincoli di calcolo. In queste circostanze, è spesso preferibile associare il conteggio dei thread RoboCopy ai thread effettivamente disponibili nel computer. Il provisioning eccessivo in questo scenario può portare a un maggior numero di cambiamenti di contesto nel processore, probabilmente rallentando la copia.

Evitare operazioni non necessarie

Evitare modifiche su larga scala nello spazio dei nomi, ad esempio lo spostamento di file tra directory, la modifica di proprietà su larga scala o la modifica delle autorizzazioni a livello di file e directory (ACL NTFS). In particolare le modifiche ACL possono avere un impatto elevato perché spesso hanno un effetto di modifica a catena sui file inferiori nella gerarchia di cartelle. Le conseguenze possono essere le seguenti:

  • il tempo di esecuzione del processo RoboCopy potrebbe risultare esteso perché ogni file e cartella interessato da una modifica ACL deve essere aggiornato
  • potrebbe essere necessario copiare nuovamente i dati spostati in precedenza. Ad esempio, sarà necessario copiare più dati quando le strutture delle cartelle cambiano dopo la copia dei file già copiati in precedenza. Un processo RoboCopy non può "riprodurre" una modifica dello spazio dei nomi. Il processo successivo deve eliminare i file precedentemente trasportati nella struttura di cartelle precedente e caricare nuovamente i file nella nuova struttura di cartelle.

Un altro aspetto importante consiste nell'usare lo strumento RoboCopy in modo efficace. Con lo script RoboCopy consigliato, si creerà e si salverà un file di log per gli errori. Gli errori di copia possono verificarsi: è normale. Questi errori spesso rendono necessario eseguire più round di uno strumento di copia come RoboCopy: un'esecuzione iniziale, ad esempio da un NAS a DataBox o da un server a una condivisione file di Azure e una o più esecuzioni aggiuntive con l'opzione /MIR per intercettare e riprovare i file che non sono stati copiati.

È consigliabile prepararsi a eseguire più round di RoboCopy in base a un determinato ambito dello spazio dei nomi. Le esecuzioni successive verranno completate più velocemente perché hanno meno contenuti da copiare, ma sono vincolate sempre più dalla velocità di elaborazione dello spazio dei nomi. Quando si eseguono più round, è possibile velocizzare ogni round impedendo a RoboCopy di copiare inutilmente tutto in una determinata esecuzione. Questi commutatori RoboCopy possono fare una differenza significativa:

  • /R:n n = frequenza con cui si riprova a copiare un file non riuscito e
  • /W:n n = numero di secondi di attesa tra i tentativi

/R:5 /W:5 è un'impostazione ragionevole che è possibile regolare in base alle proprie esigenze. In questo esempio, la copia di un file non riuscita verrà ritentata cinque volte, con un tempo di attesa di cinque secondi tra i tentativi. Se la copia del file non riesce ancora, il processo RoboCopy successivo riproverà. Spesso la copia di file che non riesce perché i file sono in uso o a causa di problemi di timeout potrebbe essere completata correttamente in questo modo.

Stima degli addebiti delle transazioni di archiviazione

Quando si avvia la migrazione a File di Azure, RoboCopy copia i file e le cartelle in Azure. A seconda del modello di fatturazione per File di Azure, potrebbero essere applicati addebiti per le transazioni. Vedere Informazioni sulla fatturazione.

Se si usa un modello di fatturazione con pagamento in base al consumo per le condivisioni file standard di Azure, potrebbe essere difficile stimare il numero di transazioni generate dalla migrazione.

  • Non è possibile stimare il numero di transazioni in base alla capacità di archiviazione utilizzata dell'origine. Il numero di transazioni viene ridimensionato con il numero di elementi dello spazio dei nomi (file e cartelle) e le relative proprietà di cui viene eseguita la migrazione, non le relative dimensioni. Ad esempio, sono necessarie più transazioni per eseguire la migrazione di 1 GiB di file di piccole dimensioni rispetto a 1 GiB di file di dimensioni maggiori.
  • Per ridurre al minimo i tempi di inattività, potrebbe essere necessario eseguire più volte operazioni di copia dall'origine alla destinazione. Tutti gli elementi di origine e di destinazione vengono elaborati durante ogni operazione di copia, anche se le esecuzioni successive terminano più velocemente. Dopo le operazioni iniziali, solo le differenze introdotte tra le esecuzioni di copia vengono trasportate in rete. È importante comprendere che, anche se sono trasportati meno dati, il numero di transazioni necessarie potrebbe rimanere invariato.
  • La copia dello stesso file due volte potrebbe non comportare lo stesso numero di transazioni. L'elaborazione di un elemento migrato in un'esecuzione di copia precedente potrebbe comportare solo poche transazioni di lettura. Al contrario, le modifiche apportate ai metadati o al contenuto tra le esecuzioni di copia potrebbero richiedere un numero maggiore di transazioni per aggiornare la destinazione. Ogni file nello spazio dei nomi potrebbe avere requisiti univoci, con conseguente numero diverso di transazioni.

È consigliabile eseguire alcuni test iniziali sui propri dati per comprendere meglio il numero di transazioni sostenute. In questo modo si avrà un'idea migliore del numero totale di transazioni che potrebbe essere generata da una migrazione di file.

Passaggi successivi

Gli articoli seguenti consentono di comprendere le opzioni avanzate e le procedure consigliate.