Steve Atkins wrote:
On Nov 9, 2007, at 8:52 AM, Tom Hart wrote:
I'm sure you guys have heard this about 100 times, and I've done some
research on Google and found out some things, but I still have a
couple questions.
As I'm sure you may have guessed from the subject, I'm trying to
schedule (under windows) pg_dumpall to run each night/morning/full
moon/whatever. The hitch in this is that it asks for a password for
each database as it dumps it. I know I can use the PGPASS environment
variable, or a ~/.pgpass file. What I'm wondering is what's
considered 'best practice' in practical applications. What solutions
do you guys use? Is it worth changing PGPASSFILE to point to a
different .pgpass?
Any of those approaches should be fine. I'd probably stick with the
default pgpass file, just for the sake of whoever may have to maintain
it next.
I tend to create a unix user just for doing backups and other
scheduled maintenance, then give that user access to the database via
ident authentication from the local system only. If PG-on-Windows has
equivalent functionality that's another approach to consider.
Ok, here's what I think is going to work best for me. I'm going to
create a user with very little access rights, and then I'm going to set
up a scheduled task in windows to run pg_dumpall on the machine that
houses the db (and where the backup will be stored). On that machine
I'll have a pgpass file that I've placed somewhere where only the dummy
backup account can access it and pointed to it with the PGPASSFILE
environment variable. I think I'll be able to run a scheduled task
associated with that name without giving them login abilities.
Sound pretty solid to you guys?
BTW, this isn't protecting a ton of data, but the data itself is pretty
sensitive, so security is a concern. I appreciate your help in building
as solid a system as I can.
BTW2, I already told somebody today that Windows and security is like a
cherry pie with gravy on top, but I don't get a choice here, so try to
understand :-)
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
