Re: PITR backup to Novell Netware file server

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Decibel!" <decibel(at)decibel(dot)org>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: PITR backup to Novell Netware file server
Date: 2007-08-08 00:38:47
Message-ID: 46B8CA47.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

> >>> Decibel! <decibel(at)decibel(dot)org> 08/07/07 4:51 PM >>>
> On Tue, Aug 07, 2007 at 02:12:29PM -0500, Kevin Grittner wrote:
> > > Copying a 16MB file that's already in memory isn't exactly an intensive
> > > operation...
> >
> > That's true for the WAL files. The base backups are another story. We will
> > normally have a database vacuum analyze between the base backup and the users
> > being in there to care about performance, but that's not always the case --
> > sometimes jury trials go late into the night and could overlap with this a
> > base backup. And some judges put in a lot of late hours; although they don't
> > tend to bang on the database very heavily, they hate to be made to wait.
>
> Ahh... well, that's something where rsync could actually help you since
> it allows you to put a bandwidth cap on it. Another option is that some
> OSes (FreeBSD for one) will respect process priority when it comes to
> scheduling IO as well, so if you nice the backup process it hopefully
> wouldn't impact the database as much.

Thanks for the suggestions. A new OS is not in the cards any time soon, but
I think the --bwlimit option makes sense -- there's not a lot of point moving
it from the database server to the file server faster than the WAN can take it,
anyway. I suppose I could "nice" the rsync requester on the database side, too.

-Kevin

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Tena Sakai 2007-08-08 00:45:25 postgres authentication
Previous Message Fabricio Peñuelas 2007-08-08 00:19:17 ssl and odbc standar driver