Discussion :

[NULL008]

bonjour a tous

Qui peut m'aider svp sur comment je peut optimiser mes plan des sauvegarde

En fait le backup il prend plus que 10 heures et parfois il ne se termine pas le matin

j'utilise la command pg_dump pour sauvegarder mes bases et je suis sous un environnement linux

merci pour vos conseil

[SQLpro]

Il n'y a pas 36000 choses à faire, car PostGreSQL est très limité en cette matière.
1) vous pouvez tenter une sauvegarde en mode compressé, cela diminue parfois le temps de sauvegarde.
2) vous pouvez agir au niveau du hardware. Un dump consiste à lire des pages de données sur le disque et les écrire sur un autre. Si vos disques sont en RAID 5, passez en RAID 10 (pour les fichiers de la base, comme pour la destination de la sauvegarde) avec beaucoup de disque en parallèle. Par exemple en passant d'un RAID 5 à 3 disques de part et d'autre (côté base, comme côté sauvegarde) à un RAID 10 à 4 disques, vous allez gagner 2 à 3h sur votre sauvegarde de 10 heures... Même chose en mettant du disque SSD à condition que ce soient des SSD professionnels de type "write intensive".

Maintenant si cela ne suffit pas changez de SGBDR !
En effet, le free coute pas cher, mais on en as pour son argent... Car c'est souvent très limité !

Par exemple dans SQL Server les sauvegarde sont toujours multithreadées ce que ne sait pas faire PG et vous pouvez faire des sauvegardes multi destination (par exemple, envoyez la sauvegarde sur 8 disques distinct en parallèle) afin de minimiser le temps d'écriture (souvent le plus long) et enfin, vous pouvez faire des sauvegardes partielles consistantes par "storage"....
Évidemment c'est pas le même prix.

A +

[ced]

Bonjour,

Pour pouvoir vous aider plus efficacement (sans vous faire changer de SGBD ), il nous faudrait un peu plus d'informations...
Quelle est la volumétrie de vos bases de données sur votre instance ?
Dans quelle version de PostgreSQL est cette instance ?
À partir de la version 9.2, il est possible de paralléliser les opérations de pg_dump avec l'option -j nb_jobs (ou --jobs=nb_jobs).

Sinon, vous pouvez aussi envisager de passer à une sauvegarde de type PITR...
Et je passe sur les solutions plus bas niveau, qui sont fonction de la configuration matérielle de votre serveur (snapshot en ZFS par exemple).
Tout cela est documenté dans la doc de PostgreSQL.

[ced]

Par exemple dans SQL Server les sauvegarde sont toujours multithreadées ce que ne sait pas faire PG

Raté ! Depuis la version 9.2 de PostgreSQL, avec pg_dump, c'est possible...
Ça date quand même de 2012...

[SQLpro]

Raté ! Depuis la version 9.2 de PostgreSQL, avec pg_dump, c'est possible...
Ça date quand même de 2012...

C'est un multithread de job pas de la sauvegarde de chaque base.
Autrement dit si vous avez 10 bases à sauvegarder, ce paramètre permet d'envoyer 10 threads pour exécuter les 10 sauvegardes distincte simultanément.
mais la sauvegarde d'une base reste toujours mono thread alors que dans oracle ou SQL Server elle est multithreadé pour une même base (dans Oracle il n'y avait d'ailleurs qu'une seule base par instance jusaqu'à la version 12c.) en fonction des "storages" existants et des destinations en face.
Pour vous votre information personelle au sujet des sauvegardes de SQL Server :
https://www.sqlbackuprestore.com/bac...sandwrites.htm
https://www.brentozar.com/archive/20...ce-of-backups/

Au lieu de systématiquement défendre bêtement PostGreSQL sans regardez ce que font les autres SGBDR, vous devriez vous cultiver et lire ce que fait la concurrence.

Pour info ce multithreadage des sauvegardes existe depuis la version 7 de SQL Server (1998) soit 20ans... Conclusion PostGreSQL à plus de 20 ans de retard sur ce sujet qui n'est toujours pas à l'horizon de la R&D de PG...

Et comme je le dis souvent PG n'est pas fait pour gérer de grosses bases....

A +

[ced]

C'est un multithread de job pas de la sauvegarde de chaque base.

Et donc, ça reste de la parallélisation de tâches. Donc, nous sommes bien d'accord...
Ensuite, tout dépend de définition qu'on donne au terme "multithread".

Autrement dit si vous avez 10 bases à sauvegarder, ce paramètre permet d'envoyer 10 threads pour exécuter les 10 sauvegardes distincte simultanément.

Ça, c'est plus lié à l'architecture de l'OS... La notion de thread est plus propre à Windows. Sous Linux, ce sont des process, et plusieurs process de sauvegarde peuvent très bien être lancés en parallèle... Un même process peut faire l'objet de plusieurs "jobs", ce qui tend à en réduire le temps d'exécution (problème rencontré dans le cas de la présente discussion).

mais la sauvegarde d'une base reste toujours mono thread

Encore une fois, tout dépend de la définition d'un thread et de l'OS dans lequel on se trouve.

Au lieu de systématiquement défendre bêtement PostGreSQL sans regardez ce que font les autres SGBDR, vous devriez vous cultiver et lire ce que fait la concurrence.

Pure conjecture et procès d'intention... Je ne défends pas PostgreSQL, je tente de rétablir un raccourci rapide de votre part.

Et comme je le dis souvent PG n'est pas fait pour gérer de grosses bases...

Encore une fois, on est là dans le jugement de valeurs... Qu'est-ce qu'on entend par "grosses bases" ? On ne connait pas la volumétrie de la base qui pose problème dans le cas présent.

Quoi qu'il en soit, l'objet de la discussion est bien d'aider un membre à résoudre un problème qu'il rencontre avec les outils dont il dispose.

A +

[NULL008]

[QUOTE=ced;10345438]Bonjour,

Pour pouvoir vous aider plus efficacement (sans vous faire changer de SGBD ), il nous faudrait un peu plus d'informations...
Quelle est la volumétrie de vos bases de données sur votre instance ?
Dans quelle version de PostgreSQL est cette instance ?
À partir de la version 9.2, il est possible de paralléliser les opérations de pg_dump avec l'option -j nb_jobs (ou --jobs=nb_jobs).

Sinon, vous pouvez aussi envisager de passer à une sauvegarde de type PITR...
Et je passe sur les solutions plus bas niveau, qui sont fonction de la configuration matérielle de votre serveur (snapshot en ZFS par exemple).
Tout cela est documenté dans la doc de PostgreSQL

oui je suis avec la version 9.1 avec des bases de données de 1.55 Tera

le problème avec le sauvegarde PITR si demain tu as une besoin de restauration d'une telle base vous été obliger de restaurer Toutes les bases

[ced]

Il va falloir songer à monter de version. La version 9.1 n'est plus supportée depuis bientôt deux ans.
Et du coup, en montant de version, vous pourrez paralléliser les dumps.

Pour l'instant, c'est difficile d'améliorer les choses. Est-ce que vos sauvegardes sont compressées ? Si oui, de quelle façon ? Avec pg_dump ou avec un outil externe de compression (type gzip) ?

[NULL008]

Il va falloir songer à monter de version. La version 9.1 n'est plus supportée depuis bientôt deux ans.
Et du coup, en montant de version, vous pourrez paralléliser les dumps.

Pour l'instant, c'est difficile d'améliorer les choses. Est-ce que vos sauvegardes sont compressées ? Si oui, de quelle façon ? Avec pg_dump ou avec un outil externe de compression (type gzip) ?

Mois j'utilise perssonellement l'option

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

pg_dump -Fc

qui me permez d'avoir le format compressé par défaut

Si je procéde a une modification vers

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

pg_dump dbname | gzip > filename.gz

y 'aura til de gain par rapprt a la formta -Fc

merci

[ced]

C'est possible, il faut tester, cela dépend des configurations.