Migração para a nuvem: estratégia de transferência de ficheiros

Uma estratégia de transferência de ficheiros para migração para a nuvem depende de três decisões: o caminho de transporte (internet pública, Direct Connect ou dispositivo físico), o modelo de transição (big-bang, faseado ou execução paralela) e as verificações de integridade em que vai confiar. Para um conjunto de dados de 50 TB numa linha de 1 Gbps, conte com cerca de 5 dias de tempo de transferência à velocidade máxima — menos se comprimir, mais se a linha estiver partilhada. Planeie a sequência antes de planear as ferramentas, e orce uma margem de 20% para repetições e reconciliação.

Dimensionar o Conjunto de Dados Antes de Tocar num Cabo

Antes de escolher AWS DataSync, Azure AzCopy ou Google Storage Transfer Service, faça o inventário do que realmente tem. Execute du -sh nas partilhas de ficheiros, consulte os catálogos de bases de dados para contar linhas e exporte manifestos do armazenamento de objetos. Uma empresa de mercado médio que auditei pensava ter 8 TB no NAS; o número real era 34 TB quando se contavam snapshots e ficheiros de bloqueio ~$ do Office ocultos.

Classifique o inventário por três eixos: tamanho, taxa de mudança e peso regulatório. Ficheiros abaixo de 1 MB movem-se devagar por byte por causa da sobrecarga por objeto — um bucket com 200 milhões de ficheiros pequenos pode demorar mais do que um com 10 TB de vídeo. Classifique os dados quentes (que mudam diariamente) separadamente dos dados frios (arquivos .pdf, faturas de 2017). Os dados frios podem ser enviados semanas antes; os dados quentes precisam de lógica de sincronização-até-transição.

Escolher um Transporte que Corresponda ao Prazo

Para menos de 10 TB com uma boa linha de fibra, a transferência online sobre TLS 1.3 geralmente ganha. Entre 10 TB e 500 TB, reserve largura de banda ou provisione AWS Direct Connect / Azure ExpressRoute para evitar saturar a WAN corporativa. Acima de 500 TB, a sementeira física supera a internet: o AWS Snowball Edge comporta 80 TB, o Snowmobile move exabytes num contentor de transporte, e o Azure Data Box Heavy armazena 1 PB.

Faça o cálculo honestamente. A 1 Gbps (125 MB/s sustentado, realisticamente 80 MB/s após sobrecarga), 100 TB demora cerca de 14 dias de débito ininterrupto. Se a janela de operações for de 48 horas, o cabo não é viável — envie discos. Inclua o egress no cálculo: mover 100 TB para fora de um fornecedor mais antigo a 0,09 EUR/GB custa 9.000 EUR antes de tocar no destino.

Integridade: Confie mas Verifique

Cada migração precisa de verificação de integridade ponta a ponta, não apenas TLS ao nível do transporte. Gere hashes SHA-256 ou xxHash64 na origem, transmita-os juntamente com o payload e re-calcule o hash no destino. O AWS DataSync faz isto por defeito; o rsync com --checksum força-o; o rclone suporta --check-first e backends crypt.

Para cargas de trabalho de conformidade, conserve o manifesto — um CSV de caminho, contagem de bytes e hash — para toda a janela de retenção. As entidades cobertas pela HIPAA devem registar cada objeto ao abrigo dos controlos de integridade 45 CFR 164.312(c)(1), e o Artigo 5.º(1)(f) do RGPD exige que demonstre que os ficheiros não foram alterados em trânsito. Um único byte desalinhado num estudo DICOM pode fazer o visualizador de um radiologista recusar-se a abri-lo.

Minimizar o Tempo de Inatividade com Sincronização Delta

As transições big-bang são inimigas do sono. Em vez disso, faça uma cópia em massa inicial semanas antes e depois execute deltas incrementais todas as noites até à janela de transição. Ferramentas como Rclone (--update --use-server-modtime), AzCopy (--overwrite=ifSourceNewer) e o gsutil rsync -d do Google detetam ficheiros alterados por mtime ou hash e movem apenas o delta.

As bases de dados precisam do seu próprio plano. Para uma instância PostgreSQL de 2 TB, use pg_basebackup mais envio de WAL; para MySQL, configure uma réplica no destino e promova-a durante a transição. Os deltas ao nível do sistema de ficheiros via rsync podem reduzir a sincronização final de horas para minutos, o que geralmente cabe dentro de uma janela de manutenção de sábado à noite.

Modelação de Largura de Banda e Transferências por Horário

As migrações que monopolizam toda a WAN terminam mal — os tickets da assistência técnica acumulam-se antes do pequeno-almoço. Limite agressivamente. O AzCopy aceita --cap-mbps, o rclone suporta --bwlimit 50M:100M para taxas diárias/noturnas, e o DataSync agenda tarefas com limites de largura de banda por hora. Uma política sensata: 30% da ligação durante o horário de trabalho, 90% durante a noite, 100% aos fins de semana.

Segmente também o tráfego na firewall. Etiquete os fluxos de migração com um valor DSCP para que as políticas QoS não prejudiquem as chamadas de vídeo. Se estiver a usar MPLS para sucursais, considere a saída SD-WAN local para que o tráfego de migração saia localmente em vez de trocar pela sede.

Gerir Dados Sensíveis em Trânsito

Qualquer migração que inclua DPP, PHI ou dados de titulares de cartões precisa de cifração que cumpra o padrão relevante. TLS 1.3 é o mínimo; para ficheiros em repouso durante a preparação, encapsule com AES-256-GCM antes do carregamento. O Requisito 4.2.1 do PCI DSS 4.0 exige criptografia forte para dados de titulares de cartões em redes públicas, e o padrão endereçável de cifração da HIPAA efetivamente exige-o para ePHI. Em Portugal, o RGPD e a CNPD determinam as mesmas exigências para dados pessoais de residentes europeus.

Para transferências ad hoc de pequenos lotes durante a migração (por exemplo, um consultor a exportar uma tabela do Salesforce ou um DBA a mover um cofre de credenciais), ferramentas com cifração ponta a ponta mantêm as chaves fora do alcance do fornecedor de transporte. O HexaTransfer trata disto de forma limpa para ficheiros únicos durante uma migração — a cifração acontece no browser antes de qualquer coisa tocar num servidor.

Ensaiar a Transição Antes da Transição

Ensaie a migração num subconjunto. Escolha um departamento — por exemplo, 300 GB da unidade partilhada de Marketing — e execute o pipeline completo: inventário de origem, transferência, verificação de checksum, mapeamento de permissões e failover de aplicação. Cronometre cada passo e documente o que falhou.

Surpresas comuns: ACLs NTFS que não se mapeiam claramente para políticas de bucket S3, symlinks que o rclone trata como ficheiros, caminhos de partilha SMB incorporados nas configurações de aplicação, e diferenças de sensibilidade a maiúsculas entre destinos Windows e Linux. Corrija esses problemas em preparação, não às 2 da manhã na noite de go-live. Um ensaio que demora uma semana poupa uma reversão que demora um mês.

Reconciliação Pós-Migração

Declare sucesso apenas após a reconciliação. Compare contagens de objetos de origem e destino, bytes totais e uma amostra aleatória de 1% de hashes. Consulte as métricas da aplicação — se um sistema de gestão de documentos reportou 4,2 milhões de ficheiros e o destino mostra 4,19 milhões, encontre os 10.000 em falta antes de desligar a origem.

Mantenha a origem em modo de apenas leitura durante pelo menos 30 dias após a transição. Os utilizadores invariavelmente precisarão de um ficheiro que não migrou porque estava em ~/Ambiente de Trabalho/coisas_antigas/ em vez da partilha inventariada. Orce para isso, não se surpreenda com isso, e escreva o runbook de reversão antes de precisar dele.

Experimente em hexatransfer.com — gratuito, sem conta necessária, máximo de 10 GB.