• Opération essentielle de sécurisation des données
• Présenter les techniques de sauvegardes disponibles
• Créer une politique de sauvegarde

• Stratégies de sauvegarde et restauration
• Sauvegardes logiques et restauration
• Sauvegardes physiques et restauration
• Scripts de sauvegarde et de restauration

• Choisir les méthodes de sauvegarde les mieux adaptées à son contexte
• Maîtriser la sauvegarde logique (dump/restore)
• Maîtriser la sauvegarde à chaud et le PITR

• Pourquoi établir une politique ?
• Que sauvegarder ?
• À quelle fréquence sauvegarder les données ?
• Quels supports ?
• Quels outils ?
• Vérifier la restauration des sauvegardes

• Sécuriser les données
• Mettre à jour le moteur de données
• Dupliquer une base de données de production
• Archiver les données

• Sauvegarde à froid des fichiers
  • aussi appelée sauvegarde physique
• Sauvegarde à chaud en SQL
  • aussi appelée sauvegarde logique
• Sauvegarde à chaud des fichiers (PITR)

• RPO (Recovery Point Objective)
  • Perte de Données Maximale Admissible
• RTO (Recovery Time Objective)
  • Durée Maximale d'Interruption Admissible
• Définissent la politique de sauvegarde/restauration

• Évaluer les coûts humains et matériels
• Intégrer les méthodes de sauvegardes avec le reste du SI
  • sauvegarde sur bande centrale
  • supervision
  • plan de continuité et de reprise d'activité

• Documenter les éléments clés de la politique :
  • perte de données
  • rétention
  • temps de référence
• Documenter les processus de sauvegarde et restauration
• Imposer des révisions régulières des procédures

• Externaliser les sauvegardes
• Stocker plusieurs copies
  • de préférence dans des endroits différents
• Sauvegarder les fichiers de configuration
• Tester la restauration

• Extraction à chaud des données dans un fichier
• Photo des données au début de l'opération
  • quelle que soit la durée de la sauvegarde
  • restauration à cet état
• Large choix d'options pour sélectionner les données

• Dump
  • pg_dump extrait le contenu d'une base en texte (SQL) ou binaire
  • pg_dumpall extrait une instance en totalité au format texte
• Restore
  • psql exécute le SQL des dumps au format texte
  • pg_restore restaure un dump binaire dans une base

• Restaurations partielles très difficiles avec le format plain (SQL)
• Limite inhérente au format tar POSIX pour les versions antérieures à la 9.5
• Parallélisation du dump seulement possible avec le format directory (9.3+)
• Sauvegarde de la définition des objets globaux seulement possible avec pg_dumpall
• Pas de support des formats binaires par pg_dumpall

=> il faut combiner pg_dump et pg_dumpall pour avoir la sauvegarde la plus flexible.

• -h / $PGHOST / socket Unix
• -p / $PGPORT / 5432
• -U / $PGUSER / utilisateur du système
• -d / $PGDATABASE / utilisateur de connexion
• Gestion des mots de passe
  • pas d'option en ligne de commande
  • $PGPASSWORD
  • .pgpass

• Les outils se comportent comme des clients pour PostgreSQL
• Préférer un rôle super-utilisateur autorisé dans pg_hba.conf
• Dans le cas contraire
  • la connexion à la/aux base(s) de données doit être autorisée
  • le rôle doit pouvoir lire le contenu de tous les objets à exporter

• Base de données : -d ou en fin de commande
• Format : -F (p, t, c, d)
• Fichier de sortie : -f chemin, sortie standard sinon
• Sélection : -a, -s, -n, -N, -t, -T, -O, -x, --section
• Compression : -Z 0-9
• Parallélisme (format directory, 9.3+) : -j jobs

• Limiter le dump aux données globales (rôles et tablespaces) : -g
• Limiter le dump aux rôles : -r
• Limiter le dump aux tablespaces : -t
• Sélection : -a, -s, -O, -x

• Client standard capable d'exécuter du SQL au format texte (plain)
• -f permet de spécifier l'emplacement du fichier dump
• -1 permet d'exécuter la restauration en une transaction
  • -v ON_ERROR_ROLLBACK=ON : faire un rollback en cas d'erreur et continuer la restauration
  • -v ON_ERROR_STOP=ON : arrêter l'exécution à la première erreur (rollback complet)

• Attention : -f indique un fichier de sortie
  • Le dump est indiqué en fin de ligne de commande
  • Entrée standard sinon
• Format : -F (t, c, d), détecté automatiquement
• Sélection : -a, -I, -n, -O, -P, -s, -t, -T, -x, --section
• Transaction : -1

• -d indique la base de données de connexion
• Avec -C (créer la base de données cible)
  • pg_restore se connecte (-d) et exécute CREATE DATABASE
  • pg_restore se connecte à la nouvelle base et exécute le SQL
• Sans -C
  • pg_restore se connecte (-d) et exécute le SQL
• Sans -d
  • pg_restore affiche le SQL (permet de débugger)

• Pour les sélections plus complexes
  • obtenir la table des matières avec -l
  • choisir les éléments à restaurer
  • fournir la liste avec -L liste.txt
• Les dépendances doivent être respectées

• Une sauvegarde à froid impose l'arrêt de l'instance
• Outils système à utiliser pour sauvegarder et restaurer
• L'instance complète doit être sauvegardée :
  • PGDATA
  • tous les tablespaces
  • journaux de transactions (fichiers WAL)
  • fichiers de configuration

• Outils au niveau système de fichiers
• Non spécifiques à PostgreSQL
• Pour réduire la durée d'interruption de service :
  • rsync à chaud, puis rsync à froid
  • snapshots des systèmes de fichiers

• Simple et rapide
• De nombreux outils disponibles
• Efficace pour les fortes volumétries

• Arrêt de la production
• Sauvegarde de l'instance complète à un instant t
• Conservation de la fragmentation
• Impossible de changer d'architecture ou de version

• Sauvegarde en deux parties :
  • les fichiers de données
  • les journaux de transactions archivés
• PostgreSQL archive les journaux de transactions
• L'administrateur réalise une copie des fichiers de données
• Point In Time Recovery : on applique les transactions archivées jusqu'à un point donné

• PostgreSQL écrit les données deux fois :
  • d'abord dans les journaux de transactions (fichiers WAL)
  • puis dans les fichiers de données de manière asynchrone
• En cas d'arrêt brutal, les journaux de transactions sont rejoués sur les fichiers de données
  • il s'agit du mode recovery
  • le rejeu des transactions permet de retourner à l'état cohérent
• Le contrôle du mode recovery permet le PITR

• Choisir le répertoire d'archivage
• Configurer PostgreSQL, dans postgresql.conf :
  • wal_level : replica ou logical
  • archive_mode : on ou always
  • archive_command : texte de la commande
  • archive_timeout : temps en secondes
• Redémarrer l'instance si wal_level et archive_mode ont changé, recharger sinon

• L'archivage doit fonctionner sans erreur
• Se connecter et exécuter SELECT pg_start_backup('label', true);
• Copier l'ensemble des fichiers de l'instance :
  • fichiers de données ($PGDATA) et de configuration
  • tablespaces
• Mais ignorer :
  • fichier postmaster.pid
  • répertoires log, pg_wal, pg_replslot
• Se connecter et exécuter SELECT pg_stop_backup();

• Restaurer les fichiers et répertoires suivants :
  • $PGDATA
  • les tablespaces (mettre à jour $PGDATA/pg_tblspc si nécessaire)
  • fichiers de configuration
• Ne pas restaurer les fichiers suivants :
  • fichiers WAL de l'instance, i.e. $PGDATA/pg_wal (on restaurera les WAL archivés)
  • fichiers postmaster.pid et postmaster.opts
  • traces si elles sont incluses

• PostgreSQL restaure lui-même les WAL archivés au démarrage
• L'instance doit pouvoir accéder aux fichiers WAL archivés
• Créer le fichier $PGDATA/recovery.conf :
  • restore_command
  • recovery target settings : recovery_target_* parameters
  • Standby server settings

• En fin de recovery, la timeline change
  • l'historique des données prend une autre voie
  • le nom des WAL change pour éviter d'écraser des archives suivant le point d'arrêt
  • l'aiguillage est inscrit dans un fichier .history, archivé
• Permet de faire plusieurs restaurations PITR à partir du même basebackup
• recovery_target_timeline permet de choisir la timeline à suivre

• postgresql.conf
  • port
  • listen_addresses
  • data_directory
  • …
• pg_hba.conf

• Sauvegarde sans interruption de service
• Restauration à la transaction près
• Efficace pour les fortes volumétries

• Restauration de l'instance complète
• Conservation de la fragmentation
• Impossible de changer d'architecture ou de version
• Point dans le temps souvent difficile à trouver

• Un script de sauvegarde doit :
  • être testé
  • être documenté
  • gérer la sauvegarde dans son intégralité
  • gérer les cas d'erreur

• Le script de sauvegarde doit au minimum :
  • être commenté
  • être versionné
  • renvoyer un code d'erreur différent de zéro si un problème est survenu
  • permettre de tracer les différentes étapes de la sauvegarde
  • annuler la sauvegarde en cours en cas d'erreur
  • générer des sauvegardes valides (il convient donc de les tester)

• La documentation devrait :
  • détailler l'architecture de sauvegarde
  • expliquer le fonctionnement du script (options, …)
  • ses dépendances (logiciels, points de montage, …)
  • être relue et validée par toute l'équipe
  • permettre de trouver la documentation associée à la restauration

• pg_dumpall -g : définition des rôles et des tablespaces
• pg_dump : contenu de chaque base de données
• Restent la définition des configurations des bases et les ACL…
• Attention aux fichiers de configuration

• Prérequis : configurer l'archivage des WAL
• La commande d'archivage peut être un script
  • dans ce cas, attention à bien tester les codes de retour !
• Utiliser pg_start_backup() et pg_stop_backup()
  • même en cas d'utilisation d'un mécanisme de snapshot (virtualisation, baie…)

• Laisser le temps à pg_start_backup() de terminer avant de démarrer la sauvegarde
• Ne pas oublier de fichiers lors de la copie (tablespaces, …)
• Laisser le temps à pg_stop_backup() de terminer avant de déclarer la sauvegarde valide
• Penser à sauvegarder et référencer les WAL archivés référencés dans le .backup

• Gérer une période de rétention pour les sauvegardes ET les WAL archivés
• attention à bien conserver tous les fichiers WAL archivés nécessaires à la restauration

• Un script de restauration doit :
  • être testé
  • être documenté
  • permettre la restauration intégrale de l'instance
  • détecter et signaler les erreurs rencontrées

• Le script de restauration doit au minimum :
  • être commenté
  • être versionné
  • faire un récapitulatif des actions effectuées et demander validation
  • renvoyer un code d'erreur différent de zéro si un problème est survenu
  • permettre de tracer les différentes étapes de la restauration
  • remettre l'instance dans un état complètement fonctionnel

• La documentation devrait
  • donner succintement et clairement l'usage du script
  • expliquer dans le détail le fonctionnement du script (commandes utilisées, …)
  • détailler les impacts (données écrasées dans un répertoire, …)
  • ses dépendances (logiciels, points de montage, …)
  • être relue et validée par toute l'équipe
  • être facile à trouver dans une version à jour (ne pas l'imprimer !)

• Laisser pg_restore détecter le format des dump binaires
• N'automatiser que les restaurations récurrentes
• Demander des confirmations de façon interactive pour les suppressions de données
• Utiliser les modes verbeux des commandes pour tracer l'exécution

• Utiliser la date et heure de fin pour choisir le basebackup à utiliser
  • le point d'arrêt dans le temps doit être après le point de cohérence
  • on peut utiliser le backup_label archivé pour obtenir le STOP TIME du backup
• Restaurer le répertoire de données et les tablespaces
• Configurer au moins restore_command dans $PGDATA/recovery.conf
• Laisser à l'utilisateur le soin de démarrer l'instance

• Les techniques de sauvegarde de PostgreSQL sont :
  • complémentaires
  • automatisables
• La maîtrise de ces techniques est indispensable pour assurer un service fiable.

• 2 mécanismes de sauvegarde natifs et robustes
• Industrialisation fastidieuse
• Des outils existent !!

• Présentation:
  • pg_back
  • pg_basebackup
  • Barman
  • pitrery
• Comment choisir ?

• Sauvegarde locale (ex. NFS) ?
• Copie vers un serveur tiers (push) ?
• Sauvegarde distante initiée depuis un serveur tiers (pull) ?
• Ressources à disposition ?
• Accès SSH ?
• OS ?
• Sauvegardes physiques ? Logiques ?
• Version de PostgreSQL ?
• Politique de rétention ?

• Type de sauvegardes: logiques (pg_dump)
• Langage: bash
• Licence: BSD (libre)
• Type de stockage: local
• Planification: crontab
• OS: Unix/Linux
• Compression: gzip
• Versions compatibles: toutes
• Rétention: durée en jour

• Outil intégré à PostgreSQL
• Prévu pour créer une instance secondaire
• Permet les sauvegardes PITR

• plain
  • arborescence identique à l'instance sauvegardée
• tar
  • archive, permet la compression

• Sauvegarde possible à partir d'un secondaire
• Transfert des WAL pendant la sauvegarde
• Débit configurable
• Relocalisation des tablespaces
• Écriture d'un recovery.conf
  • prévu pour la réplication

• Configuration de type réplication nécessaire
• Pas de configuration de l'archivage
• Pas d'association WAL archivés / sauvegarde
• Pas de gestion de la restauration
• Pas de politique de rétention

• 2ndQuadrant IT
• Langage: python 2.6/2.7
• OS: Unix/Linux
• Versions compatibles: >= 8.3
• License: GPL3 (libre)
• Type d'interface: CLI (ligne de commande)

• Type de sauvegardes: physiques/PITR (à chaud)
• Type de stockage: local ou pull (rsync/ssh)
• Planification: crontab
• Méthode: pg_start_backup() / rsync / pg_stop_backup()
• Incrémentales: rsync + hardlink
• Compression des WAL

• Limitation du débit réseau lors des transferts
• Compression des données lors des transferts via le réseau
• Sauvegardes concurrentes via l'extension pgespresso
  • sans l'extension à partir de PostgreSQL 9.6
• Hook pre/post sauvegarde
• Hook pre/post archivage WAL
• Compression WAL : gzip, bzip2, pigz, pbzip2, etc..
• Pas de compression des données (sauf WAL)

• Durée (jour/semaine)
• Nombre de sauvegardes

• Locale ou à distance
• Point dans le temps: date, identifiant de transaction, timeline ou point de restauration

• Accéder au dépôt communautaire PGDG
• Installer le paquet barman

usage: barman [-h] [-v] [-c CONFIG] [-q] [-d] [-f {console}]
              {cron,list-server,show-server,status,check,diagnose,
              backup,list-backup,how-backup,list-files,recover,
              delete,rebuild-xlogdb}
[...]
optional arguments:
  -h, --help     show this help message and exit
  -v, --version  show program's version number and exit
  -c CONFIG, --config CONFIG
                 uses a configuration file (...)
  -q, --quiet    be quiet (default: False)
  -d, --debug    debug output (default: False)
  -f {console}, --format {console}
                 output format (default: console)

• /etc/barman.conf
• Format INI
• Configuration générale dans la section [barman]
• Chaque instance à sauvegarder doit avoir sa propre section
• Un fichier de configuration par instance via la directive:

configuration_files_directory = /etc/barman.d

• Utilisateur système barman

• Utilisateur postgres pour les serveurs PostgreSQL
• Utilisateur barman pour le serveur de sauvegardes
• Générer les clefs SSH (RSA) des utilisateurs système postgres (serveurs PG) et barman (serveur barman)
• Échanger les clefs SSH public entre les serveurs PostgreSQL et le serveur de sauvegarde
• Établir manuellement une première connexion SSH entre chaque machine

• Adapter la configuration de l'archivage dans le fichier postgresql.conf :

wal_level = 'replica'
archive_mode = on
archive_command = 'rsync -a %p barman@bkpsrv:<INCOMING_WALS_DIR>/%f'

• Fichier barman.conf
• Section [barman] pour la configuration globale

[barman]
barman_home = /var/lib/barman
barman_user = barman
log_file = /var/log/barman/barman.log
log_level = INFO
configuration_files_directory = /etc/barman.d

• Configuration globale des options de sauvegarde

compression = gzip
reuse_backup = link
immediate_checkpoint = false
basebackup_retry_times = 0
basebackup_retry_sleep = 30
backup_options = exclusive_backup

• Possibilité de réduire la bande passante
• Et de compresser le trafic réseau
• Exemple

bandwidth_limit = 4000
network_compression = false

• Configuration de la rétention en nombre de sauvegardes
• Et en « fenêtre de restauration », en jours, semaines ou mois
• Déclenchement d'une erreur en cas de sauvegarde trop ancienne
• Exemple

minimum_redundancy = 5
retention_policy = RECOVERY WINDOW OF 7 DAYS
last_backup_maximum_age = 2 DAYS

• Lancer des scripts avant ou après les sauvegardes
• Et avant ou après le traitement du WAL archivé par Barman
• Exemple

pre_backup_script = ...
post_backup_script = ...
pre_archive_script = ...
post_archive_script = ...

• configuration_files_directory
  • un fichier de configuration par instance
• Ou une section par instance

• Section spécifique par instance
• Permet d'adapter la configuration aux différentes instances
• Exemple

[pgsrv]
description = "PostgreSQL Instance pgsrv"
ssh_command = ssh postgres@pgsrv
conninfo = host=pgsrv user=postgres dbname=postgres
backup_directory =
basebackup_directory =
wals_directory =
incoming_wals_directory =

• La commande show-server montre la configuration

$ sudo -u barman barman show-server {<instance> | all}

• La commande check effectue des tests pour la valider

$ sudo -u barman barman check {<instance> | all}

• La commande status affiche des informations détaillées
  • sur la configuration Barman
  • sur l'instance spécifiée
• Exemple

$ sudo -u barman barman status {<instance> | all}

• La commande diagnose renvoie
  • les informations renvoyées par la commande status
  • des informations supplémentaires (sur le système par exemple)
  • au format json
• Exemple

$ sudo -u barman barman diagnose

• Pour déclencher une nouvelle sauvegarde

$ sudo -u barman barman backup {<instance> | all}

• Le détail de sauvegarde effectuée est affiché en sortie

• Pour lister les sauvegardes existantes

$ sudo -u barman barman list-backup {<instance> | all}

• Affiche notamment la taille de la sauvegarde et des WAL associés

• show-backup affiche le détail d'une sauvegarde (taille...)

$ sudo -u barman barman show-backup <instance> <ID-sauvegarde>

• list-files affiche le détail des fichiers d'une sauvegarde

$ sudo -u barman barman list-files <instance> <ID-sauvegarde>

• Pour supprimer manuellement une sauvegarde

$ sudo -u barman barman delete <instance> <ID-sauvegarde>

• Renvoie une erreur si la redondance minimale ne le permet pas

• La commande Barman cron déclenche la maintenance
  • récupération des WAL archivés
  • compression
  • politique de rétention
• Exemple

$ sudo -u barman barman cron

• À planifier pour une exécution régulière
  • par exemple avec la crontab Linux

• Copie/transfert de la sauvegarde
• Copie/transfert des journaux de transactions
• Génération du fichier recovery.conf
• Copie/transfert des fichiers de configuration

• Locale ou à distance
• Cibles : timeline, date, ID de transaction ou point de restauration
• Déplacement des tablespaces

• Exemple d'une restauration
  • déclenchée depuis le serveur Barman
  • avec un point dans le temps spécifié

$ sudo -u barman barman recover                   \
    --remote-ssh-command "ssh postgres@pgsrv"     \
    --target-time "2015-09-02 14:15:00"           \
    pgsrv 20150902T095027 /var/lib/pgsql/9.4/main

• R&D Dalibo
• Langage : bash
• OS : Unix/Linux
• Versions compatibles : >= 8.2
• License : BSD (libre)
• Type d'interface : CLI (ligne de commande)

• Type de sauvegarde : physiques/PITR
• Type de stockage : locale ou distant (push) via rsync/ssh
• Planification : crontab
• Méthodes : pg_start_backup() / rsync ou tar / pg_stop_backup()
• Compression : gzip, bzip2, pigz, pbzip2, etc.
• Compression des WAL
• Scripts pre/post sauvegarde (hooks)
• Déduplication de fichier (rsync + lien matériel)

• Durée (en jours)
• Nombre de sauvegardes

• À partir des données locales ou distantes
• Point dans le temps : date

• Téléchargement depuis le site du projet
  • installation depuis les sources (tarball)
  • paquets RPM et DEB disponibles

usage: pitrery [options] action [args]
options:
    -c file      Path to the configuration file
    -n           Show the command instead of executing it
    -V           Display the version and exit
    -?           Print help

actions:
    list
    backup
    restore
    purge

• Adapter l'archivage dans le fichier postgresql.conf

archive_mode = on
wal_level = replica
archive_command = '/usr/local/bin/archive_xlog %p'

• Stockage des sauvegardes sur un serveur distant
• Générer les clefs SSH (RSA) des utilisateurs système postgres sur chacun des serveurs (nœud PG et serveur de sauvegarde)
• Échanger les clefs SSH publiques entre les serveurs PostgreSQL et le serveur de sauvegarde
• Établir manuellement une première connexion SSH entre chaque serveur

• Emplacement par défaut: /usr/local/etc/pitrery/pitr.conf
• Possibilité de spécifier un autre emplacement

• Options de connexion à l'instance

PGPSQL="psql"
PGUSER="postgres"
PGPORT=5432
PGHOST="/var/run/postgresql"
PGDATABASE="postgres"

• Configurer les emplacements
• Pour l'instance à sauvegarder

PGDATA="/var/lib/pgsql/9.4/data"
PGXLOG=

• Pour la destination des sauvegardes

BACKUP_DIR="/var/lib/pitrery"

• Pour la destination des WAL archivés

ARCHIVE_DIR="$BACKUP_DIR/archived_xlog"

• Paramètre de configuration STORAGE
• Deux modes possibles :
  • tar : sauvegarde complète, éventuellement compressée
  • rsync : sauvegarde complète ou différentielle, pas de compression

• Configuration de la rétention en nombre de sauvegardes

PURGE_KEEP_COUNT=3

• Ou en jours

PURGE_OLDER_THAN=7

• Les deux paramètres peuvent être combinés

• L'archivage peut être configuré pour :
  • archiver en local (montage NFS...)
  • archiver vers un serveur distant en SSH
• Exemple

ARCHIVE_LOCAL="no"
ARCHIVE_HOST=bkpsrv
ARCHIVE_USER=pitrery
ARCHIVE_COMPRESS="yes"

• Utilisé par la commande archive_xlog

• Configuration de la compression
  • des WAL archivés par la commande archive_xlog
  • des sauvegardes effectuées au format tar
• Exemple

COMPRESS_BIN=
COMPRESS_SUFFIX=
UNCOMPRESS_BIN=
BACKUP_COMPRESS_BIN=
BACKUP_COMPRESS_SUFFIX=
BACKUP_UNCOMPRESS_BIN=

• Activer l'horodatage des traces

LOG_TIMESTAMP="yes"

• Utiliser syslog pour les traces de l'archivage (archive_xlog)

SYSLOG="no"
SYSLOG_FACILITY="local0"
SYSLOG_IDENT="postgres"

• Exécuter un script avant ou après une sauvegarde

PRE_BACKUP_COMMAND=
POST_BACKUP_COMMAND=

• Pour déclencher une nouvelle sauvegarde

$ sudo -u postgres /usr/local/bin/pitrery backup

• La plupart des paramètres peuvent être surchargés
• Par exemple, l'option -s permet de spécifier un mode, tar ou rsync

• Suppression des sauvegardes et archives ne satisfaisant plus la politique de sauvegarde

$ sudo -u postgres /usr/local/bin/pitrery purge

• À déclencher systématiquement après une sauvegarde

• Lister les sauvegardes présentes et leur taille

$ sudo -u postgres /usr/local/bin/pitrery list

• L'option -v permet d'avoir plus de détails
  • mode de sauvegarde
  • date minimale utilisable pour la restauration
  • taille de chaque tablespace

• Pas de planificateur intégré
  • le plus simple est d'utiliser cron
• Exemple

00 00 * * * (   /usr/local/bin/pitrery backup                  \
             && /usr/local/bin/pitrery purge)                  \
  >> /var/log/postgresql/pitrery-$(date +\%Y-\%m-\%d).log 2>&1

• Effectuer une restauration

$ sudo -u postgres /usr/local/bin/pitrery restore

• Nombreuses options à la restauration, notamment
  • l'option -D permet de modifier la cible du PGDATA
  • l'option -t permet de modifier la cible d'un tablespace
  • l'option -x permet de modifier la cible du pg_wal
  • l'option -d permet de spécifier une date de restauration

• De nombreux autres outils existent
• Moins importants que les précédents
  • répondant à des problématiques plus spécifiques
  • parfois anciens et potentiellement obsolètes
  • ou très récents et pas encore stables

• Gestion de sauvegardes logiques
• Fonctionnalités limités
• Développement arrêté

• Simplifie la réplication Warm Standby
• Membre de la suite Skytools
• Permet la gestion de sauvegardes PITR
  • manque de fonctionnalités
  • développement arrêté

• Gestion de sauvegardes PITR
• Focus sur le stockage en cloud
• Possibilités de restauration limitées
  • pas de génération du recovery.conf
  • pas de re-création des liens vers les tablespaces

• Gestion de sauvegardes PITR
• Développé par NTT
• Peu de documentation
• Peu d'exemples d'utilisation connus

• Gestion de l'archivage et du basebackup
• Mise en place de réplication par log-shipping
• Outil obsolète :
  • gestion du log-shipping en interne depuis PostgreSQL 9.0 (2010)
  • pas de génération de recovery.conf

• Gestion de sauvegardes PITR
• Indépendant des commandes système
  • utilise un protocole dédié
• Sauvegardes complètes, différentielles ou incrémentales
• Gestion du multi-thread
• Projet récent (2014), non stabilisé

• Des outils pour vous aider!
• Pratiquer, pratiquer et pratiquer
• Superviser les sauvegardes!

• Une bonne politique de sauvegardes est cruciale
  • mais elle n'empêche pas les incidents
• Il faut être prêt à y faire face

• Anticiper les désastres
• Réagir aux désastres
• Rechercher l'origine du problème
• Outils utiles
• Cas type de désastres

• Un désastre peut toujours survenir
• Il faut savoir le détecter le plus tôt possible
  • et s'être préparé à y répondre

• Documentation complète et à jour
  • emplacement et fréquence des sauvegardes
  • emplacement des traces
  • procédures et scripts d'exploitation
• Sauvegarder et versionner la documentation

• Procédures détaillées de restauration / PRA
  • préparer des scripts / utiliser des outils
  • minimiser le nombre d'actions manuelles
• Tester les procédures régulièrement
  • s'assurer que chacun les maîtrise
• Sauvegarder et versionner les scripts

• Tout doit être supervisé
  • réseau, matériel, système, logiciels…
  • les niveaux d'alerte doivent être significatifs
• Les métriques importantes doivent être historisées
  • cela permet de retrouver le moment où le problème est apparu
  • quand cela a un sens, faire des graphes

• Des outils existent
  • Pacemaker, repmgr…
• Automatiser une bascule est complexe
• Cela peut mener à davantage d'incidents
  • voire à des désastres importants (split brain)

• Savoir identifier un problème majeur
• Bons réflexes
• Mauvais réflexes

• Crash de l'instance
• Résultats de requêtes erronnés
• Messages d'erreurs dans les traces
• Dégradation importante des temps d'exécution
• Processus manquants
  • ou en court d'exécution depuis trop longtemps

• Garder la tête froide
• Répartir les tâches clairement
• Minimiser les canaux de communication
• Garder des notes de chaque action entreprise

• Se prémunir contre une aggravation du problème
  • couper les accès applicatifs
• Si une corruption est suspectée
  • arrêter immédiatement l'instance
  • faire une sauvegarde immédiate des fichiers
  • travailler sur une copie

• Déterminer le moment de démarrage du désastre
• Adopter une vision générale plutôt que focalisée sur un détail
• Remettre en cause chaque élément de l'architecture
  • aussi stable (et/ou coûteux/complexe) soit-il
• Éliminer en priorité les causes possibles côté hardware, système
• Isoler le comportement précis du problème
  • identifier les requêtes / tables / index impliqués

• En cas de défaillance matérielle, s'assurer de travailler sur du hardware sain et non affecté !!!

• Communiquer, ne pas rester isolé
• Demander de l'aide si le problème est trop complexe
  • autres équipes
  • support
  • forums
  • listes

• Dérouler les procédures comme prévu
• En cas de situation non prévue, s'arrêter pour faire le point
  • ne pas hésiter à remettre en cause l'analyse
  • ou la procédure elle-même

• En cas de bug avéré
  • tenter de le cerner et de le reproduire au mieux
  • le signaler à la communauté de préférence en détaillant le moyen de le reproduire

• Tester complètement l'intégrité des données
  • pour détecter tous les problèmes
  • pour valider après restauration / correction

• Paniquer
• Prendre une décision hâtive
  • exemple, supprimer des fichiers du répertoire pg_wal
• Lancer une commande sans la comprendre
  • exemple, pg_resetwal

• Arrêter le diagnostic quand les symptômes disparaissent
• Ne pas pousser l'analyse jusqu'au bout

• Ne pas documenter
  • le résultat de l'investigation
  • les actions effectuées

• Quelques pistes de recherche pour cerner le problème
• Liste non exhaustive

• Avant de commencer à creuser
  • référencer les symptômes
  • identifier au mieux l'instant de démarrage du problème

• Ces symptômes ont-ils déjà été rencontrés dans le passé ?
• Ces symptômes ont-ils déjà été rencontrés par d'autres ?
• Attention à ne pas prendre les informations trouvées pour argent comptant !

• Vérifier le système disque (SAN, carte RAID, disques)
• Rechercher toute erreur matérielle
• Firmwares pas à jour
  • ou récemment mis à jour
• Matériel récemment changé

• Problèmes de mutualisation des ressources
• Configuration du stockage virtualisé
• Rechercher toute erreur sur l'hôte / la console d'administration
• Mises à jour non appliquées
  • ou appliquées récemment
• Modifications de configuration récentes

• Erreurs dans les traces
• Mises à jour système non appliquées
• Modifications de configuration récentes

• Opération d'IO impossible
  • FS plein ?
  • FS monté en lecture seule ?
• Tester l'écriture sur PGDATA
• Tester la lecture sur PGDATA

• Consommation excessive des ressources
  • OOM killer
• Après un crash, vérifier les processus actifs
  • ne pas tenter de redémarrer si des processus persistent

• Relever les erreurs dans les traces
  • ou messages inhabituels
• Vérifier les mises à jour mineures

• La désactivation de certains paramètres est dangereuse
  • fsync
  • full_page_write

• Option --data-checksums de initdb
• Disponible depuis PostgreSQL 9.3
• Détecte les corruptions silencieuses
  • au prix d'un impact sur les performances

• Traces système, traces PostgreSQL
• Revue des dernières manipulations effectuées
• Historique des commandes

• Quelques outils peuvent aider
  • à diagnostiquer la nature du problème
  • à valider la correction apportée
  • à appliquer un contournement
• ATTENTION
  • certains de ces outils peuvent corrompre les données !

• Fournit des informations de contrôle sur l'instance
• Ne nécessite pas que l'instance soit démarrée

• pg_dump
• pg_dumpall
• COPY
• psql / pg_restore

• Extension
• Vision du contenu d'un bloc
• Sans le dictionnaire, donc sans décodage des données
• Affichage brut
• Utilisé surtout en debug, ou dans les cas de corruption
• Fonctions de décodage pour heap (table), bt (btree), entête de page, et FSM
• Nécessite de connaître le code de PostgreSQL

• Efface les WAL courants
• Permet à l'instance de démarrer en cas de corruption d'un WAL
  • comme si elle était dans un état cohérent
  • ce qui n'est pas le cas
• Cet outil est dangereux !!!
• Utiliser cet outil va corrompre des données

• Les cas suivants sont assez rares
• Ils nécessitent généralement une restauration
• Certaines manipulations à haut risque sont possibles
  • mais complètement déconseillées !

• Privilégier une solution fiable (restauration, bascule)
• Les actions listées ici sont destructives
• La plupart peuvent (et vont) provoquer des incohérences
• Travailler sur une copie

• Messages d'erreur lors des accès par l'index
• Données différentes entre un indexscan et un seqscan
• Supprimer et recréer l'index (REINDEX)

• Cas plus problématique
• Restauration probablement nécessaire

• Le paramètre zero_damaged_pages peut aider
• Des données vont certainement être perdues

• Si la corruption est importante, l'accès au bloc peut faire crasher l'instance
• Il est tout de même possible de réinitialiser le bloc
  • identifier le fichier à l'aide de pg_relation_filepath()
  • trouver le bloc avec ctid / pageinspect
  • réinitialiser le bloc avec dd
  • il faut vraiment ne pas avoir d'autre choix

• Situés dans le répertoire pg_wal
• Les WAL sont nécessaires au recovery
• Démarrage impossible s'ils sont corrompus ou manquants
• Si les fichiers WAL ont été archivés, les récupérer
• Sinon, la restauration est la seule solution viable

• pg_resetwal permet de forcer le démarrage
• ATTENTION !!!
  • cela va provoquer des pertes de données
  • des corruptions de données sont également probables
  • ce n'est pas une action corrective !

• Fichier global/pg_control
• Contient les informations liées au dernier checkpoint
• Sans lui, l'instance ne peut pas démarrer
• Restauration nécessaire

• Fichier contenu dans pg_xact
• Statut des différentes transactions
• Son altération risque de causer des incohérences

• Le catalogue contient la définition du schéma
• Sans lui, les données sont inaccessibles
• Situation très délicate

• Les désastres peuvent arriver
• Il faut s'y être préparé
• Faites des sauvegardes !
  • et testez les