Meilleure méthode pour la sauvegarde incrémentale PostgreSQL
J'utilise actuellement pg_dump canalisé vers gzip canalisé vers split. Mais le problème est que tous les fichiers de sortie sont toujours modifiés. Donc, la sauvegarde basée sur la somme de contrôle copie toujours toutes les données.
Existe-t-il d'autres bons moyens d'effectuer une sauvegarde incrémentielle D'une base de données PostgreSQL, où une base de données complète peut être restaurée à partir des données de sauvegarde?
Par exemple, si pg_dump pouvait tout Ordonner absolument, donc toutes les modifications ne sont appliquées qu'à la fin du vidage, ou similaire.
3 réponses
Mise À Jour: consultez Barman pour un moyen plus facile de configurer l'archivage WAL pour la sauvegarde.
Vous pouvez utiliser la méthode d'archivage Wal continu de PostgreSQL . Vous devez d'abord définir wal_level=archive, puis effectuer une sauvegarde complète au niveau du système de fichiers (entre les commandes pg_start_backup() et pg_stop_backup()), puis copier simplement sur les nouveaux fichiers WAL en configurant l'option archive_command.
Avantages:
- incrémentielle, les archives WAL comprennent tout le nécessaire pour restaurer le courant état de la base de données
- presque pas de frais généraux, copier des fichiers WAL est bon marché
- Vous pouvez restaurer la base de données à n'importe quel point dans le temps (cette fonctionnalité est appelée PITR, ou point-in-time recovery)
Inconvénients:
- Plus compliqué à mettre en place que pg_dump
- la sauvegarde complète sera beaucoup plus grande qu'un pg_dump car toutes les structures et index de table internes sont inclus
- ne fonctionne pas bien pour les bases de données lourdes en écriture, car la récupération prendra beaucoup de temps.
Il existe des outils tels que pitrtools et omnipitr qui peuvent simplifier la configuration et la restauration de ces configurations. Mais je ne les ai pas utilisés moi-même.
Consultez Également http://www.pgbackrest.org
PgBackrest est un autre outil de sauvegarde pour PostgreSQL que vous devriez évaluer car il prend en charge:
- sauvegarde parallèle (testée pour évoluer presque linéairement jusqu'à 32 cœurs mais peut probablement aller beaucoup plus loin..)
- sauvegardes compressées au repos
- incrémental et différentiel (comprimé! les sauvegardes
- compression en streaming (les données ne sont compressées qu'une seule fois à la source, puis transférées sur le réseau et stocké)
- parallel, delta restore (possibilité de mettre à jour une ancienne copie vers la dernière version)
- prend entièrement en charge les tablespaces
- rotation de sauvegarde et expiration de l'archive
- possibilité de reprendre les sauvegardes qui ont échoué pour une raison quelconque
- etc, etc..
Une autre méthode consiste à sauvegarder en texte brut et à utiliser rdiff pour créer des diffs incrémentiels.