O que é Point-in-Time Recovery (PITR)?

Point-in-time recovery é um método de restauração que reaplica um log de mudanças sobre um backup base para reconstruir o banco em qualquer segundo. O cenário para o qual ele existe não é a falha de hardware — disso a replicação cuida — mas o cenário humano: uma migração que corrompeu linhas às 14:32, um script que apagou o tenant errado. O PITR responde com a única coisa que ajuda: o banco exatamente como estava às 14:31:59.

Principais pontos

O mecanismo, em uma sessão de trabalho

-- O log de mudanças é a matéria-prima: cada escrita commitada, em ordem.
-- Antes de um trabalho arriscado, dá para cravar um marcador nomeado nele:
SELECT pg_create_restore_point('before_pricing_migration');

-- Recuperação = backup base + replay, parado onde você mandar:
--   restaure o backup base tirado às 02:00
--   reaplique o log para a frente…
--   …e pare pouco antes do estrago:
--     recovery_target_time = '2026-08-05 14:31:59+00'
--     (ou recovery_target_name = 'before_pricing_migration')

-- Tudo que foi commitado antes do alvo existe; nada depois dele existe.

Isso é o write-ahead log fazendo dupla jornada: o mesmo registro ordenado que dá durabilidade às transações vira, quando arquivado continuamente, uma máquina do tempo. Bancos de documentos rodam a jogada idêntica com o oplog — capture o fluxo de operações, reaplique sobre um snapshot, pare sob demanda (o PostgreSQL chama isso de arquivamento contínuo; o MongoDB documenta a mesma arquitetura sobre snapshots de sistema de arquivos).

Depois de qualquer restauração, o passo de verificação do simulado (drill) acontece no nível da aplicação — confirme que a linha do tempo parou onde deveria:

// JavaScript / Node.js — Back4app JS SDK
// Restore drill: verify the restored data lines up with the incident timeline
const incident = new Date('2026-08-05T14:32:00Z'); // when the bad deploy hit

const latest = new Parse.Query('Order');
latest.lessThan('createdAt', incident);
latest.descending('createdAt');
const lastGood = await latest.first();   // newest order before the incident

const after = new Parse.Query('Order');
after.greaterThanOrEqualTo('createdAt', incident);
const leaked = await after.count();      // must be 0 on a clean PITR restore

console.log(`last good write: ${lastGood?.get('createdAt')}`);
console.log(`rows past the recovery target: ${leaked}`);

// Flutter / Dart — Back4app Flutter SDK
// Restore drill: verify the restored data lines up with the incident timeline
final incident = DateTime.parse('2026-08-05T14:32:00Z'); // the bad deploy

final latest = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereLessThan('createdAt', incident)
  ..orderByDescending('createdAt')
  ..setLimit(1);
final lastGood = await latest.query();   // newest order before the incident

final after = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereGreaterThanOrEqualsTo('createdAt', incident);
final leaked = await after.count();      // must be 0 on a clean PITR restore

print('last good write: '
    '${(lastGood.results?.first as ParseObject?)?.createdAt}');
print('rows past the recovery target: ${leaked.count}');

// iOS / Swift — Back4app Swift SDK
// Restore drill: verify the restored data lines up with the incident timeline
let incident = ISO8601DateFormatter()
  .date(from: "2026-08-05T14:32:00Z")!   // when the bad deploy hit

let latest = Order.query("createdAt" < incident)
  .order([.descending("createdAt")])
  .limit(1)
latest.first { result in                 // newest order before the incident
  if case .success(let lastGood) = result {
    print("last good write: \(String(describing: lastGood.createdAt))")
  }
}

let after = Order.query("createdAt" >= incident)
after.count { result in                  // must be 0 on a clean PITR restore
  if case .success(let leaked) = result {
    print("rows past the recovery target: \(leaked)")
  }
}

// Android / Kotlin — Back4app Android SDK
// Restore drill: verify the restored data lines up with the incident timeline
val incident = Date(1754404320000L)      // 2026-08-05T14:32:00Z, the bad deploy

val latest = ParseQuery.getQuery<ParseObject>("Order")
latest.whereLessThan("createdAt", incident)
latest.orderByDescending("createdAt")
latest.limit = 1
latest.findInBackground { lastGood, _ -> // newest order before the incident
    println("last good write: ${lastGood?.firstOrNull()?.createdAt}")
}

val after = ParseQuery.getQuery<ParseObject>("Order")
after.whereGreaterThanOrEqualTo("createdAt", incident)
after.countInBackground { leaked, e ->   // must be 0 on a clean PITR restore
    if (e == null) println("rows past the recovery target: $leaked")
}

Como uma restauração chega às 14:31:59

Duas propriedades caem do mecanismo. Primeira, o RPO é definido pela frequência de captura: logs enviados a cada poucos segundos significam segundos de perda máxima, independentemente de quando rodou o último snapshot. Segunda, o RTO é definido pela distância de replay: restaurar para as 23:00 a partir de uma base das 02:00 significa reaplicar 21 horas de escritas — razão pela qual sistemas com PITR continuam tirando snapshots frequentes, não por granularidade, mas para encurtar a pista.

Snapshots vs. PITR

De qual garantia de recuperação você realmente precisa?

Casos de uso comuns

• O deploy ruim. Uma migração ou hotfix corrompe dados no meio da tarde — restaure para o segundo anterior à subida.
• Deleção por dedo gordo. O tenant, a coleção ou o WHERE errado — recupere para logo antes de o comando rodar, muitas vezes num banco descartável para extrair só o que se perdeu.
• Ransomware e conta comprometida. Volte para antes de a invasão tocar os dados — com criptografia em repouso protegendo as próprias cópias arquivadas.
• Retenção para conformidade. Produtos regulados precisam provar recuperabilidade — janelas documentadas, restaurações testadas, simulados auditáveis.
• Ensaio pré-lançamento. O simulado de restauração como critério de release: times que já restauraram para um timestamp uma vez fazem isso com calma na noite em que importa.

Você deveria confiar nos backups padrão? Matriz de decisão

Seja qual for o que a plataforma oferece, três decisões continuam suas: o RPO que o seu produto sobrevive, o RTO que os seus usuários toleram e a cadência de simulados que mantém os dois números honestos — a disciplina que a orientação de planejamento de contingência do NIST formaliza assim: defina objetivos e depois teste contra eles.

Limitações e trade-offs

• Replicação não é recuperação. Réplicas replicam o erro em segundos; só backups alcançam o estado anterior a ele. Ferramentas diferentes, classes de falha diferentes.
• A janela é finita. O PITR alcança qualquer segundo — dentro da retenção. Estrago descoberto depois de a janela fechar é permanente; dimensione a retenção pelo tempo de detecção, não só pelo preço do armazenamento.
• Reaplicar leva tempo. Restaurações com muito log podem se arrastar; o seu RTO real é medido por simulados, não cotado por dashboards.
• Restaurações vêm inteiras. O PITR clássico reconstrói o banco num timestamp; extrair as linhas perdidas de uma tabela significa restaurar numa instância descartável e copiar de lá — planeje esse fluxo.
• Backup não testado é boato. Falhas silenciosas de export, credenciais expiradas, runbooks inexistentes — cada uma é invisível até um simulado ou um desastre encontrá-la. Simulados são mais baratos.

PITR e backups no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Os backups do banco gerenciado rodam em agenda sem configuração, e a restauração é uma operação de dashboard em vez de uma noite de arqueologia de logs — a metade de snapshots e mecânica deste artigo, absorvida pela plataforma. A metade que continua com você é a de decidir: as suas metas de RPO e RTO, as suas necessidades de retenção e o simulado trimestral em que as abas de código acima verificam que a linha do tempo restaurada é exatamente a que você pediu.