Re: Issues Outstanding for Point In Time Recovery (PITR)

From: Barry Lind <barry(at)xythos(dot)com>
To: Patrick Macdonald <patrickm(at)redhat(dot)com>
Cc: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, "J(dot) R(dot) Nield" <jrnield(at)usol(dot)com>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Issues Outstanding for Point In Time Recovery (PITR)
Date: 2002-07-08 16:53:10
Message-ID: 3D29C376.8090504@xythos.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I know that in Oracle there are 'alter database begin backup' and 'alter
database end backup' commands that allow you to script your hot backups
through a cron job by calling the begin backup command first, then using
disk backup method of choice and then finally call the end backup command.

--Barry

Patrick Macdonald wrote:

>Zeugswetter Andreas SB SD wrote:
>
>
>>>As noted, one of the main problems is knowing where to begin
>>>in the log. This can be handled by having backup processing
>>>update the control file with the first lsn and log file
>>>required. At the time of the backup, this information is or
>>>can be made available. The control file can be the last file
>>>added to the tar and can contain information spanning the entire
>>>backup process.
>>>
>>>
>>lsn and logfile number (of latest checkpoints) is already in the control
>>file, thus you need control file at start of backup. (To reduce the number
>>of logs needed for restore of an online backup you could force a checkpoint
>>before starting file backup)
>>
>>
>
>Maybe I should have been more clear. The control file snapshot must
>be taken at backup start (as you mention) but can be stored in cache.
>The fields can then be modified as we see fit. At the end of backup,
>we can write this to a temp file and add it to the tar. Therefore,
>as mentioned, the snapshot spans the entire backup process.
>
>
>
>>You will also need lsn and logfile number after file backup, to know how much
>>log needs to at least be replayed to regain a consistent state.
>>
>>
>
>This is a nicety but not a necessity. If you have a backup end log
>record, you just have to enforce that the PIT recovery encounters
>that particular log record on forward recovery. Once encountered,
>you know that you at passed the point of back up end.
>
>Cheers,
>Patrick
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html
>
>
>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gautam Jain 2002-07-08 17:12:39 6.3.1: Core during initdb on SVR4 (MIPS)
Previous Message Bruce Momjian 2002-07-08 16:51:13 Re: Issues Outstanding for Point In Time Recovery (PITR)