J'ai essayé de faire une sauvegarde automatique avec plus agréable + PostgreSQL + SSL + docker

Aperçu

• Article précédent est une continuation. ――Si vous envisagez d'utiliser le système sérieusement, vous devez penser correctement à la sauvegarde. ――Cette fois, nous l'avons systématisé afin qu'il puisse être sauvegardé automatiquement.
• Les types de sauvegarde pris en charge sont «Sauvegarde complète» et «PITR (récupération à un moment donné)».
• En entrant les paramètres AWS S3, vous pouvez également synchroniser les données de sauvegarde avec S3.

Configuration du conteneur

Un conteneur a été ajouté pour le travail de sauvegarde. Les conteneurs ajoutés sont indiqués dans le tableau ci-dessous. postgres-db et cron-backup partagent une zone DB, PITR est prêt à l'emploi.

Script de sauvegarde

Le script utilisé pour le mécanisme de sauvegarde automatique est le suivant. Ces scripts sont déployés dans le conteneur pcron-backup.

Paramètres de sauvegarde

Structure du répertoire

Le tableau ci-dessous montre la structure des répertoires vue depuis le conteneur pcron-backup. Les chemins partagés avec 〇 sont partagés avec le conteneur postgres-db.

Les données de résultat de la sauvegarde sont collectées dans "/ var / db_backup". Par conséquent, si vous connectez ce répertoire en dehors du conteneur et effectuez une sauvegarde, vous pourrez effectuer une sauvegarde depuis l'extérieur du conteneur requis.

Fréquence d'acquisition

La gestion des opérations de retour est contrôlée par cron. Le paramétrage du crom correspondant se trouve dans "cron-backup \ config \ crontab". Dans l'état initial, il est spécifié comme suit. Veuillez changer l'heure cible si nécessaire.

Démarrer la sauvegarde

Ces scripts de sauvegarde démarreront automatiquement lorsque vous démarrez Docker Compose. Aucune action spéciale n'est requise pour commencer.

Au contraire, si vous ne souhaitez pas effectuer de sauvegarde, ne démarrez pas le conteneur correspondant

Fonction optionnelle de réglage de sauvegarde Synchronisation S3

Aperçu

Avec uniquement la fonction de sauvegarde jusqu'à présent, il existe un risque de perte de données lorsque le conteneur vole à cause de quelque chose. La sauvegarde doit être conservée ailleurs. Dans les temps modernes, il y en a un pratique appelé S3, il est donc fait pour s'y synchroniser automatiquement.

Activation

Il est activé lorsque le paramètre AWS CLI existe. La passe qui est la cible du jugement d'activation est la suivante.

「/root/.aws/config」

Il est plus facile de placer ce fichier de configuration en dehors du conteneur et de le monter plutôt que de le copier à l'intérieur du conteneur en tant que configuration. (La partie marquée avec ★ ci-dessous.)

docker-compose.yml

  cron-backup:
    build:
      context: cron-backup/.
    volumes:
      - *APP_DB_data
      - *APP_DB_arclog
      #Le résultat de la sauvegarde automatique est "/var/db_Il est stocké en "sauvegarde".
      #Si vous accédez depuis l'extérieur du conteneur, placez ce chemin là où vous pouvez le voir de l'extérieur.
      - db-backup:/var/db_backup
      #Lors de la sauvegarde automatique avec S3
      #Définissez aws cli dans le chemin suivant.
      #S'il n'existe pas, il ne sera pas sauvegardé
      - ./cron-backup/config/aws-cli:/root/.aws/ ←　★

Configuration

Si l'hôte se trouve dans un environnement Windows, le ** fichier de configuration peut être acquis par CRLF ** en fonction des paramètres GIT. Si vous importez le fichier de paramètres dans le conteneur dans cet état, ** le code de saut de ligne ne correspondra pas et il ne fonctionnera pas correctement **, soyez donc prudent lorsque vous manipulez le code de saut de ligne dans le fichier de paramètres.

Tout d'abord, vous devez configurer l'AWS CLI. Il s'agit d'un paramètre général, alors obtenez les informations dont vous avez besoin à partir de votre compte.

cron-backup\config\aws-cli\credentials

[default]
aws_access_key_id =clef d'accès
aws_secret_access_key =Clef secrète

Ensuite, définissez la cible de sauvegarde. Il s'agit d'un paramètre de format shell.

cron-backup\config\aws-cli\S3Config.sh

#!/bin/bash

# ---Paramètres de synchronisation S3

#Nom du compartiment S3 à synchroniser
export S3_TARGET_BUCKET_NAME={Nom du godet}

#Nom du répertoire S3 à synchroniser
export S3_TARGET_DIRECTORY_NAME={Nom du répertoire}

Moment d'exécution

La synchronisation avec S3 correspond au moment où le processus de sauvegarde est exécuté. Si les paramètres sont corrects, aucun paramètre spécial n'est requis pour démarrer.

Mode sans échec

La synchronisation avec S3 se fait avec l'option delete de la commande aws cli "rsync". Lorsque cette commande est utilisée, ** le répertoire de destination de la synchronisation sera le même que le répertoire source de la synchronisation **. Ici, la même chose signifie ** "Les fichiers qui ne sont pas dans la source de synchronisation mais dans la même destination sont supprimés" **. Si vous faites une erreur dans les paramètres immédiatement après avoir créé un nouvel environnement et que cette sauvegarde fonctionne, les données nécessaires seront perdues et ce sera un problème sérieux.

Par conséquent, le processus de sauvegarde de S3 a un mode sans échec. En mode sans échec, si des données différentes du système de sauvegarde du conteneur existant sont confirmées dans le répertoire cible du compartiment cible de S3, créez un répertoire appelé "directory name-safe" sans écraser et sauvegardez de ce côté Ce sera un processus à faire. Pour vérifier l'identité du système de sauvegarde, reportez-vous au fichier "BackupFiles.sha256.7z" généré au moment de la sauvegarde.

Fondamentalement, les utilisateurs n'ont pas à s'inquiéter trop, mais ** veillez à ne pas endommager les sauvegardes existantes, comme lors de la migration vers un environnement. De plus, après avoir effectué la première sauvegarde, vérifiez si un répertoire tel que "nom de répertoire -safe" a été créé.

restaurer

Concernant la restauration La méthode de retour dépend de la méthode d'acquisition des données de sauvegarde.

Une fois acquis par toutes les sauvegardes

Par la suite, il est supposé que vous avez travaillé dans le conteneur cron-backup. Le fichier de sauvegarde est au format 7z et est crypté. Veuillez restaurer le cas échéant. (Reportez-vous au fichier shell "cron-backup \ shell \ pg_dumpall.sh" pour la clé de chiffrement.) Les commandes suivantes supposent que le fichier restauré est nommé «sauvegarde». La restauration à partir de toutes les sauvegardes est effectuée avec une seule commande ci-dessous.

 psql -h postgres-db -p 5432  -U postgres -f backup

PITR

Dans le cas de PITR, c'est un peu déroutant. Dans le cas de PITR, il ne peut pas être restauré correctement si postgres est en cours d'exécution, donc Démarrez uniquement le conteneur cron-backup.

docker-compose up pleasanter-cron-backup

Étape 0. Copie des données

Jouez dans un conteneur de sauvegarde plus agréable. Préparez les données à utiliser pour la restauration. Copiez les données utilisées pour la restauration dans "/ var / db_backup / PITR /".

Étape 1. Arrêtez Coulomb

Jouez dans un conteneur de sauvegarde plus agréable. Si vous démarrez Coulomb normalement, Backup Coulomb commencera à sauvegarder les données. Par conséquent, arrêtez le refroidissement de secours.

crontab -l > my_cron_backup.txt
crontab -r

Étape 2. Vérifiez les données sauvegardées

Jouez dans un conteneur de sauvegarde plus agréable. La commande suivante affiche une liste des sauvegardes acquises.

/usr/lib/postgresql/12/bin/pg_rman show  -B /var/db_backup/PITR/

Lorsque vous exécutez la commande, une liste de minutages qui peuvent être restaurés en tant que sauvegarde s'affiche comme indiqué ci-dessous.

root@885777f50d56:~/out/cron-backup/shell# /usr/lib/postgresql/12/bin/pg_rman show  -B /var/db_backup/PITR/
=====================================================================
 StartTime           EndTime              Mode    Size   TLI  Status
=====================================================================
2020-09-22 21:44:35  2020-09-22 21:44:38  INCR    33kB     3  OK
2020-09-22 21:43:32  2020-09-22 21:43:35  INCR    33kB     3  OK
2020-09-22 21:40:54  2020-09-22 21:40:58  INCR    33kB     3  OK
2020-09-22 21:39:32  2020-09-22 21:39:35  INCR    33kB     3  OK
2020-09-22 21:38:47  2020-09-22 21:38:51  INCR    33kB     3  OK
2020-09-22 21:32:47  2020-09-22 21:36:18  FULL    61MB     3  OK

Étape 3. Restaurer

Jouez dans un conteneur de sauvegarde plus agréable. Dans le cas de PITR, il existe deux modèles de retour.

Revenir au chronométrage final

Utilisez la commande suivante.

/usr/lib/postgresql/12/bin/pg_rman restore  -B /var/db_backup/PITR/ -D /var/lib/postgresql/data/

Revenir au timing arbitraire

Lors du retour à un timing arbitraire, il est possible de spécifier l'heure de retour. La commande est la suivante et spécifie l'heure cible en tant que "recovery-target-time".

/usr/lib/postgresql/12/bin/pg_rman restore  --recovery-target-time '2020-09-06 14:29:00'  -B /var/db_backup/PITR/ -D /var/lib/postgresql/data/

Étape 6. Retourner Coulomb

Jouez dans un conteneur de sauvegarde plus agréable. Restaurez les paramètres Coulomb.

crontab my_cron_backup.txt
crontab -l

Vérification de l'intégrité de la base de données

Ce processus est requis en commun, que vous reveniez de "Toutes les sauvegardes" ou "PITR". Dans le processus de sauvegarde, les données sont extraites pendant le fonctionnement du système. Pour cette raison, les informations de session qui existent sur la base de données restent dans un état semi-fini.

Utilisez la commande suivante pour nettoyer une fois les données inutiles sur la base de données. (Exécutez sur l'hôte docker.)

docker ps | grep leasanter-web | cut -d' ' -f 1  | xargs -I {} docker exec {} cmdnetcore/codedefiner.sh

Post-traitement

Un post-traitement est nécessaire après le renvoi de la base de données.

Sauvegarde complète rapide

Faites une sauvegarde complète dès que vous confirmez que cela fonctionne. Vous pouvez obtenir une sauvegarde complète en appuyant directement sur la commande suivante. Cependant, si S3 est défini, la synchronisation avec S3 fonctionnera également, donc soyez prudent.

「/var/backup_sh/pg_dumpall.sh」

Réacquisition de la sauvegarde de base dans PITR

Après être revenu de la sauvegarde, PITR peut avoir changé la sauvegarde de base de ce qu'il avait précédemment pris. (Dans PITR, la différence est superposée à la sauvegarde de base, mais si la sauvegarde de base et le dernier état de la base de données sont perdus en raison de la restauration, le processus de sauvegarde suivant ne peut pas être exécuté correctement.) Par conséquent, il est nécessaire de réacquérir la sauvegarde de base.

1. Il y a des données de sauvegarde PITR dans le chemin "/ var / db_backup / PITR /". Déplacez ça.
2. Utilisez la commande "/var/backup_sh/pg_rman.sh" pour effectuer à nouveau la sauvegarde avec les données de sauvegarde vides. (Attention car il se synchronise avec S3)

référence

Matériel OSC Hokkaido 2014_JPUG Sauvegardez PostgreSQL de Mastodon en utilisant pg_rman pg_rman Essayez d'utiliser pg_rman Sauvegarde et restauration faciles de PostgreSQL par pg_rman