TOC

Comment sauvegarder, restaurer et migrer des bases de données PostgreSQL avec Barman sur CentOS 7

introduction

  • PostgreSQL * est une plate-forme de base de données open-source très appréciée des développeurs d’applications web et mobiles pour sa facilité de maintenance, sa rentabilité et sa simple intégration à d’autres technologies open-source.

L’une des tâches critiques de la maintenance d’un environnement PostgreSQL consiste à sauvegarder régulièrement ses bases de données. Les sauvegardes font partie du processus de récupération après sinistre pour toutes les organisations. Ceci est important pour plusieurs raisons:

  • Protection contre la perte de données due à la défaillance de composants d’infrastructure sous-jacents tels que le stockage ou le serveur lui-même

  • Protection contre la corruption des données et les pertes de données indésirables ou malveillantes

  • Migration des bases de données de production dans des environnements de développement ou de test

Habituellement, la responsabilité de la sauvegarde et de la restauration de la base de données incombe à un administrateur de base de données. Dans les petites entreprises ou les startups, cependant, les administrateurs système, les ingénieurs de DevOps ou les programmeurs doivent souvent créer leurs propres serveurs de base de données. Il est donc important que tous ceux qui utilisent PostgreSQL ™ comprennent le fonctionnement des sauvegardes et la procédure de restauration à partir d’une sauvegarde.

Dans ce didacticiel, vous allez configurer le serveur de sauvegarde Barman, effectuer une sauvegarde à partir d’un serveur de base de données principal et le restaurer sur un serveur de secours.

Une brève introduction aux méthodes de sauvegarde PostgreSQL

Avant de lancer votre configuration Barman, prenons un moment pour examiner les types de sauvegardes disponibles pour PostgreSQL et leurs utilisations. (Pour un aperçu encore plus large des stratégies de sauvegarde, lisez notre article sur les effective .)

PostgreSQL propose deux types de méthodes de sauvegarde:

  • Sauvegardes logiques

  • Sauvegardes physiques

Les sauvegardes logiques sont comme des instantanés d’une base de données. Celles-ci sont créées à l’aide de l’utilitaire + pg_dump + ou + + pg_dumpall + fourni avec PostgreSQL. Sauvegardes logiques:

  • Sauvegarder des bases de données individuelles ou toutes les bases de données

  • Sauvegardez uniquement les schémas, uniquement les données, des tables individuelles ou l’ensemble de la base de données (schémas et données)

  • Créer le fichier de sauvegarde au format propriétaire binaire ou en script SQL pur

  • Peut être restauré en utilisant l’utilitaire + pg_restore + qui est également fourni avec PostgreSQL

  • Ne pas offrir * la récupération à un moment donné (PITR) *

Cela signifie que si vous effectuez une sauvegarde logique de votre base de données à 2h00 du matin, lorsque vous la restaurerez, la base de données restaurée sera telle quelle à 2h00 du matin. Il est impossible d’arrêter la restauration à un moment donné, par exemple à 1h30 du matin. Si vous restaurez la sauvegarde à 10h00, vous avez perdu huit heures de données.

Les sauvegardes physiques sont différentes des sauvegardes logiques car elles ne traitent que du format binaire et effectuent des sauvegardes au niveau des fichiers. Sauvegardes physiques:

  • Offre de récupération à un moment donné

  • Sauvegardez le contenu des répertoires PostgreSQL data et_WAL (Write Ahead Log)

  • Prenez de plus grandes quantités d’espace disque

  • Utilisez les commandes ` pg_start_backup + `et + pg_stop_backup + `de PostgreSQL. Cependant, ces commandes doivent être scriptées, ce qui rend les sauvegardes physiques plus complexes.

  • Ne sauvegardez pas des bases de données individuelles, uniquement des schémas, etc. C’est une approche du tout ou rien

Les fichiers WAL contiennent des listes de transactions (INSERT, UPDATE ou DELETE) qui se produisent dans une base de données. Les fichiers de base de données contenant les données se trouvent dans le répertoire de données. Ainsi, lorsqu’il s’agit de restaurer à un moment donné à partir d’une sauvegarde physique, PostgreSQL ™ restaure le contenu du répertoire de données en premier, puis lit les transactions qui s’y trouvent à partir des fichiers WAL. Cela amène les bases de données à un état cohérent dans le temps.

  • Comment fonctionnent les sauvegardes Barman *

Traditionnellement, les administrateurs de base de données PostgreSQL ™ écrivaient leurs propres scripts de sauvegarde et leurs travaux planifiés + cron + pour implémenter des sauvegardes physiques. Barman le fait de manière standardisée.

  • Barman * ou * Backup and Recovery Manager * est un outil de sauvegarde PostgreSQL gratuit et à code source ouvert disponible sur 2ndQuadrant - une société de solutions Postgres professionnelle. Barman a été écrit en Python et offre une méthode simple et intuitive de sauvegarde et de restauration physiques pour votre instance PostgreSQL. Certains avantages d’utiliser Barman sont:

  • C’est totalement gratuit

  • Il s’agit d’une application bien entretenue et d’un support professionnel disponible chez le fournisseur.

  • Libère le DBA / Sysadmin de l’écriture et du test de scripts complexes et de travaux + cron +

  • Peut sauvegarder plusieurs instances PostgreSQL dans un emplacement central

  • Peut restaurer sur la même instance PostgreSQL ou sur une instance différente

  • Offre des mécanismes de compression pour minimiser le trafic réseau et l’espace disque

Buts

Dans ce didacticiel, nous allons créer trois gouttelettes DigitalOcean, installer PostgreSQL 9.4 sur deux de ces machines et installer Barman sur la troisième.

L’un des serveurs PostgreSQL sera notre serveur de base de données principal: c’est ici que nous allons créer notre base de données de production. La deuxième instance PostgreSQL sera vide et traitée comme une machine de secours sur laquelle nous pouvons restaurer à partir de la sauvegarde.

Le serveur Barman communiquera avec le serveur de base de données principal et effectuera des sauvegardes physiques et un archivage WAL.

Nous allons ensuite émuler un «désastre» en supprimant une table de notre base de données en direct.

Enfin, nous allons restaurer l’instance PostgreSQL sauvegardée du serveur Barman sur le serveur de secours.

Conditions préalables

Pour suivre ce didacticiel, vous devez créer trois droplets DigitalOcean (ou vos propres serveurs Linux), chacun avec au moins * 2 Go de RAM * et 2 cœurs de processeur. Nous n’entrerons pas dans les détails de la création d’un Droplet; vous pouvez trouver plus d’informations à l’adresse here.

Les trois serveurs doivent avoir le même système d’exploitation (* CentOS 7 * x 64 bits).

Nous nommerons les machines comme suit:

  • * main-db-server * (son adresse IP sera notée)

  • * standby-db-server * (nous indiquerons son adresse IP par)

  • * barman-backup-server * (nous indiquerons son adresse IP par)

Les adresses IP réelles des machines sont disponibles à partir du panneau de commande DigitalOcean.

Vous devez également configurer un utilisateur sudo sur chaque serveur et l’utiliser pour un accès général. La plupart des commandes seront exécutées comme deux utilisateurs différents (* postgres * et * barman *), mais vous aurez également besoin d’un utilisateur sudo sur chaque serveur pour pouvoir basculer vers ces comptes. Pour comprendre le fonctionnement des privilèges sudo, reportez-vous à ce tutoriel DigitalOcean pour activer l’accès sudo .

Étape 1 - Installation des serveurs de base de données PostgreSQL

Nous allons d’abord configurer notre environnement de base de données en installant PostgreSQL 9.4 sur * main-db-server * et * standby-db-server *.

Complétez les étapes de l’installation de PostgreSQL à l’adresse his tutoriel sur la pile LEPP . A partir de ce tutoriel, vous devrez:

  • Suivez la section * Première étape - Installation de PostgreSQL *

  • Suivez la section * Deuxième étape - Configuration de PostgreSQL *

Dans * Deuxième étape - Configuration de PostgreSQL *, au lieu d’apporter des modifications au fichier + pg_hba.conf + pour autoriser l’accès à la base de données pour un serveur Web, ajoutez cette ligne afin que le serveur Barman puisse se connecter, à l’aide du fichier * barman-backup- serveur * adresse IP, suivi de + / 32 +:

host    all     all     /32        trust

Ceci configure PostgreSQL pour accepter toute connexion provenant du serveur Barman.

Le reste des instructions de cette section peut être suivi tel quel.

Assurez-vous que vous avez installé PostgreSQL sur les serveurs * main-db-server * et * standby-db-server *, et que vous avez autorisé l’accès sur les deux à partir du * barman-backup-server *.

Nous allons ensuite ajouter des exemples de données au serveur de base de données principal.

Étape 2 - Création de la base de données et des tables PostgreSQL

Une fois que PostgreSQL est installé et configuré sur les deux machines, nous ajoutons des exemples de données au * main-db-server * pour simuler un environnement de production.

Sur le serveur * main-db-server *, passez sur l’utilisateur * postgres *:

sudo su - postgres

Démarrez l’utilitaire + psql + pour accéder au serveur de base de données:

psql

À partir de l’invite + psql +, exécutez les commandes suivantes pour créer une base de données et y accéder:

CREATE DATABASE mytestdb;
\connect mytestdb;

Un message de sortie vous dira que vous êtes maintenant connecté à la base de données + mytestdb + en tant qu’utilisateur + postgres +.

Ensuite, ajoutez deux tables dans la base de données:

CREATE TABLE mytesttable1 (id integer NULL);
CREATE TABLE mytesttable2 (id integer NULL);

Ceux-ci sont nommés + mytesttable1 + et + mytesttable2 +.

Quittez l’outil client en tapant + \ q + et en appuyant sur + ENTER +.

Étape 3 - Installation de Barman

Nous allons maintenant installer Barman sur le serveur de sauvegarde, qui contrôlera et stockera nos sauvegardes.

Terminez cette étape sur le * barman-backup-server *.

Pour ce faire, vous devez d’abord installer les référentiels suivants:

  • Extra Packages pour le référentiel EPEL (Enterprise Linux)

  • Dépôt RPM de PostgreSQL Global Development Group

Exécutez la commande suivante pour installer EPEL:

sudo yum -y install epel-release

Exécutez ces commandes pour installer le repo PostgreSQL:

sudo wget http://yum.postgresql.org/9.4/redhat/rhel-7Server-x86_64/pgdg-centos94-9.4-1.noarch.rpm
sudo rpm -ivh pgdg-centos94-9.4-1.noarch.rpm

Enfin, exécutez cette commande pour installer Barman:

sudo yum -y install barman

Barman est installé! Maintenant, assurons-nous que les serveurs peuvent se connecter en toute sécurité.

Étape 4 - Configuration de la connectivité SSH entre serveurs

Dans cette section, nous allons établir des clés SSH pour une connexion sécurisée sans mot de passe entre * main-db-server * et * barman-backup-server *, et inversement.

De même, nous établirons des clés SSH entre les serveurs * standby-db-server * et * barman-backup-server *, et inversement.

Cela permet de s’assurer que PostgreSQL (sur les deux serveurs de base de données) et Barman peuvent se «parler» pendant les sauvegardes et les restaurations.

Pour ce tutoriel, vous devez vous assurer que:

  • L’utilisateur * postgres * peut se connecter à distance du * main-db-server * au * barman-backup-server *

  • L’utilisateur * postgres * peut se connecter à distance du * standby-db-server * au * barman-backup-server *

  • L’utilisateur * barman * peut se connecter à distance du * serveur barman-backup * au * serveur principal-db *

  • L’utilisateur * barman * peut se connecter à distance à partir du * serveur barman-backup-* au * serveur standby-db *

Nous n’entrerons pas dans les détails du fonctionnement de SSH. Il existe un very excellent article sur DigitalOcean sur les éléments essentiels de SSH auxquels vous pouvez vous référer.

Toutes les commandes dont vous aurez besoin sont incluses ici, cependant.

Nous allons vous montrer comment faire cela une fois pour configurer la connexion afin que l’utilisateur * postgres * puisse se connecter depuis le * serveur principal-db * au * serveur de sauvegarde-barman *.

Depuis le serveur * main-db-server *, passez sur l’utilisateur * postgres * s’il n’est pas déjà l’utilisateur actuel:

sudo su - postgres

Exécutez la commande suivante pour générer une paire de clés SSH:

ssh-keygen -t rsa

Acceptez l’emplacement et le nom par défaut des fichiers de clés en appuyant sur + ENTER.

Appuyez deux fois sur + ENTER + pour créer la clé privée sans phrase secrète.

Une fois les clés générées, un répertoire + .ssh + sera créé dans le répertoire de base de l’utilisateur * postgres *, avec les clés qu’il contient.

Vous devez maintenant copier la clé publique SSH dans le fichier + registered_keys + sous le répertoire * + .ssh + `de l’utilisateur barman * sur le * barman-backup-server *.

Exécutez la commande suivante pour générer le contenu de la clé publique de l’utilisateur * postgres *:

cat ~/.ssh/id_rsa.pub

Copiez le contenu de la sortie.

Basculez vers la console connectée au serveur * barman-backup-server * et basculez vers l’utilisateur * barman *:

sudo su - barman

Exécutez les commandes suivantes pour créer un répertoire + .ssh +, définissez ses autorisations, copiez le contenu de la clé publique dans le fichier + allowed_keys +, puis rendez ce fichier lisible et inscriptible:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Assurez-vous de placer la chaîne de clé publique longue commençant par + ssh-rsa + entre guillemets, au lieu de ++.

Vous avez copié la clé sur le serveur distant.

Maintenant, pour tester la connexion, revenez au * main-db-server * et testez la connectivité à partir de là:

ssh barman@

Après l’avertissement initial relatif à l’authenticité du serveur distant non connu et l’acceptation de l’invite, une connexion doit être établie entre le serveur * main-db-server * et * barman-backup-server *. En cas de succès, déconnectez-vous de la session en exécutant la commande + exit +.

exit

  • Vous devez configurer les connexions de clé SSH trois fois de plus. * Vous pouvez ignorer la création du répertoire + .ssh + s’il est déjà créé (bien que cela ne soit pas nécessaire).

  • Exécutez à nouveau les mêmes commandes, cette fois du * standby-db-server * au * barman-backup-server *

  • Exécutez-les une troisième fois, cette fois à partir de l’utilisateur * barman * sur le serveur * barman-backup-server *, puis de l’utilisateur * postgres * sur le serveur * main-db-server *.

  • Enfin, exécutez les commandes pour copier la clé de l’utilisateur * barman * sur le serveur * barman-backup-server * vers l’utilisateur * postgres * sur le serveur * standby-db-server *

Assurez-vous de tester la connexion dans les deux sens afin de pouvoir accepter l’avertissement initial relatif à la nouvelle connexion.

De * standby-db-server *:

ssh barman@

De * barman-backup-server *:

ssh postgres@

De * barman-backup-server *:

ssh postgres@

Étape 5 - Configuration de Barman pour les sauvegardes

Vous allez maintenant configurer Barman pour sauvegarder votre serveur PostgreSQL principal.

Le fichier de configuration principal de BARMAN est + / etc / barman.conf +. Le fichier contient une section pour les paramètres globaux et des sections distinctes pour chaque serveur à sauvegarder. Le fichier par défaut contient une section pour un exemple de serveur PostgreSQL appelée * main *, qui est commentée. Vous pouvez l’utiliser comme guide pour configurer d’autres serveurs que vous souhaitez sauvegarder.

Ouvrez + / etc / barman.conf + dans un éditeur de texte en tant que votre utilisateur * sudo * (l’utilisateur * barman * n’a qu’un accès en lecture à celui-ci):

sudo vi /etc/barman.conf

Les paramètres globaux sont définis dans la section + [barman] +. Sous cette section, apportez les modifications suivantes. Les valeurs finies sont affichées sous les points suivants:

  • Ne commentez pas la ligne + compression + et conservez la valeur par défaut + gzip. + Cela signifie que les fichiers WAL de PostgreSQL - lorsqu’ils sont copiés dans le répertoire de sauvegarde - seront sauvegardés sous une forme compressée gzip

  • Décommentez la ligne pour + reuse_backup + et conservez la valeur par défaut de + link +. Lors de la création de sauvegardes complètes du serveur PostgreSQL, Barman essaiera de gagner de la place dans le répertoire de sauvegarde en créant des sauvegardes incrémentielles au niveau des fichiers. Ceci utilise rsync et des liens durs. La création de sauvegardes complètes incrémentielles présente le même avantage que toute méthode de déduplication de données: gain de temps et d’espace disque.

  • Décommentez la ligne pour + immediate_checkpoint + et définissez sa valeur sur + true +. Ce paramètre garantit que lorsque Barman lance une sauvegarde complète, il demandera à PostgreSQL de réaliser un + CHECKPOINT +. Checkpointing garantit que toutes les données modifiées dans la mémoire cache de PostgreSQL sont écrites dans des fichiers de données. Du point de vue de la sauvegarde, cela peut apporter une valeur ajoutée, car BARMAN pourrait sauvegarder les dernières modifications apportées aux données.

  • Décommentez la ligne pour + basebackup_retry_times + et définissez une valeur de + 3 +. Lors de la création d’une sauvegarde complète, Barman essaiera de se connecter au serveur PostgreSQL trois fois si l’opération de copie échoue pour une raison quelconque.

  • Décommentez la ligne pour + basebackup_retry_sleep + et conservez la valeur par défaut de + 30 +. Il y aura un délai de 30 secondes entre chaque nouvelle tentative.

  • Décommentez la ligne pour + last_backup_maximum_age + et définissez sa valeur sur +1 DAYS +

Les nouveaux paramètres devraient ressembler à ceci:

Extraits de /etc/barman.conf

[barman]
barman_home = /var/lib/barman

. . .

barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link

. . .

immediate_checkpoint = true

. . .

basebackup_retry_times = 3
basebackup_retry_sleep = 30
last_backup_maximum_age = 1 DAYS

Ce que nous faisons ici est la suivante:

  • Conserver l’emplacement de sauvegarde par défaut

  • Spécifier cet espace de sauvegarde doit être enregistré. Les journaux WAL seront compressés et les sauvegardes de base utiliseront la copie incrémentielle des données

  • Barman réessayera trois fois si la sauvegarde complète échoue à mi-parcours pour une raison quelconque

  • L’âge de la dernière sauvegarde complète pour un serveur PostgreSQL ne doit pas être supérieur à 1 jour

A la fin du fichier, ajoutez une nouvelle section. Son en-tête devrait indiquer + [main-db-server] + entre crochets. (Si vous souhaitez sauvegarder davantage de serveurs de base de données avec Barman, vous pouvez créer un bloc comme celui-ci pour chaque serveur et utiliser un nom d’en-tête unique pour chacun.)

Cette section contient les informations de connexion pour le serveur de base de données et quelques paramètres de sauvegarde uniques.

Ajoutez ces paramètres dans le nouveau bloc:

Extrait de /etc/barman.conf

[main-db-server]
description = "Main DB Server"
ssh_command = ssh postgres@
conninfo = host= user=postgres
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF  days
wal_retention_policy = main

Les paramètres + retention_policy + signifient que Barman écrase automatiquement les anciens fichiers de sauvegarde complète et les journaux WAL, tout en conservant suffisamment de sauvegardes pour une fenêtre de récupération de 7 jours. Cela signifie que nous pouvons restaurer l’intégralité du serveur de base de données à tout moment au cours des sept derniers jours. * Pour un système de production, vous devez probablement définir cette valeur sur une valeur supérieure afin de disposer de sauvegardes plus anciennes. *

Vous devrez utiliser l’adresse IP du * main-db-server * dans les paramètres + ssh_command + et + conninfo +. Sinon, vous pouvez copier exactement les paramètres ci-dessus.

La version finale du fichier modifié devrait ressembler à ceci, moins tous les commentaires et les paramètres non modifiés:

Extraits de /etc/barman.conf

[barman]
barman_home = /var/lib/barman

. . .

barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link

. . .

immediate_checkpoint = true

. . .

basebackup_retry_times = 3
basebackup_retry_sleep = 30
last_backup_maximum_age = 1 DAYS

. . .

[main-db-server]
description = "Main DB Server"
ssh_command = ssh postgres@
conninfo = host= user=postgres
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF 7 days
wal_retention_policy = main

Enregistrez et fermez le fichier.

Ensuite, nous nous assurerons que notre * main-db-server * est configuré pour effectuer des sauvegardes.

Étape 6 - Configuration du fichier postgresql.conf

Il reste une dernière configuration à effectuer sur * main-db-server *, pour activer le mode de sauvegarde (ou d’archivage).

Premièrement, nous devons localiser la valeur du répertoire de sauvegarde entrant à partir du * barman-backup-server *. Sur le serveur Barman, passez sur l’utilisateur * barman *:

sudo su - barman

Exécutez cette commande pour localiser le répertoire de sauvegarde entrant:

barman show-server main-db-server | grep incoming_wals_directory

Cela devrait produire quelque chose comme ceci:

barman show-server command outputincoming_wals_directory: /var/lib/barman/main-db-server/incoming

Notez la valeur de + incoming_wals_directory +; dans cet exemple, il s’agit de «+ / var / lib / barman / main-db-server / incoming +».

Passez maintenant à la console * main-db-server *.

Basculez vers l’utilisateur * postgres * s’il ne s’agit pas déjà de l’utilisateur actuel.

Ouvrez le fichier + postgresql.conf dans un éditeur de texte:

vi $PGDATA/postgresql.conf

Apportez les modifications suivantes au fichier:

  • Décommentez le paramètre + wal_level + et définissez sa valeur sur + archive + au lieu de + minimal +

  • Décommentez le paramètre + archive_mode + et définissez sa valeur sur + on + au lieu de + off +

  • Décommentez le paramètre + archive_command + et définissez sa valeur sur + 'rsync -a% p barman @: /% f' + au lieu de '' ' . Utilisez l’adresse IP du serveur Barman. Si vous avez une valeur différente pour `+ incoming_wals_directory +, utilisez celle-là à la place

Extraits de postgresql.conf

wal_level = archive                     # minimal, archive, hot_standby, or logical

. . .

archive_mode = on               # allows archiving to be done

. . .

archive_command = 'rsync -a %p barman@:/%f'                # command to use to archive a logfile segment

Revenez à votre * utilisateur sudo *.

Redémarrez PostgreSQL:

sudo systemctl restart postgresql-9.4.service

Étape 7 - Tester Barman

Il est maintenant temps de vérifier si Barman a toutes les configurations configurées correctement et peut se connecter au * main-db-server *.

Sur le * barman-backup-server *, passez sur l’utilisateur * barman * si ce n’est pas l’utilisateur actuel. Exécutez la commande suivante pour tester la connexion à votre serveur de base de données principal:

barman check

Notez que si vous avez entré un nom différent entre les crochets du bloc serveur dans le fichier + / etc / barman.conf + à l’étape 5, vous devez utiliser ce nom à la place.

Si tout va bien, le résultat devrait ressembler à ceci:

barman check command outputServer main-db-server:
       PostgreSQL: OK
       archive_mode: OK
       wal_level: OK
       archive_command: OK
       continuous archiving: OK
       directories: OK
       retention policy settings: OK
       backup maximum age: FAILED (interval provided: 1 day, latest backup age: No available backups)
       compression settings: OK
       minimum redundancy requirements: OK (have 0 backups, expected at least 0)
       ssh: OK (PostgreSQL server)
       not in recovery: OK

Ne vous inquiétez pas de l’âge maximum de la sauvegarde + FAILED. Cela est dû au fait que nous avons configuré Barman pour que la dernière sauvegarde ne soit pas antérieure à 1 jour. Il n’y a pas encore de sauvegarde, donc la vérification échoue.

Si l’un des autres paramètres se trouve dans l’état + FAILED, vous devez étudier plus avant et résoudre le problème avant de poursuivre.

Plusieurs raisons peuvent expliquer l’échec d’une vérification: par exemple, Barman ne peut pas se connecter à l’instance Postgres, Postgres n’est pas configuré pour l’archivage WAL, SSH ne fonctionne pas entre les serveurs, etc. Quelle que soit la cause, il faut y remédier avant que les sauvegardes puissent avoir lieu. Suivez les étapes précédentes et assurez-vous que toutes les connexions fonctionnent.

Pour obtenir une liste des serveurs PostgreSQL configurés avec Barman, exécutez cette commande:

barman list-server

En ce moment, il devrait simplement montrer:

Sortie

main-db-server - Main DB Server

Étape 8 - Création de la première sauvegarde

Maintenant que Barman est prêt, créons une sauvegarde manuellement.

Exécutez la commande suivante en tant qu’utilisateur * barman * sur le * barman-backup-server * pour effectuer votre première sauvegarde:

barman backup

Là encore, la valeur ++ correspond à ce que vous avez entré en tant que tête du bloc serveur dans le fichier + / etc / barman.conf + à l’étape 5.

Cela initiera une sauvegarde complète du répertoire de données PostgreSQL. Comme notre instance n’a qu’une seule petite base de données avec deux tables, elle devrait se terminer très rapidement.

Sortie

Starting backup for server  in /var/lib/barman/main-db-server/base/20151111T051954
Backup start at xlog location: 0/2000028 (000000010000000000000002, 00000028)
Copying files.
Copy done.
Asking PostgreSQL server to finalize the backup.
Backup size: 26.9 MiB. Actual size on disk: 26.9 MiB (-0.00% deduplication ratio).
Backup end at xlog location: 0/20000B8 (000000010000000000000002, 000000B8)
Backup completed
Processing xlog segments for
       Older than first backup. Trashing file 000000010000000000000001 from server
       000000010000000000000002
       000000010000000000000002.00000028.backup

Emplacement du fichier de sauvegarde

Alors, où la sauvegarde est-elle sauvegardée? Pour trouver la réponse, listez le contenu du répertoire + / var / lib / barman +:

ls -l /var/lib/barman

Il y aura un répertoire ici: + main-db-server +. C’est le serveur que Barman est actuellement configuré pour la sauvegarde et ses sauvegardes y résident. (Si vous configurez Barman pour sauvegarder d’autres serveurs, un répertoire sera créé par serveur.) Sous le répertoire + main-db-server +, il y aura trois sous-répertoires:

  • + base +: C’est ici que sont sauvegardés les fichiers de sauvegarde de base

  • + incoming +: PostgreSQL envoie ses fichiers WAL complétés à ce répertoire pour archivage

  • + wals +: Barman copie le contenu du répertoire + incoming + dans le répertoire + wals +

Lors d’une restauration, Barman récupérera le contenu du répertoire + base + dans le répertoire de données du serveur cible. Il utilisera ensuite les fichiers du répertoire + wals + pour appliquer les modifications de transaction et ramener le serveur cible à un état cohérent.

Liste des sauvegardes

Il existe une commande Barman spécifique pour répertorier toutes les sauvegardes d’un serveur. Cette commande est + barman list-backup +. Exécutez la commande suivante pour voir ce qu’elle retourne pour notre ++:

barman list-backup
Outputmain-db-server 20151111T051954 - Wed Nov 11 05:19:46 2015 - Size: 26.9 MiB - WAL Size: 0 B

  • La première partie de la sortie est le nom du serveur. Dans ce cas, + main-db-server +

  • La deuxième partie - une valeur alphanumérique longue - est l’ID de sauvegarde pour la sauvegarde. Un identifiant de sauvegarde est utilisé pour identifier de manière unique toute sauvegarde effectuée par Barman. Dans ce cas, il s’agit de «++». * Vous aurez besoin de l’ID de sauvegarde pour les prochaines étapes *

  • La troisième information vous indique quand la sauvegarde a été faite

  • La quatrième partie est la taille de la sauvegarde de base (26,9 Mo dans ce cas)

  • La cinquième et dernière partie de la chaîne donne la taille de l’archive WAL sauvegardée

Pour plus de détails sur la sauvegarde, exécutez cette commande en utilisant le nom du serveur et l’ID de sauvegarde (++ dans notre exemple) de la commande précédente:

barman show-backup

Un ensemble d’informations détaillé sera affiché:

OutputBackup :
 Server Name            :
 Status                 : DONE
 PostgreSQL Version     : 90405
 PGDATA directory       : /var/lib/pgsql/9.4/data

 Base backup information:
   Disk usage           : 26.9 MiB (26.9 MiB with WALs)
   Incremental size     : 26.9 MiB (-0.00%)
   Timeline             : 1
   Begin WAL            : 000000010000000000000002
   End WAL              : 000000010000000000000002
   WAL number           : 1
   WAL compression ratio: 99.84%
   Begin time           : 2015-11-11 05:19:44.438072-05:00
   End time             : 2015-11-11 05:19:46.839589-05:00
   Begin Offset         : 40
   End Offset           : 184
   Begin XLOG           : 0/2000028
   End XLOG             : 0/20000B8

 WAL information:
   No of files          : 0
   Disk usage           : 0 B
   Last available       : 000000010000000000000002

 Catalog information:
   Retention Policy     : VALID
   Previous Backup      : - (this is the oldest base backup)
   Next Backup          : - (this is the latest base backup)

Pour explorer davantage pour voir quels fichiers vont dans la sauvegarde, exécutez cette commande:

barman list-files

Cela vous donnera une liste des fichiers de sauvegarde de base et WAL requis pour la restauration à partir de cette sauvegarde particulière.

Étape 9 - Planification des sauvegardes

Idéalement, vos sauvegardes devraient se faire automatiquement selon un calendrier.

Dans cette étape, nous automatiserons nos sauvegardes et nous demanderons à Barman d’assurer la maintenance des sauvegardes afin que les fichiers plus anciens que la stratégie de rétention soient supprimés. Pour activer la planification, exécutez cette commande en tant qu’utilisateur * barman * sur le * barman-backup-server * (passez à cet utilisateur si nécessaire):

crontab -e

Cela ouvrira un fichier + crontab + pour l’utilisateur * barman *. Editez le fichier, ajoutez ces lignes, puis enregistrez et quittez:

cron

30 23 * * * /usr/bin/barman backup
* * * * * /usr/bin/barman cron

La première commande exécutera une sauvegarde complète du * main-db-server * tous les soirs à 23h30. (Si vous avez utilisé un nom différent pour le serveur dans le fichier + / etc / barman.conf +, utilisez plutôt ce nom.)

La deuxième commande sera exécutée toutes les minutes et effectuera des opérations de maintenance sur les fichiers WAL et les fichiers de sauvegarde de base.

Étape 10 - Simuler un «désastre»

Vous allez maintenant voir comment vous pouvez restaurer à partir de la sauvegarde que vous venez de créer. Pour tester la restauration, commençons par simuler un scénario «catastrophe» dans lequel vous perdriez des données.

  • On laisse tomber une table ici. Ne le faites pas sur une base de données de production! *

Retournez à la console * main-db-server * et basculez vers l’utilisateur * postgres * s’il n’est pas déjà l’utilisateur actuel.

Lancez l’utilitaire + psql +:

psql

A partir de l’invite + psql +, exécutez la commande suivante pour passer le contexte de la base de données à + ​​mytestdb +:

\connect mytestdb;

Ensuite, listez les tables dans la base de données:

\dt

La sortie montrera les tables que vous avez créées au début de ce tutoriel:

Output            List of relations
Schema |     Name     | Type  |  Owner
--------+--------------+-------+----------
public | mytesttable1 | table | postgres
public | mytesttable2 | table | postgres

Maintenant, lancez cette commande pour supprimer l’une des tables:

drop table mytesttable2;

Si vous exécutez à nouveau la commande + \ dt +:

\dt

Vous verrez qu’il ne reste que + mytesttable1 +.

Il s’agit du type de situation de perte de données dans laquelle vous souhaitez restaurer à partir d’une sauvegarde. Dans ce cas, vous restaurerez la sauvegarde sur un serveur distinct: le * standby-db-server *.

Étape 11 - Restauration ou migration vers un serveur distant

Vous pouvez suivre cette section pour restaurer une sauvegarde ou pour migrer votre dernière sauvegarde PostgreSQL sur un nouveau serveur.

Allez sur le * serveur de base de données *.

Tout d’abord, arrêtez le service PostgreSQL en tant qu’utilisateur sudo. (Le redémarrage s’étouffera si vous essayez d’exécuter la restauration pendant que le service est en cours d’exécution.)

sudo systemctl stop postgresql-9.4.service

Une fois le service arrêté, accédez au * barman-backup-server *. Basculez vers l’utilisateur * barman * s’il ne s’agit pas déjà de l’utilisateur actuel.

Localisons les détails de la dernière sauvegarde:

barman show-backup  latest

Sortie

Backup :
 Server Name            :
 Status                 : DONE
 PostgreSQL Version     : 90405
 PGDATA directory       : /var/lib/pgsql/9.4/data

 Base backup information:

. . .

   Begin time           :
   End time             : 2016-01-14 17:35:55.054673-05:00

Dans la sortie, notez l’ID de sauvegarde imprimé sur la première ligne («+» ci-dessus). Si la sauvegarde ` latest ` contient les données souhaitées, vous pouvez utiliser ` latest +` comme ID de sauvegarde.

Vérifiez également quand la sauvegarde a été effectuée, dans le champ + heure de début + (++ ci-dessus).

Ensuite, exécutez cette commande pour restaurer la sauvegarde spécifiée à partir du * barman-backup-server * sur le * standby-db-server *:

barman recover --target-time ""  --remote-ssh-command "ssh postgres@"         /var/lib/pgsql/9.4/data

Il y a pas mal d’options, d’arguments et de variables ici, alors expliquons-les.

  • + - target-time" "+: utilise l’heure de début de la commande + show-backup +

  • + - remote-ssh-command" ssh postgres @ "+: utilise l’adresse IP du * standby-db-server *

  • ++: utilisez le nom du serveur de base de données à partir de votre fichier + / etc / barman.conf +

  • ++: utilisez l’ID de sauvegarde de la commande + show-backup +, ou utilisez + latest + si c’est celui que vous voulez

  • + / var / lib / pgsql / 9.4 / data +: Le chemin où vous souhaitez que la sauvegarde soit restaurée. Ce chemin deviendra le nouveau répertoire de données pour Postgres sur le serveur de secours. Ici, nous avons choisi le répertoire de données par défaut pour Postgres dans CentOS. Pour les cas d’utilisation réels, choisissez le chemin approprié

Pour une opération de restauration réussie, vous devriez recevoir une sortie comme ceci:

Sortie de Barman Recovery

Starting remote restore for server   using backup
Destination directory: /var/lib/pgsql/9.4/data
Doing PITR. Recovery target time:
Copying the base backup.
Copying required WAL segments.
Generating recovery.conf
Identify dangerous settings in destination directory.

IMPORTANT
These settings have been modified to prevent data losses

postgresql.conf line 207: archive_command = false

Your PostgreSQL server has been successfully prepared for recovery!

Passez maintenant à la console * standby-db-server *. En tant qu’utilisateur * sudo *, démarrez le service PostgreSQL:

sudo systemctl start postgresql-9.4.service

Ça devrait être ça!

Vérifions que notre base de données est en place. Basculez vers l’utilisateur * postgres * et démarrez l’utilitaire + psql +:

sudo su - postgres
psql

Basculez le contexte de la base de données sur + mytestdb + et répertoriez les tables qu’il contient:

\connect mytestdb;
\dt

Sortie

           List of relations
Schema |     Name     | Type  |  Owner
--------+--------------+-------+----------
public | mytesttable1 | table | postgres
public | mytesttable2 | table | postgres
(2 rows)

La liste devrait montrer deux tables dans la base de données. En d’autres termes, vous venez de récupérer la table supprimée.

En fonction de votre stratégie de récupération plus large, vous pouvez maintenant vouloir basculer vers le * serveur de base de données *, ou vous pouvez vérifier que la base de données restaurée fonctionne, puis réexécutez cette section pour restaurer le * système principal. -db-server *.

Pour restaurer sur un autre serveur, assurez-vous que vous avez bien installé PostgreSQL et établi les connexions appropriées au serveur Barman, puis suivez cette section en utilisant l’adresse IP de votre serveur de récupération cible.

Conclusion

Dans ce tutoriel, nous avons vu comment installer et configurer Barman pour sauvegarder un serveur PostgreSQL. Nous avons également appris à restaurer ou à migrer à partir de ces sauvegardes.

Avec une attention particulière, Barman peut devenir le référentiel central de toutes vos bases de données PostgresQL. Il offre un mécanisme de sauvegarde robuste et un jeu de commandes simple. Cependant, créer des sauvegardes n’est que la moitié de l’histoire. Vous devez toujours valider vos sauvegardes en les restaurant dans un emplacement différent. Cet exercice devrait être fait périodiquement.

Quelques questions pour adapter Barman à votre stratégie de sauvegarde:

  • Combien d’instances PostgreSQL seront sauvegardées?

  • Le serveur Barman dispose-t-il de suffisamment d’espace disque pour héberger toutes les sauvegardes pendant une période de conservation spécifiée? Comment pouvez-vous surveiller le serveur pour l’utilisation de l’espace?

  • Toutes les sauvegardes de différents serveurs doivent-elles démarrer en même temps ou peuvent-elles être échelonnées pendant les périodes creuses? Le démarrage simultané de sauvegardes de tous les serveurs peut constituer une charge inutile pour le serveur Barman et le réseau.

  • La vitesse du réseau entre le serveur Barman et les serveurs Postgres est-elle fiable?

Un autre point à prendre en compte est que Barman ne peut pas sauvegarder et restaurer des bases de données individuelles. Cela fonctionne au niveau du système de fichiers et utilise une approche tout-ou-rien. Lors d’une sauvegarde, toute l’instance avec tous ses fichiers de données est sauvegardée. lors de la restauration, tous ces fichiers sont restaurés. De même, vous ne pouvez pas effectuer de sauvegardes avec schéma uniquement ou données uniquement avec Barman.

Nous vous recommandons donc de concevoir votre stratégie de sauvegarde afin qu’elle utilise les sauvegardes logiques avec + pg_dump + ou + + pg_dumpall + et les sauvegardes physiques avec Barman. Ainsi, si vous devez restaurer rapidement des bases de données individuelles, vous pouvez utiliser les sauvegardes + pg_dump +. Pour la récupération à un moment précis, utilisez les sauvegardes Barman.

Related