¿Qué es Point-in-Time Recovery (PITR)?

Point-in-time recovery es un método de restauración que reaplica un log de cambios sobre un backup base para reconstruir la base de datos en cualquier segundo. El escenario para el que existe no es la falla de hardware — de eso se encarga la replicación — sino el humano: una migración que corrompió filas a las 14:32, un script que borró el tenant equivocado. El PITR responde con lo único que ayuda: la base de datos exactamente como estaba a las 14:31:59.

Puntos clave

El mecanismo, en una sesión de trabajo

-- El log de cambios es la materia prima: cada escritura confirmada, en orden.
-- Antes de un trabajo riesgoso, puedes dejarle un marcador con nombre:
SELECT pg_create_restore_point('before_pricing_migration');

-- Recuperación = backup base + replay, detenido donde tú digas:
--   restaura el backup base tomado a las 02:00
--   reaplica el log hacia adelante…
--   …y detente justo antes del daño:
--     recovery_target_time = '2026-08-05 14:31:59+00'
--     (o recovery_target_name = 'before_pricing_migration')

-- Todo lo confirmado antes del objetivo existe; nada posterior existe.

Este es el write-ahead log haciendo doble turno: el mismo registro ordenado que da durabilidad a las transacciones se convierte, cuando se archiva continuamente, en una máquina del tiempo. Las bases de datos de documentos ejecutan la jugada idéntica con el oplog — captura el stream de operaciones, reaplícalo sobre un snapshot, detente a demanda (PostgreSQL lo llama archivado continuo; MongoDB documenta la misma arquitectura sobre snapshots del sistema de archivos).

Después de cualquier restauración, el paso de verificación del simulacro es a nivel de aplicación — confirma que la línea de tiempo aterrizó donde debía:

// 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")
}

Cómo una restauración llega a las 14:31:59

Del mecanismo se desprenden dos propiedades. Primera, el RPO lo fija la frecuencia de captura: logs enviados cada pocos segundos significan segundos de pérdida máxima, sin importar cuándo corrió el último snapshot. Segunda, el RTO lo fija la distancia de replay: restaurar hasta las 23:00 desde una base de las 02:00 significa reaplicar 21 horas de escrituras — razón por la cual los sistemas con PITR siguen tomando snapshots frecuentes, no por granularidad sino para acortar la pista.

Snapshots vs. PITR

¿Qué garantía de recuperación necesitas realmente?

Casos de uso comunes

• El deploy malo. Una migración o un hotfix corrompe datos a media tarde — restaura al segundo anterior a su salida.
• Borrados de dedo gordo. El tenant, la colección o el WHERE equivocado — recupera hasta justo antes de que corriera la sentencia, muchas veces en una base desechable para extraer solo lo perdido.
• Ransomware y cuentas comprometidas. Rebobina hasta antes de que la intrusión tocara los datos — con cifrado en reposo protegiendo las propias copias archivadas.
• Retención por cumplimiento. Los productos regulados deben probar la recuperabilidad — ventanas documentadas, restauraciones probadas, simulacros auditables.
• Ensayo previo al lanzamiento. El simulacro de restauración como requisito de release: los equipos que ya restauraron a un timestamp una vez lo hacen con calma la noche en que importa.

¿Deberías confiar en los backups por defecto? Matriz de decisión

Ofrezca lo que ofrezca la plataforma, tres decisiones siguen siendo tuyas: el RPO que tu producto puede sobrevivir, el RTO que tus usuarios van a tolerar y la cadencia de simulacros que mantiene honestos ambos números — la disciplina que la guía de planificación de contingencias del NIST formaliza así: define objetivos y luego prueba contra ellos.

Limitaciones y trade-offs

• La replicación no es recuperación. Las réplicas replican el error en segundos; solo los backups alcanzan el estado anterior a él. Herramientas distintas, clases de falla distintas.
• La ventana es finita. El PITR alcanza cualquier segundo — dentro de la retención. El daño descubierto después de que la ventana cierra es permanente; dimensiona la retención según el tiempo de detección, no solo según el precio del almacenamiento.
• El replay toma tiempo. Las restauraciones con mucho log pueden alargarse; tu RTO real se mide con simulacros, no lo cotizan los dashboards.
• Las restauraciones llegan enteras. El PITR clásico reconstruye la base de datos en un timestamp; extraer las filas perdidas de una sola tabla implica restaurar en una instancia desechable y copiar desde ahí — planifica ese flujo.
• Un backup no probado es un rumor. Fallas silenciosas de export, credenciales expiradas, runbooks inexistentes — cada una es invisible hasta que un simulacro o un desastre la encuentra. Los simulacros salen más baratos.

PITR y backups en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Los backups de la base de datos gestionada corren según calendario sin configuración, y restaurar es una operación de dashboard en lugar de una noche de arqueología de logs — la mitad de snapshots y mecánica de este artículo, absorbida por la plataforma. La mitad que se queda contigo es la de decidir: tus metas de RPO y RTO, tus necesidades de retención y el simulacro trimestral en el que las pestañas de código de arriba verifican que la línea de tiempo restaurada es exactamente la que pediste.