Surveiller pg_dump (sauvegarde PostgreSQL)

1. Créez un check

Créez un check dans Mortemain correspondant au planning de votre dump (par exemple tous les jours à 02h00) et une fenêtre de grâce couvrant la durée habituelle du dump plus une marge. Copiez son URL de ping :

https://ping.mortemain.com/votre-uuid-de-check

2. Enveloppez pg_dump dans un script

Ne faites pas le check-in directement depuis cron, enveloppez pg_dump dans un petit script pour contrôler précisément quand le succès et l'échec sont signalés. Échouez sur tout code de sortie non nul du pipeline, et ne faites le check-in qu'en cas de succès :

#!/usr/bin/env bash
set -euo pipefail
URL=https://ping.mortemain.com/votre-uuid-de-check
OUT=/backups/mabase-$(date +%F).sql.gz

pg_dump -Fc -Z6 -h localhost -U postgres mabase | gzip > "$OUT"

# dire à Mortemain que le dump s'est bien terminé
curl -fsS -m 10 --retry 3 "$URL"

Pointez cron vers le script, pas directement vers pg_dump :

# dump quotidien à 02h00
0 2 * * *  /usr/local/bin/pg-dump-backup.sh

3. Alertez immédiatement en cas d'échec

Un dump peut échouer bruyamment (disque plein, connexion refusée, mauvais identifiants) bien avant l'expiration de la fenêtre de grâce. Ajoutez un trap pour qu'une erreur pingue /fail et mette le check en panne tout de suite, plutôt que d'attendre des heures pour le découvrir :

#!/usr/bin/env bash
set -euo pipefail
URL=https://ping.mortemain.com/votre-uuid-de-check
OUT=/backups/mabase-$(date +%F).sql.gz

# en cas d'erreur ci-dessous, dire à Mortemain que le dump a échoué
trap 'curl -fsS -m 10 "$URL/fail"' ERR

pg_dump -Fc -Z6 -h localhost -U postgres mabase | gzip > "$OUT"
curl -fsS -m 10 "$URL"          # succès

set -euo pipefail compte ici : sans ça, un pg_dump qui échoue et est enchaîné dans gzip peut quand même sortir avec un code 0, et le trap ne se déclenche jamais.

4. Mesurez la durée du dump (optionnel)

Pinguez /start juste avant que pg_dump démarre, et Mortemain suit la durée de chaque exécution. Une base qui a discrètement grossi jusqu'à ce que le dump prenne 5× plus longtemps qu'avant apparaît comme un avertissement, pas comme une surprise à 3h du matin lors d'une restauration :

curl -fsS -m 10 "$URL/start"
pg_dump -Fc -Z6 -h localhost -U postgres mabase | gzip > "$OUT"
curl -fsS -m 10 "$URL"

Vous préférez tout regrouper ? Un script de maintenance psql qui appelle plusieurs bases peut suivre la même logique, voir le guide général shell & cron pour le chaînage, les tentatives et les lignes uniques.

Testez

Lancez le script une fois à la main. Le check devrait passer actif en une seconde ou deux, et sa durée devrait refléter un temps de dump réaliste. Cassez-le ensuite volontairement (mauvais identifiants, hôte injoignable) et vérifiez que l'alerte /fail arrive immédiatement, avant de restaurer discrètement les bons identifiants. C'est tout le filet de sécurité : une sauvegarde qui s'arrête ou se met à échouer ne peut plus se cacher.