[{"data":1,"prerenderedAt":880},["ShallowReactive",2],{"blog-\u002Fblog\u002Fbackup-banco-em-cluster-estrategias-3-da-manha":3,"blog-surround-\u002Fblog\u002Fbackup-banco-em-cluster-estrategias-3-da-manha":864,"blog-en-alt-\u002Fblog\u002Fbackup-banco-em-cluster-estrategias-3-da-manha":878},{"id":4,"title":5,"author":6,"body":7,"category":845,"cover":846,"date":847,"description":848,"draft":849,"extension":850,"lastReviewed":846,"meta":851,"navigation":852,"path":853,"readingTime":854,"seo":855,"sitemap":856,"stem":857,"tags":858,"__hash__":863},"blog_pt\u002Fblog\u002Fbackup-banco-em-cluster-estrategias-3-da-manha.md","Backup de banco em cluster: as estratégias que sobrevivem 3 da manhã","Equipe HeroCtl",{"type":8,"value":9,"toc":829},"minimark",[10,19,26,29,32,37,43,46,49,53,56,63,72,75,81,85,92,98,108,114,135,138,144,148,151,162,167,172,177,196,199,202,207,211,214,224,230,236,242,247,256,261,280,283,288,292,295,298,303,308,313,318,325,328,333,337,340,345,350,355,360,363,368,372,375,594,597,601,604,610,616,622,628,634,638,641,650,656,662,668,674,678,681,684,687,690,693,696,700,711,717,723,737,746,752,762,766,769,772,775,808,822,825],[11,12,13,14,18],"p",{},"Três da manhã. O alerta acorda você porque o endpoint de health check tá voltando 500 há doze minutos. Você abre o terminal sonado, conecta no banco de produção, e a primeira query retorna ",[15,16,17],"code",{},"ERROR: invalid page in block 4421 of relation base\u002F16384\u002F24576",". Corrupção física. O Postgres ainda responde algumas requisições mas tá entregando dados podres pra metade dos clientes que cabem na parte sã das páginas.",[11,20,21,22,25],{},"Você lembra do cron de ",[15,23,24],{},"pg_dump"," que roda às 3 da manhã. Olha o relógio: 3h12. O cron começou há doze minutos. Ou seja, o backup que tá sendo gravado agora mesmo no S3 é a fotografia da corrupção. O backup anterior tem 24 horas. Você tem 24 horas de pedidos, pagamentos, mensagens e uploads pra perder, ou um banco corrompido pra restaurar.",[11,27,28],{},"Esse é o cenário em que toda decisão sobre backup é cobrada. Não é em reunião de arquitetura. Não é em retro de sprint. É às três da manhã, com você sozinho num terminal, decidindo entre dois ruins.",[11,30,31],{},"Esse post abre os cinco modelos de backup que existem pra banco em cluster, com os números honestos de quanto cada um perde e quanto cada um demora pra voltar. Cada estratégia tem um faixa de SaaS onde ela é a escolha certa — e uma faixa onde ela é negligência. A diferença é o estágio em que sua empresa tá, não o estilo de quem configurou.",[33,34,36],"h2",{"id":35},"a-frase-que-define-tudo-backup-que-nunca-foi-restaurado-e-placebo","A frase que define tudo: backup que nunca foi restaurado é placebo",[11,38,39,40,42],{},"A maioria dos times tem opinião confiante sobre backup e prática frágil. \"Tem cron de ",[15,41,24],{}," pra S3\" é o equivalente operacional de \"tem extintor mas nunca testou que funciona\". A confiança vem de ter o arquivo lá no bucket. A fragilidade vem de nunca ter realmente puxado esse arquivo, restaurado num ambiente isolado, validado contagem de linhas, conferido checksums.",[11,44,45],{},"Backup é o tipo de sistema em que a versão \"funciona até parar de funcionar\" é indistinguível da versão \"funciona de verdade\" — até o momento exato em que você precisa. Os dois primeiros anos de uma SaaS são vividos no estado de Schrödinger: o backup tá vivo e morto ao mesmo tempo, e ninguém abriu a caixa.",[11,47,48],{},"Esse texto é o exercício de abrir a caixa antes do incidente. As cinco estratégias abaixo são organizadas de forma crescente em complexidade e em garantia. Pra cada uma, a pergunta é: quanto de dado perco? quanto de tempo fico fora? quanto custa? e — o critério que ninguém leva a sério até precisar — quanto de competência interna isso exige?",[33,50,52],{"id":51},"rpo-e-rto-sem-buzzword","RPO e RTO sem buzzword",[11,54,55],{},"Antes de comparar estratégias, dois números precisam estar na mesa. Eles têm siglas chatas mas o conceito é simples.",[11,57,58,62],{},[59,60,61],"strong",{},"RPO — Recovery Point Objective."," Quanto de dado você aceita perder. É a distância entre o \"agora\" do incidente e o último ponto consistente que você consegue restaurar. Backup diário às 3 da manhã significa RPO de até 24 horas — se a corrupção acontece às 2 da manhã do dia seguinte, você perde 23 horas de transações. Backup contínuo significa RPO de segundos.",[11,64,65,68,69,71],{},[59,66,67],{},"RTO — Recovery Time Objective."," Quanto tempo você aceita estar offline. É a distância entre o \"começou o incidente\" e o \"tá servindo tráfego de novo\". Restore de ",[15,70,24],{}," num banco de 50 GB leva entre 30 e 60 minutos numa máquina decente. Failover pra réplica streaming leva 30 segundos.",[11,73,74],{},"Ambos custam dinheiro de jeitos diferentes. RPO baixo custa storage e largura de banda contínua (cada commit precisa virar bytes durados em algum lugar antes de ser confirmado pro cliente). RTO baixo custa hardware redundante — uma réplica quente é literalmente outro banco rodando, consumindo CPU, RAM e disco em paralelo, sem servir tráfego em momento normal.",[11,76,77,78,80],{},"Definir RPO e RTO antes de implementar evita o erro mais comum: gastar muito pra resolver o lado errado. Time que paga US$300 por mês de read replica e ainda perde 24 horas de dado quando o disco corrompe gastou mal — comprou RTO baixo e ignorou RPO. Time que faz ",[15,79,24],{}," quinzenal num bucket cross-region cifrado também gastou mal — comprou durabilidade extrema e aceitou RTO de horas que o cliente B2B não tolera.",[33,82,84],{"id":83},"estrategia-1-cron-pg_dump-pra-s3","Estratégia 1 — Cron + pg_dump pra S3",[11,86,87,88,91],{},"A versão MVP. Um cron job no servidor de banco, executa ",[15,89,90],{},"pg_dump | gzip | aws s3 cp"," às três da manhã. Bucket cross-region com lifecycle policy: arquivos com mais de 30 dias migram pra storage frio, com mais de 90 dias são apagados.",[11,93,94,97],{},[59,95,96],{},"RPO real:"," 24 horas no caminho normal. Pode chegar a 48 se o cron falhar uma noite e ninguém reparar.",[11,99,100,103,104,107],{},[59,101,102],{},"RTO real:"," 30 a 60 minutos pra banco até 50 GB. O ",[15,105,106],{},"pg_restore"," de um dump comprimido roda perto da velocidade de I\u002FO do disco — uma máquina com SSD decente faz 1 a 2 GB por minuto, contando o tempo de criar índices.",[11,109,110,113],{},[59,111,112],{},"Funciona pra:"," projeto pessoal, MVP, ferramenta interna, app onde 24 horas de dado é recuperável humanamente. Plataforma de cadastro onde o cliente refaz o que perdeu. Ferramenta de cache que reidrata do upstream. SaaS B2C nos primeiros 100 usuários, onde \"perdemos um dia, desculpa\" é resposta aceitável.",[11,115,116,119,120,122,123,126,127,130,131,134],{},[59,117,118],{},"Onde dói:"," backup quente em banco transacional pode capturar estado inconsistente entre tabelas relacionadas se você não usa as flags certas. ",[15,121,24],{}," com ",[15,124,125],{},"--serializable-deferrable"," resolve consistência transacional mas pode bloquear writes pesados. A versão paralela com ",[15,128,129],{},"-j"," é mais rápida mas exige ",[15,132,133],{},"--format=directory",", o que complica o pipe direto pro S3 — você acaba precisando de disco temporário local.",[11,136,137],{},"E o restore é lento de um jeito que surpreende. Banco de 200 GB que parecia \"só um pouco grande\" vira três horas de restore com índices sendo reconstruídos. Três horas em que sua plataforma tá fora.",[11,139,140,143],{},[59,141,142],{},"Custo:"," R$5 a R$30 por mês de storage S3-compatível pra retenção razoável. Tempo humano: zero depois do setup, dez minutos por mês pra checar log do cron.",[33,145,147],{"id":146},"estrategia-2-pg_basebackup-wal-archiving","Estratégia 2 — pg_basebackup + WAL archiving",[11,149,150],{},"A primeira vez que o RPO baixa de \"um dia\" pra \"alguns minutos\". A ideia é separar duas coisas: a fotografia completa do banco (basebackup) e o histórico de mudanças desde a última fotografia (WAL — Write-Ahead Log, o arquivo onde o Postgres escreve cada commit antes de aplicar nos dados).",[11,152,153,154,157,158,161],{},"Setup: ",[15,155,156],{},"pg_basebackup"," semanal grava um snapshot completo do diretório de dados. Em paralelo, o ",[15,159,160],{},"archive_command"," do Postgres copia cada arquivo WAL fechado (16 MB cada) pro S3 conforme são produzidos. Em condições normais, o WAL é fechado em segundos sob carga média.",[11,163,164,166],{},[59,165,96],{}," 1 a 5 minutos. É o intervalo entre o último WAL ter sido enviado e o disco ter morrido.",[11,168,169,171],{},[59,170,102],{}," 15 a 45 minutos. Restaurar o basebackup, replay dos WALs até o ponto desejado.",[11,173,174,176],{},[59,175,112],{}," SaaS com 10 a 100 GB de banco, primeira centena de clientes pagantes. Etapa em que perder 24 horas é catastrófico mas o time ainda não tem DBA dedicado.",[11,178,179,181,182,184,185,187,188,191,192,195],{},[59,180,118],{}," o ",[15,183,160],{}," precisa ser tratado como código de produção, não script de fim de semana. Se ele falhar e ninguém reparar, o WAL acumula no disco do banco até estourar, e quando estoura o banco para de aceitar writes. Já vi cluster cair às quatro da manhã porque o ",[15,186,160],{}," chamava ",[15,189,190],{},"aws s3 cp"," sem ",[15,193,194],{},"--no-progress"," e a saída do progresso bloqueava o stdout em ambiente sem TTY.",[11,197,198],{},"O volume de WAL surpreende. Banco com tráfego médio gera 5 a 50 GB de WAL por dia, dependendo do que escreve. Multiplicado por retenção de 30 dias, vira terabytes. Storage barato continua sendo barato, mas o lifecycle policy do bucket tem que estar afiado.",[11,200,201],{},"E o restore exige replay sequencial. Você não pode pular WALs. Se um arquivo intermediário foi perdido (bug no archive, bucket apagado por engano, qualquer coisa), o restore para naquele ponto e o que veio depois é ilegível. Verificação periódica é obrigatória.",[11,203,204,206],{},[59,205,142],{}," R$50 a R$200 por mês de storage dependendo de retenção. Tempo humano: 2 a 4 horas pra setup inicial bem feito, mais a primeira meia hora de cada incidente entendendo qual WAL precisa.",[33,208,210],{"id":209},"estrategia-3-pgbackrest-wal-e-restic-xtrabackup","Estratégia 3 — pgBackRest, WAL-E, restic, xtrabackup",[11,212,213],{},"Quando a estratégia 2 é boa demais pra ser feita à mão. Ferramentas dedicadas que combinam basebackup, WAL archiving, retenção, compressão, cifragem e — crucialmente — verificação automática.",[11,215,216,219,220,223],{},[15,217,218],{},"pgBackRest"," é o nome mais maduro pro Postgres. Faz tudo que a estratégia 2 faz, mas com paralelização (vários processos enviando WAL em simultâneo), validação de checksum em cada arquivo, point-in-time recovery (PITR) sem dor, e — o ganho operacional grande — um comando único ",[15,221,222],{},"pgbackrest restore"," que sabe achar o backup mais recente, baixar o que precisa, e replay até o instante que você pede.",[11,225,226,229],{},[15,227,228],{},"WAL-E"," é mais antigo mas mais simples se você só quer mandar pra S3 e voltar.",[11,231,232,235],{},[15,233,234],{},"restic"," é genérico (não é específico de Postgres), mas tem deduplicação que é especialmente útil quando você faz dump completo várias vezes ao dia — o segundo dump só envia os blocos que mudaram.",[11,237,238,241],{},[15,239,240],{},"xtrabackup"," é o equivalente pra MySQL, com a mesma filosofia: backup quente sem lock, incremental, PITR.",[11,243,244,246],{},[59,245,96],{}," minutos, igual estratégia 2. A diferença é que aqui o \"5 minutos\" é mais confiável porque a ferramenta verifica continuamente que o pipeline tá funcionando.",[11,248,249,251,252,255],{},[59,250,102],{}," 10 a 30 minutos com PITR direto. O comando ",[15,253,254],{},"pgbackrest restore --type=time --target='2025-12-11 03:42:00'"," resolve o que na estratégia 2 exige meia hora de scripts.",[11,257,258,260],{},[59,259,112],{}," SaaS sério, banco de 100 GB a 1 TB, time que assume responsabilidade formal por testes mensais de restore.",[11,262,263,265,266,268,269,272,273,272,276,279],{},[59,264,118],{}," aprender a ferramenta. ",[15,267,218],{}," tem documentação decente mas o vocabulário é específico — ",[15,270,271],{},"stanza",", ",[15,274,275],{},"repo",[15,277,278],{},"archive-async",". A configuração inicial bem feita leva 2 a 4 horas, e mais um dia pra rodar o primeiro full + incrementais e ter certeza de que tudo bate.",[11,281,282],{},"A trapaça aqui é que a ferramenta esconde a complexidade do mecanismo, não a remove. Quando algo dá errado, você precisa entender que por baixo continua sendo basebackup + WAL. A diferença é que os bugs comuns da estratégia 2 (archive falhando silenciosamente, WAL faltando) são detectados e alertados pela ferramenta antes do incidente.",[11,284,285,287],{},[59,286,142],{}," storage proporcional ao volume + tempo de DBA part-time. Falo em \"DBA part-time\" mesmo que ninguém com esse título exista no time — é o tempo que alguém de plantão precisa investir mensalmente pra rodar o restore-test.",[33,289,291],{"id":290},"estrategia-4-streaming-replication-com-failover-automatico","Estratégia 4 — Streaming replication com failover automático",[11,293,294],{},"A primeira estratégia em que o RTO baixa abaixo de um minuto. Em vez de copiar o banco depois que ele terminou de escrever, você mantém uma réplica recebendo o stream do WAL em tempo real. Quando o primário morre, um orquestrador promove a réplica a primário, atualiza o roteamento, e o serviço volta sem intervenção humana.",[11,296,297],{},"Patroni é o nome mais comum pra orquestrar isso no Postgres. Ele resolve eleição de líder entre nós, gerencia replication slots, faz fencing do nó morto pra evitar duas escritas simultâneas, e expõe um endpoint que o seu balanceador de carga consulta pra saber qual nó é o primário corrente.",[11,299,300,302],{},[59,301,96],{}," segundos. Replicação síncrona pode chegar a zero (commit no primário só confirma depois da cópia chegar na réplica) mas custa latência em cada write — escolha que se faz transação a transação na maioria dos sistemas.",[11,304,305,307],{},[59,306,102],{}," 30 segundos a 5 minutos. Os 30 segundos é o failover automático sem human-in-the-loop. Os 5 minutos é o cenário em que o orquestrador detecta o problema, decide que não é falso positivo, promove a réplica, e o cache de DNS dos clientes expira.",[11,309,310,312],{},[59,311,112],{}," SaaS com primeiro cliente B2B sério, SLA contratual igual ou maior que 99,5%. Plataforma onde 5 minutos de janela equivale a uma pena contratual.",[11,314,315,317],{},[59,316,118],{}," split-brain durante particionamento de rede. Se o primário fica isolado mas continua aceitando escritas, e a réplica é promovida pelo orquestrador no outro lado da partição, você acaba com duas verdades divergentes que precisam ser reconciliadas manualmente quando a rede volta. Os orquestradores sérios usam um terceiro nó de testemunha pra evitar isso, mas a configuração é exigente.",[11,319,320,321,324],{},"Pior ainda: a réplica copia corrupção. Se o primário escreveu uma página podre, a réplica recebeu o WAL idêntico e tá igualmente podre. Streaming replication te protege contra falha de hardware do primário; não protege contra bug de aplicação que escreveu lixo, contra ",[15,322,323],{},"DROP TABLE"," errado, contra ransomware.",[11,326,327],{},"Por isso essa estratégia nunca substitui as três anteriores — ela soma. RTO baixíssimo pra falha de hardware, mais backup tradicional pra falha lógica.",[11,329,330,332],{},[59,331,142],{}," dois ou três bancos rodando o tempo todo (um primário ativo, um ou dois standbys). Storage e CPU dobrados ou triplicados em relação ao banco único. Tempo humano: setup inicial de uma semana, mais bateria de testes de failover trimestral.",[33,334,336],{"id":335},"estrategia-5-backup-gerenciado-por-terceiro","Estratégia 5 — Backup gerenciado por terceiro",[11,338,339],{},"A estratégia em que você compra o problema fora. RDS na AWS, Cloud SQL no Google, Neon, Crunchy Bridge, ou um provedor brasileiro que entrega backup automático com PITR. Você define a janela de retenção, eles cuidam do resto.",[11,341,342,344],{},[59,343,96],{}," 5 minutos é o número típico publicado.",[11,346,347,349],{},[59,348,102],{}," 30 segundos a 5 minutos pro failover dentro da mesma região. Restore cross-region é outro animal — pode ser uma hora, dependendo do provedor.",[11,351,352,354],{},[59,353,112],{}," time sem expertise interna OU compliance que exige vendor com SOC 2 \u002F ISO 27001 emitido. Empresa que preferiria pagar caro pra não pensar no assunto.",[11,356,357,359],{},[59,358,118],{}," custo. Banco que custaria R$300\u002Fmês em hardware vira R$1500 a R$3000\u002Fmês em RDS equivalente, dependendo da configuração de réplica. Lock-in de provedor — sair de RDS é uma migração complicada porque a forma de fazer backup é específica do produto. E o restore cross-region (que é a parte que o cliente B2B exige no contrato) frequentemente é mais difícil do que parece nos slides comerciais.",[11,361,362],{},"A vantagem real é zero ops em condições normais. A desvantagem real é que quando você tá em incidente, o caminho pra escalar com o suporte do provedor pode levar mais tempo do que você teria pra resolver com self-hosted bem configurado.",[11,364,365,367],{},[59,366,142],{}," US$50 a US$500 por mês pra bancos pequenos e médios. Acima disso é cobrança proporcional ao tamanho.",[33,369,371],{"id":370},"tabela-comparativa","Tabela comparativa",[11,373,374],{},"A versão honesta lado a lado. Cada coluna é uma das estratégias acima.",[376,377,378,403],"table",{},[379,380,381],"thead",{},[382,383,384,388,391,394,397,400],"tr",{},[385,386,387],"th",{},"Critério",[385,389,390],{},"1: Cron + pg_dump",[385,392,393],{},"2: basebackup + WAL",[385,395,396],{},"3: pgBackRest",[385,398,399],{},"4: Streaming + failover",[385,401,402],{},"5: Gerenciado",[404,405,406,426,445,464,483,499,517,535,554,574],"tbody",{},[382,407,408,412,415,418,421,424],{},[409,410,411],"td",{},"RPO típico",[409,413,414],{},"24h",[409,416,417],{},"5 min",[409,419,420],{},"1-5 min",[409,422,423],{},"segundos",[409,425,417],{},[382,427,428,431,434,437,440,443],{},[409,429,430],{},"RTO típico",[409,432,433],{},"30-60 min",[409,435,436],{},"15-45 min",[409,438,439],{},"10-30 min",[409,441,442],{},"30s-5 min",[409,444,442],{},[382,446,447,450,453,456,459,462],{},[409,448,449],{},"Tamanho ideal de banco",[409,451,452],{},"até 50 GB",[409,454,455],{},"10-100 GB",[409,457,458],{},"100 GB - 1 TB",[409,460,461],{},"qualquer",[409,463,461],{},[382,465,466,469,472,475,477,480],{},[409,467,468],{},"Custo de storage",[409,470,471],{},"baixíssimo",[409,473,474],{},"médio",[409,476,474],{},[409,478,479],{},"alto (réplica)",[409,481,482],{},"alto",[382,484,485,488,491,493,495,497],{},[409,486,487],{},"Custo de tempo humano",[409,489,490],{},"~zero",[409,492,474],{},[409,494,474],{},[409,496,482],{},[409,498,490],{},[382,500,501,504,507,510,512,515],{},[409,502,503],{},"Complexidade de setup",[409,505,506],{},"trivial",[409,508,509],{},"moderada",[409,511,509],{},[409,513,514],{},"alta",[409,516,506],{},[382,518,519,522,525,527,530,533],{},[409,520,521],{},"Complexidade de restore",[409,523,524],{},"baixa",[409,526,509],{},[409,528,529],{},"baixa (PITR)",[409,531,532],{},"n\u002Fa (failover)",[409,534,524],{},[382,536,537,540,543,545,548,551],{},[409,538,539],{},"Multi-region",[409,541,542],{},"manual",[409,544,542],{},[409,546,547],{},"nativo",[409,549,550],{},"requer config",[409,552,553],{},"depende do provedor",[382,555,556,559,562,565,568,571],{},[409,557,558],{},"Point-in-time recovery",[409,560,561],{},"não",[409,563,564],{},"sim, manual",[409,566,567],{},"sim, comando único",[409,569,570],{},"n\u002Fa",[409,572,573],{},"sim",[382,575,576,579,582,585,588,591],{},[409,577,578],{},"Faixa de SaaS BR",[409,580,581],{},"MVP",[409,583,584],{},"indie",[409,586,587],{},"early\u002Fmid",[409,589,590],{},"startup com SLA",[409,592,593],{},"enterprise \u002F sem expertise",[11,595,596],{},"Repare que nenhuma linha tem um vencedor absoluto. A estratégia 5 ganha em \"tempo humano\" e perde em \"custo de storage\". A estratégia 4 ganha em RPO e perde em \"complexidade de setup\". A escolha é sempre sobre qual coluna você prioriza, dado o estágio da empresa.",[33,598,600],{"id":599},"os-cinco-erros-que-matam-o-backup-do-colega","Os cinco erros que matam o backup do colega",[11,602,603],{},"A partir daqui é folclore operacional. Cada um desses erros foi cometido por um time que tinha confiança no backup que tinha. Cada um virou pós-mortem.",[11,605,606,609],{},[59,607,608],{},"Nunca restaurou."," Backup que nunca foi restaurado em ambiente isolado é hipótese. Cron mensal que pega o backup mais recente do bucket, sobe num banco efêmero (uma máquina temporária que você desliga em seguida), valida contagem de linhas das tabelas críticas, confere checksum de algumas amostras, e manda email pro time confirmando sucesso. O backup do mês em que esse cron falhou é o único backup em que você tem certeza que vai funcionar. Tudo antes é fé.",[11,611,612,615],{},[59,613,614],{},"Backup no mesmo disco ou mesma região."," Disco morre, backup vai junto. Região inteira de provedor cloud cai (já aconteceu várias vezes nos últimos cinco anos), backup vai junto. Cross-region é o mínimo. Cross-provider — backup principal num provedor, cópia secundária noutro — é o que separa \"preparado\" de \"torcedor\".",[11,617,618,621],{},[59,619,620],{},"Sem retenção lógica longa."," Sete dias de retenção parece confortável até você descobrir que a corrupção começou há oito dias e ninguém reparou. Bug sutil de aplicação que escreve dado inválido em uma linha por minuto não dispara alerta, mas em duas semanas envenenou meio milhão de registros. Retenção curta é negligência travestida de economia. Política mínima razoável: 7 dias de backup horário, 30 dias de diário, 12 meses de mensal.",[11,623,624,627],{},[59,625,626],{},"Sem alerta de falha."," O cron silencioso é o assassino mais comum. Falhou há trinta dias por uma mudança de credencial no S3, ninguém olhou o log, todo mundo dormiu tranquilo. Alerta integrado ao sistema de notificação do time (não email perdido na caixa, mas Slack ou equivalente que alguém vai ler) é obrigatório. E o alerta tem que ser duplo — alerta quando falha, e alerta quando não há sucesso há mais de N horas (pra detectar o caso em que o cron nem rodou).",[11,629,630,633],{},[59,631,632],{},"Backup sem cifragem."," Vazamento de bucket S3 público vira vazamento do banco inteiro. Os incidentes de imprensa dos últimos anos são todos compostos por \"bucket ficou público por dois dias e tinha o backup completo\". Cifragem em repouso (server-side encryption no bucket é o mínimo, cifragem cliente-side com chave gerenciada por você é o adequado), cifragem em trânsito, e — separado disso — controle de acesso ao bucket que segue o princípio do menor privilégio.",[33,635,637],{"id":636},"a-trilha-de-maturidade-saas-br","A trilha de maturidade SaaS BR",[11,639,640],{},"A pergunta prática: qual estratégia pra qual estágio. Tomando como referência métricas brasileiras de receita mensal recorrente.",[11,642,643,646,647,649],{},[59,644,645],{},"MVP até R$5 mil de MRR."," Estratégia 1. Cron de ",[15,648,24],{}," pra S3-compatível, retenção de 30 dias, alerta básico de falha. Custa praticamente nada e protege contra o risco principal nessa fase, que é \"o servidor sumiu\". RPO de 24 horas é aceitável porque o cliente nessa fase tem expectativa de produto que tá começando.",[11,651,652,655],{},[59,653,654],{},"Indie de R$5 mil a R$30 mil."," Estratégia 2. Adiciona WAL archiving, derruba RPO de 24 horas pra 5 minutos. O salto de complexidade é compensado pelo salto de garantia. Cliente que paga R$500 por mês de assinatura B2B começa a fazer pergunta de SLA — você precisa de resposta melhor que \"diário\".",[11,657,658,661],{},[59,659,660],{},"Startup early de R$30 mil a R$200 mil."," Estratégia 3. pgBackRest configurado com restore-test mensal automático. Aqui não é mais opcional — você tem cliente sério, contrato sério, e a fragilidade da estratégia 2 feita à mão é risco operacional concreto. O setup de meio dia se paga em três meses pelo primeiro incidente que não vira pós-mortem público.",[11,663,664,667],{},[59,665,666],{},"Startup com SLA contratual."," Estratégia 4 somada à 3. Streaming replication com failover automático cuida do hardware; pgBackRest cuida do dado lógico. As duas juntas resolvem os dois modos de falha que os contratos B2B sérios cobram: indisponibilidade momentânea e perda de dado.",[11,669,670,673],{},[59,671,672],{},"Enterprise ou compliance pesado."," Estratégia 5 OU estratégia 4 com auditoria detalhada. Aqui a decisão é menos técnica e mais regulatória. Se a auditoria exige fornecedor com certificação X, você compra gerenciado. Se a auditoria aceita self-hosted com runbook documentado, você opera as estratégias 3 e 4 e investe na trilha de auditoria.",[33,675,677],{"id":676},"como-o-heroctl-simplifica-isso","Como o HeroCtl simplifica isso",[11,679,680],{},"A motivação do produto é justamente esse esquema acima — são camadas que aparecem repetidamente em todo SaaS, e cada time gasta uma estação inteira reconstruindo o mesmo encanamento. O HeroCtl resolve o transporte, a orquestração e a observação dessas camadas. Mantém o que é específico do banco com o time, automatiza o que é genérico.",[11,682,683],{},"Concretamente, no plano Community (gratuito), você roda Postgres como job comum no cluster, com persistência cifrada em repouso. O cron de backup vira outro job, com retry automático, alerta integrado de falha (sem precisar montar Alertmanager por fora), e métricas que aparecem no painel — duração do dump, tamanho do arquivo, tempo desde o último sucesso.",[11,685,686],{},"No Business, entra backup gerenciado de Postgres e MySQL. A diferença em relação a \"fazer você mesmo\" é que a verificação de integridade, o restore-test mensal, a cifragem cliente-side com chave gerenciada por você, e a política de retenção em três tiers (horário\u002Fdiário\u002Fmensal) já vêm configuradas. Você define a janela e o resto é problema nosso.",[11,688,689],{},"No Enterprise, entra orquestração de streaming replication entre nós do cluster — um job descreve a topologia (primário aqui, standby ali, quem promove quem), e o cluster cuida do failover quando o primário morre. Bateria de testes de chaos roda contra o seu cluster mensalmente, com relatório.",[11,691,692],{},"Em todos os planos, o restore-test pode ser configurado como cron job interno: o cluster sobe um banco efêmero, restaura o backup mais recente, valida o que você definir como \"saudável\" (uma query de checksum, uma contagem de linhas, o que faça sentido), reporta sucesso ou falha, e desliga o banco efêmero. O custo é os minutos de CPU do teste, não dia de trabalho de engenheiro.",[11,694,695],{},"A filosofia é a mesma do resto do produto: o que é genérico pra todo SaaS já tá pronto; o que é específico do seu domínio fica com você. Backup é genérico. O conteúdo do banco é seu.",[33,697,699],{"id":698},"faq","FAQ",[11,701,702,707,708,710],{},[59,703,704,706],{},[15,705,24],{}," basta pra começar?","\nSim, pra MVP até primeiros clientes pagantes. A regra prática: se perder 24 horas de dado custa menos do que três horas de tempo de engenheiro, ",[15,709,24],{}," é a escolha certa. Quando inverter (perder dado custa mais que migrar pra estratégia 2), migre.",[11,712,713,716],{},[59,714,715],{},"Quanto custa storage S3-compatível no Brasil em 2026?","\nFaixa atual entre R$0,15 e R$0,40 por GB-mês dependendo do provedor e do tier. Backup de banco de 50 GB com retenção de 30 dias mais alguns dumps semanais antigos = ~3 TB-mês equivalente comprimido = R$50 a R$120\u002Fmês. Cross-region praticamente dobra. Tier frio pra retenção mensal longa derruba pra metade.",[11,718,719,722],{},[59,720,721],{},"Como testo restore sem afetar produção?","\nCron job no cluster que: 1) baixa o backup mais recente do bucket; 2) sobe um Postgres temporário em outro nó (ou contêiner efêmero) sem expor porta pública; 3) restaura o dump; 4) roda queries de validação (contagem por tabela, checksum de amostras, query crítica do domínio); 5) compara com baselines esperados; 6) reporta resultado no canal de alertas; 7) destrói o ambiente. Roda mensal, no mínimo. Nunca toca o banco de produção em momento nenhum.",[11,724,725,728,729,732,733,736],{},[59,726,727],{},"Backup cifrado no S3 — qual a forma certa?","\nTrês camadas. Server-side encryption do bucket (",[15,730,731],{},"AES256"," ou KMS) é a base e é grátis. Cifragem cliente-side com chave gerenciada por você (você criptografa o arquivo antes de subir, com chave que vive fora do provedor cloud) protege contra cenário de comprometimento de credencial. Política de bucket com ",[15,734,735],{},"aws:SecureTransport=true"," e bloqueio de acesso público explícito. As três juntas, sem exceção. Uma só não basta.",[11,738,739,742,743,745],{},[59,740,741],{},"Read replica conta como backup?","\nNão. Read replica protege contra falha de hardware do primário. Não protege contra ",[15,744,323],{}," errado, contra bug que escreve dado inválido, contra corrupção lógica que se replica. Toda corrupção lógica que entra no primário entra na réplica em segundos. Read replica é alta disponibilidade, não backup. As duas coisas coexistem; nenhuma substitui a outra.",[11,747,748,751],{},[59,749,750],{},"Cross-region replication é necessário?","\nPra cliente B2B sério, sim. Pra MVP, não. A fronteira prática: se um único provedor cloud caindo por 4 horas é suficiente pra você quebrar contrato, cross-region é mínimo. Se 4 horas de fora ainda dá pra explicar pelo email, cross-region pode esperar.",[11,753,754,757,758,761],{},[59,755,756],{},"Quanto tempo leva restaurar 100 GB de Postgres?","\nDepende muito do disco. SSD NVMe local: 20 a 40 minutos contando criação de índices. SSD remoto (volume de provedor cloud): 40 a 90 minutos. HDD: você não quer saber. Compressão do dump tipicamente derruba pra metade do tamanho original; banco de 100 GB vira dump de 30 a 50 GB. Crie índices em paralelo (",[15,759,760],{},"pg_restore -j",") pra acelerar 30 a 50%.",[33,763,765],{"id":764},"fechamento","Fechamento",[11,767,768],{},"Backup é menos sobre estratégia técnica e mais sobre disciplina de teste. As cinco estratégias acima são todas decentes em algum estágio. A diferença entre o time que sobrevive ao incidente e o time que perde cliente não tá em qual delas escolheu — tá em ter restaurado um backup recentemente o suficiente pra confiar.",[11,770,771],{},"Se a sua resposta pra \"quando foi o último restore-test?\" começa com \"deixa eu ver\", você tem trabalho pra essa semana. Não é a próxima sprint. É essa semana. O cenário das três da manhã não tá agendado.",[11,773,774],{},"O HeroCtl roda em qualquer servidor Linux com Docker. Você instala num laboratório, sobe um Postgres como job, configura backup automático, agenda restore-test mensal, e em uma tarde tem o esquema da estratégia 3 inteiro funcionando. Sem montar cinco produtos diferentes, sem aprender vocabulário de orquestrador especializado.",[776,777,782],"pre",{"className":778,"code":779,"language":780,"meta":781,"style":781},"language-sh shiki shiki-themes github-dark-default","curl -sSL get.heroctl.com\u002Finstall.sh | sh\n","sh","",[15,783,784],{"__ignoreMap":781},[785,786,789,793,797,801,805],"span",{"class":787,"line":788},"line",1,[785,790,792],{"class":791},"sQhOw","curl",[785,794,796],{"class":795},"sFSAA"," -sSL",[785,798,800],{"class":799},"s9uIt"," get.heroctl.com\u002Finstall.sh",[785,802,804],{"class":803},"suJrU"," |",[785,806,807],{"class":791}," sh\n",[11,809,810,811,816,817,821],{},"Pra contexto sobre quando faz sentido rodar Postgres no próprio cluster vs. comprar gerenciado, leia ",[812,813,815],"a",{"href":814},"\u002Fblog\u002Fpostgres-em-producao-gerenciado-vs-self-hosted","Postgres em produção: gerenciado vs self-hosted",". Pra entender por que a janela de deploy é o outro lado moeda do backup (porque o deploy ruim é a forma mais comum de gerar o incidente que vai exigir restore), leia ",[812,818,820],{"href":819},"\u002Fblog\u002Frolling-deploy-seguro-por-que-o-seu-talvez-nao-seja","Rolling deploy seguro: por que o seu talvez não seja",".",[11,823,824],{},"Backup que nunca foi restaurado é placebo. A diferença entre placebo e remédio aparece exatamente uma vez, exatamente quando você não pode escolher.",[826,827,828],"style",{},"html pre.shiki code .sQhOw, html code.shiki .sQhOw{--shiki-default:#FFA657}html pre.shiki code .sFSAA, html code.shiki .sFSAA{--shiki-default:#79C0FF}html pre.shiki code .s9uIt, html code.shiki .s9uIt{--shiki-default:#A5D6FF}html pre.shiki code .suJrU, html code.shiki .suJrU{--shiki-default:#FF7B72}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":781,"searchDepth":830,"depth":830,"links":831},2,[832,833,834,835,836,837,838,839,840,841,842,843,844],{"id":35,"depth":830,"text":36},{"id":51,"depth":830,"text":52},{"id":83,"depth":830,"text":84},{"id":146,"depth":830,"text":147},{"id":209,"depth":830,"text":210},{"id":290,"depth":830,"text":291},{"id":335,"depth":830,"text":336},{"id":370,"depth":830,"text":371},{"id":599,"depth":830,"text":600},{"id":636,"depth":830,"text":637},{"id":676,"depth":830,"text":677},{"id":698,"depth":830,"text":699},{"id":764,"depth":830,"text":765},"engenharia",null,"2025-12-11","Backup que nunca foi restaurado é placebo. Cinco estratégias com tempo de recuperação real (RTO) e perda de dados aceitável (RPO) honesto, pra cada estágio de SaaS brasileiro.",false,"md",{},true,"\u002Fblog\u002Fbackup-banco-em-cluster-estrategias-3-da-manha","14 min",{"title":5,"description":848},{"loc":853},"blog\u002Fbackup-banco-em-cluster-estrategias-3-da-manha",[859,860,861,845,862],"backup","postgres","disaster-recovery","rpo-rto","-L9skeqx7sjuj-UUp-e6n-MSKoE8CfEbNUWqZramRJc",[865,872],{"title":866,"path":867,"stem":868,"description":869,"date":870,"category":871,"children":-1},"AWS ECS vs Kubernetes vs auto-hospedado: três caminhos pra rodar containers em 2026","\u002Fblog\u002Faws-ecs-vs-kubernetes-vs-auto-hospedado","blog\u002Faws-ecs-vs-kubernetes-vs-auto-hospedado","ECS é a oferta da AWS pra fugir de Kubernetes. Kubernetes é Kubernetes. Auto-hospedado é o caminho de saída do AWS. Cada um faz sentido em contextos específicos — sem trade-off uniforme.","2026-03-04","comparativo",{"title":873,"path":874,"stem":875,"description":876,"date":877,"category":871,"children":-1},"CapRover vs Coolify vs Dokploy: o segmento simples comparado em 2026","\u002Fblog\u002Fcaprover-vs-coolify-vs-dokploy-segmento-simples","blog\u002Fcaprover-vs-coolify-vs-dokploy-segmento-simples","Os três painéis dominantes pra rodar 'Heroku em 1 VPS'. Cada um aposta numa filosofia diferente — maturidade, riqueza de features, ou peso leve. Comparativo honesto pra escolher sem arrependimento.","2026-01-19",{"path":879},"\u002Fen\u002Fblog\u002Fdatabase-backup-strategies-cluster",1777362184410]