netbackup¶

Mise en place de l’intégration des sauvegardes PITR avec netbackup¶

Ce document a pour but de mettre en place une intégration entre l’outil de sauvegardes netbackup, et le mécanisme de sauvegarde PITR (Point-In-Time Recovery) de PostgreSQL.

Prérequis:

installation et configuration de netbackup
configuration de l’archivage des journaux de transactions sur le serveur PostgreSQL.

Principe¶

Les binaires PostgreSQL sont sauvegardés avec la politique de sécurité standard des systèmes Unix. Cette politique génère une sauvegarde de l’intégralité (/) des systèmes de fichiers d’un serveur.

Une exclusion doit être ajoutée pour exclure les répertoires de données PostgreSQL. Cela correspond au répertoire $PGDATA et autres tablespaces de la sauvegarde totale de ces systèmes. Ceux-ci seront pris en charge par une police spécifique (ici nommée PolicePG). Celle-ci définira des scripts spécifiques exécutés au démarrage et à la fin du backup.

De même, une exclusion doit être ajoutée pour le répertoire de stockage des journaux de transactions.

Une autre police spécifique sera chargée de sauvegarder les journaux de transactions archivés, ici nommée PolicePGXlog. Celle-ci sera éxécutée juste après la police PolicePG.

Activation du `Hot-Backup`¶

Au niveau de NetBackup, l’activation du mode on-line backup peut être exécutée par un script de “pre-backup”. NetBackup, comme la plupart des systèmes de sauvegarde, offre la possibilité d’exécuter un script sur le système à exécuter avant le démarrage de la sauvegarde proprement dite. Du code retour de ce script dépend la suite des opérations. Si le code retour du script retourne une valeur différente de 0 la sauvegarde est annulée et un message d’erreur est remonté sur la console d’administration de NetBackup.

Le script de pre-backup exécuté sur le serveur à sauvegarder doit se nommer bpstart_notify et avoir comme extension le nom de la police de sauvegarde, par exemple:

/user/openv/netbackup/bin/bpstart_notify.PolicePG

Voici le contenu du script :

#!/bin/sh
#---------------------------------------------------------------
# Script execute lors du demarrage de la sauvegarde Netbackup.
# Le code de retour d'execution du script est recupere par
# Netbackup : 0 = success, autre = failure.
# Aucun parametre n'est utilisés dans le script.
#
# Exemple de parametres : NOM_SERVEUR Nom_Police FULL FULL
#---------------------------------------------------------------

PGUSER=postgres

PGSERVER=$1
POLICYNAME=$2
SCHEDNAME=$3
SCHEDTYPE=$4

#echo "file: $1 $2 $3 $4">/tmp/bkupdebug.log

/bin/su - $PGUSER -c "psql -c \"SELECT pg_start_backup('PostgreSQL Full Backup');\""
if [ $? -ne 0 ]; then
        echo "FATAL: impossible de lancer la sauvegarde de PostgreSQL"
        exit 1
fi

exit 0

Ce script doit impérativement être exécutable dans le répertoire /usr/openv/netbackup/bin/, à noter aussi qu’il est exécuté en tant que root, il faut donc utiliser la commande /bin/su pour passer les commandes à PostgreSQL.

Sous Unix, extrait de la documentation NetBackup, les paramètres passés au script par NetBackup sont les suivants :

clientname : Name of the client from the NetBackup catalog ;
policyname : Policy name from the NetBackup catalog ;
schedname : Schedule name from the NetBackup catalog ;
schedtype : One of the following: FULL, INCR (differential incremental), CINC (cumulative incremental),UBAK, UARC.

Aucun de ces paramètres n’est utile pour l’instant dans le script, ils ne sont donc pas utilisés.

Sauvegarde du système de fichiers¶

Une fois le mode on-line backup activé, il faut procéder à la sauvegarde totale des systèmes de fichiers contenant les binaires, la configuration PostgreSQL, le PGDATA et tous les tablespaces utilisés que ce soit pour les données ou les index.

Fin du `Hot-Backup`¶

Si la sauvegarde s’est correctement déroulée, NetBackup va exécuter le script de post-backup sur le serveur à sauvegarder. Il doit se nommer bpend_notify et avoir comme extension le nom de la police de sauvegarde, ici :

/usr/openv/netbackup/bin/bpend_notify.PolicePG

#!/bin/sh
#---------------------------------------------------------------
# Script execute lors de l'arret de la sauvegarde Netbackup.
# Le code de retour d'execution du script est recupere par
# Netbackup : 0 = success, autre = failure.
# Aucun parametre n'est utilises dans le script.
#
# Exemple de parametres : NOM_SERVEUR Nom_Police Full FULL 0
#
# En fin de script la retention des fichiers archives est limité
# a MAX_TIME
#---------------------------------------------------------------


PGUSER=postgres
ARCHIVE_DIR=/chemin/vers/stockage/des/journaux/transactions/
MAX_TIME=6

PGSERVER=$1
POLICYNAME=$2
SCHEDNAME=$3
SCHEDTYPE=$4
CLIENTRESULT=$5

/bin/su - $PGUSER -c "psql -c \"SELECT pg_stop_backup();\""
if [ $? -ne 0 ]; then
        echo "FATAL: impossible d'arreter la sauvegarde de PostgreSQL"
        exit 1
fi

# Suppression des fichiers archive > MAX_TIME jours
/usr/bin/find $ARCHIVE_DIR -name '*' -mtime +$MAX_TIME | /usr/bin/xargs -i /bin/rm -f {}

exit 0

Sous Unix, extrait de la documentation NetBackup, les paramètres passés au script par NetBackup sont les suivants :

clientname : Name of the client from the NetBackup catalog ;
policyname : Policy name from the NetBackup catalog ;
schedname : Schedule name from the NetBackup catalog ;
schedtype : One of the following: FULL, INCR (differential incremental), CINC (cumulative incremental),UBAK, UARC ;
existstatus: Exit code from bpbkar. The status is the client status and does not indicate that the backup is complete and successful. The client can display a status 0 when, due to a failure on the server, the All Log Entries report displays a status 84.

Aucun de ces paramètres n’est utile pour l’instant dans le script, ils ne sont donc pas utilisés.

Ce script doit impérativement être exécutable dans le répertoire /usr/openv/netbackup/bin/. Il est exécuté en tant que root, il faut donc utiliser la commande /bin/su pour passer les commandes à PostgreSQL.

Sauvegarde des archives¶

Durant toute la sauvegarde à chaud des systèmes de fichiers, PostgreSQL a continué à générer des archives de journaux de transactions. Ces archives sont indispensables à la restauration de la sauvegarde qui vient d’être réalisée.

C’est pour cela qu’il faut aussi procéder à la sauvegarde totale immédiate du dossier contenant les journaux de transactions archivés. Il est impératif que cette sauvegarde se fasse juste après la politique de sauvegarde de l’instance PostgreSQL.

Pour ne pas multiplier les politiques de sauvegarde il est possible de sauvegarder cette partie avec la sauvegarde complète du système, mais dans ce cas il faut s’assurer que cette politique est exécutée juste après celle de PostgreSQL. Dans le cas contraire, les sauvegardes ne pourront être restaurées.

Dans le cadre d’une sauvegarde incrémentale, c’est aussi ce système de fichiers des journaux de transactions archivés qui doit être sauvegardé. Ce type de sauvegarde consiste à réaliser des sauvegardes de ces archives entre deux sauvegardes totales. Cela permet de réintégrer les transactions archivées sur la sauvegarde totale précédente qui vient d’être restaurée.

Par exemple, si les sauvegardes totales sont réalisées toutes les semaines, les sauvegardes incrémentales du dossier des journaux de transactions archivés pourront être faites tous les jours. Ainsi l’instance PostgreSQL pourra être restaurée à n’importe quel moment entre la sauvegarde totale et la dernière sauvegarde incrémentale.

Maintenance / monitoring¶

Comme les archives ne sont pas éliminées par PostgreSQL au fur et à mesure des sauvegardes, il faut veiller à la purge des archives antérieures à 7 jours, ou moins en fonction de la place disponible pour leur rétention. Ceci est réalisé dans le script post_backup.

L’espace disque doit particulièrement être surveillé. Le nombre de journaux de transactions archivés dépend de l’activité sur la base de données. Cet espace disque peut facilement être rempli lors d’un chargement en masse d’une base de données.

Un autre problème rencontré lors des tests de mise en œuvre est que NetBackup ne vérifie pas le code retour du script de post-backup. Si ce script rencontre un problème, il renvoit alors une valeur différente de 0 et ce cas n’est malheureusement pas traité par le système de sauvegarde. Ce problème empêche la remontée d’une alarme au niveau de la console d’administration.

Ceci est d’autant plus gênant si le pg_stop_backup() a échoué, cela signifie que la prochaine fois que la sauvegarde sera lancée, elle échouera. Lors de l’exécution du pg_start_backup(), PostgreSQL détecte qu’il est toujours en mode on-line backup et renvoit une erreur. Certes à ce moment là une alarme sera remontée sur la console d’administration NetBackup mais la sauvegarde sera abandonnée.

Il est donc conseillé de vérifier régulièrement que le mode on-line backup est désactivé. Pour cela, il faut tester la présence du fichier backup_label du répertoire $PGDATA et remonter une alarme s’il est trouvé après qu’une sauvegarde totale soit terminée.

Pour remettre l’instance PostgreSQL en mode normal, il suffit alors simplement d’exécuter le script de post-backup, ou de se connecter sur une base de l’instance en tant qu’utilisateur postgres et d’exécuter la commande :

SELECT pg_stop_backup();