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.
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? |