Re: Backup and Restore mechanism in Postgres - Mailing list pgsql-general

From Brian A. Seklecki
Subject Re: Backup and Restore mechanism in Postgres
Date
Msg-id 20060124122348.W37425@arbitor.digitalfreaks.org
Whole thread Raw
In response to Re: Backup and Restore mechanism in Postgres  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
List pgsql-general
On Tue, 20 Sep 2005, Lincoln Yeoh wrote:

> At 10:00 AM 9/20/2005 -0400, Vivek Khera wrote:
>
>
>> On Sep 14, 2005, at 9:45 AM, vinita bansal wrote:
>>
>>> I have a 4 proc. AMD Opteron machine with 32 GB RAM and ~400GB HDD

Just curious what ever came of this?

Also, were you reading the DB and writing the dump file from the same file
system?  Different partitions on the same disk?  The 400GB is presumably a
RAID1+0 or RAID5?

If that's the case then, I would highly recommend having a separate
physical drive/file system for writing backups to (from which your actual
backup software should be pointed).  Maybe even put it on a different
channel on the same controller, or a different controller alltogether..

Obviously, the biggest thing missing from a lot of PostgreSQL
documentation is practicle information for large deployments, including
strategy and system design requirements.  All in due-time I suppose.

~BAS

>
> Any reason why Postgresql would only get 2.8MB/sec for dumps or slower?
>
> Regards,
> Link.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>      choose an index scan if your joining column's datatypes do not
>      match
>

l8*
     -lava

x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8

pgsql-general by date:

Previous
From: Yl Zhou
Date:
Subject: Re: user defined function
Next
From: MargaretGillon@chromalloy.com
Date:
Subject: Constraint that compares and limits field values