Re: How to determine a database is intact?

Hi,

Am Sa, den 04.09.2004 schrieb Wes um 22:51:
> On 9/4/04 2:42 PM, "Jan Wieck" <JanWieck@yahoo.com> wrote:
>
> > Why isn't doing a restore of those reasonable?
>
> Because of the size and time required.  Right now, it takes at least 24
> hours, with a full hardware configuration (multi-CPU, 8 disk SCSI RAID,
> etc).  That is going to do nothing but increase.  Extrapolating linearly the
> *current* load, it will take at least 4 days to load when the database size
> peaks.
...

> As for your earlier question of cascading errors, consider a file system - a
> type of database.  If you get a file system error and correct it quickly,
> you usually will lose nothing.  If, however, you ignore that error, it is
> likely to get worse over days or weeks.  Other errors will crop up as a
> result of the bad information in the first one.  At some point, the file
> system corruption may become so bad that it can't be recovered.  Format and
> reload.  I have seen this on NTFS, UFS, HFS/HFS+, and even ReiserFS.
> Journaling greatly reduces, but doesn't eliminate, this problem.  There are
> tools that will scan your file system and guarantee it's integrity, or fix
> the errors (or attempt to fix them) if it finds any.  I was looking for
> something similar for a Postgres database.

Well, with such a huge database you probably should consider
different backup strategies, a filesystem with snapshot
support (XFS?) could help where you can copy a state of the database
at any time - so you can backup the database cluster without
stopping the postmaster. Also replication via slony could be
an option.

The best tool to verify the backup is probably the postmaster
itself. I really doubt any other program would be smaller and
faster :)

(Filesystems provide a tool because the actual filesystem code
is a kernel module)

Regards
Tino