Au sens abstrait, un système PostgreSQL fonctionnel produit une séquence infinie d'enregistrements de journaux de transactions. Le système divise physiquement cette séquence en fichiers de segment WAL de 16 Mo chacun (en général, mais cette taille peut être modifiée lors de l'exécution d'initdb). Les fichiers segment reçoivent des noms numériques pour refléter leur position dans la séquence abstraite des journaux de transactions. Lorsque le système n'utilise pas l'archivage des journaux de transactions, il ne crée que quelques fichiers segments, qu'il « recycle » en renommant les fichiers devenus inutiles. Un fichier segment dont le contenu précède le dernier checkpoint est supposé inutile et peut être recyclé.

Lors de l'archivage des journaux de transactions, le contenu de chaque fichier segment doit être capturé dès qu'il est rempli pour sauvegarder les données ailleurs avant son recyclage. En fonction de l'application et du matériel disponible, « sauvegarder les données ailleurs » peut se faire de plusieurs façons : les fichiers segment peuvent être copiés dans un répertoire NFS monté sur une autre machine, être écrits sur une cartouche (après s'être assuré qu'il existe un moyen d'identifier le nom d'origine de chaque fichier) ou être groupés pour gravure sur un CD, ou toute autre chose. Pour fournir autant de flexibilité que possible à l'administrateur de la base de données, PostgreSQL essaie de ne faire aucune supposition sur la façon dont l'archivage est réalisé. À la place, PostgreSQL permet de préciser une commande shell ou une bibliothèque d'archivage à exécuter pour copier le fichier segment complet à l'endroit désiré. Cela peut être aussi simple qu'une commande shell qui utilise cp ou cela peut appeler une fonction C complexe -- c'est l'utilisateur qui décide.

Pour activer l'archivage des journaux de transaction, configurez le paramètre de configuration wal_level à replica ou supérieur, archive_mode à on, et précisez la commande shell à utiliser dans le paramètre de configuration archive_command ou précisez la bibliothèque à utiliser dans le paramètre archive_library de la configuration. En fait, ces paramètres seront toujours placés dans le fichier postgresql.conf.

Un moyen simple d'archiver est de configurer le paramètre archive_library avec une chaîne vide et de spécifier une commande shell au niveau du paramètre archive_command. Dans cette chaîne, un %p est remplacé par le chemin absolu de l'archive alors qu'un %f n'est remplacé que par le nom du fichier. (Le nom du chemin est relatif au répertoire de travail du serveur, c'est-à-dire le répertoire des données de l'instance.) %% est utilisé pour écrire le caractère % dans la commande. La commande la plus simple ressemble à :

archive_command = 'test ! -f /mnt/serveur/repertoire_archive/%f && cp %p /mnt/serveur/repertoire_archive/%f'  # Unix
  archive_command = 'copy "%p" "C:\\serveur\\repertoire_archive\\%f"'  # Windows

qui copie les segments WAL archivables dans le répertoire /mnt/serveur/repertoire_archive. (Ceci est un exemple, pas une recommandation, et peut ne pas fonctionner sur toutes les plateformes.) Après le remplacement des paramètres %p et %f, la commande réellement exécutée peut ressembler à :

test ! -f /mnt/serveur/repertoire_archive/00000001000000A900000065 && cp pg_wal/00000001000000A900000065 /mnt/serveur/repertoire_archive/00000001000000A900000065

Une commande similaire est produite pour chaque nouveau fichier à archiver.

La bibliothèque d'archivage est exécutée sous l'identité de l'utilisateur propriétaire du serveur PostgreSQL. La série de journaux de transactions en cours d'archivage contient absolument tout ce qui se trouve dans la base de données, il convient donc de s'assurer que les données archivées sont protégées des autres utilisateurs ; on peut, par exemple, archiver dans un répertoire sur lequel les droits de lecture ne sont positionnés ni pour le groupe ni pour le reste du monde.

Il est important que la commande d'archivage renvoie le statut de sortie zéro si et seulement si elle réussit. En cas de réception d'un code zéro, PostgreSQL supposera que le fichier a été archivé avec succès, et le supprimera ou le recyclera. Néanmoins, un code différent de zéro indique à PostgreSQL que le fichier n'a pas été archivé ; il essaiera de nouveau périodiquement jusqu'à sa réussite.

Une autre façon d'archiver est d'utiliser un module d'archivage personnalisé avec archive_library. Comme de tels modules sont écrits en C, créer son propre module nécessite considérablement plus d'effort que d'écrire une commande shell. Néanmoins, les modules d'archivage peuvent être plus performants que l'archivage via le shell, et ils auront accès à un grand nombre de ressources serveurs utiles. Pour plus d'informations sur les modules d'archivage, voir Chapitre 49.

Quand la commande d'archivage est terminée par un signal (autre que le signal SIGTERM qui est utilisé comme partie d'un arrêt du serveur) ou une erreur par le shell avec un statut de sortie plus grand que 125 (tel que « command not found »), ou si la fonction d'archivage émet un message ERROR ou FATAL, le processus d'archivage annule ou est redémarré par le processus postmaster. Dans de tels cas, l'échec n'est pas reporté dans pg_stat_archiver.

En général, les commande et bibliothèques d'archivage doivent être conçue pour refuser d'écraser tout fichier archive déjà existant. C'est une fonctionnalité de sécurité importante pour préserver l'intégrité de l'archive dans le cas d'une erreur de l'administrateur (comme l'envoi de la sortie de deux serveurs différents dans le même répertoire d'archivage). Il est conseillé de tester la commande ou la bibliothèque d'archivage proposée pour s'assurer, qu'en effet, elle n'écrase pas un fichier existant

Dans de rare cas, PostgreSQL pourrait tenter d'archiver de nouveau un journal de transaction qui a déjà été archivé.? Par exemple, si le système s'arrête brutalement avant que le serveur ait pu enregistrer de manière durable le succès de l'archivage, le serveur tentera d'archiver de nouveau le fichier après avoir redémarré (en supposant que l'archivage est toujours activé). Quand une commande ou une bibliothèque d'archivage rencontre un fichier existant, il doit renvoyer respectivement le statut zéro ou true si le journal a un contenu identique au journal archivé et que l'archive actuelle est correctement enregistré sur disque. Si un fichier pré-existant contient un contenu différent du journal à archiver, la commande d'archivage ou la bibliothèque doivent renvoyer respectivement un statut différent de zéro ou false.

La commande d'exemple pour Unix ci-dessus évite d'écraser une archive pré-existante grâce à l'étape test séparée. Sur certaines plateformes Unix, la commande cp dispose d'une option, comme -i pouvant être utilisé pour faire la même chose, mais en moins verbeux. Cependant, vous ne devriez pas vous baser là-dessus sans vous assurer que le code de sortie renvoyé est le bon. (En particulier, la commande cp de GNU renvoie un code zéro quand -i est utilisé et que le fichier cible existe déjà, ce qui n'est pas le comportement désiré.)

Lors de la conception de votre configuration d'archivage, il faut considérer ce qui peut se produire si la commande ou la bibliothèque d'archivage échoue de façon répétée, que ce soit parce qu'une intervention de l'opérateur s'avère nécessaire ou par manque d'espace dans le répertoire d'archivage. Ceci peut arriver, par exemple, lors de l'écriture sur une cartouche sans changeur automatique ; quand la cartouche est pleine, rien ne peut être archivé tant que la cassette n'est pas changée. Toute erreur ou requête à un opérateur humain doit être rapportée de façon appropriée pour que la situation puisse être résolue rapidement. Le répertoire pg_wal/ continue à se remplir de fichiers de segment WAL jusqu'à la résolution de la situation.(Si le système de fichiers contenant pg_wal/ se remplit, PostgreSQL s'arrête en mode PANIC. Aucune transaction validée n'est perdue mais la base de données est inaccessible tant que de l'espace n'a pas été libéré.)

La vitesse de la commande ou de la bibliothèque d'archivage n'est pas importante, tant qu'elle suit le rythme de génération des journaux de transactions du serveur. Les opérations normales continuent même si le processus d'archivage est un peu plus lent. Si l'archivage est significativement plus lent, alors la quantité de données qui peut être perdue croît. Cela signifie aussi que le répertoire pg_wal/ contient un grand nombre de fichiers segment non archivés, qui peuvent finir par remplir l'espace disque disponible. Il est conseillé de surveiller le processus d'archivage pour s'assurer que tout fonctionne normalement.

Lors de l'écriture de la commande ou de la bibliothèque d'archivage, il faut garder à l'esprit que les noms de fichier à archiver peuvent contenir jusqu'à 64 caractères et être composés de toute combinaison de lettres ASCII, de chiffres et de points. Il n'est pas nécessaire de conserver le chemin relatif original (%p) mais il est nécessaire de se rappeler du nom du fichier (%f).

Bien que l'archivage des journaux de transactions autorise à restaurer toute modification réalisée sur les données de la base, il ne restaure pas les modifications effectuées sur les fichiers de configuration (c'est-à-dire postgresql.conf, pg_hba.conf et pg_ident.conf) car ceux-ci sont édités manuellement et non au travers d'opérations SQL. Il est souhaitable de conserver les fichiers de configuration à un endroit où ils sont sauvegardés par les procédures standard de sauvegarde du système de fichiers. Voir la Section 19.2 pour savoir comment modifier l'emplacement des fichiers de configuration.

La commande ou la bibliothèque d'archivage n'est appelée que sur les fichiers segments WAL complets. Du coup, si le serveur engendre peu de trafic dans les journaux de transactions (ou qu'il y a des périodes de calme où le trafic est léger), il peut y avoir un long délai entre la fin d'une transaction et son enregistrement garanti dans le stockage d'archive. Pour placer une limite sur l'ancienneté des données archivées, il faut configurer archive_timeout, ce qui permet de forcer le serveur à changer de fichier segment WAL passé ce délai. Les fichiers archivés lors d'un tel forçage ont toujours la même taille que les fichiers complets. Il est donc déconseillé de configurer un délai archive_timeout trop court -- cela fait grossir anormalement le stockage. Une minute pour archive_timeout est généralement raisonnable.

De plus, le changement d'un segment peut être forcé manuellement avec pg_switch_wal. Cela permet de s'assurer qu'une transaction tout juste terminée est archivée aussi vite que possible. D'autres fonctions utilitaires relatives à la gestion des journaux de transactions sont disponibles dans Tableau 9.95.

Quand wal_level est configuré à la valeur minimal, certaines commandes SQL sont optimisées pour éviter la journalisation des transactions, de la façon décrite dans Section 14.4.7. Si l'archivage ou la réplication en flux sont activés lors de l'exécution d'une de ces instructions, les journaux de transaction ne contiennent pas suffisamment d'informations pour une restauration via les archives. (La restauration après un arrêt brutal n'est pas affectée.) Pour cette raison, wal_level ne peut être modifié qu'au lancement du serveur. Néanmoins, archive_command et archive_library peut être modifié par rechargement du fichier de configuration. Si vous archivez via le shell et souhaitez arrêter temporairement l'archivage, une façon de le faire est de peut placer une chaîne vide ('') dans archive_command. Les journaux de transaction sont alors accumulés dans pg_wal/ jusqu'au rétablissement d'un paramètre archive_command fonctionnel.

La manière la plus simple pour effectuer une sauvegarde revient à utiliser l'outil pg_basebackup. Il peut créer une sauvegarde de base sous la forme soit de fichiers standards, soit d'une archive tar. Pour les cas plus complexes, il est possible de réaliser une sauvegarde de base en utilisant l'API bas niveau (voir Section 25.3.4).

La durée d'une sauvegarde de base n'est pas toujours un critère déterminant. Toutefois, si vous exploitez votre serveur avec l'option full_page_writes désactivée, vous constaterez une baisse des performances lorsque la sauvegarde est effectuée car l'option full_page_writes est activée de force pendant les opérations de sauvegarde.

Pour utiliser une sauvegarde, vous devez conserver tous les fichiers segments WAL générés pendant et après la sauvegarde des fichiers. Pour vous aider dans cette tâche, le processus de sauvegarde crée un fichier historique de sauvegarde qui est immédiatement enregistré dans la zone d'archivage des journaux de transactions. Le nom de ce fichier reprend le nom du premier fichier segment WAL que vous devez conserver. Par exemple, si le premier fichier segment WAL à garder est 0000000100001234000055CD, alors le fichier historique de sauvegarde sera nommé de la manière suivante 0000000100001234000055CD.007C9330.backup. (La seconde partie du nom de fichier indique la position exacte à l'intérieur du fichier segment WAL. Cette information peut être ignorée.) Une fois que vous avez archivé avec précaution la sauvegarde de base et les fichiers segments WAL générés pendant la sauvegarde (tel qu'indiqué par le fichier historique de sauvegarde), tous les fichiers segments WAL antérieurs ne sont plus nécessaires pour restaurer votre sauvegarde de base. Ils peuvent être supprimés. Toutefois, il est conseillé de conserver plusieurs groupes de sauvegardes pour être absolument certain de récupérer vos données.

Le fichier historique de sauvegarde est un simple fichier texte. Il contient le label que vous avez attribué à l'opération pg_basebackup, ainsi que les dates de début, de fin et la liste des fichiers segments WAL de la sauvegarde. Si vous avez utilisé le label pour identifier le fichier de sauvegarde associé, alors le fichier historique vous permet de savoir quel fichier de sauvegarde vous devez utiliser pour la restauration.

Puisque vous devez archiver tous les fichiers segments WAL depuis votre dernière sauvegarde de base, l'intervalle entre deux sauvegardes de base doit être déterminé en fonction de l'espace de stockage que vous avez alloué pour l'archivage des fichiers segments WAL. Vous devez également prendre en compte le temps de restauration (le système devra rejouer tous les fichiers segments WAL, cela prendra un certain temps si la sauvegarde de base est ancienne).

Vous pouvez utiliser pg_basebackup pour réaliser une sauvegarde incrémentale en spécifiant l'option --incremental. Vous devez préciser comme argument de --incremental le manifeste de sauvegarde d'une précédente sauvegarde du même serveur. Dans la sauvegarde résultante, les fichiers ne correspondant pas à des relations seront inclus dans leur intégralité, mais certains fichiers de relations seront remplacés par des fichiers incrémentaux, plus petits, contenant uniquement les blocs modifiés depuis la sauvegarde précédente, et suffisamment de métadonnées pour reconstruire la version courante du fichier.

Pour trouver les blocs à sauvegarder, le serveur utilise les résumés de journaux de transactions, résumés stockés dans le sous-répertoire pg_wal/summaries du répertoire des données. Si les fichiers résumés requis sont absents, toute tentative de sauvegarde incrémentale échouera. Les résumés présents dans ce répertoire doivent couvrir tous les LSN depuis le LSN de début de la sauvegarde précédente. Comme le serveur recherche les résumés des journaux de transaction juste après avoir établi le LSN de départ de la sauvegarde courante, les fichiers de résumé nécessaires ne seront pas instantanément présents sur disque, mais le serveur attendra l'arrivée des fichiers manquants. Ceci aide aussi si le processus résumant les journaux a pris du retard. Néanmoins, si les fichiers nécessaires ont déjà été supprimés, ou si le processus de résumé des journaux ne rattrape pas son retard suffisamment rapidement, la sauvegarde incrémentale échouera.

Lors de la restauration d'une sauvegarde incrémentale, il sera nécessaire d'avoir non seulement la sauvegarde incrémentale, mais aussi toutes les sauvegardes précédentes requises pour fournir les blocs absents de la sauvegarde incrémentale. Voir pg_combinebackup pour plus d'informations sur ce prérequis. Notez qu'il existe des restrictions sur l'utilisation de pg_combinebackup quand le statut des sommes de contrôle sur l'instance a changé ; voir les limitations de pg_combinebackup.

Notez que tous les prérequis sur l'utilisation d'une sauvegarde complète s'appliquent aussi à une sauvegarde incrémentale. Par exemple, vous aurez besoin de tous les segments de fichiers WAL générés pendant et après la sauvegarde du système de fichiers, ainsi que de tous les fichiers d'historique. Vous aurez toujours encore besoin de créer un fichier recovery.signal (ou standby.signal) et d'exécuter la restauration, comme décrit dans Section 25.3.5. Le besoin des sauvegardes précédentes au moment de la restauration et l'utilisation de pg_combinebackup est une condition supplémentaire en plus de tout le reste. Gardez en tête que PostgreSQL, seul, ne sait pas détecter quelles sont les sauvegardes nécessaires à la restauration d'une sauvegarde incrémentale postérieure. Vous devez garder la trace des liens entre vos sauvegardes complète et incrémentales, et vous assurer de ne pas supprimer les sauvegardes précédentes si elles sont nécessaires pour restaurer des sauvegardes incrémentales ultérieures.

Les sauvegardes incrémentales n'ont d'interêt que pour des bases de données relativement volumineuses, où une portion significative des données ne change pas, ou change à un faible rythme. Pour une petite base, il est plus simple d'oublier les sauvegardes incrémentales et de rester sur des sauvegardes complètes, bien plus simples à gérer. Pour une base de données volumineuse et lourdement modifiée, les sauvegardes incrémentales ne seront pas beaucoup plus petites que les sauvegardes complètes.

Une sauvegarde incrémentale est seulement possible si le rejeu peut commencer à partir un checkpoint ultérieur à la précédente sauvegarde dont il dépend. Si vous réalisez une sauvegarde incrémentale à partir du serveur primaire, cette condition est toujours satisfaite car chaque sauvegarde déclenche un nouveau checkpoint. Sur un serveur secondaire, le rejeu commence à partir du restartpoint le plus récent. De ce fait, une sauvegarde incrémentale d'un serveur secondaire peut échouer s'il y a eu très peu d'activité depuis la sauvegarde précédente car aucun nouveau restartpoint n'aura été créé.

Au lieu de prendre une sauvegarde de base complète ou incrémentale avec pg_basebackup, vous pouvez faire une sauvegarde de base en utilisant l'API bas niveau. Cette procédure contient quelques étapes supplémentaires à la méthode pg_basebackup mais reste relativement simple. Il est très important de dérouler ces étapes dans l'ordre, et de vérifier que chacune s'est déroulée correctement avant de passer à la suivante.

Plusieurs sauvegardes peuvent s'exécuter en même temps (celles démarrées en utilisant cette API comme celles démarrées avec pg_basebackup).

Le pire est arrivé et il faut maintenant repartir d'une sauvegarde. Voici la procédure :

Le point clé de tout ceci est la configuration de la restauration qui décrit comment et jusqu'où restaurer. La seule chose qu'il faut absolument préciser dans postgresql.conf, c'est la valeur du paramètre restore_command qui indique à PostgreSQL comment récupérer les fichiers segments WAL archivés. À l'instar d'archive_command, c'est une chaîne de commande shell. Elle peut contenir %f, qui est remplacé par le nom du journal de transactions souhaité, et %p, qui est remplacé par le chemin du répertoire où copier le journal de transactions.(Le nom du chemin est relatif au répertoire de travail du serveur, c'est-à-dire le répertoire des données du cluster.) Pour écrire le caractère % dans la commande, on utilise %%. La commande la plus simple ressemble à :

restore_command = 'cp /mnt/serveur/répertoire_archive/%f %p'

qui copie les fichiers segments WAL précédemment archivés à partir du répertoire /mnt/serveur/répertoire_archive. Il est toujours possible d'utiliser une commande plus compliquée, voire même un script shell qui demande à l'utilisateur de monter la cassette appropriée.

Il est important que la commande renvoie un code de sortie différent de zéro en cas d'échec. Des fichiers absents de l'archive seront demandés à la commande ; elle doit renvoyer autre chose que zéro dans ce cas. Ce n'est pas une condition d'erreur. Une exception est possible si la commande a été terminée par un signal (autre que SIGTERM, qui est utilisé pour l'arrêt du serveur) ou par une erreur shell (comme une commande introuvable). Dans ces cas, la restauration va s'arrêter et le serveur ne démarrera plus.

Tous les fichiers demandés ne seront pas des fichiers segments WAL ; vous pouvez aussi vous attendre à des demandes de fichiers suffixés par .history. Il faut également garder à l'esprit que le nom de base du chemin %p diffère de %f ; ils ne sont pas interchangeables.

Les segments WAL qui ne se trouvent pas dans l'archive sont recherchés dans pg_wal/ ; cela autorise l'utilisation de segments récents non archivés. Néanmoins, les segments disponibles dans l'archive sont utilisés de préférence aux fichiers contenus dans pg_wal/.

Normalement, la récupération traite tous les segments WAL disponibles, restaurant du coup la base de données à l'instant présent (ou aussi proche que possible, en fonction des fichiers segments WAL disponibles). Une récupération normale se finit avec un message « fichier non trouvé », le texte exact du message d'erreur dépendant du choix de restore_command. Un message d'erreur au début de la restauration peut également apparaître concernant un fichier nommé dont le nom ressemble à 00000001.history. Ceci est aussi normal et n'indique pas un problème dans les situations de restauration standards. Voir Section 25.3.6 pour plus d'informations.

Pour restaurer jusqu'à un moment précis (avant que le DBA junior n'ait supprimé la table principale par exemple), il suffit d'indiquer le point d'arrêt requis. Le point d'arrêt, aussi nommé « cible de récupération » (« recovery target » dans la version originale) , peut être précisé par une combinaison de date et d'heure, par un point de restauration nommé ou par un identifiant de transaction. Actuellement, seules les options date/heure et point de restauration nommé sont vraiment utilisables car il n'existe pas d'outils permettant d'identifier avec précision l'identifiant de transaction à utiliser.

Si la restauration fait face à une corruption des données des journaux de transactions, le rejeu s'interrompt juste avant la corruption détectée et le serveur ne démarre pas. Dans un tel cas, le processus de restauration peut alors être ré-exécuté à partir du début en précisant une « cible de restauration » antérieure au point de corruption pour permettre à cette dernière de se terminer correctement. Si la restauration échoue pour une raison externe (arrêt brutal du système ou archive devenue inaccessible), la restauration peut être simplement relancée. Elle redémarre alors quasiment là où elle a échoué. Le redémarrage de la restauration fonctionne comme les checkpoints du déroulement normal : le serveur force une écriture régulière de son état sur les disques et actualise alors le fichier pg_control pour indiquer que les données déjà traitées des journaux de transactions n'ont plus à être parcourues.

La possibilité de restaurer la base de données à partir d'un instantané crée une complexité digne des histoires de science-fiction traitant du voyage dans le temps et des univers parallèles.

Par exemple, dans l'historique original de la base de données, supposez qu'une table critique ait été supprimée à 17h15 mardi soir, mais que personne n'ait réalisé cette erreur avant mercredi midi. Sans stress, la sauvegarde est récupérée et restaurée dans l'état où elle se trouvait à 17h14 mardi soir. La base est fonctionnelle. Dans cette histoire de l'univers de la base de données, la table n'a jamais été supprimée. Or, l'utilisateur réalise peu après que ce n'était pas une si grande idée et veut revenir à un quelconque moment du mercredi matin. Cela n'est pas possible, si, alors que la base de données est de nouveau fonctionnelle, elle réutilise certaines séquences de fichiers segments WAL qui permettent de retourner à ce point. Il est donc nécessaire de pouvoir distinguer les séries d'enregistrements des journaux de transactions engendrées après la restauration de l'instantané de celles issues de l'historique originel de la base.

Pour gérer ces difficultés, PostgreSQL inclut la notion de lignes temporelles (ou timelines). Quand une récupération d'archive est terminée, une nouvelle ligne temporelle est créée pour identifier la série d'enregistrements de journaux de transactions produits après cette restauration. Le numéro d'identifiant de la timeline est inclus dans le nom des fichiers segments WAL. De ce fait, une nouvelle timeline ne réécrit pas sur les données engendrées par des timelines précédentes. Par exemple, dans le nom de journal 0000000100001234000055CD, le début 00000001 est l'identifiant de la timeline en hexadécimal. (Notez que, dans d'autres contexyes, comme les traces du serveur, les identifiants de timeline sont habituellement affichés en décimal.)

En fait, il est possible d'archiver plusieurs timelines différentes. Bien que cela semble être une fonctionnalité inutile, cela peut parfois sauver des vies. Dans une situation où l'instantané à restaurer n'est pas connu avec certitude, il va falloir tester les restaurations de différents instantanés jusqu'à trouver le meilleur. Sans les timelines, ce processus engendre vite un bazar ingérable. Avec les timelines, il est possible de restaurer n'importe quel état précédent, même les états de branches temporelles abandonnées.

Chaque fois qu'une nouvelle timeline est créée, PostgreSQL crée un fichier d'« historique des timelines » qui indique à quelle timeline il est attaché, et depuis quand. Ces fichiers d'historique sont nécessaires pour permettre au système de choisir les bons fichiers segments WAL lors de la restauration à partir d'une archive qui contient plusieurs timelines. Ils sont donc archivés comme tout fichier segment WAL. Puisque ce sont de simples fichiers texte, il est peu coûteux et même judicieux de les conserver indéfiniment(contrairement aux fichiers segments, bien plus volumineux). Il est possible d'ajouter des commentaires au fichier d'historique expliquant comment et pourquoi cette timeline a été créée. De tels commentaires s'avèrent précieux lorsque l'expérimentation conduit à de nombreuses timelines.

Par défaut, la restauration s'effectue jusqu'à la dernière timeline trouvée dans l'archive. Si vous souhaitez effectuer la restauration uniquement pour la timeline de la sauvegarde ou jusqu'à une timeline précise (c'est-à-dire retourner à un état enregistré après une tentative de restauration), il faut préciser current ou l'identifiant de la timeline cible dans recovery_target_timeline. Il n'est pas possible de restaurer dans des timelines antérieures à la sauvegarde.

Quelques conseils de configuration de l'archivage continu sont donnés ici.

archive_command = 'gzip < %p > /mnt/server/archivedir/%f'

restore_command = 'gunzip < /mnt/server/archivedir/%f.gz > %p'

archive_command = 'local_backup_script.sh "%p" "%f"'

Au moment où ces lignes sont écrites, plusieurs limitations de la technique d'archivage en continu sont connues. Elles seront probablement corrigées dans une prochaine version :

De plus, il faut garder à l'esprit que le format actuel des journaux de transactions est extrêmement volumineux car il inclut de nombreuses images complètes des blocs disques. Ces images de bloc sont conçues pour supporter la restauration après un arrêt brutal, puisqu'il peut être nécessaire de corriger des blocs disque partiellement écrits. En fonction du matériel et des logiciels composant le système, le risque d'écriture partielle peut être suffisamment faible pour être ignoré, auquel cas le volume total des traces archivées peut être considérablement réduit par la désactivation des images de bloc à l'aide du paramètre full_page_writes(lire les notes et avertissements dans Chapitre 28 avant de le faire). Désactiver les images de bloc n'empêche pas l'utilisation des traces pour les opérations PITR. Un piste éventuelle de développement futur consiste à compresser les données des journaux de transactions archivés en supprimant les copies inutiles de blocs même si full_page_writes est actif. Entre temps, les administrateurs peuvent souhaiter réduire le nombre d'images de blocs inclus dans les journaux de transactions en augmentant autant que possible les paramètres d'intervalle entre les checkpoints.