---
term: 'Point-in-Time Recovery (PITR) et Sauvegardes en BaaS'
seoTitle: 'Point-in-Time Recovery (PITR) et sauvegardes en BaaS'
headline: "Qu'est-ce que le point-in-time recovery (PITR) ?"
slug: sauvegardes-et-pitr
category: database
shortDefinition: "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."
relatedTerms:
  - multi-tenant-database-architecture
  - data-encryption-at-rest-transit
  - database-schema
  - acid-transactions
contrastsWith:
  - data-encryption-at-rest-transit
faq:
  - question: "Qu'est-ce que le point-in-time recovery, en termes simples ?"
    answer: "Une restauration qui peut atterrir sur n'importe quel instant, et pas seulement aux heures des sauvegardes planifiées. Le moteur part d'une sauvegarde de base et rejoue son journal des modifications — chaque écriture validée, dans l'ordre — en s'arrêtant à la seconde que vous indiquez. Au lieu de perdre tout ce qui s'est passé depuis le snapshot de la nuit dernière, vous ne perdez que ce qui a eu lieu après 14:31:59, la seconde précédant l'incident."
  - question: "Quelle est la différence entre un snapshot et le PITR ?"
    answer: "La granularité. Un snapshot est une photographie : la restauration atterrit exactement sur l'instant où il a été pris, et tout ce qui suit est perdu. Le PITR est un film : sauvegarde de base plus capture continue du journal, ce qui permet d'arrêter la lecture n'importe où dans la fenêtre de rétention. Les snapshots sont plus simples et moins chers à conserver ; le PITR fait passer la question de la restauration de « quelle nuit ? » à « quelle seconde ? »."
  - question: 'Que sont le RPO et le RTO ?'
    answer: "Les deux chiffres dont parle en secret toute discussion sur les sauvegardes. Le RPO — recovery point objective — est la quantité de données récentes que vous pouvez vous permettre de perdre, fixée par la fréquence des sauvegardes ou de l'envoi des journaux. Le RTO — recovery time objective — est la durée que la restauration peut prendre, fixée par le volume des données et la mécanique de restauration. Des snapshots quotidiens donnent un RPO de plusieurs heures ; la capture continue du journal le ramène à quelques secondes."
  - question: 'La réplication remplace-t-elle les sauvegardes ?'
    answer: "Non — la réplication relève de la disponibilité, pas de la restauration. Une réplique copie fidèlement tout ce que fait le primaire, y compris le DROP TABLE lancé par erreur ; en quelques secondes, toutes les copies s'accordent sur les dégâts. Les sauvegardes et le PITR existent précisément pour revenir à un état *antérieur* à l'erreur, ce qu'aucune réplication ne préserve. Il vous faut les deux, pour des catégories de pannes différentes."
  - question: 'À quelle fréquence faut-il lancer les sauvegardes ?'
    answer: "Partez de votre RPO et remontez. Si perdre une journée d'écritures est supportable, des snapshots nocturnes suffisent ; si une heure fait mal, ajoutez des sauvegardes incrémentales plus fréquentes ; si les minutes comptent, il vous faut une capture continue du journal — et dès lors, la fréquence des snapshots détermine la vitesse de restauration plutôt que la perte de données. Quel que soit le calendrier, la durée de rétention décide jusqu'où les erreurs restent réparables."
  - question: 'Pourquoi les exercices de restauration sont-ils importants ?'
    answer: "Parce qu'une sauvegarde jamais testée est une hypothèse, pas un plan. Les exercices font remonter les défaillances qui n'apparaissent qu'à la pratique : des exports cassés sans bruit, des restaurations qui prennent neuf heures pour un RTO d'une heure, des identifiants manquants, des étapes non documentées. Un exercice trimestriel — restaurer dans un environnement jetable, vérifier les données, chronométrer le processus — transforme l'hypothèse en procédure répétée."
  - question: 'Que faut-il vérifier après la restauration d''une base de données ?'
    answer: "Vérifiez d'abord la chronologie : les enregistrements les plus récents doivent se situer juste avant la cible de restauration, et rien ne doit exister après. Vérifiez ensuite l'intégrité — nombre de lignes conforme aux attentes, invariants critiques, références qui doivent se résoudre. Vérifiez enfin l'application : connectez-vous, déroulez les parcours essentiels, assurez-vous que les jobs en arrière-plan reprennent proprement. Une restauration « terminée » peut encore être fausse sur ces trois plans."
  - question: 'Qui gère les sauvegardes dans un BaaS — la plateforme ou moi ?'
    answer: "La mécanique revient à la plateforme : snapshots, capture du journal, stockage, outils de restauration. Les objectifs restent les vôtres : choisir le RPO et le RTO de votre produit, connaître la fenêtre de rétention, mener les exercices de restauration et conserver un export indépendant si votre politique l'exige. Un backend géré supprime la tuyauterie, pas la responsabilité de décider à quoi ressemble une perte supportable."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'PostgreSQL — continuous archiving and PITR'
    url: 'https://www.postgresql.org/docs/current/continuous-archiving.html'
  - name: 'Recovery point objective (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Recovery_point_objective'
  - name: 'MongoDB backup methods'
    url: 'https://www.mongodb.com/docs/manual/core/backups/'
  - name: 'NIST SP 800-34 — Contingency Planning Guide'
    url: 'https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final'
cta:
  title: 'Des sauvegardes configurées en minutes, pas maintenues pendant des années'
  text: "Back4app exécute automatiquement des sauvegardes planifiées de votre base de données gérée, avec une restauration disponible depuis le dashboard — votre équipe consacre ainsi son budget de reprise à choisir ses objectifs de RPO et à répéter ses exercices, pas à câbler l'archivage des journaux."
  linkText: 'Commencez gratuitement'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-16'
translationKey: point-in-time-recovery-backups
---

**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

| Question | Réponse |
| --- | --- |
| Snapshot | Une photographie — la restauration atterrit sur l'instant où il a été pris |
| PITR | Sauvegarde de base + journal des modifications rejoué — la restauration atterrit sur n'importe quelle seconde |
| RPO | La quantité de données récentes que vous pouvez perdre — fixée par la fréquence de capture |
| RTO | La durée que peut prendre la restauration — fixée par le volume et la mécanique |
| Le partage | Un BaaS gère la mécanique ; les objectifs et les exercices restent à votre charge |

## Le mécanisme, en une seule session

```sql
-- 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](/glossary/fr/transactions-acid/) 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](https://www.postgresql.org/docs/current/continuous-archiving.html) ; [MongoDB documente la même architecture](https://www.mongodb.com/docs/manual/core/backups/) à 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:**

```javascript
// 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
// 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}');
```

**Swift:**

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

**Kotlin:**

```kotlin
// 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

```mermaid
flowchart LR
  accTitle: Déroulement d'un point-in-time recovery
  accDescr: Une sauvegarde de base nocturne est restaurée, puis le journal des modifications archivé est rejoué dans l'ordre jusqu'à la cible de restauration configurée juste avant l'incident, ce qui produit l'état de la base de données à la seconde choisie.
  B["Sauvegarde de base<br/>(snapshot de 02:00)"] --> R["Rejeu du journal archivé<br/>02:00 → …"]
  L["Capture continue du journal<br/>(WAL / oplog)"] --> R
  R -->|"arrêt à la cible :<br/>14:31:59"| S["Base de données telle<br/>qu'à la seconde choisie"]
  X["Incident à 14:32<br/>(migration défectueuse)"] -. "jamais rejoué" .-> S
```

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

| Dimension | Snapshots seuls | PITR (base + rejeu du journal) |
| --- | --- | --- |
| Granularité de restauration | Les instants où les snapshots ont été pris | N'importe quelle seconde de la fenêtre |
| RPO typique | Des heures (l'écart du calendrier) | De quelques secondes à quelques minutes |
| Coût de stockage | Faible — n copies | Plus élevé — copies + archive continue du journal |
| Vitesse de restauration | Rapide — on recopie | Plus lente — copie + rejeu |
| Face à l'erreur humaine | Tout ce qui suit le dernier snapshot est perdu | Presque rien d'antérieur à l'erreur n'est perdu |
| Complexité | Minimale | Réelle — archivage, ordonnancement, cibles |

### De quelle garantie de restauration avez-vous vraiment besoin ?

| Si perdre… est supportable | Alors il vous faut | À surveiller |
| --- | --- | --- |
| Une journée d'écritures | Des snapshots nocturnes | La durée de rétention |
| Une heure | Snapshots + sauvegardes incrémentales fréquentes | Que le calendrier se déclenche vraiment |
| Quelques minutes ou moins | Capture continue du journal (PITR) | Le retard d'archivage — c'*est* votre RPO |
| Rien, jamais | PITR + réplication synchrone | Le coût et la latence d'écriture, évalués honnêtement |

## 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](/glossary/fr/chiffrement-des-donnees/) 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

| Les réglages par défaut suffisent quand… | Allez au-delà quand… |
| --- | --- |
| Perdre une journée de données est gênant, pas fatal | Les écritures, c'est de l'argent — commandes, registres comptables, réservations |
| Le produit n'est pas encore lancé ou reste interne | Une heure de perte serait une catastrophe pour le support |
| Les données peuvent être reconstruites depuis une autre source | La base de données est l'unique source de vérité |
| Personne n'a demandé de garanties de restauration | Un contrat ou un régulateur fixe des valeurs de RPO/RTO |
| Vous n'avez jamais eu besoin de restaurer | Vous en avez eu besoin — et c'était tendu |

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](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final) 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.