PostgreSQL vous fournit tous les outils nécessaires pour le sauvegarder dans son installation de base. C'est ce que j'ai fait il y a quelques semaines pour mettre en place des sauvegardes à chaud d'instances PostgreSQL hébergées sur un hôte Windows :

1. Créez un utilisateur spécifique pour les sauvegardes, appelons-le 'backups'. Vous pouvez utiliser le createuser de votre installation PostgreSQL.

2. Donnez à l'utilisateur un mot de passe et un accès en lecture à tout. Cela peut devenir un peu complexe. Alternativement, vous pouvez aussi en faire un superutilisateur PostgreSQL et appliquer des restrictions de connexion comme mentionné ci-dessous.

3. Autorisez-le à se connecter à partir de localhost uniquement en utilisant un mot de passe (mécanisme 'md5'), ou si vous jouez, créez un utilisateur sur votre machine MS Windows et utilisez le mécanisme 'ident'. Vous devrez modifier le fichier pg_hba.conf pour appliquer l'un ou l'autre de ces comportements et la restriction de la connexion à partir de localhost uniquement.

4. Créer un script à utiliser pg_dumpall pour sauvegarder la base de données. Le script peut être appelé via une configuration de tâche dans Task Scheduler ou via un planificateur de sauvegarde comme Bacula. Si vous avez choisi de vous authentifier à l'aide d'un mot de passe, vous pouvez le spécifier en tant que variable d'environnement qui pg_dumpall lira ou spécifiera un fichier contenant le mot de passe en utilisant une variable d'environnement différente.

Les détails de cette méthode sont disponibles à l'adresse suivante http://wiki.postgresql.org/wiki/Automated_Backup_on_Windows .

Je ne sais pas pourquoi vous utilisez pgAdmin pour les sauvegardes automatisées de PostgreSQL. J'aimerais entendre vos raisons, sachant que PostgreSQL a un moyen de le faire sans outils externes et dispose d'un document bien écrit sur le sujet.

J'ai configuré pgAdmin de cette façon

pgagent.exe INSTALL pgAgent -u postgres -p secret host=localhost dbname=pgadmin user=postgres

Ensuite, vous devez configurer le fichier pgpass.conf dans le répertoire utilisateur de postgres, sous winxp, il se trouve dans Application Data/postgres/pgpass.conf et sous win7, il devrait être appdata/local/postgres/pgpass.conf (pas sûr à 100%).

Elle est définie ici http://wiki.postgresql.org/wiki/Pgpass

hostname:port:database:username:password

ceci permet à pgAgent d'accéder au serveur postgreSQL, il y aurait un pgpass créé pour votre utilisateur lorsque vous vous souvenez du mot de passe pour pgAdmin.

Sans ce pgpass, pgAgent ne peut pas accéder à la base de données.

Postgres est très flexible - il y a plus d'une façon d'obtenir une bonne sauvegarde utilisable (et beaucoup des meilleures ne nécessitent pas l'utilisation de pgAgent - vous pouvez les script avec les outils ordinaires du système d'exploitation).

nearora a déjà décrit l'utilisation pg_dumpall qui peuvent être viables pour vous.

Le manuel Postgres décrit deux autres options qui peut être automatisé sous Windows avec un petit script.

Option 2 : Sauvegarde au niveau du système de fichiers

Normalement, cela se fait en arrêtant le serveur et en saisissant le fichier PGDATA répertoire.
Si vous ne pouvez pas arrêter le serveur alors contrairement à ce que dit le manuel ici vous peut obtenir une sauvegarde utilisable sans arrêter le serveur -- Il suffit de prendre une "sauvegarde de base" comme vous le feriez pour mettre en place une Esclave WAL/PITR .

Le résultat de cette sauvegarde doit être une copie de la base de données de l'entreprise. PGDATA plus quelques segments WAL, stockés dans un emplacement séparé sur le serveur que vos processus de sauvegarde normaux au niveau du système de fichiers peuvent récupérer.
Vous devez vous assurer que la sauvegarde de base est terminée avant de saisir les fichiers avec votre processus de sauvegarde du système de fichiers habituel, sinon vous risquez d'obtenir une sauvegarde inutilisable.

Option 3 : Sauvegarde d'un esclave

Avec cette méthode, vous devrez créer un serveur esclave, qu'il s'agisse d'un serveur d'expédition ou d'un serveur de secours à chaud, comme décrit dans les documents de Postgres .
Quand il est temps de sauvegarder votre cluster, arrêter l'esclave et sauvegarder son PGDATA comme vous le feriez pour une sauvegarde régulière du système de fichiers. puis redémarrez l'esclave et laissez-le rattraper le maître.

C'est de loin mon option préférée pour sauvegarder un cluster Postgres - Si vous dédiez un serveur esclave spécifique pour être "l'esclave des sauvegardes", vous pouvez effectuer des sauvegardes de votre cluster avec un impact nul sur les applications de production utilisant votre base de données.

Ses principaux inconvénients sont qu'elle nécessite un serveur esclave et que vous devez vous assurer que Postgres est arrêté sur l'esclave. antes de vous attrapez le PGDATA et n'est pas relancé tant que vous n'avez pas fini de saisir les fichiers.
Vous devez également vous assurer que les sauvegardes se terminent dans un délai raisonnable afin que les segments WAL dont vous avez besoin pour rattraper le maître soient toujours disponibles. Dans la pratique, cela ne sera un problème que pour les clusters avec des fichiers EXTREMELY des charges d'écriture élevées, ou si vous faites quelque chose comme une VACUUM FULL sur le maître pendant que l'esclave est sauvegardé