Re: incremental backups? - Mailing list pgsql-general

From Jan Wieck
Subject Re: incremental backups?
Date
Msg-id 40EAD00C.2020002@Yahoo.com
Whole thread Raw
In response to Re: incremental backups?  (Martin Marques <martin@bugs.unl.edu.ar>)
List pgsql-general
On 7/3/2004 9:11 AM, Martin Marques wrote:

> El Vie 02 Jul 2004 18:39, Jan Wieck escribió:
>> On 6/22/2004 11:51 PM, mike g wrote:
>> > Slony version 1 is supposed to be live very soon.  You can test beta3 if
>> > you like.
>>
>> Slony-I version 1.0 is out now. It does not contain incremental backup.
>> This feature is on the TODO list for 1.1.
>
> I'm very interested in this.
> How is it that a replication system would give the ability of doing
> incremental backups?

The information Slony collects with triggers basically consists of
INSERT, UPDATE and DELETE statements that cause exactly the same changes
on a slave, that have been performed on the master. If it is possible to
extract a consistent data snapshot and to know exactly what actions are
included in that, and which need to be redone after ...

There isn't much of a difference between applying the changes to a
database and writing SQL statements into files.

> How would these incremental backups compare to Informix's level backups (level
> 0 is a full backup, 1 are the differences from the last 0, and 2 are the
> differences from the last level 1 BU)?

I wonder how informix does that sort of level backup. It sounds very
much like a filesystem dump, but on a database level I can't really
imagine this. Especially with an MVCC database like PostgreSQL.

There will be no levels. Slony will provide a dump, and then
incrementals. One advantage will be that the incrementals are just plain
SQL scripts containing INSERT, UPDATE and DELETE operations. One usually
does PITR because a misbehaving application corrupted the data from a
logical point of view. Finding the offending statement with grep in
those files will ultimately lead to the exact point in time to wich the
DB can be rolled forward. Plus, it will be easy to analyze what had been
done after that point, based on the wrong data.


Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-general by date:

Previous
From: Duane Lee - EGOVX
Date:
Subject: Re: Formatting Function..
Next
From: ruben
Date:
Subject: Re: server closed the connection unexpectedly