Re: Problem with PITR recovery - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Problem with PITR recovery
Date
Msg-id 1113897976.16721.2128.camel@localhost.localdomain
Whole thread Raw
In response to Re: Problem with PITR recovery  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: Problem with PITR recovery
List pgsql-hackers
On Tue, 2005-04-19 at 08:55 +0400, Oleg Bartunov wrote:
> On Mon, 18 Apr 2005, Simon Riggs wrote:
> > but I'm not sure it's best practice to delete them at that point. I
> > would recommend that users keep at least the last 3 backups. So, I'd
> > prefer the wording
> >
> > ...all archived WAL segments with names numerically less will no longer
> > be needed as part of that backup set. You may delete them at that point,
> > though you should consider keeping more than one backup set to be
> > absolutely certain that you are can recover your data.
> 
> I see that clear and deterministic procedure of online backup as I imagined
> earlier becomes fuzzy and blurred :) 

The process is involved and requires strictly observed administration
procedures, just as it does with other database systems. Each of them
have difficulties that need to be surmounted and require much thought to
implement. If PostgreSQL is the first DBMS on which you have attempted
to implement transactional archive recovery then you will definitely
find it hard, just as most Oracle and SQLServer DBAs don't understand
how their log recovery systems work either.

> This is obviously not suited even
> for my notebook.

Thats a pretty silly comment Oleg. 

Since most laptops require portability as the main objective and that
usually requires or at least must frequently expect disconnection from
networks and other peripheral devices such as tape units, then no, the
PITR design isn't suitable in general for laptop use. If you use your
notebook as a production system with online archiving then PITR is
suitable.

PITR was designed to offer data protection for major production systems.
My experience was that these sites would have a reasonable stream of
transactions coming through, making the time between log file switches
somewhat predictable and usually every few minutes. The use case of a
very low transaction rate system was not considered fully since it was
felt that people in that situation would be less bothered to protect
their data with a rigorous backup procedure, leaving the issue we have
been discussing.

If you want recoverability, use PITR. If you choose not to use PITR,
thats fine. If you'd like to help make it better, that's fine too.

Best Regards, Simon Riggs




pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Problem with PITR recovery
Next
From: "Ilya A. Kovalenko"
Date:
Subject: Re: inet increment w/ int8