Aller au contenu

Sauvegarde d’un serveur PostgreSQL

PostgreSQL propose plusieurs solutions de sauvegarde à froid et à chaud, logique ou physique, ainsi que des méthodes de restauration partielle ou complète.

Définir une politique de sauvegarde

Quels objectifs ?

  1. Sécuriser les données : Restaurer les bases en cas de problème.
  2. Mettre à jour le moteur de données : Sauvegarder avant migration ou changement de version.
  3. Dupliquer une base de production : Exporter vers un serveur de développement.
  4. Archivage : Conserver les données pour des périodes légales.

Que doit-on sauvegarder ?

Options possibles : - Une ou plusieurs tables - Une ou plusieurs bases de données - L’ensemble des bases du cluster - L’ensemble des fichiers du cluster PostgreSQL

À quelle fréquence sauvegarder ?

Dépend du volume et de la criticité des données : - Serveur de développement : Sauvegarde hebdomadaire - Données critiques : Sauvegarde à chaud sans perte - Compromis : Sauvegarde journalière et archivage mensuel

Quels supports de stockage ?

Options : - Serveur tiers - Disque NFS ou dédié - Bandes magnétiques - Supports non réinscriptibles (CD, DVD)

Remarque : Ne pas laisser les sauvegardes sur le même serveur que la base de données !

Quels outils ?

Approches possibles : - Sauvegarde logique : crée un fichier texte ou binaire avec des commandes SQL. - Sauvegarde physique : crée une copie cohérente des répertoires de données. - à froid, la cohérence est assurée car l’instance est arrêtée - à chaud, la cohérence est assurée grâce au reujeu des archives de journaux de transactions

Mise en place des sauvegardes

Commandes de sauvegarde

Utiliser pg_dumpall pour sauvegarder toutes les bases de l’instance :

pg_dumpall > dump.sql
pg_dumpall | gzip > dump.sql.gz

Automatiser avec un script Bash :

#!/bin/bash
SERVER_NAME="Sylvraint"
DEST_DIR="/var/backups/postgresql"
DATE=`date "+%d-%m-%y"`
DEST_FILE="$DEST_DIR/$SERVER_NAME.$DATE.dump.sql.gz"
su postgres -c "pg_dumpall | gzip > $DEST_FILE"

Programmer l’exécution avec cron :

01 00 * * * root /usr/local/postgresql/dump_all.sh

Exports des données

  • Archivage sur support non-réinscriptible : En cas de panne informatique générale il est intéressant de s’intéresser à la sauvegarde sur bandes perforées. Il est toutefois possible de graver les sauvegardes sur des CD / DVD mais avec le défaut que le CD ou DVD se détériore avec le temps. La sauvegarde sur bandes est quand même celle à privilégier.
  • Archivage sur un serveur tiers : Envoyer via rsync :
rsync -raz --delete /var/backups/postgresql 192.168.252.201::sauvegarde_sylvraint/

Rotation des sauvegardes

Conserver un mois de sauvegardes quotidiennes et programmer un script de nettoyage avec cron :

01 00 01 * * root /usr/local/postgresql/rotate_pgbackups.py

Restaurer les données

Décompresser le fichier dump et utiliser psql pour réinjecter les données :

gunzip -c Sylvraint.15-05-07.dump.sql.gz | psql

Maintenance : Utiliser VACUUM ANALYZE ou vacuumdb -a -z pour optimiser la base après restauration.

Sauvegarde physique à chaud

Principe

PostgreSQL utilise des journaux WAL pour enregistrer chaque modification. L’archivage de ces journaux permet de reconstruire une base à partir d’une sauvegarde récente.

Avantages

  • Pas d’interruption de service
  • Correction des incohérences par ré-exécution des journaux
  • Réduction de la perte de données avec PITR (Point In Time Recovery)

Limitations

  • Ne permet pas de restaurer un sous-ensemble de données
  • Nécessite un grand espace de stockage

Bonnes pratiques

Surveiller l’espace disque

Vérifier que les fichiers de sauvegardes ne saturent pas le système, notamment la partition /var.

Ne pas modifier le répertoire des fichiers dump

Éviter de changer les noms ou de décompresser les fichiers dans le répertoire de sauvegarde.

Vérifier la procédure de restauration

Tester régulièrement la procédure de restauration pour s’assurer de son bon fonctionnement.

Conclusion

Une politique de sauvegarde bien établie doit être stable et régulièrement testée pour garantir la sécurité des données. Les changements de politique peuvent être nécessaires en cas d’augmentation du volume de données ou de renforcement des mesures de sécurité.