Re: Incremental backup

Christopher Browne wrote:
> What PITR generally consists of is the notion that you want to recover
> to the state at a particular moment in time.
>
> In O*****-nomenclature, this means that you recover as at some earlier
> moment for which you have a good backup, and then re-apply changes,
> which in their terms, are kept in "archive logs," which are somewhat
> analagous to WAL files.

Yeah, that's pretty much what I figured.

Oracle has something they call "rollback segments" which I assume are
separate bits of data that have enough information to reverse changes
that were made to the database during a transaction, and I figured
PITR would (or could) apply particular saved rollback segments to the
current state in order to "roll back" a table, tablespace, or database
to the state it was in at a particular point in time.

As it is, it sounds like PITR is a bit less refined than I expected.

So the relevant question is: how is *our* PITR going to work? In
particular, how is it going to interact with our WAL files and the
table store? If I'm not mistaken, right now (well, as of 7.2 anyway)
we round robin through a fixed set of WAL files. For PITR, I assume
we'd need an archivelog function that would copy the WAL files as
they're checkpointed to some other location (with destination names
that reflect their order in time), just for starters.

It'd be *awfully* nice if you could issue a command to roll a table
(or, perhaps, a tablespace, if you've got a bunch of foreign keys and
such) back to a particular point in time, from the command line, with
no significant advance preparation (so long as the required files are
still around, and if they're not then abort the operation with the
appropriate error message). But it doesn't sound like that's what
we're talking about when we talk about PITR...

I wouldn't expect the O***** docs to be particularly revealing about
how the database manages PITR at the file level, but if it does, would
you happen to know where so I can look at it? What I've seen so far
is very basic and not very revealing at all...

--
Kevin Brown kevin(at)sysexperts(dot)com