Обсуждение: Backup Strategies?

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

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
>


*******************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

After takin a swig o' Arrakan spice grog, josh@globalherald.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@~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.)

Thanks for the hint, Shoaib.  My question - and I should have phrased this
more carefully - related to the security of the various backup tactics.
Is it more secure to have a "backup user" with read permissions on all
databases, or is it more secure to have a dedicated Unix backup user -
with the .pgpass file in the home directory and all.  If someone can, by
way of cracking, get in to the account of the backup Unix user, then the
postgres user's database account is also surrendered.  If I have a
Postgres backup user (with read only permissions on all DB's), then even
if someone got into the unix account of the backup user, all they could do
is read DB data (versus delete or write over stuff).

Essentially it's the diffrenece between being *really* secure and *really
really* secure.

On Sat, 3 Feb 2007, Shoaib Mir wrote:

> A cron job can always do the job using pg_dump/pg_dumpall, in case you need
> the incremental backup you can opt for PITR WAL based archive logs...
>
> --
> Shoaib Mir
> EnterpriseDB (www.enterprisedb.com)
>
> On 2/3/07, Joshua Kramer <josh@globalherald.net> 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
>>
>

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
>

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@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Ray Stell
Sent: Wednesday, 7 February 2007 00:34
To: Phillip Smith
Cc: pgsql-admin@postgresql.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@postgresql.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