Dalibo SCOP
Formation | Module I4 |
Titre | Outils de sauvegarde physique |
Révision | 24.12.1 |
https://dali.bo/i4_pdf | |
EPUB | https://dali.bo/i4_epub |
HTML | https://dali.bo/i4_html |
Slides | https://dali.bo/i4_slides |
TP | https://dali.bo/i4_tp |
TP (solutions) | https://dali.bo/i4_solutions |
Vous trouverez en ligne les différentes versions complètes de ce document.
Cette formation est sous licence CC-BY-NC-SA. Vous êtes libre de la redistribuer et/ou modifier aux conditions suivantes :
Vous n’avez pas le droit d’utiliser cette création à des fins commerciales.
Si vous modifiez, transformez ou adaptez cette création, vous n’avez le droit de distribuer la création qui en résulte que sous un contrat identique à celui-ci.
Vous devez citer le nom de l’auteur original de la manière indiquée par l’auteur de l’œuvre ou le titulaire des droits qui vous confère cette autorisation (mais pas d’une manière qui suggérerait qu’ils vous soutiennent ou approuvent votre utilisation de l’œuvre). À chaque réutilisation ou distribution de cette création, vous devez faire apparaître clairement au public les conditions contractuelles de sa mise à disposition. La meilleure manière de les indiquer est un lien vers cette page web. Chacune de ces conditions peut être levée si vous obtenez l’autorisation du titulaire des droits sur cette œuvre. Rien dans ce contrat ne diminue ou ne restreint le droit moral de l’auteur ou des auteurs.
Le texte complet de la licence est disponible sur http://creativecommons.org/licenses/by-nc-sa/2.0/fr/legalcode
Cela inclut les diapositives, les manuels eux-mêmes et les travaux pratiques. Cette formation peut également contenir quelques images et schémas dont la redistribution est soumise à des licences différentes qui sont alors précisées.
PostgreSQL® Postgres® et le logo Slonik sont des marques déposées par PostgreSQL Community Association of Canada.
Ce document ne couvre que les versions supportées de PostgreSQL au moment de sa rédaction, soit les versions 13 à 17.
Sur les versions précédentes susceptibles d’être encore rencontrées en production, seuls quelques points très importants sont évoqués, en plus éventuellement de quelques éléments historiques.
Sauf précision contraire, le système d’exploitation utilisé est Linux.
Nous avons vu le fonctionnement interne du mécanisme de sauvegarde physique. Celui-ci étant en place nativement dans le moteur PostgreSQL depuis de nombreuses versions, sa robustesse n’est plus à prouver. Cependant, son industrialisation reste fastidieuse.
Des outils tiers existent et vont permettre de faciliter la gestion des sauvegardes, de leur mise en place jusqu’à la restauration. Dans ce module nous allons voir en détail certains de ces outils et étudier les critères qui vont nous permettre de choisir la meilleure solution selon notre contexte.
Lors de cette présentation, nous allons passer en revue les différents outils principaux de gestion de sauvegardes, leurs forces, le paramétrage, l’installation et l’exploitation.
Où les sauvegardes doivent-elles être stockées ?
Quelles ressources sont à disposition : serveur de sauvegarde dédié ? quelle puissance pour la compression ?
De quel type d’accès aux serveurs de base de données dispose-t-on ? Quelle est la version du système d’exploitation ?
Il est très important de se poser toutes ces questions, les réponses vont servir à établir le contexte et permettre de choisir l’outil et la méthode la plus appropriée.
Attention, pour des raisons de sécurité et de fiabilité, les répertoires choisis pour la restauration des données de votre instance ne doivent pas être à la racine d’un point de montage.
Si un ou plusieurs points de montage sont dédiés à l’utilisation de
PostgreSQL, positionnez toujours les données dans un sous-répertoire,
voire deux niveaux en dessous du point de montage (eg.
<point de montage>/<version majeure>/<nom instance>
).
pg_basebackup est une application cliente intégrée à PostgreSQL, au même titre que pg_dump ou pg_dumpall.
pg_basebackup a été conçu pour permettre l’initialisation d’une instance secondaire, et il peut donc être utilisé pour effectuer facilement une sauvegarde physique ponctuelle. Celle-ci inclut les fichiers et journaux nécessaires pour une restauration telle que l’instance était à la fin de la sauvegarde.
pg_basebackup peut aussi être à la base d’outils permettant le PITR (par exemple barman). Ces outils s’occupent en plus de l’archivage des journaux générés pendant et après la sauvegarde initiale, pour une restauration dans un état postérieur à la fin de cette sauvegarde.
Le format par défaut de la sauvegarde est plain
, ce qui
signifie que les fichiers seront créés tels quels dans le répertoire de
destination (ou les répertoires en cas de tablespaces). C’est idéal pour
obtenir une copie immédiatement utilisable.
Pour une archive à proprement parler, préférer l’option
--format tar
. pg_basebackup génère alors une archive
base.tar
pour le PGDATA de l’instance, puis une archive
<oid>.tar
par tablespace. Les journaux récupérés
seront également dans un fichier .tar
.
L’option --gzip
(-z
) ajoute la compression
gzip
. Le niveau de compression peut également être spécifié
avec --compress=1
à 9
(-Z
). Cela
permet d’arbitrer entre la durée de la sauvegarde et sa taille.
Même avec un serveur un peu ancien, il possible d’installer un
pg_basebackup
récent, en installant les outils clients de
la dernière version de PostgreSQL.
Récupération des journaux :
pg_basebackup sait récupérer les fichiers WAL nécessaires à la restauration de la sauvegarde sans passer par la commande d’archivage. Il connaît deux méthodes :
Avec l’option --wal-method fetch
(ou -X
),
les WAL générés pendant la sauvegarde seront demandés une fois celle-ci
terminée, à condition qu’ils n’aient pas été recyclés entre-temps (ce
qui peut nécessiter un slot de réplication, ou éventuellement une
configuration élevée du paramètre
wal_keep_size
/wal_keep_segments
).
L’option par défaut est cependant -X stream
: les WAL
sont récupérés non pas en fin de sauvegarde, mais en streaming
pendant celle-ci. Cela nécessite néanmoins l’utilisation d’un wal
sender supplémentaire, le paramètre max_wal_senders
doit parfois être augmenté en conséquence.
Rappelons que si l’archivage des WAL n’est pas actif, la sauvegarde effectuée ne sera utilisée que pour restaurer l’instance telle qu’elle était au moment de la fin de la sauvegarde : il ne sera pas possible de réaliser une restauration PITR.
À l’inverse, -X none
peut être utile si la récupération
des journaux est réalisée par ailleurs (généralement par
archive_command
ou archive_library
).
Attention, l’archive réalisée avec pg_basebackup ne sera alors pas
« complète », et ne pourra pas être restaurée sans ces archives des
journaux (il faudra indiquer où aller les chercher avec
restore_command
.)
Slots de réplication :
Par défaut, pg_basebackup va créer un slot de réplication temporaire sur le serveur pour sécuriser la sauvegarde. Il disparaîtra une fois celle-ci terminée.
Pour faciliter la mise en place d’une instance secondaire, et
garantir que tous les journaux nécessaires seront encore sur le primaire
à son démarrage, il est possible de créer un slot de réplication
permanent, et de le fournir à pg_basebackup avec
--slot nom_du_slot
. pg_basebackup peut le créer lui-même
avec --create
. Si l’on préfère le créer préalablement, il
suffit d’exécuter la requête suivante :
SELECT pg_create_physical_replication_slot ('nom_du_slot');
Rappelons qu’un slot initialisé mais inutilisé doit être rapidement supprimé pour ne pas mener à une dangereuse accumulation des journaux.
Sécurisation de la sauvegarde :
Par défaut, pg_basebackup
crée un fichier manifeste (à
partir de PostgreSQL 13). Ce fichier contient la liste des fichiers
sauvegardés, leur taille et leur somme de contrôle. Cela permet après
coup de vérifier l’intégrité de la sauvegarde à l’aide de l’outil
pg_verifybackup
.
L’algorithme par défaut de la somme de contrôle, CRC32, suffit pour détecter une erreur technique accidentelle ; d’autres algorithmes disponibles permettent de détecter une manipulation volontaire de la sauvegarde.
Vérification des sommes de contrôle :
Une sauvegarde avec pg_basebackup entraîne la vérification des sommes de contrôle de l’instance. Cela garantit que la sauvegarde n’héritera pas d’une corruption existante, sinon l’outil tombe en erreur.
L’option --no-verify-checksums
autorise la sauvegarde
d’une instance où une corruption est détectée (sauvegarde aussi
problématique, certes, mais qui peut permettre de travailler sur la
récupération, ou de sauver l’essentiel).
Emplacement de la sauvegarde
À partir de la version 15, l’option --target
permet de
spécifier où la sauvegarde doit être réalisée :
client
)
;server
) ;blackhole
).Des destinations peuvent être ajoutées par des extensions,
basebackup_to_shell
est fournie à titre d’exemple et permet d’exécuter une commande à
l’issue d’une sauvegarde.
Lorsque la destination server
est choisie, plusieurs
restrictions s’appliquent à la sauvegarde :
tar
;pg_write_server_files
;fetch
ou
none
.Compression de la sauvegarde :
À partir de la version 15, il est possible de demander la compression de la sauvegarde avec un grand niveau de personnalisation :
gzip
, lz4
et zstd
;lz4
) ;zstd
) ;zstd
) ;Cela permet de gérer différents scénarios et d’éviter certains goulets d’étranglement lors d’une sauvegarde.
Autres options :
Le débit de la sauvegarde est configurable avec l’option
--max-rate=
(-r
) pour limiter l’impact sur
l’instance ou le réseau. Cette restriction de débit ne concerne pas les
journaux transférés en parallèle (-X stream
).
Pour gagner un peu de temps, si l’instance n’est pas trop chargée,
--checkpoint=fast
accélère le checkpoint préalable à la
sauvegarde.
Avec une sauvegarde plain
, il est possible de modifier
sur la cible les chemins des éventuels tablespaces avec l’option
--tablespace-mapping=<vieuxrep>=<nouveaurep>
(ou -T
), et de relocaliser le répertoire des fichiers WAL
avec l’option --waldir=<nouveau chemin>
.
Depuis un secondaire :
pg_basebackup permet nativement de réaliser une sauvegarde à partir d’une instance secondaire. Le paramétrage nécessaire figure plus bas.
Suivi :
Pour suivre le déroulement de la sauvegarde depuis un terminal, il
existe l’option --progress
(-P
).
À partir de PostgreSQL 13, il existe aussi une vue pour ce suivi :
pg_stat_progress_basebackup
.
Options complètes :
Pour mémoire, toutes les options disponibles sont celles-ci (en version 15) :
$ pg_basebackup --help
pg_basebackup prend une sauvegarde binaire d'un serveur PostgreSQL en cours
d'exécution.
Usage :
pg_basebackup [OPTION]...
Options contrôlant la sortie :
-D, --pgdata=RÉPERTOIRE reçoit la sauvegarde de base dans ce répertoire
-F, --format=p|t format en sortie (plain (par défaut), tar)
-r, --max-rate=TAUX taux maximum de transfert du répertoire de
données (en Ko/s, ou utiliser le suffixe « k »
ou « M »)
-R, --write-recovery-conf écrit la configuration pour la réplication
-t, --target=CIBLE[:DETAIL] cible de sauvegarde (si autre que client)
-T, --tablespace-mapping=ANCIENREP=NOUVEAUREP
déplace le répertoire ANCIENREP en NOUVEAUREP
--waldir=RÉP_WAL emplacement du répertoire des journaux de
transactions
-X, --wal-method=none|fetch|stream
inclut les journaux de transactions requis avec
la méthode spécifiée
-z, --gzip compresse la sortie tar
-Z, --compress=[{client|server}-]METHODE[:DETAIL]
compresse sur le client ou le serveur comme indiqué
-Z, --compress=none ne compresse pas la sortie tar
Options générales :
-c, --checkpoint=fast|spread exécute un CHECKPOINT rapide ou réparti
--create-slot crée un slot de réplication
-l, --label=LABEL configure le label de sauvegarde
-n, --no-clean ne nettoie pas en cas d'erreur
-N, --no-sync n'attend pas que les modifications soient
proprement écrites sur disque
-P, --progress affiche la progression de la sauvegarde
-S, --slot=NOMREP slot de réplication à utiliser
-v, --verbose affiche des messages verbeux
-V, --version affiche la version puis quitte
--manifest-checksums=SHA{224,256,384,512}|CRC32C|NONE
utilise cet algorithme pour les sommes de
contrôle du manifeste
--manifest-force-encode encode tous les noms de fichier dans le
manifeste en hexadécimal
--no-estimate-size ne réalise pas d'estimation sur la taille de la
sauvegarde côté serveur
--no-manifest supprime la génération de manifeste de
sauvegarde
--no-slot empêche la création de slots de réplication
temporaires
--no-verify-checksums ne vérifie pas les sommes de contrôle
-?, --help affiche cette aide puis quitte
Options de connexion :
-d, --dbname=CHAÎNE_CONNEX chaîne de connexion
-h, --host=HÔTE hôte du serveur de bases de données ou
répertoire des sockets
-p, --port=PORT numéro de port du serveur de bases de données
-s, --status-interval=INTERVAL durée entre l'envoi de paquets de statut au
serveur (en secondes)
-U, --username=UTILISATEUR se connecte avec cet utilisateur
-w, --no-password ne demande jamais le mot de passe
-W, --password force la demande du mot de passe (devrait
survenir automatiquement)
Rapporter les bogues à <pgsql-bugs@lists.postgresql.org>. Page d'accueil de PostgreSQL : <https://www.postgresql.org/>
Configuration :
pg_basebackup étant conçu pour la mise en place d’une instance en réplication, l’instance principale nécessite d’être configurée en conséquence :
max_wal_senders
doit avoir une valeur supérieure à
0
pour permettre à pg_basebackup de se connecter (au moins
2
si on utilise le transfert des WAL par streaming) — c’est
le cas par défaut ;pg_hba.conf
de l’instance principale doit
être configuré pour autoriser les connexions de type
replication
depuis la machine où la sauvegarde est
déclenchée, par exemple ainsi :host replication repli_user 192.168.0.100/32 scram-sha-256
Dans l’idéal, l’utilisateur employé est dédié à la réplication. Pour
automatiser, stocker le mot de passe nécessaire dans un fichier
.pgpass
.
L’archivage n’est pas géré par pg_basebackup. Il ne récupère par
streaming que les journaux nécessaires à la cohérence de sa
sauvegarde. Il faudra paramétrer archive_command
ou
archive_library
à la main pour une sauvegarde PITR.
Si la sauvegarde est effectuée à partir d’une instance secondaire :
hot_standby
à
on
) ;max_wal_senders
supérieur 0
et droits en
place pour permettre à pg_basebackup de se connecter ;full_page_writes
à on
) ;Gestion des sauvegardes :
La gestion des sauvegardes (rétention, purge…) n’est pas prévue dans l’outil.
pg_basebackup n’effectue pas non plus de lien entre les WAL archivés
et les sauvegardes effectuées (si pg_basebackup ne les sauvegarde pas
lui-même avec l’option -X
).
Il ne sait faire des sauvegardes incrémentales qu’à partir de
PostgreSQL 17. Les archives créées sont à restaurer avec le nouvel outil
pg_combinebackup
, dont le maniement est encore assez
fastidieux.
Restauration :
pg_basebackup n’offre pas d’outil ni d’option pour la restauration.
La copie est directement utilisable, éventuellement après déplacement
et/ou décompression des .tar.gz
. Mais, généralement, on
ajoutera un fichier recovery.signal
, et on définira la
restore_command
pour récupérer les archives. Dans l’idéal,
restore_command
sera déjà prête dans le
postgresql.conf
.
Si le but est de monter un serveur secondaire de l’instance copiée,
il existe une option utile : --write-recovery-conf
(ou
-R
), qui génère la configuration nécessaire dans le
répertoire de la sauvegarde (postgresql.auto.conf
et
fichier vide standby.signal
). avec les paramètres pour une
réplication en streaming.
pgBackRest est un outil de gestion de sauvegardes PITR écrit en perl et en C, par David Steele de Crunchy Data.
Il met l’accent sur les performances avec de gros volumes et les fonctionnalités, au prix d’une complexité à la configuration :
pg_wal
;pgBackRest n’utilise pas pg_receivewal
pour garantir la
sauvegarde du dernier journal (non terminé) avant un sinistre. Les
auteurs considèrent que dans ce cas un secondaire synchrone est plus
adapté et plus fiable.
Le projet est très actif et considéré comme fiable, et les fonctionnalités proposées sont intéressantes.
Pour la supervision de l’outil, une sonde Nagios est fournie par un des développeurs : check_pgbackrest.