Re: > 16TB worth of data question

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Jeremiah Jahn <jeremiah(at)cs(dot)earlham(dot)edu>
Cc: Jan Wieck <JanWieck(at)yahoo(dot)com>, postgres list <pgsql-general(at)postgresql(dot)org>
Subject: Re: > 16TB worth of data question
Date: 2003-04-28 15:42:56
Message-ID: Pine.LNX.4.33.0304280941110.2646-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 28 Apr 2003, Jeremiah Jahn wrote:

> On Fri, 2003-04-25 at 16:46, Jan Wieck wrote:
> > Jeremiah Jahn wrote:
> > >
> > > On Tue, 2003-04-22 at 10:31, Lincoln Yeoh wrote:
> > > > How about backups? Backing up 2-16TB needs a bit more planning and design.
> > > The proposed solution here is to have the raid controller mirror accross
> > > the street to a similar system. At what point do off line backups become
> > > pointless?
> >
> > Fine, so you have a 10 MBit link across the "street" in the budget but
> > nothing to buy decent server hardware? 4TB (just to be around where you
> > expect to be after 6 months or so) per year means an average MBit per
> > second ... on a second thought, the 10 MBit will probably not be enough
> > to satisfy peak times.
> actually they have fiber accross the street. So the SAN can just move
> stuff right across at 2Gbps.
>
>
> >
> > Who made that mirror proposal and where is your PITR capable backup? I
> > once saved a company by doing PITR. They ran an Oracle database on two
> > software mirrored Raid5 systems ... and the application was
> > misconfigured and deleted too much data (way too much).
>
> I don't belive that postgres does PITR yet. However, this is a system
> that doesn't need to be 24/7, so we can shut down the db and dump the
> whole thing to tape every day with no problem.

Don't shut it down and backup at file system level, leave it up, restrict
access via pg_hba.conf if need be, and use pg_dump. File system level
backups are not the best way to go, although for quick recovery they can
be added to full pg_dumps as an aid, but don't leave out the pg_dump,
it's the way you're supposed to backup postgresql, and it can do so when
the database is "hot and in use" and provide a consistent backup
snapshot.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Nigel J. Andrews 2003-04-28 15:48:32 timestamps and dates
Previous Message Eric D Nielsen 2003-04-28 15:23:02 Doxygen/Javadoc-esque SQL DDL documentor?