Vous n'êtes pas identifié(e).
Bonjour
Peut-on restaurer une ou plusieurs bases de données postgresql à partir d'un snapshot de la VM à chaud ?
Merci
Hors ligne
Bonjour,
Je l'ai personnellement déjà fait sur des instances de test et ça fonctionne.
Par contre il n'y a aucune garanti sur l'intégrité des données.
Je déconseille donc fortement ce genre de sauvegarde en production.
Cordialement,
Sébastien.
Hors ligne
Comme il n'y a aucune garantie de la cohérence des donées, dans le cadre d'un PRA, faut il privilégier les snapshots de VM ou les sauvegardes cotés bases ?
Hors ligne
sans hésitation : côtés bases.
Et pour un PRA : sauvegarde à chaud (voir même réplication streaming si le site du PRA est dispo en permanence).
Cordialement,
Sébastien.
Hors ligne
Un snapshot à chaud de la VM est une sauvegarde acceptable, mais il est impossible de ne restaurer que quelques bases. C'est forcément la totalité. SI vous avez besoin de granularité (ne restaurer qu'une base ou qu'une table), la seule solution est pg_dump pour la sauvegarde et pg_restore pour la restauration.
Guillaume.
Hors ligne
Bonjour
Je ne sais pas si dans votre cas c'est possible, mais chez nous le snapshot commence par lancer un de nos outils pour passer l'instance en "start backup", et à la fin du snapshot, le "stop backup" est lancé.
Ensuite lorsque l'on doit repartir sur un snapshot, on rentre dans le cas d'une restauration PITR. Certes nécessitant la création d'un recovery.conf, donc une action manuelle pour redémarrer, mais jusqu'à aujourd'hui tous nos tests ont été concluant sur le sujet.
Hors ligne
Bonjour,
Effectivement, dans le cas de petites bases avec peu de transaction, il y a des chances que ça marche. En faisant un start_backup, puis un stop_backup, vous augmentez les chances que ça se passe bien (mais assurez-vous de bien archiver vos WAL ailleurs). Dès que vous atteindrez un certain volume et un certain nombre de transactions, vos sauvegardes ne vaudront plus rien.
En tant que DBA, je ne prendrai jamais le risque de reposer sur de la chance pour mes sauvegardes.
Donc, mise en place de l'archivage continu et sauvegardes physiques régulières des bases avec l'outil prévu pour ça (barman ou backrest, mais il y en a d'autres).
À vous de voir quels sont vos objectifs de perte de données maximale admissible et durée maximale d'interruption admissible.
Cordialement,
Arkhena
Hors ligne
Je suis surpris de cette réponse: "petites bases et peu de transactions, il y a des chances que ça marche." !!!
Si on fait le start_backup, la sauvegarde, le stop_backup et que l'on sauvegarde l'ensemble des WAL générés pendant la sauvegarde, on doit pouvoir dans tous les cas restaurer l'instance, NON ? Je dirais même que quand on a beaucoup de volume, ce type de sauvegardes est tout de même bien plus rapide et tout à fait valide, je me trompe ?
Merci pour vos réponses sur le sujet.
Philippe
Hors ligne
Pour faire la restauration des bases à partir du snapshot de la VM à chaud, les étapes seraient donc :
- restauration de la VM sur un environnement
- Arret de l'instance sur le nouvel environnement
- copie du cluster du nouvel environnement + fichier de configuration
- arret de l'instance sur l'ancien environnement
-renommer l'ancien cluster si on a de la place
- coller le cluster du nouvel environnement
-redémarrer l'instance
Est ce que cela parait correcte ?
Merci d'avance
Hors ligne
En passant par un nouvel environnement:
_ Restauration de la VM sur le nouvel environnement
_ L'instance ne va normalement pas démarrer, il est nécessaire de créer le fichier recovery.conf qui va bien et de la lancer.
_ Lui mettre à disposition les WAL qu'elle demande (Si la sauvegarde est complète, ces WAL seront dedans).
_ Une fois opérationnelle, la stopper
_ Stopper l'ancienne instance, sauvegarder les données si possible (Sauf si pas de place, mais je ne drop jamais de fichier en situation de restauration)
_ Recopier la grappe de données du nouvel environnement sur l'ancien environnement
_ Relancer sur l'ancien environnement
En espérant ne rien avoir oublié.
Philippe
Hors ligne
Ça me laisse très dubitatif comme solution si je puis me permettre.
Car que ce passe t'il si le serveur d'origine est HS ?
On n'a pas les derniers wal et du coup on perd les derniers transactions.
En fait tout dépend de votre contrat de service (temps pour relancer l'appli sur un PRA, possibilité de perte de données, etc...)
Cordialement,
Sébastien.
Hors ligne
Si le serveur est HS, la restauration se fait avec le jeu de données au moment de la sauvegarde (comme pour un pg_dump !!), d'où l'importance de ne pas rater de WAL lors de la sauvegarde. Il faut le nécessaire pour remettre l'instance en service.
Si on veut aller plus loin, et retrouver le jeu de données au moment du crash, il est impératif que tous les WAL archivés le soit sur un serveur distant. Sinon c'est effectivement impossible.
Par contre j'aimerai bien avoir ton avis (expérience) sur la façon de faire les sauvegardes sur des instances gros volumes avec un taux de transactions importants et surtout sur des instances que l'on ne peut stopper.
Merci
Hors ligne
Bonjour,
Personnellement sur de gros volumes je préconise :
- une sauvegarde à chaud complète (fichiers de données, archives, etc...) une fois par semaine (par exemple le dimanche).
- tous les autres jours de la semaine (plusieurs fois par jour si beaucoup de transactions) : sauvegardes des archives seulement.
Les sauvegardes sont stockées en dehors du serveur (baie de stockage ou autre).
avantage : sauvegarde rapide en semaine.
inconvénient : récupération plus longue en cas de restauration lors d'un crash.
Il y aussi la solution de la réplication (en streaming) en complément de la sauvegarde pour pouvoir faire une bascule rapide en cas de crash du serveur master.
Et encore au dessus il y a toutes les solutions de haute dispo (PAF, pgpool, slony, etc...).
Bref dans le monde postgresql il y a plein de solutions internes, donc à mon sens pas besoin d'utiliser des solutions externes comme le snapshot de VM. PostgreSQL fait très bien ce travail lui-même.
Cordialement,
Sébastien.
Hors ligne
Pour votre sauvegarde de fichiers, cela me semble tout à fait correct. Le seul bémol, c'est les journaux de transactions. Vous dites : "Lui mettre à disposition les WAL qu'elle demande (Si la sauvegarde est complète, ces WAL seront dedans)." Si je comprends, vous sauvegardez tous les fichiers dont le répertoire pg_xlog. Si c'est bien le cas, ça ne peut pas fonctionner. Vous devez passer par le système d'archivage de PostgreSQL (en plus de la sauvegarde des fichiers).
Guillaume.
Hors ligne
Tout à fait gleu, je ne sauvegarde pas pg_xlog mais je sauvegarde les WAL du répertoire d'archive des WAL géré par Postgresql. Pour cela, j'utilise le fichier *backup de pg_xlog pour identifier les WAL archivés a embarquer avec la sauvegarde.
Dans le cas particulier des sauvegardes par snapshots sur VM, où c'est une image disque qui est fait par le système, cela implique que l'ensemble des WAL du répertoire d'archive sont inclus dans le snapshot, ce qui n'est forcement pas problématique.
Philippe
Hors ligne
Dans ce cas, pas de soucis 
Guillaume.
Hors ligne
Je suis surpris de cette réponse: "petites bases et peu de transactions, il y a des chances que ça marche." !!!
Si on fait le start_backup, la sauvegarde, le stop_backup et que l'on sauvegarde l'ensemble des WAL générés pendant la sauvegarde, on doit pouvoir dans tous les cas restaurer l'instance, NON ? Je dirais même que quand on a beaucoup de volume, ce type de sauvegardes est tout de même bien plus rapide et tout à fait valide, je me trompe ?
Merci pour vos réponses sur le sujet.
Philippe
Effectivement, mais je n'avais pas compris que vous sauvegardiez aussi les WALs...
Par contre, j'ai toujours tendance à préférer utiliser les outils standards éprouvés plutôt que de reposer sur des sur-couches technologiques que je maîtrise moins. Donc barman, backrest ou wal-e... Mais ce n'est que ma vision des choses et la votre peut être valable aussi.
Pour revenir sur la discussion, il manque à mon sens deux informations vitales pour savoir quel type de sauvegarde mettre en place:
- Quelle est la durée maximale d'interruption admissible ?
- Combien de temps dure votre opération de restauration ?
Sans ces informations, nous ne pouvons que faire des spéculations...
Cordialement,
Arkhena
Hors ligne
Bonjour à tous,
Avec intérêt, j'ai suivi tout cette discussion.
Ma question était :
Peut-on restaurer une instance postgresql à partir d'un snapshot (système) de la VM à chaud ? Si oui comment ?
Merci
Hors ligne
Sans les journaux de transactions archivés, non, ce n'est pas possible.
Guillaume.
Hors ligne
Bonjour à tous, je me greffe à la discutions car j'ai le même problème à résoudre.
Nous souhaitons faire des sauvegardes à chaud de nos instances via snapshoot VMWAre.
J'ai trouvé une solution : Script pg_start_backup --> Snap VMWare VMDK 0 « OS + Instance pgs » script pg_stop_backup --> Snap VMWare VMDK 1 « WAL Archivés » --> purge des journaux générés avant pg_start_backup
J'ai ainsi décorrélé la sauvegarde des data et des journaux ce qui me permet en théorie de pouvoir, en restaurant mes 2 VMDK de ma VM, lancer un recovery de la base "propre" puisqu'il aura les WAL générés après le pg_stop_backup.
En pratique, ça fonctionne sauf que ... lorsque que je redémarre ma VM, l'instance pgs redémarre automatiquement (alors qu'il y a le fichier postmaster.pid sous PGDATA !!) ce qui m'empêche de pouvoir configurer le fichier recovery.conf.
Est ce que vous auriez une idée pourquoi pgs démarre quand même alors que le postmaster.pid est présent ? Sachant que j'utilise systemd sous RHEL 7.
Et sinon, que pensez vous de ma méthode de sauvegarde / restauration ?
Hors ligne
Le fichier postmaster.pid n'interdit pas à PostgreSQL de démarrer. Il cause une vérification de la présence d'un processus ayant ce PID. Si un tel processus existe, il s'arrêtera immédiatement. Si aucun processus n'existe avec ce PID, il démarrera.
Guillaume.
Hors ligne
Merci pour ta réponse, c'est plus clair maintenant ! :-)
Est ce que tu aurais une idée pour faire en sorte que mon instance ne redémarre pas automatiquement au reboot à la suite de la restauration du snapshoot (dans un état du coup potentiellement incohérente) ?
Hors ligne
oui il suffit de désactiver le redémarrage au niveau de systemctl.
Car quand tu restaures le snapshot la vm redémarre.
Cordialement,
Sébastien.
Hors ligne
Je ne suis en aucun cas un spécialiste de VMWare. Donc, à moins de dire un truc du genre "ne fait pas de snapshot" ou "fais en sorte que PG ne démarre pas automatiquement au démarrage du serveur", non, pas vraiment.
Par contre, je peux dire que le "potentiellement incohérente" est faux. Elle sera forcément incohérente si une seule écriture intervient.
Guillaume.
Hors ligne
Sébastien, le problème, c'est que si je restore le snapshot, c'est avec le service postgresql en enable ... et comme je suis bien obligé de redémarrer la VM ... pgs démarre ... je suis coincé ?
Hors ligne
