Sauvegardes incrémentielles PostgreSQL avec pgBackRest. Partie 2. Chiffrement, démarrage vers S3, restauration vers un nouveau serveur, PITR

Cet article est une suite de l'article "Sauvegardes incrémentielles PostgreSQL avec pgbackrest - le parcours d'un jeune soldat du développeur".



Dans la première partie, nous avons appris à faire des sauvegardes incrémentielles, à les télécharger sur un serveur distant (référentiel avec sauvegardes) et à revenir à la dernière sauvegarde.

Dans cet article, nous allons apprendre à crypter les sauvegardes, à les télécharger sur un stockage compatible S3 (au lieu d'un deuxième serveur de référentiel), à restaurer sur un cluster propre et, enfin, à récupérer à un moment donné (PITR).


Moment L'



auteur ne prétend pas être un DBA, mais il aime parfois tout mettre en place et tout voir lui-même.



Entraînement



Pour reproduire ce manuel, nous avons besoin de:



  1. Un serveur avec une base de données (nous installerons pgbackrest dessus);
  2. Stockage S3 (vous pouvez utiliser Amazon ou tout autre compatible S3, j'utiliserai Amazon S3);
  3. Troisième serveur. Optionnel. Sur celui-ci, nous allons nous entraîner à déployer postgresql et pgbackrest à partir de zéro, en déployant une sauvegarde existante à partir du stockage S3 (le serveur est épuisé, en mouvement, etc.);


Il est supposé que postgresql est déjà installé et que l'utilisateur postgres est donc également disponible.



J'ai décrit le processus d'installation de pgbackrest dans l'article précédent, mais juste au cas où je le dupliquerais à nouveau (je vous le rappelle: avant d'installer, créez un utilisateur sudo pour vous-même - j'utiliserai un utilisateur sudo avec le nom d'utilisateur pgbackrest).



Pour que vous ayez moins de problèmes lors de la reproduction des instructions, j'écris en italique où, par quel utilisateur et avec quels droits j'ai exécuté la commande en écrivant et en vérifiant l'article.



Nous suivrons ce chemin:



Configurer postgresql et pgbackrest Configurer le

chiffrement des sauvegardes (deux lignes)

Apprenez à sauvegarder et envoyer vers le stockage S3 (cinq lignes)

Faire une sauvegarde

Imaginons que nous cassions le cluster, déployions sur un nouveau serveur, connections le référentiel S3 existant et

remontions la sauvegarde Regardons PITR (Point In Time Recovery): nous allons récupérer à un certain moment (disons que pgbackrest a déjà sauvegardé la table de dépôt, mais nous devons reculer de 4 heures) quand le signe existait encore)



Allons-y!



Installation de pgBackRest



utilisateur sudo ou root:



1. Téléchargez l'archive depuis pgbackrest et transférez son contenu dans le dossier / build:



sudo mkdir /build
sudo wget -q -O - \
       https://github.com/pgbackrest/pgbackrest/archive/release/2.18.tar.gz | \
       sudo tar zx -C /build


2. Installez les dépendances nécessaires à la construction:



sudo apt-get update
sudo apt-get install build-essential libssl-dev libxml2-dev libperl-dev zlib1g-dev \
       libpq-dev


3. Assemblage du pgbackrest:



cd /build/pgbackrest-release-2.18/src && sudo ./configure
sudo make -s -C /build/pgbackrest-release-2.18/src


4. Copiez le fichier exécutable dans le répertoire / usr / bin:



sudo cp /build/pgbackrest-release-2.18/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest


5.pgBackRest nécessite perl. Installer:



sudo apt-get install perl


6. Créez des répertoires pour les journaux, donnez-leur certains droits:



sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf


7. Vérifiez:



pgbackrest version


Configurer postgresql et pgBackRest



utilisateur sudo ou root:



1. Effectuez les réglages nécessaires dans postgresql.conf (il se trouve dans le dossier / etc / postgresql / 11 / main) pour que pgBackRest fonctionne:



archive_command = 'pgbackrest --stanza=main archive-push %p' #  main -  .   postgres    main.
archive_mode = on
max_wal_senders = 3
wal_level = replica


2. Faisons les réglages nécessaires dans le fichier de configuration de pgbackrest (/etc/pgbackrest/pgbackrest.conf):



[main]
pg1-path=/var/lib/postgresql/11/main

[global]
log-level-file=detail
repo1-cipher-pass=tr5+BXdfdoxeyUqfo6AzLTrW+c+Jfd/1QbQj2CDMMBwtB0YGH3EJajry4+Eeen6D
repo1-cipher-type=aes-256-cbc
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2 # ,     . ..           ,      .    "     " -     .
repo1-type=s3
repo1-s3-bucket=pgbackrest-part2-tutorial
repo1-s3-endpoint=s3.us-east-1.amazonaws.com
repo1-s3-region=us-east-1
repo1-s3-key=9wdS3G8U5wz7kNsFWVGck7DDZ7DtVDtbM
repo1-s3-key-secret=A9zRmW16zXKt2vVA8mmNsFWy2mUAPYHa
start-fast=y

[global:archive-push]
compress-level=3


Comme vous le comprenez, nous avons immédiatement configuré le chiffrement et configuré la prise en charge du stockage S3.



PS Il ne devrait y avoir aucun commentaire dans la configuration.

PS Pour générer une clé de cryptage forte, vous pouvez utiliser la commande:



openssl rand -base64 48


Créer du stockage



utilisateur sudo ou root:



sudo mkdir -m 770 /var/lib/pgbackrest
sudo chown -R postgres /var/lib/pgbackrest/
sudo -u postgres pgbackrest --stanza=main stanza-create


Si tout a fonctionné, dans le compartiment S3, vous verrez les fichiers générés par pgbackrest.



Faire une sauvegarde:



utilisateur sudo ou root:



sudo -u postgres pgbackrest --log-level-console=info --stanza=main backup


pgBackRest créera la première sauvegarde complète. Si vous le souhaitez, vous pouvez réexécuter la commande de sauvegarde et vous assurer que le système créera une sauvegarde incrémentielle.



Si vous souhaitez effectuer à nouveau une sauvegarde complète, spécifiez un indicateur supplémentaire:



sudo -u postgres pgbackrest --log-level-console=info --stanza=main --type=full backup


Vous pouvez afficher la liste des sauvegardes à l'aide de la commande:



sudo -u postgres pgbackrest --stanza=main info




Restauration de la sauvegarde:



utilisateur sudo ou root:



1. Arrêtez le cluster en cours d'exécution:



sudo pg_ctlcluster 11 main stop


2. Récupération à partir d'une sauvegarde:



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --recovery-option=recovery_target=immediate restore


Pour restaurer la base de données à l'état de la dernière sauvegarde FULL, utilisez la commande sans spécifier recovery_target:



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta restore


Important! Après la récupération, il se peut que la base de données se bloque en mode de récupération (il y aura des erreurs comme ERROR: impossible d'exécuter DROP DATABASE dans une transaction en lecture seule). Il est résolu comme suit (vous devrez attendre un peu après avoir exécuté la commande):



sudo -u postgres psql -c "select pg_wal_replay_resume()"


UPD: Si je comprends bien, cette erreur se produit en raison du fait qu'après la récupération avec recovery_target = immédiat, pgbackrest met la base de données en pause . Pour éviter cela, vous devez en plus spécifier certains indicateurs (vous pouvez lire leur signification ici et ici ):



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --recovery-option=recovery_target=immediate --target-action=promote --type=immediate restore


En fait, il est possible de restaurer une sauvegarde spécifique par son nom. Ici, je ne fournirai qu'un lien vers la description de cette fonctionnalité dans la documentation . Les développeurs conseillent d'utiliser ce paramètre avec prudence et expliquent pourquoi. De moi-même, je peux ajouter que je l'ai utilisé. L'essentiel est de s'assurer qu'après la récupération, la base de données a quitté le mode de récupération (sélectionnez pg_is_in_recovery () devrait afficher "f") et juste au cas où, faire une sauvegarde complète après la récupération.



3. Démarrez le cluster:



sudo pg_ctlcluster 11 main start


Après la restauration de la sauvegarde, nous effectuerons une seconde sauvegarde:

sudo -u postgres pgbackrest --log-level-console=info --stanza=main backup


Restauration de la sauvegarde sur un cluster propre:



Imaginons que quelque chose de terrible se soit produit: le serveur a brûlé (tombé, inondé, accès perdu). Vous devez tout restaurer sur un nouveau serveur propre. Sur le nouveau serveur, nous avons déjà créé un utilisateur sudo, installé pgbackrest, installé postgresql et nous avons un cluster principal propre et frais.



Tout ce que nous devons faire est de configurer la configuration postgresql et pgBackRest de la même manière que sur le serveur précédent, redémarrer postgresql et exécuter l'ordre de commande similaire à la restauration:



utilisateur sudo ou root:



1. Arrêtez le cluster en cours d'exécution:



sudo pg_ctlcluster 11 main stop


2. Récupération à partir d'une sauvegarde:



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --recovery-option=recovery_target=immediate  --target-action=promote --type=immediate restore


PS J'ai décrit les nuances et les subtilités de cette commande ci-dessus. 



3. Démarrez le cluster:



sudo pg_ctlcluster 11 main start


Après avoir restauré la sauvegarde, nous devons effectuer une deuxième sauvegarde:



sudo -u postgres pgbackrest --log-level-console=info --stanza=main backup


C'est, en fait, tout. Le feu est éteint.



Récupération ponctuelle (PITR)



Imaginons une situation telle qu'à 16h00 une sauvegarde a été créée, et à 18h05 nous avons accidentellement effacé une plaque importante dans laquelle beaucoup de données importantes que nous ne voudrions pas perdre ont réussi à obtenir en 2 heures. PgBackRest aux dépens de PostgreSQL nous offre une telle opportunité: nous pouvons revenir à un moment précis dans le temps, à condition que nous ayons suffisamment d'informations pour récupérer.



Cela fonctionne comme ceci:



  1. Nous disons que nous voulons revenir à l'heure 18:04;
  2. pgBackRest recherche la dernière sauvegarde à jour (16:00);
  3. Restaure, mais tout ne se retourne pas, mais seulement ce que nous avons réussi à faire avant le 18.04;


PS ce mécanisme est construit sur les journaux WAL. Vous pouvez le lire ici .



Vous pouvez effectuer une récupération à un moment précis (après l'arrêt du cluster) avec cette commande:



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --type=time "--target=2020-09-06 18:27:24.561458+02" --target-action=promote restore


Remarque importante - PostgreSQL ne peut lire les journaux WAL qu'en avant, pas en arrière. Qu'est-ce que cela signifie en pratique?



Disons qu'une sauvegarde a été créée à 16h00. À 18h05, nous avons accidentellement supprimé la table et à 18h10, une sauvegarde a été créée à nouveau avec la table déjà supprimée. Lorsque vous essayez de faire un PITR, pgBackRest prendra la sauvegarde qui a été créée à 16h00 et retournera tout ce qui était avant 18:05, et ne prendra pas la sauvegarde qui a été créée à 18:10 et annulera tout. Ceci est important à comprendre. Ce mécanisme est décrit plus en détail ici .



Supposons que vous ayez effectué une sauvegarde contenant déjà des informations sur la suppression d'une table. En utilisant l'indicateur --set, disons quelle sauvegarde doit être utilisée pour la base (celle dans laquelle la table était encore). pgBackRest prendra cette sauvegarde et retournera tout ce qui était avant la suppression de la table.



sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --type=time --set=20200905-183838F_20200906-182612I "--target=2020-09-06 18:27:24.561458+02" --target-action=promote restore


PS J'ai montré la commande pour obtenir une liste de sauvegardes ci-dessus.



Commençons le cluster. Après le lancement, examinons le fichier /var/log/postgresql/postgresql-11-main.log. Dans celui-ci, nous nous intéressons aux lignes suivantes, montrant que la récupération au moment spécifié a réussi:



starting point-in-time recovery to 2020-09-07 11:26:52.493127+02
...
recovery stopping before commit of transaction 576, time 2020-09-07 11:27:14.584496+02
...
last completed transaction was at log time 2020-09-07 11:24:09.583761+02


C'est tout. Je vous conseille vivement d'expérimenter cet outil avant de l'utiliser en combat.



All Articles