Re: Backup Strategies?

From: Joshua Kramer <josh(at)globalherald(dot)net>
To: Shoaib Mir <shoaibmir(at)gmail(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Backup Strategies?
Date: 2007-02-05 20:18:00
Message-ID: Pine.LNX.4.64.0702051514520.1342@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin


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(at)globalherald(dot)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
>>
>

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Mario 2007-02-05 20:22:31 Res: Moving a table to another directory
Previous Message Milen A. Radev 2007-02-05 20:14:16 Re: Moving a table to another directory