pgdossier
2.54.0:
pgBackRest est une solution de sauvegarde et de restauration fiable pour PostgreSQL qui s'adapte de manière transparente aux bases de données et charges de travail les plus volumineuses.
pgBackRest v2.54.0 est la version stable actuelle. Les notes de version se trouvent sur la page Versions.
Retrouvez-nous sur GitHub et donnez-nous une étoile si vous aimez pgBackRest !
La compression est généralement le goulot d'étranglement lors des opérations de sauvegarde, c'est pourquoi pgBackRest résout ce problème avec un traitement parallèle et des algorithmes de compression plus efficaces tels que lz4 et zstd.
Un protocole personnalisé permet à pgBackRest de sauvegarder, restaurer et archiver localement ou à distance via TLS/SSH avec une configuration minimale. Une interface pour interroger PostgreSQL est également fournie via la couche protocole afin qu'un accès à distance à PostgreSQL ne soit jamais requis, ce qui améliore la sécurité.
Plusieurs référentiels permettent, par exemple, un référentiel local avec une rétention minimale pour des restaurations rapides et un référentiel distant avec une rétention plus longue pour la redondance et l'accès dans toute l'entreprise.
Les sauvegardes complètes, différentielles et incrémentielles sont prises en charge. pgBackRest n'est pas sensible aux problèmes de résolution temporelle de rsync, ce qui rend les sauvegardes différentielles et incrémentielles sécurisées sans avoir besoin de vérifier la somme de contrôle de chaque fichier. Les sauvegardes au niveau des blocs économisent de l'espace en copiant uniquement les parties des fichiers qui ont été modifiées.
Des politiques de conservation peuvent être définies pour des sauvegardes complètes et différentielles afin de créer une couverture pour n'importe quelle période. L'archive WAL peut être conservée pour toutes les sauvegardes ou strictement pour les sauvegardes les plus récentes. Dans ce dernier cas, les WAL nécessaires à la cohérence des anciennes sauvegardes seront conservés dans l'archive.
Les sommes de contrôle sont calculées pour chaque fichier de la sauvegarde et revérifiées lors d'une restauration ou d'une vérification. Une fois qu'une sauvegarde a fini de copier les fichiers, elle attend que chaque segment WAL requis pour rendre la sauvegarde cohérente atteigne le référentiel.
Les sauvegardes dans le référentiel peuvent être stockées dans le même format qu'un cluster PostgreSQL standard (y compris les tablespaces). Si la compression est désactivée et que les liens physiques sont activés, il est possible de créer un instantané d'une sauvegarde dans le référentiel et d'afficher un cluster PostgreSQL directement sur l'instantané. Ceci est avantageux pour les bases de données à l’échelle du téraoctet dont la restauration de manière traditionnelle prend beaucoup de temps.
Toutes les opérations utilisent fsync au niveau des fichiers et des répertoires pour garantir la durabilité.
Si les sommes de contrôle des pages sont activées, pgBackRest validera les sommes de contrôle pour chaque fichier copié lors d'une sauvegarde. Toutes les sommes de contrôle des pages sont validées lors d'une sauvegarde complète et les sommes de contrôle des fichiers modifiés sont validées lors des sauvegardes différentielles et incrémentielles.
Les échecs de validation n'arrêtent pas le processus de sauvegarde, mais des avertissements indiquant exactement quelles pages ont échoué à la validation sont affichés dans la console et dans le journal des fichiers.
Cette fonctionnalité permet de détecter précocement la corruption au niveau de la page, avant l'expiration des sauvegardes contenant des copies valides des données.
Une sauvegarde interrompue peut être reprise à partir du point où elle a été arrêtée. Les fichiers déjà copiés sont comparés aux sommes de contrôle du manifeste pour garantir leur intégrité. Étant donné que cette opération peut avoir lieu entièrement sur l'hôte du référentiel, elle réduit la charge sur l'hôte PostgreSQL et permet de gagner du temps puisque le calcul de la somme de contrôle est plus rapide que la compression et la retransmission des données.
Les calculs de compression et de somme de contrôle sont effectués en flux pendant que les fichiers sont copiés dans le référentiel, que le référentiel soit situé localement ou à distance.
Si le référentiel se trouve sur un hôte du référentiel, la compression est effectuée sur l'hôte PostgreSQL et les fichiers sont transmis dans un format compressé et simplement stockés sur l'hôte du référentiel. Lorsque la compression est désactivée, un niveau de compression inférieur est utilisé pour utiliser efficacement la bande passante disponible tout en maintenant le coût du processeur au minimum.
Le manifeste contient des sommes de contrôle pour chaque fichier de la sauvegarde, de sorte que lors d'une restauration, il est possible d'utiliser ces sommes de contrôle pour accélérer considérablement le traitement. Lors d'une restauration delta, tous les fichiers non présents dans la sauvegarde sont d'abord supprimés, puis des sommes de contrôle sont générées pour les fichiers restants. Les fichiers correspondant à la sauvegarde sont laissés en place et le reste des fichiers est restauré comme d'habitude. Le traitement parallèle peut conduire à une réduction considérable des temps de restauration.
Des commandes dédiées sont incluses pour pousser WAL vers l'archive et obtenir WAL à partir de l'archive. Les deux commandes prennent en charge le parallélisme pour accélérer le traitement et s'exécutent de manière asynchrone pour fournir le temps de réponse le plus rapide possible à PostgreSQL.
WAL push détecte automatiquement les segments WAL qui sont poussés plusieurs fois et les duplique lorsque le segment est identique, sinon une erreur est générée. Le push WAL asynchrone permet de décharger le transfert vers un autre processus qui compresse les segments WAL en parallèle pour un débit maximal. Cela peut s'avérer une fonctionnalité essentielle pour les bases de données avec un volume d'écriture extrêmement élevé.
L'obtention asynchrone des WAL maintient une file d'attente locale de segments WAL qui sont décompressés et prêts à être rejoués. Cela réduit le temps nécessaire pour fournir les WAL à PostgreSQL, ce qui maximise la vitesse de relecture. Les connexions et le stockage à latence plus élevée (comme S3) en bénéficient le plus.
Les commandes push et get garantissent toutes deux que la base de données et le référentiel correspondent en comparant les versions de PostgreSQL et les identifiants système. Cela élimine pratiquement la possibilité d'une mauvaise configuration de l'emplacement de l'archive WAL.
Les tablespaces sont entièrement pris en charge et, lors de la restauration, ils peuvent être remappés à n'importe quel emplacement. Il est également possible de remapper tous les tablespaces vers un seul emplacement avec une seule commande, ce qui est utile pour les restaurations de développement.
Les liens de fichiers et de répertoires sont pris en charge pour tout fichier ou répertoire du cluster PostgreSQL. Lors de la restauration, il est possible de restaurer tous les liens vers leurs emplacements d'origine, de remapper tout ou partie des liens, ou de restaurer tout ou partie des liens sous forme de fichiers ou de répertoires normaux dans le répertoire du cluster.
Les référentiels pgBackRest peuvent être situés dans des magasins d'objets compatibles S3, Azure et GCS pour permettre une capacité et une rétention pratiquement illimitées.
pgBackRest peut chiffrer le référentiel pour sécuriser les sauvegardes où qu'elles soient stockées.
pgBackRest inclut la prise en charge de dix versions de PostgreSQL, des cinq versions prises en charge et des cinq dernières versions d'EOL. Cela laisse suffisamment de temps pour passer à une version prise en charge.
pgBackRest s'efforce d'être facile à configurer et à utiliser :
Guides d'utilisation pour différents systèmes d'exploitation et versions de PostgreSQL.
Référence de commande pour les opérations de ligne de commande.
Référence de configuration pour créer des configurations pgBackRest.
La documentation pour la v1 peut être trouvée ici. Aucune autre version n'est prévue pour la v1 car la v2 est rétrocompatible avec les options et les référentiels v1.
Les contributions à pgBackRest sont toujours les bienvenues ! Veuillez consulter nos directives de contribution pour plus de détails sur la manière de contribuer à des fonctionnalités, des améliorations ou des problèmes.
pgBackRest est entièrement gratuit et open source sous licence MIT. Vous pouvez l'utiliser à des fins personnelles ou commerciales sans aucune restriction. Les rapports de bogues sont pris très au sérieux et seront traités le plus rapidement possible.
Créer une politique robuste de reprise après sinistre avec des stratégies de réplication et de sauvegarde appropriées peut être une tâche très complexe et ardue. Vous constaterez peut-être que vous avez besoin d'aide pendant la phase d'architecture et d'un support continu pour garantir le bon fonctionnement de votre entreprise.
Crunchy Data fournit des versions packagées de pgBackRest pour les principaux systèmes d'exploitation et un support commercial expert sur tout le cycle de vie de pgBackRest et de tout ce qui concerne PostgreSQL. Crunchy Data s'engage à fournir des solutions open source sans dépendance à un fournisseur, garantissant que la compatibilité croisée avec la version communautaire de pgBackRest est toujours strictement maintenue.
Veuillez visiter Crunchy Data pour plus d’informations.
La première reconnaissance revient à Stephen Frost pour tous ses précieux conseils et critiques lors du développement de pgBackRest.
Crunchy Data a consacré beaucoup de temps et de ressources à pgBackRest et continue de soutenir activement le développement. Resonate a également contribué au développement de pgBackRest et a permis l'installation de versions antérieures (mais bien testées) comme solution de sauvegarde PostgreSQL principale.
Graphique de fauteuil par Sandor Szabo.
