freehck.script_psql_backup

Aperçu Versions Perspectives

freehck.script_psql_backup

Ce rôle crée un script qui effectue des sauvegardes psql.

Il sauvegarde la base de données, compresse éventuellement avec gzip et chiffre la sauvegarde avec aes256.

Il peut envoyer des messages dans Slack.

Il peut stocker votre sauvegarde sur S3 et/ou la transférer à un autre hôte via scp.

Variables du Rôle

Variables de base

psql_backup_host: hôte psql

psql_backup_port: port psql (par défaut 3306)

psql_backup_user: utilisateur psql

psql_backup_pass: mot de passe psql

psql_backup_db: base de données psql à sauvegarder (si non spécifié, l'option --all-databases sera passée à psqldump)

psql_backup_backend_use_s3: à mettre sur vrai si vous souhaitez stocker votre sauvegarde sur S3

psql_backup_backend_use_scp: à mettre sur vrai si vous voulez envoyer votre sauvegarde à un autre hôte via scp

Variables pour backend S3

psql_backup_s3cfg_template: modèle de votre configuration s3fs (le modèle par défaut est fourni, ne vous inquiétez pas)

psql_backup_s3: options de configuration S3 au format suivant

psql_backup_s3:
  username: "s3user"
  access_key: "s3user-akey"
  secret_key: "s3user-skey"
  bucket: "nom-du-bucket"

Variables pour backend SCP

psql_backup_scp_host: hôte de stockage pour copier votre sauvegarde

psql_backup_scp_user: utilisateur pour se connecter à l'hôte de stockage

psql_backup_scp_dst: chemin sur l'hôte de stockage pour enregistrer votre sauvegarde

psql_backup_scp_identity_src: fichier d'identité à utiliser pour se connecter à l'hôte de stockage (oui, cela doit être une clé privée)

Nommage

psql_backup_archive_prefix: juste le nom de la sauvegarde ou tout ce qui précède le timestamp

psql_backup_archive_stamp: modèle de timestamp au format de l'outil date (le défaut est %F-%Hh%Mm%Ss et les timestamps résultants ressemblent à 2019-09-23-12h22m07s)

psql_backup_script_name: si vous souhaitez renommer le script de base, vous êtes libre de le faire

psql_backup_custom_script_name: si vous souhaitez définir un nom spécifique pour le script de travail qui effectue la sauvegarde. Le défaut est psql-backup-<database_name>.sh, où peut être all si aucune base de données n'a été spécifiée pour la sauvegarde.

psql_backup_scp_identity_name: le défaut est id_rsa, mais cela pourrait être utile de le modifier si vous souhaitez avoir plusieurs backends SCP utilisant des clés différentes

psql_backup_encrypt_aes_key_name: le défaut est aes256.key, nécessaire si vous voulez avoir des clés de chiffrement différentes pour différentes tâches de sauvegarde

Notifications

psql_backup_warn_size: en GiB, le défaut est 0. Comparez votre sauvegarde avec cette taille. Si votre sauvegarde est inférieure, un avertissement sera donné.

psql_backup_hostname: nom d'hôte (qui sera imprimé dans les messages Slack)

psql_backup_slack_webhook: comme indiqué, c'est un webhook Slack ; définissez-le pour recevoir des notifications Slack

Comment obtenir un webhook Slack : https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack

Variables de compression et de chiffrement

psql_backup_gzip: fichier de sauvegarde gzip

psql_backup_encrypt_aes: chiffrer le fichier de sauvegarde (si gzip est activé, cette action sera effectuée spécifiquement APRÈS gzip)

psql_backup_encrypt_aes_key_src: clé aes256 pour chiffrer votre sauvegarde

La clé aes256 est juste 32 octets aléatoires.

Vous pouvez utiliser la commande suivante pour la créer : dd if=/dev/urandom of=aes256.key count=1 bs=32.

Si vous préférez des mots de passe sous forme de chaîne (moins sécurisé), vous pouvez utiliser ceci : pwgen -n1 -s 32 | tr -d '\n' >aes256.key

Répertoires

psql_backup_script_dir: répertoire pour stocker le script de base

psql_backup_custom_script_dir: répertoire pour stocker les scripts spécifiques aux travaux de sauvegarde appropriés

psql_backup_conf_dir: répertoire pour stocker les fichiers de configuration du script de sauvegarde

psql_backup_encrypt_aes_key_dir: répertoire pour stocker la clé de chiffrement aes256

psql_backup_tmpdir: répertoire pour conserver les résultats temporaires (vous n'avez pas besoin d'en créer un séparé, c'est /tmp par défaut)

Passer les données hors du rôle

psql_backup_save_facts_about_custom_script: si vous le définissez sur vrai, le rôle enregistrera le chemin complet du script de travail généré, qui doit être exécuté pour effectuer la sauvegarde, dans la variable psql_backup_last_generated_custom_script. Vous pouvez utiliser cette variable pour ajouter une tâche cron spécifique pour ce script.

Exemple de Playbook

# créer le script de sauvegarde psql
- rôle: freehck.script_psql_backup
  # paramètres de connexion psql
  psql_backup_host: "{{ db_host }}"
  psql_backup_user: "{{ db_user }}"
  psql_backup_pass: "{{ db_pass }}"
  psql_backup_db: "{{ db_name }}"
  # paramètres de stockage backend
  psql_backup_backend_use_s3: non
  psql_backup_backend_use_scp: oui
  psql_backup_scp_host: "{{ hostvars['storage'].ansible_host }}"
  psql_backup_scp_identity_src: "{{ playbook_dir }}/files/id_rsa.bkp.db01"
  psql_backup_scp_user: 'file'
  psql_backup_scp_dst: '/var/www/file/public/psql-db-prod-backup'
  # gzip et chiffrement
  psql_backup_gzip: oui
  psql_backup_encrypt_aes: oui
  psql_backup_encrypt_aes_key_src: "{{ playbook_dir }}/files/aes256.bkp.key"
  # autres
  psql_backup_save_facts_about_custom_script: oui
  psql_backup_logfile: "/var/log/psql-backup.log"
  tags: [ backup, psql ]

# il est sensé de créer un travail cron pour ce script de travail
- rôle: freehck.crontask
  crontask_file: "backups"
  crontask_name: "sauvegarde de la base de données"
  crontask_hour: "12"
  crontask_minute: "0"
  crontask_job: "{{ psql_backup_last_generated_custom_script }}"
  crontask_user: "root"
  crontask_commented_out: faux
  tags: [ backup, psql ]

Informations importantes

Après avoir déployé le script psql-backup sur votre hôte, il serait judicieux de vous rendre sur l'hôte qui effectue les tâches de sauvegarde et d'exécuter le script de travail depuis /opt/scripts sans paramètres. S'il passe sans erreurs et que vous voyez le fichier de sauvegarde dans le stockage, alors tout est en ordre. Sinon, vous découvrirez quel était le problème. Par exemple, vous pourriez avoir oublié d'ajouter l'hôte de stockage à known_hosts lors de la configuration des utilisateurs. Ou votre modèle s3cfg pourrait contenir une erreur. N'oubliez pas de tout vérifier deux fois : la sauvegarde est une tâche très importante.

Après avoir vérifié que la sauvegarde a été créée et stockée au bon endroit, examinez-la attentivement. Vous devez être sûr de pouvoir la restaurer.