Re: backup database by cloning itself

----- Original Message -----
From: "Ron Johnson" <ron.l.johnson@cox.net>
To: <pgsql-general@postgresql.org>
Sent: Wednesday, February 14, 2007 3:46 PM
Subject: Re: [GENERAL] backup database by cloning itself


>>
>> It seems to me that if you really want a historical record of what
>> certain tables looked like in the past, it would be smarter and more
>> accurate to create triggers, for each possible operation, that store the
>> relevant details in an audit table including especially who made the
>> edits and when. This strikes me as being much less work than developing
>> code that processes so many backups.
>
> I dunno about that.  We use triggers to populate log tables that get
> extracted, truncated then loaded into a reporting db every night.
> Because of the night time batch cycle, there is no quiescent time to
> do this, so we have 2 log tables, and the triggers alternate which
> log table to insert into, depending on whether the day number is
> even or odd.
>
> That's in addition to the trigger logic to insert into history tables.
>
> It's a royal pain.

Sounds painful, but not as painful as trying to do the same thing with a
suite of backups and client code to read the backups.  Or maybe the latter
task is easier than it looks at first glance.

Doesn't the amount of pain depend on the amount of traffic your servers see,
the capability of the hardware you can devote to the task, what you're doing
with the history tables, &c.?  When I've worked on this kind of problem,
everything was in a single DB. The traffic, though, was low enough that for
daily reports a simple view of the log selecting only the previous day's
data, was sufficient, but only occasionally used.  The principal reason for
the log was to support accountability, to know who made changes, and when,
and who knew what when.  Historical reconstructions were required, e.g.,
only when something went awry and there was a need to know if a good
decision was made based on bad data or a bad decision was made based on good
data, or, e.g., during an audit of the business processes and decision
support systems.

Cheers,

Ted