Re: Backup Strategies?

Have you looked at pg_dump and/or pg_dumpall? That would be the more
common way of performing backups.

I run 2 backup's nightly of our databases:
1) As part of a backup script, call pg_dumpall as the postgres *nix
users and PG user, then pipe the output to a file on a remote server.
2) As a cronjob: pg_dumpall > /dev/st0

Cheers,
-p

On Sat, 2007-02-03 at 01:51 -0500, Joshua Kramer wrote:
> 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.
>
> Thanks,
> -Josh
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

Going with a PostgreSQL backup user (with read only permissions) seems to be
a better option for your case....

Anyone else on the list might be able to come up with much better options.

--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)

On 2/3/07, Phillip Smith <fukawi2(at)iinet(dot)net(dot)au> wrote:
>
> Have you looked at pg_dump and/or pg_dumpall? That would be the more
> common way of performing backups.
>
> I run 2 backup's nightly of our databases:
> 1) As part of a backup script, call pg_dumpall as the postgres *nix
> users and PG user, then pipe the output to a file on a remote server.
> 2) As a cronjob: pg_dumpall > /dev/st0
>
> Cheers,
> -p
>
>
> On Sat, 2007-02-03 at 01:51 -0500, Joshua Kramer wrote:
> > 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.
> >
> > Thanks,
> > -Josh
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

On Sat, Feb 03, 2007 at 08:28:48PM +1100, Phillip Smith wrote:
> 1) As part of a backup script, call pg_dumpall as the postgres *nix
> users and PG user, then pipe the output to a file on a remote server.

might consider adding scp to the mix so that the data is not in
the clear on the wire. You can use the authorized_keys feature
so that passwd is not needed in the script.

I actually dump to a local file, then include that in a TAR GZ file, so it's
not actually in plain text on the network, although not truly encrypted
either...

Cheers,
-p

-----Original Message-----
From: pgsql-admin-owner(at)postgresql(dot)org
[mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of Ray Stell
Sent: Wednesday, 7 February 2007 00:34
To: Phillip Smith
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] Backup Strategies?

On Sat, Feb 03, 2007 at 08:28:48PM +1100, Phillip Smith wrote:
> 1) As part of a backup script, call pg_dumpall as the postgres *nix
> users and PG user, then pipe the output to a file on a remote server.

might consider adding scp to the mix so that the data is not in
the clear on the wire. You can use the authorized_keys feature
so that passwd is not needed in the script.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
message can get through to the mailing list cleanly

*******************Confidentiality and Privilege Notice*******************

The material contained in this message is privileged and confidential to
the addressee. If you are not the addressee indicated in this message or
responsible for delivery of the message to such person, you may not copy
or deliver this message to anyone, and you should destroy it and kindly
notify the sender by reply email.

Information in this message that does not relate to the official business
of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta.
Weatherbeeta, its employees, contractors or associates shall not be liable
for direct, indirect or consequential loss arising from transmission of this
message or any attachments