Migração de infraestrutura não é um negócio fácil, e quando envolve dinheiro fica pior. Li o relatório do Abacate Pay inteiro e tiro o chapéu pela transparência. Aqui eu junto as lições deles com as minhas — incluindo o dia em que a gente descobriu que todas as cópias de backup estavam corrompidas.
Resposta rápida: backup só vira backup depois que você restaura e confere. O roteiro que eu uso: 1) backup automático por script, todo dia, porque ser humano falha; 2) teste de restore no máximo uma vez por mês, num banco de staging, com o sistema conectado nele pra valer; 3) antes de restaurar, desliga o proxy de conexão — ou a própria API — pra ninguém escrever no meio; 4) janela de manutenção de verdade pra testar a teoria aplicada, em pedaços antes do global; 5) rollback testado em produção, não no papel: eu viro a chave entre Brasil e Estados Unidos de madrugada; 6) conte o tempo de reaquecer o cache no seu plano — cache quente não volta na hora; 7) em multicloud, olhe a camada de baixo: mesma rede de trânsito IP ou mesmo DNS = ponto único de falha; 8) backup não é redundância — réplica copia o arquivo corrompido junto, versionamento de objeto salva.
Gravei esses 17 minutos no canal @josimarjmv, publicados em 9 de julho de 2026. Assista e leia junto: aqui embaixo eu abro cada lição com calma, com a cronologia do relatório deles na mão e com o que eu faço na minha operação.
🎧 PREFERE OUVIR? · 17 min
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Vou dar a minha carteirada antes, porque análise de incidente alheio virou esporte de rede social. Eu sou CEO de uma empresa de tecnologia, tenho infraestrutura em data center no Brasil e nos Estados Unidos e trafego centenas de terabytes de vídeo por dia. No quinto dia útil quem paga a conta desse ambiente sou eu. Não é palpite de fora: é o que eu opero.
E antes da primeira lição, o mais importante: vai aqui a minha admiração pela transparência do pessoal do Abacate Pay, e o meu respeito. É difícil uma empresa ser transparente do jeito que eles foram — publicaram a cronologia certinha, o horário de cada coisa que aconteceu, com muita seriedade. Meus parabéns de verdade à equipe. Transparência é um dos valores que eu tenho na minha empresa e é inegociável, com colaborador e com todo mundo. Quando mexe com grana então, sem transparência o negócio não anda.
Então trate o que vem abaixo como o que é: lição deles e lição minha. Coisa parecida já aconteceu aqui dentro. Eu escrevo isso pro amigo dev que carrega o piano da empresa sozinho, pro que coordena uma equipe pequena, pro dono de empresa e pro que está montando a dele agora — porque essas maldades ninguém conta antes, só depois que dói.
Apuração minha, feita em 25/09/2026, pra você não depender da minha memória: o relatório público de incidente do Abacate Pay, dos dias 16 e 17 de janeiro de 2026, descreve mais de 36 horas de impacto intermitente e contínuo durante uma migração planejada pro lançamento da plataforma v2. O ponto que resume tudo é esse: a infraestrutura principal de produção não podia ser recriada ou replicada de forma imediata em outro ambiente.
Da cronologia deles, três marcas que valem mais que mil opiniões: o acesso ao banco foi interrompido às 00h20 do dia 16 pra iniciar a migração; poucas horas depois, às 07h03, apareceu um gargalo crítico nas conexões com o banco de dados; e só às 13h20 do dia 17 se descobriu que o proxy não estava habilitado no DNS, o que deixou entrar tráfego indevido e afundou a performance. Havia estratégia multicloud, mas os componentes críticos não estavam replicados entre os provedores — e é por isso que o rollback e o failover rápido não aconteceram.
No fim, eles listaram 17 ações corretivas, e algumas parecem tiradas do caderno de quem já apanhou: janela de manutenção comunicada, replicação dos componentes críticos entre nuvens, infraestrutura como código versionada, estratégia de rollback testada, critérios de go/no-go, simulação de incidentes e validação pós-deploy. Essa lista é um presente pra quem quiser aprender sem pagar o pedágio.
O primeiro do primeiro do primeiro de tudo é backup. Mas não é "ah, legal, vou fazer o backup e soltar lá". É fazer o backup e testar a restauração dele. Enquanto você não restaurou, você tem um arquivo. Arquivo não é backup.
Isso já aconteceu aqui na empresa e eu conto sem vergonha nenhuma: fizeram backups de gigas e gigas e gigas de um banco PostGIS. Rodava bonitinho, a cópia estava lá, todo mundo dormindo tranquilo no travesseiro. Aí foi fazer uma atualização de infraestrutura, foi restaurar — e descobriu-se que o backup estava corrompido na hora de zipar e compactar. Todas as cópias estavam corrompidas. Por sorte a gente não precisou restaurar de verdade; foi descoberto a tempo.
Para e pensa nisso um minuto: se tivesse caído tudo naquele dia, ia dar pau. Não existia backup, existia a sensação de backup. E sensação de backup é pior que backup nenhum, porque com ela você aprova migração, aprova atualização e dorme achando que tem rede embaixo. Eu já contei aqui como eu perdi o meu medo de subir em produção, e o resumo é esse: o medo vai embora quando a volta está testada, não quando você fica repetindo que vai dar certo.
Essa é uma lição que o próprio caso deles deixa clara, e eu assino embaixo. Quando você vai restaurar um backup grande, tem que desligar toda a comunicação com o banco. Usa um proxy de conexão entre as APIs e o banco? Desliga o proxy. "Ah, mas a minha API conecta direto no banco." Então desliga a API. Seja lá qual for o meio de conexão, derruba, restaura, confere e só então religa.
Não importa o banco: MySQL, MariaDB, PostgreSQL, Elasticsearch, Mongo com réplica e shard, distribuído ou não. A regra é a mesma, porque o inimigo é o mesmo: alguém escrevendo no banco enquanto você escreve o passado por cima. Aí você não tem mais nem o dado velho nem o dado novo — tem uma mistura que ninguém sabe auditar.
O backup tem que ser automático. Automático mesmo, com hora marcada. E o motivo é simples: ser humano falha. Cansa, esquece, viaja, fica doente, sai da empresa. Rotina que depende de alguém lembrar toda sexta-feira não é rotina, é aposta.
Monta um script e uma telinha. Eu criei um painel pra gerir toda a minha infraestrutura porque não tinha nada pronto que se adequasse ao meu negócio — e hoje, com as ferramentas de IA que a gente tem, escrever esse script é a parte fácil do serviço. O desenho é sempre o mesmo: cron em tal hora, faz o dump, compacta, salva no destino, registra que deu certo. Se não deu, grita.
E aí vem a parte que quase ninguém faz: pega o último backup e manda restaurar no banco de staging. Restaurou? Conecta o seu ambiente de staging nesse banco e testa se está funcionando direitinho. Confere as tabelas, confere as linhas, confere se o dado de ontem está lá. Funcionou certinho? Beleza, agora você está tranquilo — e tranquilidade em infra sempre tem prova, nunca tem fé. Sem log e observabilidade de verdade, você nem fica sabendo que a automação parou de rodar.
Aqui eu vou contrariar muita gente: eu não conheço nenhuma empresa que tenha o ambiente de staging igual ao de produção, até porque não se paga. O Google não tem. Não tem mesmo — eu falo isso porque eu converso com os caras, já falei de infraestrutura com gente grande. O que existe é o mais próximo possível, com simulador.
E por que nunca fica igual? Porque o pau da produção tem dois nomes: carga e usuário imprevisível. A maravilha da informática é a coisa que acontece que ninguém esperava — e é justamente pra isso que a gente está lá. Simulador reproduz a carga; ninguém reproduz o ser humano criativo do outro lado da tela.
O que dá pra fazer é o caminho do meio: teste pequeno, teste médio, ambiente de staging com simulador, e gastar uma grana nisso no começo. Só não caia na conversa de que o verde no staging quer dizer que a produção vai aguentar. Não quer.
A gente tem que trabalhar de forma preditiva, não reativa. E o melhor exemplo disso não está na tecnologia, está na aviação — um dos transportes mais seguros que se tem notícia.
Já parou pra pensar por que existe avião de 30, 40 anos rodando? Quarenta anos atrás eu tinha um Fusca; o Fusca hoje nem anda. O segredo é que, na aviação, as peças têm tempo pra serem trocadas mesmo estando funcionando. Imagina que o carburador foi feito pra durar três anos: com dois anos e meio você troca e bota um novo. Não se espera falhar — porque se falhar, cai, e mata gente.
Em desenvolvimento e infraestrutura é a mesma coisa. Certificado que vence, disco com horas de uso, versão de banco que sai de suporte, chave de API que expira, fonte de servidor que já rodou demais: tudo isso tem vida útil e todo mundo age como se não tivesse, até o dia do incidente. Trocar peça boa antes da hora parece desperdício até você ver a fatura de uma hora parado.
Me perguntam como eu testo o ambiente do Brasil contra o dos Estados Unidos. "Ah, você sobe uma VM de teste no staging." Tenho isso tudo, sim. Você acha que eu confio só nisso?
Eu sou doente com isso, admito. De madrugada eu viro a chave inteira de um lado pro outro pra ver se aguenta o tranco. Eu tenho estatística da hora em que tem uso; então meia-noite, às vezes duas da manhã, eu sento e derrubo na produção pra ver se vira direitinho. Se não virar, eu subo na hora, porque o rollback já está prontinho antes de eu começar. Sem a volta pronta, isso não é teste, é roleta.
Esse é exatamente o ponto que faltou no caso deles: tinham dois ambientes, mas não tinham feito a virada de chave em produção pra valer. É uma diferença sutil na planilha e brutal na hora do aperto. Tirar janela de manutenção pra testar a teoria aplicada é obrigação, não luxo: testar se o rollback funciona, se o proxy direciona certo pro ambiente reserva, se a VM do outro lado aguenta o que a primeira aguentava.
E olha quem faz isso com método: o meu data center. Todo mês eu recebo um e-mail com aviso em vermelho dizendo que vão desligar a energia elétrica e que o resultado esperado é zero impacto — os nobreaks seguram a queda de tensão e os motores a diesel assumem a carga. Antes de desligar tudo, eles desligam um pedacinho, veem se dá certo, depois outro, e só então o global. Checagem minha: pelo sistema de classificação do Uptime Institute, um data center Tier III é concurrently maintainable — "these facilities require no shutdowns when equipment needs maintenance or replacement", com caminhos de distribuição redundantes, e é isso que permite testar o gerador sem derrubar a operação de TI. Eu não tenho data center próprio, que dizer, isso é coisa de bilhões de reais; eu tenho infraestrutura dentro de um, no mesmo ambiente onde está gente muito maior que eu — guardadas as devidas proporções. E eu copio o método deles porque ele funciona.
Essa é a lição que quase ninguém coloca no plano de recuperação, e ela sozinha explica muito "voltou, mas está lento". Tem sistema cuja recuperação é lenta por natureza — e cache é o campeão.
No meu caso envolve um volume alto: eu trafego vídeo, são centenas de terabytes por dia, com camadas de cache e pontos de presença de distribuição. Quando um desses pontos cai, ou quando o cache quente precisa ser resetado, ele tem que esquentar de novo. E esquentar leva tempo e cobra pedágio: sobrecarrega disco, memória, processamento e a rede inteira enquanto isso acontece.
Ou seja: o seu tempo de recuperação não é o tempo de subir a máquina. É o tempo de subir a máquina mais o tempo de o sistema voltar ao regime normal. Quem promete "em cinco minutos está tudo no ar" nunca resetou cache de verdade em produção com gente usando. E, sim, isso muda o peso que infraestrutura tem na era da IA: quanto mais o seu produto depende de resposta rápida, mais caro fica cada minuto de reaquecimento.
Quando você vai pra multicloud ou multirregião, precisa ter maldade. Maldade aqui é pergunta chata: o backbone passa por onde? O trânsito IP é de quem? E o DNS, está pendurado onde?
Porque acontece muito de as duas VMs, de nuvens diferentes, usarem a mesma rede de trânsito IP — e aí, quando dá problema de banda, dá nas duas. Ou de o DNS dos dois ambientes estar no mesmo provedor. A gente já viu a Cloudflare dar problema, já viu a Amazon dar problema. Se o seu plano B depende do mesmo elo que o plano A, você não tem plano B.
Redundância de verdade é em todos os níveis ao mesmo tempo: DNS, endereços IP (com VIP ou sem), storage, memória, banco de dados e API. E não é aquela palhaçada de achar que redundância é botar dez réplicas no autoescale pra aplicação escalar magicamente — autoescale não salva aplicação ruim, só multiplica o problema e a fatura. Sincronização de banco de dados com 100, 150 milissegundos de latência entre pontos é assunto complicadíssimo, assíncrono, cheio de decisão difícil. Isso se projeta antes, não no meio do incidente. É a mesma conta que eu fiz quando escrevi sobre o que acontece se cortarem o cabo submarino: a dependência que você não enxerga é a que te derruba.
Antes de eu fechar, um cuidado que eu quero que você leve: backup é diferente de redundância. Não confunde isso.
Redundância é a mesma coisa em dois lugares ao mesmo tempo. Imagina um arquivo PDF replicado: por algum motivo ele corrompe, mandaram errado, o upload cortou no meio — o A e o B corromperam juntos, porque a réplica copiou fielmente o estrago. Backup é uma cópia de outro momento no tempo, e é isso que faz dele um backup.
Por isso você não pode sincronizar em tempo real sobrepondo a cópia anterior e chamar aquilo de backup. A não ser que você use versionamento: a cada novo arquivo enviado, gera-se uma versão nova e a anterior continua lá. Checagem minha: a documentação do Amazon S3 sobre versionamento diz literalmente que "versioning-enabled buckets can help you recover objects from accidental deletion or overwrite" — e que, ao sobrescrever, o resultado é uma nova versão do objeto, com a anterior recuperável. Fica o aviso de bolso: cada versão é cobrada como um objeto inteiro, não como diferença. Versionamento é seguro pago em armazenamento.
Essa galera que passou por incidente grande hoje é madura justamente por isso. E eu me incluo no time dos precavidos: eu sou medroso, eu sou cagão mesmo — com um monte de coisa. Não porque dá certeza de alguma coisa, mas porque é assim que a gente aprende mais um pouco e erra menos onde dói. E onde dói é no cliente: quando impacta o cliente, o cliente vai embora.
Gravei em 09/07/2026 e escrevi este texto em 25/09/2026. O incidente comentado é de 16 e 17 de janeiro de 2026, e a cronologia, a duração de mais de 36 horas, o gargalo de conexões com o banco, o proxy não habilitado no DNS e a lista de 17 ações corretivas vieram do relatório público deles, que eu reli hoje pra escrever aqui. A classificação Tier III do Uptime Institute e o trecho da documentação do S3 também são apuração minha de hoje, não estavam na gravação. As lições de infraestrutura e os casos da minha operação continuam iguais — backup corrompido, virada de chave de madrugada, cache que demora a esquentar. Isso não muda com o calendário.
TODA SEGUNDA · MEIO-DIA · AO VIVO
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
É isso que eu queria trazer: as lições do caso deles e as que custaram caro aqui. Se você quer aprender infraestrutura de verdade — essa daqui e dezenas de outras coisas: banco, escala, Kubernetes, Docker, storage, compra de servidor, data center, até que ponto vale a pena usar nuvem e até que ponto vale a pena ter ambiente próprio —, é disso que eu trato na minha imersão de infraestrutura, presencial em São Paulo. Valor, data e condição ficam na página dela, que é onde essa informação fica atualizada. É pra quem é dono de empresa e quer entender como isso funciona, pro CTO que não quer ser enganado, pra quem gasta muito em nuvem e cogita ambiente próprio, e pra quem quer trabalhar com isso — que, com inteligência artificial e soberania nacional na mesa, pra mim é o futuro. Um grande abraço, e até a próxima.
Baseado na gravação do canal @josimarjmv publicada em 09/07/2026 (17min09), com transcrição própria das legendas do próprio vídeo. São da minha vivência e foram ditos na gravação: a admiração e o respeito pela transparência da equipe do Abacate Pay, que publicou a cronologia detalhada do incidente; a transparência como valor inegociável na minha empresa; o caso do backup de gigas e gigas de um PostGIS com todas as cópias corrompidas na hora de zipar e compactar, descoberto a tempo numa atualização de infraestrutura, sem necessidade de restaurar; a regra de desligar o proxy de conexão ou a própria API antes de restaurar um backup grande; a exigência de backup automático por script porque ser humano falha, e o painel que eu criei pra gerir a minha infraestrutura por não existir nada que se adequasse ao meu negócio; o teste de restore num banco de staging, com o ambiente conectado nele, uma vez por mês no máximo; a afirmação de que nenhuma empresa tem staging igual à produção, nem o Google, porque o pau da produção é carga e usuário imprevisível; a analogia da aviação que troca peça dentro do prazo de vida dela mesmo funcionando; o e-mail mensal do data center avisando do teste de desligamento da energia com zero impacto esperado, nobreaks e motores a diesel, e o teste feito em pedaços antes do global; o fato de eu não ter data center próprio e sim infraestrutura dentro de um, no Brasil e nos Estados Unidos; a virada de chave inteira na produção de madrugada, à meia-noite ou às duas da manhã, com base na estatística de uso e com rollback pronto; a necessidade de janela de manutenção pra testar a teoria aplicada, o rollback e o direcionamento do proxy; o cache quente que precisa esquentar de novo e sobrecarrega disco, memória, processamento e rede, no contexto de centenas de terabytes de vídeo por dia; a auditoria do backbone, do trânsito IP e do DNS no multicloud, com a lembrança de que Cloudflare e Amazon já deram problema; a redundância em todas as camadas; a crítica ao autoescale como solução mágica e a dificuldade de sincronização de banco com 100 a 150 milissegundos de latência; a diferença entre backup e redundância, com o exemplo do arquivo corrompido replicado e o versionamento de objeto como saída; e a minha franqueza de me chamar de medroso, pelo custo de impactar cliente. É apuração minha, feita em 25/09/2026, e não estava na gravação: a cronologia exata do relatório público de incidente do Abacate Pay de 16 e 17 de janeiro de 2026, com mais de 36 horas de impacto intermitente e contínuo, o acesso ao banco interrompido às 00h20 do dia 16, o gargalo crítico de conexões às 07h03, a descoberta do proxy não habilitado no DNS às 13h20 do dia 17, os componentes críticos não replicados entre provedores e as 17 ações corretivas anunciadas; a definição de Tier III como concurrently maintainable, conforme o sistema de classificação do Uptime Institute; e o trecho da documentação do Amazon S3 sobre versionamento a respeito de recuperar objeto de exclusão ou sobrescrita acidental, com a ressalva de cobrança por versão. Eu cito a minha imersão de infraestrutura na gravação, com faixa de preço e número de inscritos daquele momento: como preço, data, vagas e condição são finais e mudam a cada turma, aqui eu não repito nenhum desses números e mando para a página da imersão.