La restauration point-in-time (Point-in-Time Recovery, PITR) est une technique de sauvegarde et de récupération qui permet de restaurer une base de données ou un système à un état précis, correspondant à un instant spécifique dans le temps. Cette méthode est essentielle pour minimiser les pertes de données en cas d'incident (erreur humaine, corruption, attaque malveillante, etc.).

Principe de fonctionnement

La PITR repose sur deux composants principaux :
Sauvegarde de base (base backup / full backup) : capture périodique et physiquement cohérente de l'intégralité des données.
Journaux de transactions (WAL, Write-Ahead Logs) : enregistrement continu de toutes les modifications apportées aux données depuis la sauvegarde.

Processus :

Restauration de la dernière sauvegarde de base antérieure au point de restauration souhaité.
Rejeu des journaux de transactions jusqu'au moment exact (timestamp, numéro de transaction ou point de restauration nommé) souhaité, afin de reconstruire l'état des données à cet instant précis.
Cas d'usage

Récupération après une erreur humaine : suppression accidentelle de données critiques, UPDATE/DELETE sans clause WHERE, migration ratée.
Corruption logique de données : table ou jeu de données incohérent après un traitement défectueux.
Attaques malveillantes : après un ransomware ou une intrusion, pour revenir à un état sain antérieur à la compromission.
Tests et audits : reconstituer l'état d'un système à un moment donné (environnement de test, analyse forensique).

Technologies et outils compatibles

Bases de données :
PostgreSQL (sauvegarde par pg_basebackup + archivage et rejeu des WAL ; outils pgBackRest, Barman).
MySQL/MariaDB (sauvegarde + binary logs rejoués via mysqlbinlog).
Oracle (RMAN avec les archived redo logs).
SQL Server (sauvegarde complète + différentielle + sauvegardes du journal des transactions, RESTORE ... WITH STOPAT).
MongoDB (oplog d'un jeu de réplicas).
Systèmes de fichiers / stockage (granularité au snapshot, non transactionnelle) :
ZFS (snapshots, zfs send/receive).
Btrfs (snapshots).
Services cloud :
AWS RDS / Aurora (Point-in-Time Restore à partir des sauvegardes automatiques et des journaux).
Azure SQL Database (Point-in-Time Restore intégré).
Google Cloud SQL (PITR via journaux binaires / WAL).

Avantages

Précision temporelle : restauration à la seconde près (voire à la transaction près), selon la granularité des journaux.
Minimisation des pertes : seules les transactions postérieures au point cible sont abandonnées (RPO très faible).
Flexibilité : s'intègre aux plans de reprise après sinistre (Disaster Recovery) et permet la restauration sur un serveur distinct.

Limites et défis

Coût de stockage : les journaux de transactions archivés peuvent occuper un espace disque important.
Performance / RTO : le rejeu des journaux peut être long pour des bases volumineuses ou une longue période à rejouer.
Complexité : nécessite une configuration et une maintenance rigoureuses de l'archivage et de la chaîne de sauvegardes.
Fenêtre de récupération limitée : impossible de remonter avant la plus ancienne sauvegarde de base disponible, et toute rupture dans la chaîne de WAL bloque le rejeu au-delà du trou.
Granularité globale : la PITR restaure généralement l'instance ou la base entière, pas un seul objet.

Exemple concret avec PostgreSQL
Sauvegarde de base :

pg_basebackup -D /chemin/vers/sauvegarde -U utilisateur -P

Archivage des WAL :

Configurer wal_level = replica, archive_mode = on et archive_command dans postgresql.conf pour archiver les WAL dans un emplacement dédié.

Restauration :

Restaurer la sauvegarde de base dans le répertoire de données.
Définir restore_command et la cible de récupération, par exemple recovery_target_time = '2024-05-01 14:30:00' :
PostgreSQL 12 et versions ultérieures : dans postgresql.conf, puis créer un fichier vide recovery.signal.
PostgreSQL 11 et versions antérieures : dans un fichier recovery.conf.
Lancer le serveur, qui rejoue les WAL jusqu'à la cible :
pg_ctl start -D /chemin/vers/sauvegarde
Terminer la récupération avec pg_wal_replay_resume() ou promote une fois l'état vérifié.
À noter : pg_restore sert à recharger un dump logique produit par pg_dump ; il n'intervient pas dans la PITR physique.

Bonnes pratiques

Automatiser les sauvegardes : planifier des sauvegardes de base régulières et un archivage WAL continu.
Tester les restaurations : valider périodiquement la PITR de bout en bout (RPO/RTO réels mesurés).
Surveiller l'espace disque : un archive_command en échec fait saturer le répertoire des WAL et peut arrêter l'instance.
Sécuriser les sauvegardes : chiffrement, immuabilité (WORM) et copie hors site pour résister à un sinistre local ou à un ransomware.
Documenter la rétention : définir explicitement la profondeur de la fenêtre de récupération.

En résumé : la PITR combine une sauvegarde de base et le rejeu des journaux de transactions pour ramener un système à un instant choisi ; c'est une solution puissante de résilience des données, mais elle exige une planification, une surveillance et des tests rigoureux.