Outil de sauvegarde PostgreSQL de Bacula Systems

Simplifiez et accélérez la sauvegarde de votre base de données PostgreSQL. 

Cet outil de sauvegarde PostgreSQL automatisé rend le processus rapide et simple du fait, que l’administrateur de la base de données PostgreSQL n’a pas besoin d’apprendre les techniques internes de sauvegarde et de restauration des bases de données ou d’écrire des scripts complexes. Le logiciel de sauvegarde PostgreSQL s’occupera automatiquement pour vous de sauvegarder les informations essentielles telles que la configuration, la définition des utilisateurs ou les tables. L’outil prend en charge les techniques de sauvegarde et de restauration de type dump et PITR (Point In Time Recovery).

Télécharger l’essai gratuitTéléchargez le whitepaper de PostgreSQL

Types de sauvegarde PostgreSQL

Il y a deux méthodes principales pour sauvegarder une base de données PostgreSQL avec notre outil – ce sont soit des instantanés au niveau du système de fichiers (physique) ou des dumps SQL (logique).

Physique

Les sauvegardes au niveau du système de fichiers (ou sauvegardes physiques) sont essentiellement des instantanés de tous les fichiers de la base de données. Mais ce n’est pas aussi facile qu’il n’y paraît car les fichiers à l’intérieur d’une base de données subissent généralement des réécritures et des modifications constantes. La sauvegarde de la base de données PostgreSQL repose sur deux méthodes clés : la continuité de l’archivage et la récupération ponctuelle. Ces deux méthodes sont destinées à se compléter l’une l’autre – c’est pourquoi il est important de savoir comment elles fonctionnent toutes les deux.

Pour des raisons de cohérence, les sauvegardes doivent avoir un moyen de savoir avec certitude que le processus de sauvegarde copie la base de données entière ou ne change rien et laisse la base de données telle quelle. C’est pourquoi PostgreSQL dispose d’une technologie de journalisation write-ahead – les segments WAL (write-ahead log) sont ceux qui sont exactement sauvegardés pendant le processus d’archivage en cours. Les informations stockées dans ces fichiers permettent à la fois une récupération plus facile après un crash et une meilleure cohérence des données.

Il n’est pas rare que les bases de données subissent quelques modifications au cours du processus de sauvegarde du système de fichiers, mais certaines de ces modifications peuvent endommager certaines parties de la sauvegarde ou la rendre irréparable dans son ensemble. Pour éviter de telles conséquences désastreuses, PostgreSQL dispose d’une API de bas niveau pour le processus de sauvegarde physique. L’utilisation de « pg_start_backups() » et « pg_stop_backup() » avant et après le processus, respectivement, permet de s’assurer qu’aucun changement dangereux n’est effectué sur la base de données pendant le processus de sauvegarde. En même temps, vous aurez toujours besoin de générer tous les segments WAL entre ces deux commandes.

Le nom commun pour l’instantané au niveau du système de fichiers comme celui-ci (et tous les segments WAL nécessaires pour le restaurer, aussi bien) a le nom – une « sauvegarde de base ».

Logique

Quelque chose de partiellement différent d’une sauvegarde physique est le dump SQL (ou sauvegarde logique). Comme son nom l’indique, cette sauvegarde consiste à utiliser les commandes de sauvegarde PostgreSQL pour créer la structure de base de la base de données et ensuite la remplir de données. Un dump SQL représente toujours un état précis de la base de données à un moment donné (puisque le processus de « dumping » est presque identique à toute autre session de la base de données).

Le processus se déroule comme suit : le logiciel parcourt toutes les tables disponibles et récupère toutes les lignes. Ce n’est pas vraiment compliqué, mais il est suffisamment intelligent pour respecter l’ordre des choses afin de tout restaurer tel qu’il a été sauvegardé, avec toutes les connexions et autres.

L’utilisation des Dumps SQL signifie que vous devrez vous habituer à ce que les données de diverses tables soient réparties sur la ligne de temps. Cela signifie qu’une table peut avoir un horodatage A, et que l’autre peut-être terminée à l’horodatage B. Il est utile de garder cela à l’esprit au cas où il y aurait des règles dans la base de données sur la façon dont les lignes et les tables doivent interagir les unes avec les autres.
Télécharger l’essai gratuitTéléchargez le whitepaper de PostgreSQL

• Bacula Enterprise supporte de nombreux systèmes d’exploitation sur lesquels vous pouvez exécuter la base de données PostgreSQL. Regardez notre solution de sauvegarde de serveur Windows ou Linux.
• Vous avez besoin d’une sauvegarde des machines virtuelles pour tous les hyperviseurs de votre infrastructure ? Jetez un œil à notre sauvegarde des machines virtuelles.
• Consultez les principales fonctionnalités du logiciel de sauvegarde et de restauration Bacula Enterprise.