Brad Littlejohn <blittlejohn(at)posportal(dot)com> wrote:
> Okay.. then let's ask this. If I take a file-based backup of the
> source database now, the previous WAL logs should be irrelevant,
> right? The reason I ask, is that one of my developers made a
> change to 2 tables last night, didn't wrap his changes around a
> begin/commit/rollback statement, and dropped a column he needs
> back. The WAL logs are now the only place the column and the data
> for that column exist. If I took a file-based backup of the
> current database (read: today), could I apply the WAL logs (from
> up to when they made that change) to that file-based backup to get
> the data back that he needs?
How much of the data was in that column when the pg_dump was run?
You could certainly recover any of that. Data entered after that
would be in the WAL file stream somewhere, but picking it out would
be a very tedious and time-consuming process. I'm not aware of any
tools which would make that easy, but capturing a file-based copy of
your database as soon as possible, as well as keeping that old
pg_dump output, would be important if you have any hope of sifting
that out. I'd start by doing those, "just in case" -- but your best
bet would be to try to find some other source to re-enter the data,
if at all possible.
Then be sure to follow backup directions from the documentation more
closely, and *never* believe that any backup technique is working
until you've tested a restore. On any product. I don't like to
trust that any particular *backup* is good until I've restored it,
even if the process hasn't changed.
-Kevin