Che cos'è il point-in-time recovery (PITR)?

Il point-in-time recovery è un metodo di restore che riproduce un log delle modifiche sopra un backup di base per ricostruire il database a un secondo scelto. Lo scenario per cui esiste non è il guasto hardware – di quello si occupa la replica – ma quello umano: una migrazione che ha corrotto delle righe alle 14:32, uno script che ha eliminato il tenant sbagliato. Il PITR (ripristino a un istante nel tempo) risponde con l’unica cosa che aiuta: il database esattamente com’era alle 14:31:59.

Punti chiave

Il meccanismo, in una sola sessione di lavoro

-- Il log delle modifiche è la materia prima: ogni scrittura confermata, in ordine.
-- Prima di un'operazione rischiosa, si può lasciarci un marcatore con un nome:
SELECT pg_create_restore_point('before_pricing_migration');

-- Ripristino = backup di base + replay, fermato nel punto indicato:
--   ripristinare il backup di base preso alle 02:00
--   riprodurre il log in avanti…
--   …e fermarsi appena prima del danno:
--     recovery_target_time = '2026-08-05 14:31:59+00'
--     (oppure recovery_target_name = 'before_pricing_migration')

-- Tutto ciò che è stato confermato prima dell'obiettivo esiste; nulla di posteriore esiste.

È il write-ahead log che fa doppio lavoro: lo stesso registro ordinato che dà alle transazioni la loro durabilità diventa, se archiviato in continuo, una macchina del tempo. I database documentali giocano la stessa partita con l’oplog – catturare il flusso di operazioni, riprodurlo sopra uno snapshot, fermarsi a comando (PostgreSQL lo chiama continuous archiving; MongoDB documenta la stessa architettura sopra snapshot del file system).

Dopo qualsiasi restore, il passo di verifica dell’esercitazione è a livello applicativo – confermare che la linea temporale sia atterrata dove previsto:

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

Come un restore arriva alle 14:31:59

Dal meccanismo discendono due proprietà. Primo, l’RPO è fissato dalla frequenza di cattura: log spediti ogni pochi secondi significano pochi secondi di perdita massima, a prescindere da quando è girato l’ultimo snapshot. Secondo, l’RTO è fissato dalla distanza di replay: ripristinare alle 23:00 da una base delle 02:00 significa riprodurre 21 ore di scritture – ed è per questo che i sistemi PITR continuano a fare snapshot frequenti, non per la granularità ma per accorciare la rincorsa.

Snapshot vs. PITR

Quale garanzia di ripristino serve davvero?

Casi d’uso comuni

• Il deployment sbagliato. Una migrazione o un hotfix corrompe i dati a metà pomeriggio – si ripristina al secondo prima del rilascio.
• Cancellazioni per errore di battitura. Il tenant, la collection o la clausola WHERE sbagliati – si torna ad appena prima dell’istruzione, spesso in un database usa e getta per estrarre solo ciò che è andato perso.
• Ransomware e compromissione dell’account. Si riavvolge a prima che l’intrusione toccasse i dati – con la crittografia a riposo a proteggere le stesse copie archiviate.
• Conservazione per conformità. I prodotti regolamentati devono dimostrare la ripristinabilità – finestre documentate, restore testati, esercitazioni verificabili.
• Prova generale prima del lancio. L’esercitazione di restore come barriera di rilascio: i team che hanno già ripristinato a un timestamp una volta lo rifanno con calma la notte in cui conta.

Conviene affidarsi ai backup predefiniti? Matrice decisionale

Qualunque cosa fornisca la piattaforma, tre decisioni restano a chi sviluppa: l’RPO a cui il prodotto può sopravvivere, l’RTO che gli utenti tollereranno, e la cadenza delle esercitazioni che tiene onesti entrambi i numeri – la disciplina che la guida del NIST alla pianificazione di contingenza formalizza così: definire gli obiettivi, poi testare rispetto a essi.

Limiti e trade-off

• La replica non è ripristino. Le repliche replicano l’errore nel giro di secondi; solo i backup arrivano a prima. Strumenti diversi, classi di guasto diverse.
• La finestra è finita. Il PITR raggiunge qualsiasi secondo – dentro la conservazione. Un danno scoperto dopo la chiusura della finestra è permanente; la conservazione va dimensionata sul tempo di rilevamento, non solo sul prezzo dell’archiviazione.
• Il replay richiede tempo. I restore pesanti di log possono durare a lungo; l’RTO reale si misura con le esercitazioni, non si legge nelle dashboard.
• I restore ripristinano il database intero. Il PITR classico ricostruisce il database a un timestamp; estrarre le righe perse di una sola tabella significa ripristinare su un’istanza usa e getta e copiare da lì – quel workflow va pianificato.
• Un backup mai testato è una voce di corridoio. Export falliti in silenzio, credenziali scadute, runbook mancanti – ognuno è invisibile finché non lo trova un’esercitazione o un disastro. Le esercitazioni costano meno.

PITR e backup su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. I backup del database gestito girano a calendario senza configurazione, e il restore è un’operazione della dashboard anziché una notte di archeologia nei log – la metà “snapshot e meccanica” di questo articolo, assorbita dalla piattaforma. La metà che resta a chi sviluppa è la decisione: gli obiettivi di RPO e RTO, le esigenze di conservazione, e l’esercitazione trimestrale in cui le schede di codice qui sopra verificano che la linea temporale ripristinata sia esattamente quella richiesta.