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
>
>
>
>
>
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) |