S’assurer que la sauvegarde d’hier soir a bien eu lieu

Ce que vous saurez

• La tâche s’est exécutée, à l’heure, et s’est terminée sans erreur. Le script de sauvegarde appelle une URL de battement de cœur quand il réussit, et une autre quand il échoue. Si ni l’une ni l’autre n’arrive à temps, c’est aussi un problème.
• Le fichier écrit est récent, et assez gros pour être une sauvegarde. L’agent examine le vidage le plus récent du dossier de sauvegarde : son âge, et s’il est plus gros que ne le serait un vidage vide.

Il vous faut les deux. Un battement de cœur se fie à la parole de la tâche, et il arrive qu’une tâche annonce une réussite à tort. Un pipeline pg_dump | gzip sans pipefail se termine avec le statut de gzip : un vidage raté peut donc quand même annoncer une réussite, avec un fichier de 20 octets. La vérification du fichier le détecte. Le battement de cœur détecte ce que la vérification du fichier ne peut pas voir, comme la tâche qui signale son propre échec au milieu de la nuit.

Ce que cela ne peut pas vous dire : si la sauvegarde se restaure. Seule une restauration vous le dira. Une façon de surveiller une restauration d’essai régulière est décrite sous Variantes.

Avant de commencer

• La machine où s’exécute la sauvegarde, ajoutée comme hôte dans Gryphon.
• curl sur cette machine. La plupart des distributions l’incluent.
• Pour la vérification du fichier, l’agent Gryphon sur la même machine. Le battement de cœur fonctionne sans lui.

L’exemple sauvegarde chaque nuit une base de données PostgreSQL nommée app, sous l’utilisateur postgres. Pour MySQL, MariaDB, restic ou autre chose, seule la commande de sauvegarde change : voyez Variantes.

Étapes

1Ajouter le battement de cœur

Ouvrez l’hôte, allez dans Services, choisissez Ajouter le service, puis Battement de cœur.

Une fois la vérification ajoutée, sa ligne affiche son URL, avec un bouton Copier. Gardez-la pour l’étape suivante. Quiconque a cette URL peut faire rapport à cette vérification : traitez-la donc comme un mot de passe. Si elle fuit, les paramètres de la vérification permettent de lui en donner une nouvelle.

L’horaire commence quand vous ajoutez la vérification. Tant que le premier ping n’est pas arrivé, elle reste en attente. Après une journée plus le délai de grâce sans ping, elle devient un problème.

2Faire signaler la sauvegarde

Enregistrez ceci sous /usr/local/bin/backup-postgres, collez-y l’URL de votre battement de cœur, et rendez le fichier exécutable avec sudo chmod 755 /usr/local/bin/backup-postgres.

#!/bin/bash
# Nightly PostgreSQL backup that reports to Gryphon.
set -euo pipefail
umask 077

HB="https://gryphon.gocode.ca/hb/your-token"
DEST=/var/backups/postgres
FILE="$DEST/app-$(date +%F).sql.gz"

# Any failure, on any line, reports itself before the script exits.
trap 'curl -fsS -m 10 --retry 3 "$HB/fail" > /dev/null || true' ERR

pg_dump app | gzip > "$FILE.part"
mv "$FILE.part" "$FILE"

# Keep two weeks.
find "$DEST" -name 'app-*.sql.gz' -mtime +14 -delete

curl -fsS -m 10 --retry 3 "$HB" > /dev/null

set -o pipefail fait échouer tout le pipeline quand pg_dump échoue, et le trap fait de tout échec un appel à l’URL /fail. Le vidage est écrit sous un nom temporaire et renommé une fois terminé : un fichier à moitié écrit n’a donc jamais l’air d’une sauvegarde.

Créez le dossier et planifiez le script dans la crontab de l’utilisateur postgres, à 2 h 30 chaque nuit :

getent group backup > /dev/null || sudo groupadd --system backup
sudo install -d -o postgres -g backup -m 0750 /var/backups/postgres
sudo crontab -u postgres -e

30 2 * * * /usr/local/bin/backup-postgres

Le dossier appartient au groupe backup pour qu’à l’étape suivante, l’agent puisse être autorisé à en lister le contenu. Debian et Ubuntu ont déjà ce groupe, et la première ligne le crée ailleurs. Les vidages eux-mêmes ne sont lisibles que par postgres, à cause du umask du script. L’agent ne les ouvre jamais. Il n’a besoin de voir que leurs noms, leurs dates et leurs tailles.

3Laisser l’agent voir le dossier

L’agent ne regarde que dans les dossiers que vous nommez, et sous Linux, il s’exécute sous son propre utilisateur, sans aucun groupe. Indiquez le dossier dans ses réglages, puis ajoutez l’agent au groupe backup :

GWC_WATCH_DIRS=/var/backups/postgres

[Service]
SupplementaryGroups=backup

sudo systemctl restart gryphon-agent

4Ajouter la vérification du fichier

De retour dans Gryphon, ajoutez un second service au même hôte : Fraîcheur de fichier (agent).

Avec un dossier, c’est le fichier correspondant le plus récent qui est jugé : le fichier .part d’un vidage en cours n’est donc jamais pris pour la sauvegarde. L’âge donne un avertissement à 26 heures et un problème à 30, ce qui convient à une tâche de nuit, avec de la marge pour une nuit plus lente. Pour une tâche à un autre horaire, modifiez Avertissement à et Problème à dans les Paramètres de la vérification. Un dossier manquant, aucun fichier correspondant ou un fichier sous la taille minimale est un problème sur-le-champ.

Faire un essai

1. Lancez la sauvegarde à la main : sudo -u postgres /usr/local/bin/backup-postgres. En moins d’une minute, le battement de cœur est en bon état et indique quand le dernier ping est arrivé. La vérification du fichier passe en bon état à sa prochaine exécution.
2. Signalez un échec exprès : curl -fsS https://gryphon.gocode.ca/hb/your-token/fail. En moins d’une minute, le battement de cœur devient un problème et des alertes partent vers tous ceux qui les reçoivent pour cet hôte : prévenez-les d’abord.
3. Relancez la sauvegarde. Le prochain bon ping le remet en bon état, et le rétablissement est annoncé comme n’importe quel autre.

Variantes

MySQL ou MariaDB

Remplacez la ligne pg_dump, et gardez les identifiants de l’utilisateur dans son propre ~/.my.cnf plutôt que dans le script :

mysqldump --single-transaction --routines app | gzip > "$FILE.part"

restic, Borg, rsync ou toute autre commande

Enveloppez la commande et signalez son code de sortie :

HB="https://gryphon.gocode.ca/hb/your-token"
if restic backup /srv/data; then
    curl -fsS -m 10 --retry 3 "$HB" > /dev/null
else
    curl -fsS -m 10 --retry 3 "$HB/fail" > /dev/null
fi

Un dépôt, contrairement à un dossier de fichiers, n’a pas de fichier unique à juger. Laissez tomber la vérification du fichier, ou pointez-la vers un fichier journal que la tâche écrit à chaque exécution.

Un minuteur systemd au lieu de cron

Laissez systemd signaler le résultat : le script lui-même reste inchangé. Dans le service que lance le minuteur, ajoutez ceci. Le $$ doublé transmet la variable au shell :

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-postgres
ExecStopPost=/bin/sh -c 'if [ "$$SERVICE_RESULT" = success ]; then curl -fsS -m 10 --retry 3 https://gryphon.gocode.ca/hb/your-token; else curl -fsS -m 10 --retry 3 https://gryphon.gocode.ca/hb/your-token/fail; fi'

Une restauration d’essai chaque semaine

La façon la plus sûre de vérifier une sauvegarde est de la restaurer. Scriptez une restauration dans une base de données jetable, lancez une requête qui prouve que les données y sont, et signalez le résultat à un second battement de cœur réglé à Fréquence 7 Jours. Une restauration qui cesse de fonctionner devient alors un problème dans Gryphon, et non une mauvaise surprise plus tard.

Sous Windows

Les deux mêmes vérifications y fonctionnent. Pour SQL Server, voyez Vérifier les sauvegardes SQL Server sous Windows. Pour le reste, la dernière ligne du script PowerShell d’une tâche planifiée est le ping, avec $hb réglé sur l’URL du battement de cœur : Invoke-WebRequest -UseBasicParsing -TimeoutSec 10 -Uri $hb | Out-Null.