Re: Standby servers and incrementally updated backups

On Jun 25, 2007, at 4:54 PM, Erik Jones wrote:
> On Jun 25, 2007, at 4:40 PM, Simon Riggs wrote:
>> On Mon, 2007-06-25 at 16:00 -0500, Erik Jones wrote:
>>> On Jun 25, 2007, at 3:40 PM, Simon Riggs wrote:
>>>>> If I'm correct, then for large databases wherein it can
>>>>> take hours to take a base backup, is there anything to be
>>>>> gained by
>>>>> using incrementally updated backups?
>>>>
>>>> If you are certain there are parts of the database not touched
>>>> at all
>>>> between backups. The only real way to be sure is to take file level
>>>> checksums, or you can trust file dates. Many backup solutions
>>>> can do
>>>> this for you.
>>>
>>> Wait, um, what? I'm still not clear on why you would want to run a
>>> backup of an already caught up standby server.
>>
>> Sorry, misread your question.
>>
>> While you are running a warm standby config, you will still want
>> to take
>> regular backups for recoverability and DR. These are additional
>> backups,
>> i.e they are not required to maintain the warm standby.
>>
>> You can backup the Primary, or you can backup the Standby, so most
>> people will choose to backup the Standby to reduce the overhead on
>> the
>> Primary.
>
> Ok, yeah, that's what I was thinking and is where we are headed in
> the next month or so here at work: we already have a standby
> running and will be adding a second standby server that we will be
> using for snapshot backups (packaged with the pertinent wal
> files...) as well as periodically bringing the second standby up to
> run dumps from just to cover all of our bases and also to be able
> to take our main primary server down for maintenance and still have
> both a production and standby running. I guess I was really just
> wanting to make sure I wasn't missing some other big usage for
> incremental backups from the standby.

Note that (currently) once you bring a standby up you can't go back
to standby mode without restoring the filesystem level backup you
started with and replaying everything.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)