From: | Christopher Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Backup Strategies? |
Date: | 2007-02-04 03:07:43 |
Message-ID: | 87r6t6vcw0.fsf@wolfe.cbbrowne.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
After takin a swig o' Arrakan spice grog, josh(at)globalherald(dot)net (Joshua Kramer) belched out:
> Hello All,
>
> What strategies are people using for automated, script-based backup of
> databases? There are a few I can think of:
>
> 1. Create a "db_backup" unix user and a "db_backup" pgsql user. Grant
> READ access to all objects on all databases for the "db_backup" pgsql
> user. Create a .pgpass file in the home directory of the "db_backup"
> unix user. Backup as needed with a script run as the "db_backup" unix
> user.
>
> 2. Create a "db_backup" unix user and repeat above, except using the
> "postgres" db user.
My department took the approach of having a set of "admin-specific"
users, much in the spirit of 1.
For backups, vacuuming, and replication, the respective clever names
were dumpy, molly, and slony. (When auditors asked about the new
users, there was much snickering...)
We didn't create a special Unix account for it; that seemed
unnecessary.
--
(format nil "~S(at)~S" "cbbrowne" "linuxfinances.info")
http://cbbrowne.com/info/rdbms.html
Who wants to remember that escape-x-alt-control-left shift-b puts you
into super-edit-debug-compile mode? (Discussion in comp.os.linux.misc
on the intuitiveness of commands, especially Emacs.)
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2007-02-04 05:11:42 | Re: identity es postgresql |
Previous Message | Devrim GUNDUZ | 2007-02-03 20:43:49 | Re: Postgres is not starting or stopping |