Les timelines¶

Quand on réalise une restauration PITR (à partir d’une copie et des fichiers et des archives des journaux de transactions), on restaure habituellement jusqu’à un certain point dans le temps, en précisant un recovery_target_time par exemple.

Imaginons un environnement fonctionnant en production.

À 14 h se produit un incident en production, constaté à 16h.
À 13 h 59, on effectue une restauration, par exemple (première flèche noire du schéma).
La restauration ramène l’instance à son état à 13 h 59. À partir de ce moment-là, nous avons deux versions possibles de l’instance pour les événements postérieurs à 13 h 59. Pour les distinguer, PostgreSQL incrémente la « timeline » de l’instance. Si nous étions à la timeline 1, il crée une timeline 2.
À 17 h un second incident se produit sur la production en place, donc sur cette timeline 2.

Nous voulons donc restaurer l’instance, cette fois-ci à 16 h 59. Il faut alors préciser lors de la restauration, dans le fichier postgresql.conf (ou recovery.conf jusqu’en version 11), que nous voulons restaurer l’instance sur la timeline 2.

Par défaut, PostgreSQL restaure sur la timeline de la sauvegarde, ce qui ne correspond pas au besoin. Il faut donc préciser recovery_target_timeline=2 dans le fichier. Cette restauration étant terminée, la timeline est incrémentée à 3.

Finalement, il est décidé que les données de la timeline 1 jusqu’à 16 h sont plus importantes que les conséquences de l’incident de 14 h (ou bien nous voulons restaurer l’instance à son état à 16 h, sur un autre serveur, pour en récupérer les données). Nous reprenons la restauration, mais en précisant la timeline 1 dans le postgresql.conf (attention, si l’on ne précise rien, la timeline choisie par défaut est la dernière trouvée à la restauration).

Une fois l’état de l’instance à 16 h restaurée, sa timeline est passée à 4.

Cette fonctionnalité est très pratique, car elle permet de gérer cette problématique, permet de mélanger des journaux d’avant et après restauration dans le même dépôt, et évite réaliser une sauvegarde juste après chaque restauration pour disposer d’un point de reprise (cela reste conseillé).

D’un point de vue technique, peu de choses sont visibles :

Les journaux de transaction générés dans une timeline ont un nom qui contient la timeline : elle est stockée dans les 8 premiers chiffres du nom du fichier. Par exemple : 0000000300000001000000A5 est un fichier de la timeline 3.
Chaque création de timeline crée un fichier xxxxxxxx.history, xxxxxxxxcorrespondant au numéro de la timeline, qui contient les informations sur les liens entre chaque timeline. Ces fichiers sont archivés comme les journaux de transaction. Contrairement aux journaux, il est fortement recommandé de ne pas les supprimer :
ils ne pèsent que quelques octets
ils sont utilisés pour déterminer le chemin à prendre pour atteindre une timeline à partir d’une sauvegarde
ils permettent de déterminer le numéro de la prochaine timeline

Le numéro de timeline courant peut être récupéré avec la commande pg_controldata.

Warning

Le numéro de timeline dans les traces, ou affiché par pg_controldata, est en décimal. Mais les fichiers .history portent un numéro en hexadécimal (par exemple 00000014.history pour la timeline 20). On peut fournir les deux à recovery_target_timeline (20 ou 0x14). Attention, il n’y a pas de contrôle !