Donc je me suis décidé à mettre en place ce fameux système de sauvegarde que je voulais tant mettre sur pied. Je commencerai par le tour de l'"ancienne" manière de faire avant de parler de la nouvelle installation et survoler rapidement comment ça s'est passé. L'installation en détail fera peut-être l'objet d'un autre article. Sur ce, prenez un peu de popcorn, mettez-vous bien et bonne lecture :)

L'"ancienne" manière de faire: pg_dump

L'ancienne manière de faire était de faire des dump toutes les heures. Donc le serveur qui conserve les sauvegarde faisait tourner ses disques toutes les heures et un gros dump SQL par base est fait avant d'être archivé à coup de Borg. Une méthode certes un peu naïve mais qui fonctionnait bien. Ensuite, j'ai changé de format et je suis passé au format tar. Et enfin au format custom, un fichier par base.

Pour palier le "problème" des disques qui doivent tourner toutes les heures pour accueillir l'archive de Borg, j'ai espacé l'archivage à une fois par jour.

Au passage, un dump de tout le serveur est aussi mis dans les archives.

Quelques inconvénients

Cette méthode présente quand même quelques inconvénients si on y réfléchit un peu. Toutes les bases du serveur sont relues du début à la fin, donc on risque d'évicter des données un peu plus utiles du cache du SGBDR (Système de Gestion de Bases de Données Relationnelles, a.k.a. PostgreSQL) et du cache en RAM du kernel.

Dépendant de la fréquence de sauvegarde, je fais mouliner les disques du NAS qui doivent sortir de veille. Détail mineur mais qui peut avoir son importance. Lié à la fréquence de sauvegarde est la perte potentielle de données que je peux avoir si le SGBDR décide de rendre l'âme. En effet, plus la dernière sauvegarde est "distante" dans le temps, plus la perte peut être importante si je décide de prendre la sauvegarde la plus récente pour opérer une restauration. C'est loin d'être idéal surtout quand une base bouge beaucoup (coucou Synapse).

Cette méthode de faire fonctionne très bien même si elle n'est pas le plus top. Je pense qu'elle convient pour des bases qui bougent pas beaucoup ou pour ceux qui n'ont pas besoin d'avoir les données jusqu'au moment T.

Le barman de PostgreSQL, pgBarman

Jeu de mots moisi, bonjour !

Barman approche la problématique des sauvegardes du serveur en passant sur une autre couche: la structure physique. PostgreSQL, quand il a fini d'écrire dans un WAL et de le traiter, le recycle. On peut lui demander d'exécuter un programme qui se chargera de l'archiver avant qu'il recycle le fichier. Dans mon installation, j'ai choisi de prendre l'envoi des WALs (Write Ahead Log) via rsync vers le serveur avec Barman.

Déduplication et hardlinks

Une autre fonctionnalité intéressante est la déduplication des sauvegardes de bases de données. C'est très pratique lorsqu'on sauvegarde des grosses bases qui changent peu en structure. Barman propose la déduplication à l'aide de hardlinks. Les hardlinks, dans le contexte d'un système de fichiers, font référence à des liens vers un même inode, un même identifiant de fichier. Concrètement, vous avez bien deux fichiers distincts dans les dossiers mais ils pointent au même endroit. Déééééémonstration !

$ ls -li
total 2097156
4428075 -rw-r--r-- 2 l4p1n l4p1n 1073741824 16 fév 21:06 fichier1.zero
4428075 -rw-r--r-- 2 l4p1n l4p1n 1073741824 16 fév 21:06 fichier_hardlink.zero
4428104 lrwxrwxrwx 1 l4p1n l4p1n         13 16 fév 21:07 fichier_symlink.zero -> fichier1.zero

$ du -h *
1.0G    fichier1.zero
4.0K    fichier_symlink.zero

La première colonne représente l'inode du fichier, la 6ème la taille dudit fichier. On peut constater que les fichiers fichier1.zero et fichier_hardlink.zero ont le même inode et pointent physiquement vers le même fichier. Petite parenthèse, on remarquera que le nombre de références, la 3ème colonne, est à deux parce que le fichier physique a deux liens rattachés à lui. C'est pour cela qu'on ne peut pas faire de hardlinks entre systèmes de fichiers. Par contre, on voit bien que fichier_symlink.zero a un inode différent en plus d'être un fichier de type "lien symbolique".

En ce qui concerne la taille réellement prise, du -h * montre bien que seul 1 GB est pris sur le disque, donc le fichier est effectivement dédupliqué. Si un des deux fichiers venait à être supprimé, le fichier persisterait encore dans le système de fichiers puisqu'un lien y pointe encore.

Installation

L'installation s'est faite assez facilement si on ne prend pas en compte la mise en place d'un tunnel SSH pour accéder au serveur PostgreSQL. Je suis assez frileux à l'idée d'exposer un port de serveur de bases à tout Internet. Il a donc fallu faire un tunnel SSH entre le serveur de sauvegarde et le serveur du SGBDR. Sinon rien de spécial, suivre les indications du manuel a suffi à mettre en place ce système de sauvegarde.