Recuperação point-in-time vs snapshots: o que você perde

Alguém executa um DELETE sem uma cláusula WHERE às 16h15. Seu backup mais recente é das 03h00. Tudo entre esses dois momentos se perdeu, e nenhuma restauração será capaz de trazer isso de volta.

Essa lacuna tem um nome — objetivo de ponto de recuperação, ou RPO — e a decisão entre recuperação point-in-time e snapshots trata inteiramente do tamanho que você está disposto a aceitar para ela.

Os dois modelos

Snapshots capturam o estado dos seus dados em um determinado momento. Eles são executados conforme uma programação, geralmente todas as noites. Restaurar um deles coloca você exatamente no estado em que estava quando o snapshot foi criado, e tudo o que aconteceu depois é perdido.

A recuperação point-in-time combina um backup base com um fluxo contínuo do write-ahead log do banco de dados. Como cada alteração é registrada em ordem, você pode reproduzir os eventos até qualquer momento coberto pelo log retido — inclusive às 16h14, um minuto antes da exclusão.

A diferença não é incremental. É a diferença entre “perdemos um dia” e “perdemos um minuto”.

O número que decide

Faça uma pergunta, com honestidade: se você perdesse tudo o que foi gravado nas últimas doze horas, o que aconteceria?

Para um projeto pessoal, um site de documentação ou uma ferramenta interna cujos dados podem ser reproduzidos: não muita coisa. Snapshots noturnos são genuinamente a resposta certa, e pagar por arquivamento contínuo seria desperdício.

Para qualquer sistema em que clientes gravem dados, a resposta geralmente é alguma versão de “teríamos que enviar um e-mail às pessoas e explicar”. Pedidos que não existem mais. Uploads que desapareceram. Mensagens que foram enviadas e agora não estão mais lá. Só o custo de suporte normalmente já supera, em um ano, a diferença nos gastos com infraestrutura.

O erro não é escolher snapshots. O erro é escolher snapshots por padrão, sem nunca perguntar quanto custaria uma lacuna de doze horas.

Onde os snapshots são realmente bons

Eles não são um produto inferior. Eles cobrem falhas que o PITR não cobre:

• Perda total do disco. Um snapshot em um armazenamento separado restaura tudo, inclusive arquivos que não pertencem ao banco de dados.
• Rollback rápido e amplo. Reverter uma migration mal executada em um ambiente de staging é mais rápido a partir de um snapshot do que reproduzindo um log.
• Custo. Armazenar uma cópia por dia é mais barato do que armazenar cada gravação.
• Simplicidade. Menos componentes é uma característica operacional real, especialmente para uma equipe pequena.

A armadilha é tratá-los como suficientes para um banco de dados que recebe gravações continuamente.

Quanto o PITR custa

Ele não é gratuito, e vale a pena explicitar os custos:

• Armazenamento. Você mantém o backup base mais cada gravação realizada durante a janela de retenção.
• Complexidade. O arquivamento precisa funcionar continuamente. Um archiver que falhou silenciosamente por uma semana significa que sua janela recuperável terminou há uma semana — por isso monitorar o archive é tão importante quanto configurá-lo.
• Tempo de restauração. Reproduzir um log demora mais do que restaurar um snapshot. Seu RPO melhora; seu RTO geralmente piora.

Essa última troca costuma surpreender. PITR significa perder menos dados, não voltar a ficar online mais rápido.

A resposta em camadas de que a maioria das equipes realmente precisa

Na prática, não se trata de escolher entre duas coisas. Bancos de dados de produção geralmente precisam de três camadas, porque falham de três maneiras diferentes:

Snapshots diários, retidos por uma ou duas semanas. Um seguro barato contra a perda da máquina. Essa também é a camada que cobre os arquivos que não pertencem ao banco de dados e estão no mesmo volume.

Dumps lógicos diários, mantidos fora do host. Um pg_dump é portátil e consistente por construção. Ele pode ser restaurado em uma versão major diferente, em outro provedor ou em um laptop — exatamente o que você quer quando o problema está na plataforma, não nos dados.

Arquivamento contínuo, quando o banco contém dados de clientes. A camada que transforma “perdemos o dia de hoje” em “perdemos um minuto”.

Cada camada cobre o que as outras não cobrem. Um snapshot não ajuda você a mudar de provedor. Um dump lógico não ajuda a recuperar um arquivo que não estava no banco de dados. Nenhum dos dois ajuda a desfazer uma exclusão ocorrida quatro horas atrás.

Onde o Dockup se encaixa

O Dockup oferece as duas camadas que cobrem as falhas mais comuns, e vale a pena ser preciso sobre quais são elas.

Snapshots de volume, sob demanda ou programados com uma quantidade de retenção:

dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api

Backups lógicos de banco de dados, enviados diretamente para o object storage e criptografados durante o processo:

dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json

Duas características dessa segunda opção são importantes para a recuperação. O backup nunca é gravado no host do banco de dados — ele é transmitido para o storage à medida que o pg_dump o produz, portanto não compartilha o destino do disco de origem. Além disso, um dump que termina com código diferente de zero ou produz zero bytes é excluído e registrado como falho, em vez de permanecer na lista parecendo um backup válido.

O arquivamento contínuo não é algo que o Dockup executa para você atualmente. Se o seu RPO realmente precisa ser medido em minutos, é importante saber disso antes de escolher e é perfeitamente razoável executá-lo por conta própria em um banco de dados gerenciado, usando a plataforma para todo o restante.

O exercício que vale a pena fazer esta semana

Anote dois números para o seu banco de dados de produção:

1. RPO — quantos dados você pode perder. Medido em tempo.
2. RTO — por quanto tempo você pode ficar indisponível. Também medido em tempo.

Em seguida, verifique o que sua configuração atual realmente oferece restaurando alguma coisa. Se os números que você anotou e os números oferecidos pela sua configuração forem diferentes, você encontrou uma decisão a tomar enquanto nada está pegando fogo — que é o único bom momento para tomá-la.

Perguntas frequentes

Qual é a diferença entre RPO e RTO? RPO é a quantidade de dados que você perde — a lacuna entre o último momento recuperável e a falha. RTO é o tempo que a recuperação leva. Snapshots oferecem um RPO grande e um RTO curto; PITR inverte essa relação.

Posso recuperar linhas excluídas há uma hora a partir de um snapshot noturno? Não. Um snapshot restaura o estado no momento em que foi criado. Tudo o que foi gravado depois dele não está no arquivo. Para recuperar um momento arbitrário, é necessário arquivamento contínuo.

Um snapshot de volume é a mesma coisa que um backup de banco de dados? Não. Um snapshot captura o disco, incluindo o estado em que o banco de dados estava no meio de uma gravação. Um dump lógico é internamente consistente e portátil para outras versões e provedores. A maioria das configurações de produção precisa dos dois.

Por quanto tempo devo reter os backups? Por tempo suficiente para perceber um problema. Corrupção ou uma migration mal executada muitas vezes só é descoberta dias depois, portanto um único dia de retenção frequentemente significa que os únicos backups disponíveis já contêm o dano.