freehck.script_mysql_backup

Diese Rolle erstellt ein Skript, das MySQL-Backups durchführt.

Es speichert die Datenbank, komprimiert sie möglicherweise mit Gzip und verschlüsselt das Backup mit AES256.

Das Skript kann Nachrichten in Slack senden.

Es kann dein Backup auf S3 speichern und/oder es mit SCP auf einen anderen Host übertragen.

Rollenvariablen

Basisvariablen

mysql_backup_host: MySQL-Host

mysql_backup_port: MySQL-Port (Standard 3306)

mysql_backup_user: MySQL-Nutzer

mysql_backup_pass: MySQL-Passwort

mysql_backup_db: MySQL-Datenbank zum Backup (wenn nicht festgelegt, wird die Option --all-databases an mysqldump übergeben)

mysql_backup_backend_use_s3: auf true setzen, wenn du dein Backup auf S3 speichern möchtest

mysql_backup_backend_use_scp: auf true setzen, wenn du dein Backup mit SCP auf einen anderen Host übertragen möchtest

S3-Backend-Variablen

mysql_backup_s3cfg_template: Vorlage für deine s3fs-Konfiguration (das Standardformat ist vorhanden, keine Sorge)

mysql_backup_s3: S3-Konfigurationsoptionen im folgenden Format

mysql_backup_s3:
  username: "s3user"
  access_key: "s3user-akey"
  secret_key: "s3user-skey"
  bucket: "bucket-name"

SCP-Backend-Variablen

mysql_backup_scp_host: Speicher-Host, um dein Backup zu kopieren

mysql_backup_scp_user: Benutzer, um sich am Speicher-Host anzumelden

mysql_backup_scp_dst: Pfad auf dem Speicher-Host, um dein Backup zu speichern

mysql_backup_scp_identity_src: Identitätsdatei, die zur Anmeldung am Speicher-Host verwendet wird (ja, es sollte ein privater Schlüssel sein)

Benennung

mysql_backup_archive_prefix: nur der Backup-Name oder alles vor dem Zeitstempel

mysql_backup_archive_stamp: Zeitstempelvorlage im Format des date-Befehls (das Standardformat ist %F-%Hh%Mm%Ss, was zu Zeitstempeln führt, die wie 2019-09-23-12h22m07s aussehen)

mysql_backup_script_name: wenn du das Basisskript umbenennen möchtest, kannst du das gerne tun

mysql_backup_custom_script_name: wenn du dem spezifischen Jobskript, das das Backup tatsächlich durchführt, einen bestimmten Namen geben möchtest. Das Standardformat ist mysql-backup-<datenbank_name>.sh, wobei all sein kann, wenn keine Datenbanken zum Backup angegeben wurden.

mysql_backup_scp_identity_name: das Standardformat ist id_rsa, aber es könnte nützlich sein, es zu ändern, falls du mehrere SCP-Backends mit unterschiedlichen Schlüsseln haben möchtest

mysql_backup_encrypt_aes_key_name: das Standardformat ist aes256.key, benötigt, wenn du unterschiedliche Verschlüsselungsschlüssel für verschiedene Backup-Aufgaben haben möchtest

Benachrichtigungen

mysql_backup_warn_size: in GiB, Standard ist 0. Vergleiche dein Backup mit dieser Größe. Wenn dein Backup kleiner ist, wirst du darüber gewarnt.

mysql_backup_hostname: Hostname (der in Slack-Nachrichten angezeigt wird)

mysql_backup_slack_webhook: wie beschrieben, es ist ein Slack-WebHook; setze es, um Slack-Benachrichtigungen zu erhalten

Wie man einen Slack-WebHook erhält: https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack

Komprimierungs- und Verschlüsselungsvariablen

mysql_backup_gzip: Gzip-Backup-Datei

mysql_backup_encrypt_aes: Backup-Datei verschlüsseln (wenn Gzip aktiviert ist, wird diese Aktion speziell NACH Gzip ausgeführt)

mysql_backup_encrypt_aes_key_src: AES256-Schlüssel zur Verschlüsselung deines Backups

Der AES256-Schlüssel sind einfach 32 Bytes Zufallsdaten.

Du kannst den folgenden Befehl verwenden, um ihn zu erstellen: dd if=/dev/urandom of=aes256.key count=1 bs=32.

Wenn du String-Passwörter bevorzugst (das ist weniger sicher), kannst du dies verwenden: pwgen -n1 -s 32 | tr -d '\n' >aes256.key

Verzeichnisse

mysql_backup_script_dir: Verzeichnis zum Speichern des Basisskripts

mysql_backup_custom_script_dir: Verzeichnis zum Speichern von Skripten, die für die entsprechenden Backup-Jobs spezifisch sind

mysql_backup_conf_dir: Verzeichnis zum Speichern von Konfigurationsdateien für das Backup-Skript

mysql_backup_encrypt_aes_key_dir: Verzeichnis zum Speichern des AES256-Verschlüsselungsschlüssels

mysql_backup_tmpdir: Verzeichnis für temporäre Ergebnisse (du musst kein separates erstellen, es ist standardmäßig /tmp)

Daten außerhalb der Rolle speichern

mysql_backup_save_facts_about_custom_script: wenn du es auf true setzt, speichert die Rolle den vollständigen Pfad des generierten Jobskripts, das ausgeführt werden muss, um das Backup durchzuführen, in der Variablen mysql_backup_last_generated_custom_script. Du kannst diese Variable verwenden, um eine spezifische Cron-Aufgabe für dieses Skript hinzuzufügen.

Beispiel-Playbook

# Erstelle MySQL-Backup-Jobs-Skript
- role: freehck.script_mysql_backup
  # MySQL-Verbindungsparameter
  mysql_backup_host: "{{ db_host }}"
  mysql_backup_user: "{{ db_user }}"
  mysql_backup_pass: "{{ db_pass }}"
  mysql_backup_db: "{{ db_name }}"
  # Backend-Speicherparameter
  mysql_backup_backend_use_s3: no
  mysql_backup_backend_use_scp: yes
  mysql_backup_scp_host: "{{ hostvars['storage'].ansible_host }}"
  mysql_backup_scp_identity_src: "{{ playbook_dir }}/files/id_rsa.bkp.db01"
  mysql_backup_scp_user: 'file'
  mysql_backup_scp_dst: '/var/www/file/public/mysql-db-prod-backup'
  # Gzip und Verschlüsseln
  mysql_backup_gzip: yes
  mysql_backup_encrypt_aes: yes
  mysql_backup_encrypt_aes_key_src: "{{ playbook_dir }}/files/aes256.bkp.key"
  # Sonstiges
  mysql_backup_save_facts_about_custom_script: yes
  mysql_backup_logfile: "/var/log/mysql-backup.log"
  tags: [ backup, mysql ]

# Es ist sinnvoll, den Cron-Job für dieses Jobs-Skript zu erstellen
- role: freehck.crontask
  crontask_file: "backups"
  crontask_name: "Datenbank sichern"
  crontask_hour: "12"
  crontask_minute: "0"
  crontask_job: "{{ mysql_backup_last_generated_custom_script }}"
  crontask_user: "root"
  crontask_commented_out: false
  tags: [ backup, mysql ]

Wichtige Informationen

Nachdem du das MySQL-Backup-Skript auf deinem Host bereitgestellt hast, ist es ratsam, sich zu dem Host zu begeben, der die Backup-Tasks ausführt, und das Jobs-Skript ohne Parameter aus /opt/scripts auszuführen. Wenn es fehlerfrei durchläuft und du die Backup-Datei im Speicher siehst, ist alles in Ordnung. Wenn nicht, findest du heraus, was das Problem war. Zum Beispiel hast du möglicherweise vergessen, den Speicher-Host zu known_hosts hinzuzufügen, als du die Benutzer konfiguriert hast. Oder deine s3cfg-Vorlage könnte einen Fehler enthalten. Vergiss nicht, alles zweimal zu überprüfen: Backups sind eine sehr wichtige Aufgabe.

Nachdem du überprüft hast, dass das Backup erstellt und am richtigen Ort gespeichert wurde, überprüfe es sorgfältig. Du musst sicherstellen, dass du es verwenden kannst, um eine Wiederherstellung durchzuführen.

Lizenz

MIT

Autoreninformationen

Dmitrii Kashin, freehck@freehck.ru