Re: incremental backups

Yes! Thanks you! That is exactly what I was looking for.

So I take it that this means that it is save to copy the current in
use WAL file even as it is being written to?
And it also means that if I copy it with my physical file system
backup then I should have the last file that I need to restore from
that physical backup?

So if I write my own backup_latest_WAL_file.sh script (I think I
found one on the list from Simon Riggs) then I can do what I need to
do before those todo items get done? Or will I need to wait till
postgres gives me the ability to safely copy the file?

On Jan 30, 2006, at 11:13 AM, Bruce Momjian wrote:

>
> Unfortunately, I think I understand your question. :-)
>
> These TODO items are what you need:
>
> * Point-In-Time Recovery (PITR)
>
> o Allow point-in-time recovery to archive partially filled
> write-ahead logs [pitr]
>
> Currently only full WAL files are archived. This means
> that the
> most recent transactions aren't available for recovery
> in case
> of a disk failure. This could be triggered by a user
> command or
> a timer.
>
> o Automatically force archiving of partially-filled WAL
> files when
> pg_stop_backup() is called or the server is stopped
>
> Doing this will allow administrators to know more
> easily when
> the archive contains all the files needed for point-in-
> time
> recovery.
>
> I will try to push to have them done for 8.2.
>
> ----------------------------------------------------------------------
> -----
>
> Rick Gigger wrote:
>> I guess my email wasn't all that clear. I will try to rephrase. I
>> am moving from using the old style pg_dump for backups to using
>> incrementals and want to make sure I understand the process before I
>> go about writing a bunch of scritps.
>>
>> To me setting up incremental backup consists of the following
>> components:
>>
>> 1) Setting up the WAL archiving. This one is trivial.
>> 2) Doing physical dumps of the $PGDATA directory. This one is once
>> again trivial.
>> 3) Knowing which physical dumps are Good and Not Good. For a given
>> physical dump D there is are WAL archive files Dstart and Dend for
>> which you much have Dstart and Dend and all files in between. If you
>> have all those files then the physical dump is Good. If you don't
>> have them then the dump is worthless to you.
>> 4) Knowing which dumps and which archive files can be deleted. This
>> depends on a number of factors.
>> a) How far back do you want to be able to do PITR
>> b) How much space do you have / want to use for PITR
>> c) Which physical dumps are Good and which are Not Good. (see #3)
>>
>> Now I think I have a pretty good plan here except for #3 (and so #4
>> then also suffers).
>>
>> Just as an example lets say I'm not concerned so much with PITR as I
>> am recovering from a db crash. I've got all the backups files saved
>> to my backup db server so I can failover to it if my primary db
>> server dies. I just want to make sure I've got one physical dump
>> that is good. (This is not my actual situation but it illustrated my
>> point better.)
>>
>> Now when I do a physical dump it is not a Good dump. That is I don't
>> have the end archive file necessary to recover from that physical
>> dump. That is to say that when I call pg_backup_start() then copy
>> $PGDATA then call pg_backup_stop() postgres might be on say WAL
>> archive file #5. Once the physical dump is completed WAL archive
>> file #5 hasn't been archived yet. I only have up to #4. So if I
>> delete my old physical dumps and all I've got is this most recent one
>> and my database crashes before #5 gets archived then I am hosed. I
>> have no good physical backups to start from.
>>
>> My main question is about the best way to figure out when a physical
>> dump is Good.
>>
>> One strategy is to always keep around lots of physical dumps. If you
>> keep around 100 dumps you can be pretty sure that in the space of
>> time that those physical dumps take place that at least one WAL file
>> was archived. In fact if you keep 2 physical dumps you can be fairly
>> certain of this. If not then you really need to space our your dumps
>> more.
>>
>> Is this making sense at this point?
>>
>> The problem is that the WAL archiving is triggered by postgres and
>> the rate at which the db is updated. The physical dumps are
>> triggered by cron and on a purely time based schedule. So in theory
>> if you had the physical dumps happening once a day but for some odd
>> reason no one updated the database for 4 days then all of a sudden
>> you'd have 2 physical backups and neither of them are good. If
>> you're db crashes during that time you are hosed.
>>
>> Maybe I am arguing a point that is just stupid because this will
>> never happen in real life. But in that it is my backups system that
>> I will be using to recover from complete and total disaster I just
>> want to have all my bases covered.
>>
>> So my ideas on how to determine if a physical dump is Good are as
>> follows.
>>
>> 1) When you do the physical backup (after dumping the $PGDATA dir but
>> before calling pg_stop_backup() ) determine the current WAL archive
>> file. Mark somewhere in the backed up physical dump the last file
>> needed for the dump to be considered good. Then your deletion
>> scripts can look at the WAL archive files you have and the last one
>> required for the dump to be Good and determine if the dump is Good or
>> not.
>>
>> 2) After doing the physical dump but before calling pg_stop_backup()
>> just copy the current WAL file to the physical dump. If that file
>> later gets archived then the restore commands overwrites your
>> partially completed one so it doesn't hurt but you know that when you
>> call pg_stop_backup() that that physical dump is good. (Is it ok to
>> copy the current WAL file while it is still in use?)
>>
>> Is anyone taking one of these or any other precautions to make sure
>> they've got a good physical dump or does everyone just keep a whole
>> bunch of dumps around, and then actually restore the dump to see if
>> it is good and if not go back to a previous dump?
>>
>> I hope that makes more sense.
>>
>> Thanks,
>>
>> Rick
>>
>> On Jan 27, 2006, at 3:33 AM, Richard Huxton wrote:
>>
>>> Rick Gigger wrote:
>>>> Um, no you didn't read my email at all. I am aware of all of that
>>>> and it is clearly outlined in the docs. My email was about a
>>>> specific detail in the process. Please read it if you want to
>>>> know what my actual question was.
>>>
>>> I'm not sure your email is quite right as regards the process. You
>>> need:
>>> 1. the filesystem backup
>>> 2. the WAL file indicated in the history-file
>>> 3. all the WAL files later than that
>>> to get up to "now".
>>>
>>> If you don't want to replay up to "now" then you will not need some
>>> of the more recent WAL files. You can't afford to throw them away
>>> though since you've got a rolling backup system running and the
>>> whole point is so you can recover to any point you like.
>>>
>>> You can however throw away any WAL files older than that indicated
>>> in the history file for your current filesystem-backup. You can
>>> then only restore from that point in time forward.
>>>
>>> There is no "last one" in the WAL set unless you know the time you
>>> want to restore to. Indeed, the "last one" might not be "full" yet
>>> and therefore archived if you want to restore to 10 seconds ago.
>>>
>>> Or am I mis-understanding your email too?
>>>
>>> --
>>> Richard Huxton
>>> Archonet Ltd
>>>
>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 4: Have you searched our list archives?
>>
>> http://archives.postgresql.org
>>
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square,
> Pennsylvania 19073
>