Reprise d’Activité PostgreSQL : Sauvegardes Automatisées vers S3

1. Pourquoi les sauvegardes locales sont insuffisantes

Un pg_dump écrit dans un fichier sur le même VPS que la base de données qu’il sauvegarde protège contre exactement un seul mode de défaillance : la suppression accidentelle d’une table. Il ne protège contre rien d’autre qui cause réellement une perte de données en pratique — panne disque, hôte compromis où un attaquant efface à la fois la base et sa « sauvegarde » situé sur le même volume, un rm -rf accidentel pendant une maintenance, ou l’hébergeur qui perd purement et simplement l’instance. Si votre sauvegarde vit dans le même domaine de défaillance que vos données primaires, ce n’est pas une sauvegarde, c’est une seconde copie du même point de défaillance unique.

La règle du 3-2-1 existe précisément pour cette raison : au moins trois copies de vos données, sur deux types de support de stockage différents, avec au moins une copie stockée hors site. Pour une base de données de production maintenue en solo, un minimum pratique est la base en production elle-même, une sauvegarde locale sur le VPS pour une récupération rapide en cas d’erreur simple, et une copie chiffrée expédiée vers un stockage objet (S3, Backblaze B2, ou équivalent) chez un fournisseur et dans une région différents du VPS lui-même. C’est la copie hors site qui vous sauve réellement lorsque le fournisseur du VPS subit une panne régionale ou que votre compte se retrouve bloqué.

La fréquence de sauvegarde doit être dictée par votre objectif de point de récupération réel (RPO) — la quantité de perte de données acceptable — pas par la commodité. Un pg_dump nocturne vous donne un RPO pouvant aller jusqu’à 24 heures, ce qui convient pour un blog ou un portfolio à faible volume d’écriture, et devient totalement inacceptable pour une application transactionnelle traitant des paiements ou du contenu généré par les utilisateurs en continu. Au-delà d’un projet personnel à faible trafic, l’archivage continu du WAL (via un outil comme WAL-G ou pgBackRest), qui expédie les segments de write-ahead log au fur et à mesure de leur génération, ramène le RPO à quelques minutes plutôt qu’à une journée entière.

2. Script de sauvegarde quotidienne avec chiffrement

Une sauvegarde logique via pg_dump -Fc (format custom) constitue le bon point de départ pour la plupart des bases de production de petite à moyenne taille : elle est portable entre versions mineures de PostgreSQL, prend en charge la restauration sélective de tables, et se compresse bien. Redirigez le dump directement à travers gpg pour le chiffrement avant qu’il ne touche le disque sous forme non chiffrée, afin qu’une destination de sauvegarde compromise ne livre pas l’intégralité de vos données en clair à un attaquant, et utilisez une passphrase symétrique (ou mieux, une paire de clés GPG dédiée) stockée comme secret en dehors du script de sauvegarde lui-même.

Nommer les sauvegardes avec un horodatage et les téléverser immédiatement vers le stockage objet, plutôt que de les accumuler localement d’abord, minimise la fenêtre durant laquelle une sauvegarde n’existe que sur le même hôte que la base qu’elle protège. L’AWS CLI (ou un client compatible S3 pour d’autres fournisseurs) gère le téléversement ; encapsulez toute la séquence dans un script déclenché par un timer systemd ou une tâche cron, avec une gestion d’erreurs explicite pour qu’un dump ou un upload échoué soit bruyant plutôt que silencieux.