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@xxxxxxxxxxxxxxxx | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square,
Pennsylvania 19073
