J'ai réfléchi à ce que vous avez écrit et voici quelques idées pour vous :
- Si vous avez besoin d'une sauvegarde qui sera vraiment cohérente à un moment donné, vous devez utiliser pg_basebackup ou pg_barman (utilise en interne pg_basebackup) - l'explication est dans le lien 1. ci-dessous. Le dernier pg_basebackup 10 diffuse les journaux WAL afin que vous sauvegardiez également toutes les modifications effectuées pendant la sauvegarde. Bien sûr, cette sauvegarde ne prend que l'intégralité de l'instance PG. Par contre il ne verrouille aucune table. Et si vous le faites à partir d'une instance distante, cela ne cause qu'une petite charge CPU sur l'instance PG et les E/S du disque ne sont pas aussi importantes que certains textes le suggèrent. Voir les liens 4 sur mes expériences. La restauration est assez simple - voir lien 5.
- Si vous utilisez pg_dump, vous devez comprendre que vous n'avez aucune garantie que votre sauvegarde est vraiment cohérente à ce moment-là - voir à nouveau le lien 1. Il est possible d'utiliser un instantané de la base de données (voir les liens 2 et 3) mais même avec cela, vous ne pouvez pas compter sur une cohérence à 100%. Nous avons utilisé pg_dump uniquement sur notre base de données analytique qui ne charge de nouvelles qu'une fois par jour (les partitions d'hier de la base de données de production). Vous pouvez l'accélérer avec l'option parallèle (fonctionne uniquement pour le format de sauvegarde de répertoire). Mais l'inconvénient est une charge beaucoup plus élevée sur l'instance PG - une utilisation plus élevée du processeur, des E/S disque beaucoup plus élevées. Même si vous exécutez pg_dump à distance - dans ce cas, vous enregistrez uniquement les E/S du disque pour enregistrer les fichiers de sauvegarde. De plus, pg_dump doit placer un verrou en lecture sur les tables afin qu'il puisse être lié soit avec de nouvelles insertions, soit avec une réplication (lorsqu'il est pris sur une réplique). Mais lorsque votre base de données atteint des centaines de Go, même le vidage parallèle peut prendre des heures et à ce moment-là, vous devrez de toute façon passer à pg_basebackup.
- pg_barman est une "version confortable" de pg_basebackup + il vous permet d'éviter la perte de données même lorsque votre instance PG plante très mal. Le faire fonctionner nécessite plus de changements, mais cela en vaut vraiment la peine. Vous devrez définir l'archivage des journaux WAL (voir lien 6) et si votre PG est <10, vous devrez définir "max_wal_senders" et "max_replication_slots" (dont vous avez besoin pour la réplication de toute façon) - tout est dans le manuel pg-barman bien que la description n'est pas vraiment génial. pg_barman diffusera et stockera les enregistrements WAL même entre les sauvegardes afin que vous puissiez être sûr que la perte de données en cas de très grave crash sera presque nulle. Mais le faire fonctionner peut prendre de nombreuses heures car les descriptions ne sont pas vraiment bonnes. pg-barman effectue à la fois la sauvegarde et la restauration avec ses commandes.
Votre base de données fait 5 Go, donc toute méthode de sauvegarde sera rapide. Mais vous devez décider si vous avez besoin d'une récupération ponctuelle et d'une perte de données presque nulle ou non - donc si vous allez investir du temps pour configurer pg-barman ou non.
Liens :
- PostgreSQL, sauvegardes et tout vous devez savoir
- Revue pour le papier :14-Serializable Isolation d'instantané dans PostgreSQL - sur les instantanés
- Dumping parallèle de bases de données - exemple d'utilisation de l'instantané
- expériences pg_basebackup
- pg_basebackup - restaurer la sauvegarde tar
- Archivage des journaux WAL à l'aide d'un script
