Qu'est-ce que le point-in-time recovery (PITR) ?

Le point-in-time recovery est une méthode de restauration qui rejoue un journal des modifications sur une sauvegarde de base, jusqu’à la seconde choisie. Le scénario pour lequel il existe n’est pas la panne matérielle — la réplication s’en charge — mais l’erreur humaine : une migration qui a corrompu des lignes à 14:32, un script qui a supprimé le mauvais tenant. Le PITR y répond avec la seule chose utile : la base de données exactement telle qu’elle était à 14:31:59.

Points clés

Le mécanisme, en une seule session

-- Le journal des modifications est la matière première : chaque écriture validée, dans l'ordre.
-- Avant une opération risquée, vous pouvez y déposer un marqueur nommé :
SELECT pg_create_restore_point('before_pricing_migration');

-- Restauration = sauvegarde de base + rejeu, arrêté là où vous le décidez :
--   restaurer la sauvegarde de base prise à 02:00
--   rejouer le journal vers l'avant…
--   …et s'arrêter juste avant les dégâts :
--     recovery_target_time = '2026-08-05 14:31:59+00'
--     (ou recovery_target_name = 'before_pricing_migration')

-- Tout ce qui a été validé avant la cible existe ; rien de postérieur n'existe.

C’est le write-ahead log qui fait double emploi : le même enregistrement ordonné qui assure la durabilité des transactions devient, une fois archivé en continu, une machine à remonter le temps. Les bases de données documentaires jouent exactement la même partition avec l’oplog — capturer le flux d’opérations, le rejouer sur un snapshot, s’arrêter à la demande (PostgreSQL parle d’archivage continu ; MongoDB documente la même architecture à partir de snapshots du système de fichiers).

Après toute restauration, l’étape de vérification de l’exercice se joue au niveau applicatif — confirmez que la chronologie a atterri là où vous le vouliez :

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

Comment une restauration atteint 14:31:59

Deux propriétés découlent du mécanisme. D’abord, le RPO est fixé par la fréquence de capture : des journaux expédiés toutes les quelques secondes signifient quelques secondes de perte maximale, quelle que soit l’heure du dernier snapshot. Ensuite, le RTO est fixé par la distance de rejeu : restaurer à 23:00 depuis une base de 02:00 implique de rejouer 21 heures d’écritures — c’est pourquoi les systèmes de PITR prennent toujours des snapshots fréquents, non pour la granularité, mais pour raccourcir la piste.

Snapshots vs. PITR

De quelle garantie de restauration avez-vous vraiment besoin ?

Cas d’usage courants

• Le déploiement raté. Une migration ou un hotfix corrompt les données en plein après-midi — restaurez à la seconde qui précède sa mise en production.
• Les suppressions par erreur de manipulation. Le mauvais tenant, la mauvaise collection ou la mauvaise clause WHERE — revenez juste avant l’exécution de l’instruction, souvent dans une base jetable pour n’en extraire que ce qui a été perdu.
• Ransomware et compromission de compte. Revenez à l’état antérieur à l’intrusion sur les données — avec le chiffrement au repos pour protéger les copies archivées elles-mêmes.
• Rétention réglementaire. Les produits réglementés doivent prouver leur capacité de restauration — fenêtres documentées, restaurations testées, exercices auditables.
• Répétition avant lancement. L’exercice de restauration comme condition de sortie : les équipes qui ont déjà restauré une fois à un horodatage précis le refont sereinement le soir où cela compte.

Devriez-vous vous fier aux sauvegardes par défaut ? Matrice de décision

Quoi que fournisse la plateforme, trois décisions vous reviennent : le RPO auquel votre produit peut survivre, le RTO que vos utilisateurs toléreront, et la cadence des exercices qui garde ces deux chiffres honnêtes — la discipline que le guide de planification de continuité du NIST formalise ainsi : définir les objectifs, puis tester par rapport à eux.

Limites et trade-offs

• La réplication n’est pas une restauration. Les répliques reproduisent l’erreur en quelques secondes ; seules les sauvegardes permettent de revenir avant. Outils différents, catégories de pannes différentes.
• La fenêtre est finie. Le PITR atteint n’importe quelle seconde — à l’intérieur de la rétention. Des dégâts découverts après la fermeture de la fenêtre sont définitifs ; dimensionnez la rétention sur le délai de détection, pas seulement sur le prix du stockage.
• Le rejeu prend du temps. Les restaurations chargées en journaux peuvent être longues ; votre RTO réel se mesure lors des exercices, il ne s’affiche pas dans un dashboard.
• Les restaurations portent sur l’ensemble. Le PITR classique reconstruit toute la base à un horodatage donné ; récupérer les lignes perdues d’une seule table implique de restaurer dans une instance jetable puis de recopier — prévoyez ce workflow.
• Une sauvegarde jamais testée n’est qu’une rumeur. Exports qui échouent en silence, identifiants expirés, runbooks manquants — tout cela reste invisible jusqu’à ce qu’un exercice ou un sinistre le révèle. Les exercices coûtent moins cher.

PITR et sauvegardes sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Les sauvegardes de la base de données gérée s’exécutent selon un calendrier sans aucune configuration, et la restauration est une opération du dashboard plutôt qu’une nuit d’archéologie dans les journaux — la moitié « snapshots et mécanique » de cet article, prise en charge par la plateforme. La moitié qui vous reste, c’est la décision : vos objectifs de RPO et de RTO, vos besoins de rétention, et l’exercice trimestriel au cours duquel les onglets de code ci-dessus vérifient que la chronologie restaurée est exactement celle que vous avez demandée.