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
