PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 05/06/2013 14:18:06

barthymus
Membre

Stratégie de back-up logique

Bonjour à tous !

Voilà j'aimerais avoir vos avis sur une question qui me dérange depuis quelques jours... Comment dois je backupé, et surtout, comment je restaure ?
J'ai beaucoup cherché sur internet, et j'ai rien trouvé de très... Concret quoi. Chacun présentent sa solution(surement top) mais ne racontent que peu comment ils restaurent...

J'ai repris la solution suivante pour mes backups (Pour un cluster C contenant BD1 et BD2)
- pg_dump de BD1
- pg_dump de BD2
- pg_dumpall -g C ( pour sauvegarder les roles... Les users...)

Maintenant... Restauration dans le cas suivant :
1 ) -Oups, j'ai delete BD1, je veux le remettre dans C sad
Je lance pg_restore ? Je dois créé la base non ? à vide ?

2 ) -Je veux plutot mettre BD1 dans le cluster D (vide)
Je dois importer les roles avant non ? Mais comment ?
Et les tablespaces enregistrer dans le dumpAll contiennent des chemins physique sur le premier cluster... En gros, mes tablespaces vont pas passés...
Et ensuite importer BD1 ?

Bref je suis un peu perdu. J'ai peut etre pas vu le super tutoriel magique qui préconise et qui explique the best way pour faire ceci...
(Et je suis mal car on parle uniquement de save logique ici... Quand j'en serais au physique, cela risque d'etre un autre problème)

Merci à tous ceux qui pourront m'accorder un peu de temps,
Anthony

Dernière modification par barthymus (06/06/2013 14:36:13)

Hors ligne

#2 05/06/2013 15:46:37

kenrio
Membre

Re : Stratégie de back-up logique

Tout dépend du contexte, un pg_dump c'est bien mais pour des grosses bases c'est pas le mieux, loin de la même.
Et puis là dans votre exemple vous parlez d'un delete de base qui dans les faits sont ultra rare, comparé à un truncate de table ou un delete de lignes erronées.

C'est quoi un cluster pour vous ? un serveur ?

Vous mettez de coté la sauvegarde physique de suite mais pourquoi ?

Hors ligne

#3 05/06/2013 16:04:33

barthymus
Membre

Re : Stratégie de back-up logique

Alors,
C'est vrai que j'ai oublié un peu le contexte. On parle ici de bases < 200 go donc assez petites. La moyenne tournerait autour des 30/50go.
Je parle d'un delete de base car c'est le plus critique. On peut alors plutot pensé à un ... Corruption d'block, truncate applicatif, souhait d'un retour sur une ancienne tempo... (Je parle pas ici de PITR, plus tard avec le physique).

Non un cluster... C'est un cluster quoi x) Je comprends pas trop ce que vous demandez.
En gros sur mon serveur, j'ai deux ou trois clusters  A, B, et C qui contiennent chacun plusieurs Bases de Données. J'ai plusieurs clusters pour une hiérarchisation des niveaux de services (Standard, premium... etc)
Je met de coté le "Physique" car j'ai plus de mal à visualiser comment faire ma restauration logique, la physique, je l'ai déja testé et cela à été concluant, je l'a déployerais juste après.

Dernière modification par barthymus (05/06/2013 16:05:49)

Hors ligne

#4 05/06/2013 21:24:24

gleu
Administrateur

Re : Stratégie de back-up logique

1 ) -Oups, j'ai delete BD1, je veux le remettre dans C sad
Je lance pg_restore ? Je dois créé la base non ? à vide ?

Il faut tout d'abord créer la base, puis y restaurer les objets. Donc en gros, "createdb la_base" suivi d'un "pg_restore -d la_base le_dump".

2 ) -Je veux plutot mettre BD1 dans le cluster D (vide)
Je dois importer les roles avant non ? Mais comment ?

Il faut en effet importer les rôles ainsi que les tablespaces. C'est ce que vous avez sauvé avec le pg_dumpall. Comme il s'agit d'un script SQL, il faut suffit de le lancer avec psql. Ça vous donne donc: "psql -f le_script postgres", suivi de la création de base avec "createdb la_base" et de la restauration avec "pg_restore -d la_base le_dump".


Guillaume.

Hors ligne

#5 06/06/2013 07:54:05

barthymus
Membre

Re : Stratégie de back-up logique

Merci beaucoup, je commence à y voir plus clair !

Dans le cas 2, si mon cluster n'est pas si vide que sa et contient déjà des roles & autres, dont le rôles postgresql. Lancer le script dumpAll va lui provoquer des erreurs Already exists de partout non ? Si c'est un script SQL pur, il y a bien moyen de taper dedans pour insérer uniquement ce que je souhaite, c'est sa ?

Hors ligne

#6 06/06/2013 10:13:06

kenrio
Membre

Re : Stratégie de back-up logique

ouai mais après suivant ça taille ça peut devenir assez difficile de le bidouiller.

Hors ligne

#7 06/06/2013 10:19:29

Bidou
Membre

Re : Stratégie de back-up logique

Si tu as des éléments déjà existants, ça n'empêchera pas le reste du script de s’exécuter donc pas forcément un problème dans le cas où il s'agit juste d'utilisateurs déjà présents.
Par contre si c'est des tables dont le squelette a changé, c'est plus problématique.

Hors ligne

#8 06/06/2013 11:11:59

barthymus
Membre

Re : Stratégie de back-up logique

Mais par exemple. Une base crash sur un cluster A, qui est heureusement backupé de façon à avoir un dump de la base d'un coté, et un pg_dumpAll de la structure du cluster A.
Si je lance le pg_restore de la structure sur un autre cluster, il va aussi me créé tout les roles et tablespaces relatives à plein de base de données existant sur le premier cluster... Meme si je veux la structure que d'une seule base de donnée.
Il n'existe pas de moyen plus propre selon vous que de trifouillez dedans ? (Ou importez des roles et tablespaces en trop) ?
Ce cas là vous est surement arrivé non ?

Merci à tous pour vos réponses en tout cas... Cette communauté est vraiment là pour aider les nouveaux et c'est un vrai point fort.

Hors ligne

#9 06/06/2013 11:34:10

kenrio
Membre

Re : Stratégie de back-up logique

vous avez une base de données par client ou un schéma par client ?

Hors ligne

#10 06/06/2013 12:28:24

barthymus
Membre

Re : Stratégie de back-up logique

Les deux. J'ai quelques bases dédiés. J'ai pas de cluster dédié par contre, chaque cluster contient plusieurs bases. Et un serveur contient plusieurs cluster en générale.

Hors ligne

#11 06/06/2013 13:51:57

kenrio
Membre

Re : Stratégie de back-up logique

un cluster en fait c'est une instance postgresql ?

Hors ligne

#12 06/06/2013 14:09:53

barthymus
Membre

Re : Stratégie de back-up logique

Hum, tout à fait. A moins que je me trompe ?

Hors ligne

#13 06/06/2013 14:28:03

kenrio
Membre

Re : Stratégie de back-up logique

ok donc on parle d'instance smile

Sinon pour répondre, faut mettre en place une procédure de sauvegarde logique en adéquation avec le contexte.
Vous pourriez faire par exemple un script, qui organise les sauvegardes suivant les bases de données par instance.
Découper ça avec un pgdumpall --roles-only ( pour n'avoir que les définitions de roles)
coupler à un pgdumpall --tablespaces-only pour avoir uniquement les tablespaces de votre base, etc,...

en fait il faut scripter en amont pour pouvoir ensuite scripter en restore.

désolé d'être aussi évasif.

Dernière modification par kenrio (06/06/2013 14:28:31)

Hors ligne

#14 06/06/2013 19:25:13

gleu
Administrateur

Re : Stratégie de back-up logique

Il n'existe pas de moyen plus propre selon vous que de trifouillez dedans ? (Ou importez des roles et tablespaces en trop) ?

Non, pas d'autre moyen. Je n'appelerais pas ça un moyen "sale" (enfin, pas propre) pour autant.

Vous pouvez toujours tout restaurer au niveau du pg_dumpall, puis restaurer votre base, puis vérifier la taille de chaque tablespace et supprimer les tablespaces inutiles.


Guillaume.

Hors ligne

Pied de page des forums