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.
