Migrazione al cloud: strategia di trasferimento file

Una strategia di trasferimento file per la migrazione al cloud dipende da tre decisioni: il percorso di trasporto (internet pubblico, Direct Connect o appliance fisica), il modello di cutover (big-bang, a fasi o parallel-run), e i controlli di integrità di cui ti fiderai. Per un parco dati da 50 TB su una linea da 1 Gbps, aspettati circa 5 giorni di puro trasferimento alla velocità del filo — meno se comprimi, di più se la linea è condivisa. Il GDPR e il Garante per la protezione dei dati personali richiedono che i dati personali in transito siano crittografati con TLS 1.3 come minimo: pianifica la sequenza prima degli strumenti, e prevedi il 20% di margine per retry e riconciliazione.

Dimensionare il dataset prima di toccare un filo

Prima di scegliere AWS DataSync, Azure AzCopy o Google Storage Transfer Service, inventaria ciò che hai davvero. Esegui du -sh sulle condivisioni file, interroga i cataloghi del database per i conteggi delle righe ed esporta i manifest dell'object store. Un'azienda di medie dimensioni che ho verificato pensava di avere 8 TB sul suo NAS; il numero reale era 34 TB una volta contati gli snapshot e i file di blocco Office ~$ nascosti.

Classifica l'inventario in base a tre assi: dimensione, tasso di cambiamento e peso normativo. I file sotto 1 MB si spostano lentamente per byte a causa dell'overhead per oggetto — un bucket con 200 milioni di file piccoli può richiedere più tempo di uno con 10 TB di video. Classifica i dati caldi (che cambiano quotidianamente) separatamente dai dati freddi (archivi .pdf, fatture del 2017). I dati freddi possono essere trasferiti settimane prima; i dati caldi necessitano di logica sync-until-cutover.

Scegliere un trasporto che corrisponda alla timeline

Per meno di 10 TB con una buona linea in fibra, il trasferimento online su TLS 1.3 di solito vince. Tra 10 TB e 500 TB, riserva larghezza di banda o provisiona AWS Direct Connect / Azure ExpressRoute per evitare di saturare la WAN aziendale. Sopra i 500 TB, il seeding fisico batte internet: AWS Snowball Edge tiene 80 TB, Snowmobile sposta exabyte in un container, e Azure Data Box Heavy archivia 1 PB.

Fai il calcolo onestamente. A 1 Gbps (125 MB/s sostenuti, realisticamente 80 MB/s dopo l'overhead), 100 TB richiede circa 14 giorni di throughput ininterrotto. Se la tua finestra operativa è di 48 ore, il filo non è praticabile — spedisci dischi. Considera l'egress: spostare 100 TB fuori da un provider precedente a 0,09 $/GB costa 9.000 $ prima ancora di toccare la destinazione.

Integrità: fidati ma verifica con checksum

Ogni migrazione necessita di verifica dell'integrità end-to-end, non solo TLS a livello di trasporto. Genera hash SHA-256 o xxHash64 alla sorgente, trasmettili insieme al payload e ricalcolali alla destinazione. AWS DataSync fa questo di default; rsync con --checksum lo impone; rclone supporta --check-first e backend crypt.

Per i carichi di lavoro di conformità, conserva il manifest — un CSV di percorso, byte-count e hash — per l'intera finestra di retention. L'Articolo 5(1)(f) del GDPR richiede di dimostrare che i file non sono stati alterati in transito. Un byte disallineato in uno studio DICOM può far rifiutare l'apertura al visualizzatore di un radiologo.

Minimizzare i tempi di inattività con la sincronizzazione delta

I cutover big-bang sono nemici del sonno. Invece, esegui una copia bulk iniziale settimane prima, poi sincronizzazioni incrementali notturne delta fino alla finestra di cutover. Strumenti come Rclone (--update --use-server-modtime), AzCopy (--overwrite=ifSourceNewer) e gsutil rsync -d di Google rilevano i file modificati per mtime o hash e spostano solo il delta.

I database necessitano di un piano proprio. Per un'istanza PostgreSQL da 2 TB, usa pg_basebackup più WAL shipping; per MySQL, configura una replica sulla destinazione e promuovila durante il cutover. I delta file-system su rsync possono ridurre la sincronizzazione finale da ore a minuti, che di solito rientra in una finestra di manutenzione del sabato sera.

Shaping della banda e trasferimenti nelle ore notturne

Le migrazioni che saturano tutta la WAN finiscono male — i ticket dell'help desk si accumulano prima di colazione. Throttle aggressivamente. AzCopy accetta --cap-mbps, rclone supporta --bwlimit 50M:100M per tariffe giorno/notte, e DataSync pianifica le attività con limiti di banda per ora. Una policy ragionevole: 30% del collegamento durante le ore lavorative, 90% di notte, 100% nei weekend.

Segmenta il traffico anche al firewall. Tagga i flussi di migrazione con un valore DSCP in modo che le policy QoS non affamino le chiamate Zoom. Se usi MPLS per le filiali, considera il breakout SD-WAN in modo che il traffico di migrazione esca localmente anziché fare trombone attraverso la sede centrale.

Gestire i dati sensibili in transito

Qualsiasi migrazione che include dati personali, sanitari o di titolari di carta richiede crittografia che soddisfi lo standard rilevante. TLS 1.3 è il minimo; per i file a riposo durante la staging, avvolgi con AES-256-GCM prima dell'upload. Il requisito 4.2.1 di PCI DSS 4.0 impone crittografia robusta per i dati del titolare di carta su reti pubbliche, e il GDPR richiede di fatto misure tecniche adeguate per i dati personali.

Per i trasferimenti ad hoc di piccoli batch durante la migrazione — pensa a un consulente che esporta una tabella Salesforce o un DBA che sposta un vault di credenziali — gli strumenti con crittografia end-to-end mantengono le chiavi fuori dalla portata del provider di trasporto. HexaTransfer gestisce questo in modo pulito per i file singoli durante una migrazione — la crittografia avviene nel browser prima che qualsiasi cosa tocchi un server.

Testare il cutover prima del cutover

Fai una prova generale della migrazione su un sottoinsieme. Scegli un dipartimento — diciamo, 300 GB della condivisione drive del Marketing — ed esegui l'intera pipeline: inventario sorgente, trasferimento, verifica checksum, mappatura dei permessi e failover dell'applicazione. Cronometra ogni step e documenta cosa si è rotto.

Sorprese comuni: ACL NTFS che non si mappano pulitamente alle policy bucket S3, symlink che rclone tratta come file, percorsi di condivisione SMB incorporati nelle configurazioni delle applicazioni, e differenze di case-sensitivity tra destinazioni Windows e Linux. Correggile in staging, non alle 2 del mattino nella notte del go-live. Una prova generale che richiede una settimana evita un rollback che richiede un mese.

Riconciliazione post-migrazione

Dichiara il successo solo dopo la riconciliazione. Confronta conteggi degli oggetti, byte totali e un campione hash casuale dell'1% tra sorgente e destinazione. Interroga le metriche delle applicazioni — se un sistema di gestione documentale riportava 4,2 milioni di file e la destinazione mostra 4,19 milioni, trova i 10.000 mancanti prima di spegnere la sorgente.

Mantieni la sorgente in sola lettura per almeno 30 giorni dopo il cutover. Gli utenti inevitabilmente accederanno a un file che non è stato migrato perché si trovava in ~/Desktop/roba_vecchia/ anziché nella condivisione inventariata. Mettilo in budget, non sorprenderti, e scrivi il runbook di rollback prima di averne bisogno.

Prova su https://hexatransfer.com — gratuito, senza account, max 10 GB.