Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 7C3214760E4 for ; Tue, 8 Oct 2002 10:04:52 -0400 (EDT) Received: from smtp3.ihug.com.au (smtp3.ihug.com.au [203.109.250.76]) by postgresql.org (Postfix) with ESMTP id 955D3475F32 for ; Tue, 8 Oct 2002 10:04:51 -0400 (EDT) Received: from p576-tnt1.mel.ihug.com.au (postgresql.org) [203.173.162.68] by smtp3.ihug.com.au with esmtp (Exim 3.22 #1 (Debian)) id 17yuya-00031E-00; Wed, 09 Oct 2002 00:04:44 +1000 Message-ID: <3DA2E5F8.EA496ADD@postgresql.org> Date: Wed, 09 Oct 2002 00:04:40 +1000 From: Justin Clift X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Erwan DUROSELLE Cc: itvthor@sdf.lonestar.org, kleptog@svana.org, pgsql-general@postgresql.org Subject: Re: Hot Backup References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/454 X-Sequence-Number: 31452 Hi Erwan, Erwan DUROSELLE wrote: > As someone said, Replication may be a way to reduce the risks. Yes, it can, but it all depends on how much the data is worth, what kind of load happens, etc. Something as simple as a master->slave replication setup will do, because the master would generally be the beefy box doing processing, and the slave database server only receives changes, etc. Useful for lots of circumstances, although not the only solution. :-) Regards and best wishes, Justin Clift > E.D. > > ------------------------------------------------------------------------------- > Erwan DUROSELLE // SEAFRANCE DSI > Responsable Bases de Données // Databases Manager > Tel: +33 (0)1 55 31 59 70 // Fax: +33 (0)1 55 31 85 28 > email: eduroselle@seafrance.fr > ------------------------------------------------------------------------------- -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi