EC2 - Comment sauvegarder correctement les données PostgreSQL?

Voici la configuration: 1 petite instance Amazon Linux (soutenue par EBS) EC2 avec 3 volumes supplémentaires. Il s'agit à la fois d'un serveur Web et d'un serveur de base de données. Un volume pour le code, un pour le répertoire de données PostgreSQL (8.4) et un volume pour stocker les fichiers WAL de PostgreSQL.

(1) Le volume avec les fichiers WAL aura également une sauvegarde de base du répertoire de données, qui est copiée après avoir fait un pg_start_backup (). Ensuite, il stockera la sortie d'archive continue de PostgreSQL (fichiers WAL). Pour prendre un instantané de ce volume, est-il utile d'émettre une synchronisation et de geler le système de fichiers (en utilisant xfs_freeze s'il s'agit de XFS ou dmsetup s'il s'agit d'EXT4)? Ou puis-je simplement prendre un instantané en direct? Les fichiers WAL seront expédiés à raison de un par minute. Est-il possible qu'un instantané puisse être lancé alors qu'un seul fichier WAL est copié et entraîne des données corrompues?

(2) Le volume contenant le répertoire de données PostgreSQL en direct sera également sauvegardé pour faire bonne mesure (quotidiennement). Avant de faire un instantané de ce volume, j'émets un pg_dump et le fichier SQL résultant est conservé dans le répertoire de données. Est-il utile de prendre des précautions pour garantir la cohérence des données réelles de la base de données? Serait-il correct de supposer que la prise d'un instantané en direct (a) sauvegardera correctement les fichiers de configuration (postgresql.conf, pg_hba.conf, pg_ident.conf) et (b) sauvegardera le fichier de vidage SQL. La sauvegarde de ces deux choses, le fichier de vidage sql et les fichiers de configuration, serait le principal point de capture instantanée de ce volume. La base de données n'est pas très grande, donc cela ne me dérange pas que les fichiers de données gonflent cet instantané. Et dans ce cas, je peux juste faire un instantané en direct - correct?

(2a) Serait-il préférable de conserver le répertoire de données sur le volume racine et d'avoir un script de sauvegarde qui copie le fichier de vidage sql ainsi que des fichiers de configuration sur un autre volume, et de prendre un instantané de ce volume une fois la copie terminée?

(3) En ce qui concerne le volume avec du code, est-il encore utile de synchroniser et de figer le système de fichiers? Ou peut-on simplement prendre un instantané en direct? Ces données doivent être assez "statiques".

(4) S'agit-il d'un solide système de sauvegarde? Le volume racine n'est pas sauvegardé régulièrement, car je ne conserverai qu'une image de machine après son installation et sa configuration.

Merci

Voir le beau manuel . Si mes conseils sont en contradiction avec les siennes, c'est vrai.

1. Une synchronisation n'est pas une mauvaise idée, sauf si votre outil de copie fsync () s chaque fichier WAL qu'il écrit et le répertoire dans lequel il se trouve avant de copier le suivant. Un dernier fichier WAL incomplet n'a pas beaucoup d'importance; au pire, vous venez de le supprimer. Pg s'étouffe généralement sur un WAL incomplet - bien qu'il n'y ait pas de somme de contrôle, vous pouvez doncêtre vraiment malchanceux et le faire essayer d'appliquer des données d'ordures qui, par pure folie, se sont avérées ressembler à de vrais enregistrements WAL. À votre place, je synchroniserais le volume avant un instantané pour vous assurer que les tampons sales non écrits dans la RAM atteignent l'image du système de fichiers sur le disque. Un gel aiderait à éviter les WAL mal écrits mais non fatals partiellement écrits, donc ce n'est pas une idée terrible mais pas vitale. Ce qui est vital, c'est d'avoir une chronologie en bon état jusqu'au point de récupération. Personnellement, j'écris mes WAL dans un nom de fichier temporaire et je ne les renomme leur nom final qu'une fois entièrement copié; si vous faites cela, vous n'avez pas besoin de geler.

2. Cela semble correct. Un instantané en direct, c'est comme faire un test d'extraction de plug sur un système en direct avec une mise en cache en écriture. Votre base de données devrait récupérer correctement lors de la restauration à partir d'un instantané en direct, comme après le plug-pull. Je vous recommande d'automatiser les tests de restauration à partir d'instantanés. (Remarque: Un test de restauration d'instantané n'est pas un substitut complet au test d'extraction de plug-in car il ne tient pas compte du cache possible du disque, du contrôleur de raid, etc. en écriture). Non seulement les fichiers de configuration et le vidage, mais la base de données elle-même devrait être bien après votre instantané. Pensez à synchroniser le volume avant l'instantané pour vous assurer que toutes les données de vidage, etc., ont réellement atteint le disque.
   
   2a. Pourrait économiser de l'espace disque. Petite différence sinon. Vous pourrez conserver les instantanés beaucoup plus longtemps sans tout le taux de désabonnement de la base de données en direct sur eux.

3. Pourquoi même prendre un instantané du volume de votre code? Une copie simple au niveau du fichier peut très bien convenir. Un instantané en direct devrait certainement l'être.

4. Ce n'est pas un schéma de sauvegarde solide. Il échoue dans un domaine critique: aucun test de restauration ni validation n'est en cours. Vous devez toujours tester vos sauvegardes régulièrement pour vous assurer que vous pouvez vraiment les restaurer.

   Personnellement, je vous recommande l' utilisation d' expedition WAL, ou envoyer des décharges de base de données, à un autre hôte , de préférence pas sur Amazon EC2 ou au moins dans une autre région. Cet hôte doit effectuer des tests de restauration automatisés, vous envoyer des rapports sur les résultats et doit également être vérifié manuellement.

   Bien que vos instantanés (contenant des vidages) soient sur S3 et y soient en sécurité, cela ne signifie pas qu'ils seront accessibles lorsque vous en aurez besoin de toute urgence. Les affirmations d'Amazon sur la durabilité sont rassurantes, mais vos données peuvent toujours être sûres et totalement inaccessibles pour vous lors d'une panne mal synchronisée du service S3.