Prove que você consegue deixar seu fornecedor de armazenamento: execute um Simulado Trimestral de Egresso

Quando uma afiliada da PBS disse recentemente que um provedor de armazenamento em nuvem a "ghosted" (parou de responder) — deixando cerca de 50 TB de dados em risco — a dor reverberou pelos canais de engenharia no Slack. Se o seu fornecedor de armazenamento parasse de responder amanhã, em quantas horas você conseguiria extrair seus conjuntos de dados críticos? Quanto isso custaria? Quem é o dono do runbook? A maioria das equipes não consegue responder sem ressalvas. Isso é um modo de falha.

Você testa backups. Você pratica resposta a incidentes. Mas provavelmente não ensaiou o movimento que mais importa quando a relação com um fornecedor azeda: tirar seus bytes de lá — rápido, íntegros e sem se quebrar com taxas de egresso (saída). Em 2026, egresso de armazenamento é um risco de continuidade de negócios, não um caso de borda.

O problema não é só indisponibilidade. É custódia.

"Ser ghosted por um fornecedor" vai além de indisponibilidade. Inclui:

• Falha no plano de controle: o suporte deixa de responder; mudanças em IAM ou bloqueios de cobrança o tiram do sistema; as APIs de listagem se degradam; limites de taxa (rate limits) estrangulam você quando começa a copiar dados para fora.
• Incompatibilidades silenciosas: "compatível com S3" não garante as semânticas das suas ferramentas. ETags multipart diferem, a paginação de ListObjectsV2 pode ser lenta com prefixos profundamente aninhados, e versionamento de objetos ou retenções legais podem bloquear exclusões e movimentações.
• Bombas de custo: Egresso a US$ 0,02–0,09/GB parece inofensivo até você mover dezenas de terabytes sob forte pressão de tempo.

O risco não é teórico. Arquivos de mídia, imagens médicas, corpora de treinamento de ML, logs, artefatos de build e até uploads de clientes se acumulam em object stores fáceis de encher e difíceis de esvaziar sob pressão. Não dá para resolver isso em planilha; você precisa de throughput medido, integridade verificada e um simulado que encontre os cortes de papel antes que eles te sangrem.

Um framework para CTOs: o Simulado Trimestral de Egresso

Objetivo: provar que você consegue extrair uma fatia representativa dos seus dados — ponta a ponta — em 48 horas, com verificação de integridade e um envelope de custos pré-negociado. Faça isso todo trimestre. Torne-o entediante.

1) Escolha um corpus representativo (5–10% do total)

• Inclua objetos grandes (mídia de 1–20 GB, checkpoints de modelos) e objetos pequenos (logs de 1–100 KB, miniaturas). Objetos pequenos limitam você em list+open; os grandes exercitam pipelines multipart.
• Espelhe suas semânticas reais: buckets versionados, Object Lock (compliance/governança), árvores de prefixos profundas e casos de borda incômodos (chaves com espaços, unicode).
• Tamanho alvo: 2–10 TB se você tem 20–100 TB no total. O objetivo é revelar o comportamento, não replicar a fatura inteira todo trimestre.

2) Pré-provisione um destino que você controla

• Use um segundo provedor com dentes contratuais (ex.: Cloudflare R2, AWS S3, Azure Blob) ou rode seu próprio endpoint S3 (ex.: MinIO) em um cluster efêmero com NICs de 10/25/40 Gbps.
• Mantenha credenciais separadas e acessíveis via break-glass. Não dependa do plano de controle do provedor de origem para autenticar o destino.
• Ative a criptografia no servidor no destino e armazene chaves gerenciadas pelo cliente (BYOK) no seu próprio KMS, não no provedor de origem.

3) Construa um manifesto canônico e um plano de integridade

• Para cada objeto: armazene chave, tamanho, version-id (se houver), last-modified, SHA-256. Não confie em ETags multipart como se fossem MD5; não são.
• Use o inventory export do seu provedor (ex.: S3 Inventory) como base e depois calcule checksums faltantes com um job de map único.
• Após a cópia, verifique 100% dos objetos por tamanho e SHA-256 e amostre 1–5% com comparação byte a byte para garantia adicional.

4) Escolha ferramentas e paralelismo

• rclone para cópias entre provedores com checksums embutidos (--transfers, --checkers, --s3-chunk-size, --s3-upload-concurrency).
• s5cmd para milhões de arquivos pequenos; ele paraleliza list/copy de forma mais agressiva do que o AWS CLI.
• Para volume dentro de uma única nuvem, use ferramentas nativas do provedor em batch (aws s3 cp/sync com flags cuidadosas) para evitar gargalos atravessando a Internet pública.
• Comece com 64–256 transferências concorrentes, 64–128 checkers e partes multipart de 64–128 MiB. Faça profiling, não chute.

5) Faça a matemática de banda antes de aprender do jeito difícil

Conversão aproximada: 1 TB ≈ 8.192 Gbit. Tempo (horas) ≈ (TB × 8.192) / Gbps do link / 3600.

• Em 1 Gbps, 50 TB dá ~114 horas (~4,7 dias) se você saturar o link. Você não vai.
• Em 10 Gbps, 50 TB são ~11,4 horas na teoria; planeje 18–24 horas com overhead de protocolo e estrangulamento do object store.
• Em 2 Gbps (uplink típico de escritório), 10 TB ainda podem levar ~11–14 horas — se sua performance de listagem e cotas de API acompanharem.

Dica prática: quando origem e destino estão em nuvens diferentes, puxe a partir de compute próximo da origem (mesma região) e então envie por um interconnect dedicado ou por um caminho de egresso de alta vazão que você controla. Não faça backhaul de centenas de TB por um único NAT no seu escritório.

6) Coloque um preço real no egresso

• A US$ 0,02–0,09/GB, mover 50 TB custa US$ 1.000–4.500 só para sair — antes de computação e storage de destino.
• Alguns fornecedores anunciam “sem taxas de egresso” com limites ou cláusulas de comportamento. Leia-as. Se um simulado disparar revisão ou throttling, isso não é liberdade de verdade.
• Negocie agora: inclua uma cláusula de "egresso sem taxa na rescisão" e uma de "simulado trimestral de até N TB com egressos isentos". Se houver resistência, precifique explicitamente o risco no seu modelo de TCO.

7) Defina critérios de sucesso

• Tempo até o primeiro byte: quão rápido você consegue autenticar e iniciar uma transferência quando o pager dispara?
• Throughput sustentado: Gbps médio por um período estável de 2–6 horas. Qualquer coisa abaixo de 30–50% do teórico precisa de diagnóstico.
• Integridade de ponta a ponta: 100% de correspondência de tamanho; 100% de correspondência de checksum; zero arquivos corrompidos; o log de auditoria mostra cobertura completa.
• Custo total: Egresso + computação + storage de destino e quaisquer taxas de cross-connect.
• Proprietário do runbook: Pessoas nomeadas; credenciais de break-glass testadas; a escala de plantão inclui o simulado.

Arquiteture para saídas antes de precisar delas

Construa para portabilidade de S3 — mas verifique os cantos

• Mantenha-se no mínimo denominador comum: PUT/GET simples, regras de lifecycle que você consegue replicar e evite políticas proprietárias que não dá para traduzir. Onde precisar do proprietário, isole atrás da sua própria abstração.
• Versioning e Object Lock são boas redes de segurança, mas confirme que retenções de governança/legais não vão bloquear cópias. Nos simulados, use um bucket com controles idênticos aos de produção.
• Listagem é o gargalo escondido. Buckets com dezenas de milhões de objetos minúsculos rastejam. Use compactação (agrupe arquivos pequenos em Parquet/ORC ou segmentos tar) e particionamento por prefixo (yyyy/mm/dd/...) para limitar operações de listagem.

Seja dono das suas chaves de criptografia

• Se seus dados estiverem trancados atrás do KMS do provedor de origem, um congelamento de conta pode virar um congelamento de dados. Prefira BYOK quando possível; no mínimo, mantenha material de chave exportável ou faça dupla criptografia de arquivos sensíveis antes do upload.
• Não descubra no meio do simulado que uma retenção de compliance em uma chave impede leituras. Teste rotação de chaves e caminhos de restauração regularmente.

Mantenha a contagem de objetos sob controle

• Controlar 200 milhões de objetos de 1 KB é "fofo" até que seus limites de ListObjectsV2 dominem o relógio. Limite a contagem de objetos por prefixo; imponha compactação nos pipelines de ingestão; rejeite PRs que criem objetos por linha sem compactação.

Designe um “golden manifest”

• Armazene o manifesto autoritativo (chave, tamanho, checksum) fora do provedor de origem — por exemplo, no seu repositório de operações versionado em git e em um object store separado — para poder verificar de forma independente.

E quanto a volumes em bloco, bancos de dados e blobs só em SaaS?

Volumes em bloco (snapshots)

• Automatize a exportação de snapshots para imagens brutas (ex.: VMDK/VHD ou raw) para um object storage que você controla. Teste uma restauração a frio em um hypervisor diferente uma vez por trimestre.
• Meça o tempo de restauração com limites realistas de IOPS. Se seu RTO depende de créditos de burst, você não tem um RTO.

Bancos de dados

• Faça exports lógicos (ex.: pg_dump/mysqldump) semanais para schemas críticos no seu próprio bucket. Mantenha scripts de schema+migração versionados.
• Ensaiar uma importação a frio em um provedor alternativo (gerenciado ou self-hosted). “Usamos replicação” não substitui “reconstruímos a partir de dumps em 90 minutos”.

Blobs embutidos em SaaS

• Documentação de produto, assets de design e logs presos em SaaS (Figma, Notion, Sentry, plataformas de mídia do fornecedor) são fáceis de esquecer. Crie exports agendados via APIs para o seu bucket. Se um fornecedor não tem API de exportação, isso é uma linha de risco, não uma nota de rodapé.

Números reais de campo

• Evacuação de mídia em 15 horas, 20 TB: Movendo um corpus de mídia misto (objetos de 1–8 GB) com rclone (--transfers 128, --s3-chunk-size 128M, --s3-upload-concurrency 32) sobre um link de 10 Gbps sustentou ~3,5 Gbps após throttling de API e overhead de TLS. O egresso total foi de ~US$ 200 com preço promocional de US$ 0,01/GB.
• Imposto dos objetos pequenos, 200M de chaves: Um bucket de logging com objetos de 1–4 KB bateu nos limites de ListObjectsV2 e no overhead de abrir/fechar no lado da aplicação. Mesmo com 10 Gbps teóricos, o throughput efetivo ficou em < 200 Mbps. Compactar em Parquet por hora reduziu a contagem de objetos em 1000x e transformou uma semana em horas.
• O uplink do escritório é uma armadilha: Uma equipe tentou puxar 8 TB por uma VPN de escritório de 1 Gbps, saturando por dias e acionando resets de firewall. Executar os jobs de cópia a partir de computação na mesma região da origem concluiu em menos de 8 horas com as mesmas ferramentas.

Não esqueça a governança: contratos e SLAs

• Egresso sem taxa na rescisão: Especifique. Quantifique: “Até X TB, Y dias, Z requisições, sem taxas”.
• Franquia para o simulado trimestral: Inclua uma janela de teste (ex.: 5–10 TB por trimestre) com throttling suspenso e suporte de prontidão.
• Matriz de compatibilidade com S3: Peça uma lista por escrito: comportamento de ETag multipart, tamanho máximo de parte, QPS de ListObjectsV2, semânticas de versionamento, paridade de Object Lock, garantias de leitura após escrita eventual vs. forte.
• Escalonamento de suporte: Contrate um caminho de escalonamento nomeado e um SLA de resposta para questões de egresso. Se não houver compromisso, esse é o seu sinal.

Rode isso com uma equipe follow-the-sun

Esses simulados são perfeitos para uma equipe nearshore. Você ganha 6–8 horas de sobreposição com os EUA para kickoffs e passagens de bastão e, depois, progresso contínuo enquanto você dorme. Na DHD Tech no Brazil, já estruturamos simulados de egresso com uma dupla em rotação: um engenheiro conduz a cópia/verificação durante o horário dos EUA, outro mantém o pipeline até a noite, registrando estatísticas concretas de throughput, somatórios de custo e PRs de correção para compactação e higiene de prefixos. De manhã, você tem um postmortem limpo e um manifesto validado.

Um plano 30/60/90 para começar neste trimestre

Dias 1–30: Prove que você consegue mover 2–5 TB

• Escolha um bucket alvo e separe uma fatia de 5% com pathing, tamanhos de objetos e controles do mundo real.
• Provisione um destino (segundo provedor ou MinIO) e conecte credenciais de break-glass.
• Gere um manifesto e checksums; rode a primeira cópia com rclone ou s5cmd; registre throughput e custo.
• Abra JIRAs para os problemas descobertos: lacunas de compactação, hotspots de prefixo, limites de throttling, falta de BYOK.

Dias 31–60: Remova os gargalos

• Implemente compactação para objetos pequenos daqui para frente; faça backfill nos piores casos.
• Eleve limites de QPS ou paralelismo onde for seguro; adicione computação efêmera próxima aos buckets de origem.
• Negocie aditivos contratuais: egresso sem taxa na rescisão, janelas de simulado trimestrais, atestado de compatibilidade com S3.

Dias 61–90: Simulado completo, visibilidade executiva

• Execute um simulado de 10 TB de ponta a ponta dentro de uma janela de 48 horas.
• Publique um dashboard de uma página: Gbps sustentados, horas totais, taxa de aprovação de integridade e custo por TB.
• Institucionalize: agende o próximo simulado; adicione links do runbook e localizações dos manifestos ao seu BCP.

Boa engenharia é sobre provar reversibilidade

É fácil fazer upload. É difícil sair. Essa assimetria é o seu risco. Um simulado trimestral de egresso força sua arquitetura, seus contratos e sua higiene operacional a provarem que funcionam ao contrário. Você vai encontrar nomes DNS obsoletos em regras de lifecycle, políticas de IAM que pareciam ok até bloquearem cópias headless, buckets com 100 milhões de objetos zumbis e chaves de KMS cuja política de rotação teria paralisado você em um incidente real.

Corrija isso no seu tempo — não no do fornecedor.

Principais pontos

• Se um fornecedor te "ghostar", você tem um problema de custódia, não apenas de confiabilidade. Pratique saídas.
• Rode um simulado trimestral de egresso em 5–10% dos seus dados; verifique SHA-256 e meça throughput e custo reais.
• Objetos pequenos destroem a performance. Compacte em Parquet/ORC e particione prefixos para limitar o overhead de listagem.
• BYOK ou dupla criptografia para que a custódia da chave não vire custódia do dado.
• Negocie egresso sem taxa na rescisão e uma franquia de simulado trimestral no contrato.
• Posicione computação próxima da origem para evitar gargalos no uplink do escritório; use rclone/s5cmd com paralelismo agressivo.
• Mantenha um golden manifest fora do provedor de origem; verifique 100% e faça amostragem com comparação byte a byte.
• Equipe os simulados com um pod nearshore para 6–8 horas de sobreposição e impulso 24h; publique um scorecard pronto para executivos.