Vous n'êtes pas identifié(e).
Bonjour à tous,
Je suis novice sur PostGreSQL, et je souhaite actuellement tester la sauvegarde de mes premières bases de données.
Mon serveur est installé sur un poste Windows 7, et j'ai lancé la commande suivante pour créer une archive TAR d'une BDD :
pg_dump --host localhost --port 5432 --username postgres --format tar --blobs --verbose --file "C:\Users\Name\...\backup_base.tar" baseCelle-ci s’exécute correctement et créé bien le TAR souhaité en quelques secondes (moins de 2 min)
Je tente maintenant la restauration de ce TAR avec cette commande (après avoir renommé l'ancienne base sauvegardée) :
pg_restore -C --host localhost --port 5432 --username postgres --verbose "C:\Users\Name\...\backup_base.tar"Voila maintenant près d'une demie heure que j'ai une fenêtre DOS avec des caractères qui défilent (à la Matrix !!).
Le TAR créé fait 1,5 Go.
Peut-être est-ce normal que la restauration soit aussi longue, mais j'ai quand même un gros doute...
Pourriez-vous me confirmer/infirmer que c'est normal, et éventuellement me dire ce que je peux faire pour optimiser cela ?
Merci à vous (et merci de votre indulgence avec un débutant ! ;-) )
Sylvain
Hors ligne
Bonjour,
Il faut spécifier le nom de la base dans laquelle restaurer en utilisant l'option « -d », sinon la restauration (un ensemble d'ordres SQL) se fera sur la sortie standard, cf la documentation http://docs.postgresql.fr/9.4/app-pgrestore.html :
pg_restore peut opérer dans deux modes. Si un nom de base de données est spécifié, pg_restore se connecte à cette base de données et restaure le contenu de l'archive directement dans la base de données. Sinon, un script contenant les commandes SQL nécessaires pour reconstruire la base de données est créé et écrit dans un fichier ou sur la sortie standard
Julien.
https://rjuju.github.io/
Hors ligne
sur la sortie standard
Excuse moi, mais je ne comprends pas ce terme de "sortie standard" ?
Je viens de revenir sur mon poste, et la fenêtre DOS continuait avec les caractères qui défilent : ça devait donc tourner en boucle (mais ça part "où" ??), et je l'ai donc fermé.
Il faut spécifier le nom de la base dans laquelle restaurer en utilisant l'option « -d »
Je pensais que l'option « -C » allait créer la base de donnée (dont le nom doit être dans la sauvegarde ?)
Je viens d'ajouter « -d base » à ma commande, mais j'ai eu le message
trop d'arguments en ligne de commande (le premier étant « -d »)
Essayer « pg_restore --help » pour plus d'informations.Merci pour ton aide !
Sylvain M.
Hors ligne
Bonjour,
La sortie standard est ce qui s'affiche à l'écran.
Normalement la commande :
pg_restore -C -d ma_base --verbose "C:\Users\Name\...\backup_base.tar"
devrait suffire dans ton cas.
Quelle est la commande que tu passes et qui génère l'erreur ?
Cordialement.
Cordialement,
Sébastien.
Hors ligne
Quelle est la commande que tu passes et qui génère l'erreur ?
Je viens, sur ton modèle, d’exécuter celle-ci :
pg_restore -C -d base --host localhost --port 5432 --username postgres --verbose "C:\Users\Name\...\backup_base.tar"Mais j'ai le message d'erreur suivant :
pg_restore: [programme d'archivage (db)] la connexion à la base de données « base » a échoué : FATAL: la base de données « base » n'existe pas
Effectivement, "base" n'existe pas, mais je pensais que le "-C" allait la créer ???
Sylvain M.
Hors ligne
non la base de données du "-d" sert à la connexion et doit donc exister avant.
Et toutes ces options : --host localhost --port 5432 --username postgres ne servent à rien puisque ce sont les valeurs par défaut.
Cordialement,
Sébastien.
Hors ligne
non la base de données du "-d" sert à la connexion et doit donc exister avant.
Donc si je remplace "-d base" par "-d postgres", ça va se connecter à la base postgres (qui existe), et recréer la base dont le nom est sauvegardé dans le backup ?? (du fait du "-C")
Je ne voudrais pas corrompre ma base postgres, donc je préfère votre avis avant.
Merci encore.
Sylvain M.
[edit]
J'ai remplacé base par postgres, ça tourne !! SUPER ! MERCI !
[/edit]
Dernière modification par Sylvain M. (09/12/2015 16:40:29)
Hors ligne
Je poursuis sur ce fil car j'ai encore 2 questions d'optimisations dans mon processus de Sauvegarde / Restauration.
1] La première concerne la compression de l'archive sauvegardée.
J'ai compris que le TAR n'était pas compressé. Effectivement, si je compresse ses 1.5 Go avec 7Zip (par exemple), je passe à 400 Mo.
Que me conseillez-vous pour optimiser le poids des fichiers en sortie ?
2] La deuxième concerne une tentative de transfert de ma base sur un autre Serveur, celui-ci sous installé sur une machine Debian.
J'ai tenté de lancer le pg_restore sur ce serveur, mais j'obtiens le message d'erreur suivant :
pg_restore: connexion à la base de données pour la restauration
pg_restore: création de DATABASE ma_base
pg_restore: [programme d'archivage (db)] Erreur pendant le traitement de la TOC
(« PROCESSING TOC ») :
pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 3447 ;
1262 1537996 DATABASE ma_base postgres
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: nom de locale invalide : « French_France.1252 »
La commande était : CREATE DATABASE ma_base WITH TEMPLATE = template0 ENCODING =
'UTF8' LC_COLLATE = 'French_France.1252' LC_CTYPE = 'French_France....
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: la base de données « ma_base » n'existe pas
La commande était : ALTER DATABASE ma_base OWNER TO postgres;Problème d'encodage on dirait ?
Auriez vous des conseils pour éviter ce problème ?
Merci à vous.
Sylvain M.
Hors ligne
1) tu peux compresser à la volée l'export avec un pipe (pg_dump.....|gzip mon_fichier.dump)
ou en utilisant les options de compression native à pg_dump en ne faisant pas un tar mais un format personnalisé (voir la doc)
2)sur la deuxieme machine debian il doit manquer des locales par rapport à la debian d'origine (voir avec la commande locale -a)
Si il en manque il faut les installer.
Cordialement,
Sébastien.
Hors ligne
Utiliser tar est potentiellement une mauvaise idée. Le format tar utilisé ne permet pas de sauvegarder des fichiers de plus de 8 Go, autrement dit certaines tables pourraient ne pas pouvoir être sauvegardées. Utiliser plutôt le format custom.
La compression de custom n'est pas forcément une bonne idée (lente, pas très efficace). Désactivez la avec l'option -Z 0. Compressez avec un autre outil comme gzip ou bzip2 ou lzma. Voire un outil multithread (aucune idée de ce qu'il existe sur Windows à ce niveau).
Concernant les locales, cela sous-entend que vous devez oublier l'option -C et créer vous-même la base dans la bonne locale (ie, UTF8 pratiquement à coup sûr).
Guillaume.
Hors ligne
Bonjour et désolé de ne pas vous avoir remercié plus tôt pour vos réponses : MERCI !
1) tu peux compresser à la volée l'export avec un pipe (pg_dump.....|gzip mon_fichier.dump)
ou en utilisant les options de compression native à pg_dump en ne faisant pas un tar mais un format personnalisé (voir la doc)
Effectivement, le format personnalisé est plus efficace, pour la restauration ensuite également.
2)sur la deuxieme machine debian il doit manquer des locales par rapport à la debian d'origine (voir avec la commande locale -a)
Si il en manque il faut les installer.
Bon, mon souci c'est que je ne connais pas du tout l'environnement linux, et que je n'avais encore jamais entendu ce terme de "locale" avant de lire votre réponse...
Je vais voir pour approfondir cette question !
Par contre, en essayant de comprendre un peu mieux le message d'erreur, et grace à vos réponses, je me dis que c'est mon export qui n'a pas le bon encodage (French_France.1252 au lieu d'UTF-8). Il suffirait que je précise l'encodage en sortie (-E codage, --encoding=codage) ?
Par contre, je ne sais pas trop comment j'écris cette option ?
-E 'UTF-8'(avec des guillemets ???)
Merci à vous !
Sylvain M.
Hors ligne
Ça dépend du système, donc il vous faut tester. Les guillemets ne sont pas nécessaires ceci dit.
Guillaume.
Hors ligne