Postgres is very flexible - there is more than one way to grab a good, usable backup (and many of the best don't require you to use pgAgent - you can script them with regular OS tools).
nearora already described using
pg_dumpall which may be viable for you.
The Postgres manual describes two other options which can be automated on Windows with a little scripting.
Option 2: Filesystem-Level Backup
Normally this is done by shutting down the server and grabbing the
If you can't shut down the server then contrary to what the manual says here, you can get a usable backup without shutting down the server -- Simply to take a "base backup" as you would for setting up a WAL/PITR Slave.
The result of this backup should be a copy of the
PGDATA directory, plus a few WAL segments, stored in a separate location on the server that your normal filesystem-level backup processes can pick up.
You must ensure that the base backup completes prior to grabbing the files with your regular filesystem backup process, otherwise you might wind up getting an unusable backup.
Option 3: Backing up a slave
With this method you will need to create a slave server, either log-shipping or hot standby, as described in the Postgres docs.
When it's time to back up your cluster, shut the slave down and back up its
PGDATA directory as you would for a regular filesystem backup, then restart the slave and let it catch up with the master again.
This is by far my favorite option for backing up a Postgres cluster - If you dedicate a specific slave server to be the "backups slave" you can perform backups of your cluster with zero impact on production applications using your database.
The major downsides are that it requires a slave server, and you must make sure that Postgres is stopped on the slave before you grab the
PGDATA directory, and is not started again until you're done grabbing the files.
You also need to ensure that backups complete in a reasonable timeframe so the WAL segments you need to catch up to the master are still available. In practice that will only be an issue for clusters with EXTREMELY high write loads, or if you do something like a
VACUUM FULL on the master while the slave is being backed up..