Thanks for the info, Raid is definitely in the picture,
I'm worried about the less likely but definitely possible case where
your entire raid array gets smoked (or just the two disks you care about)
and I don't want to recover from a 24 hour backup.
The two options I can see are one way replication to a slave server or
incremental dumps like sybase or oracle (or dare I say mysql)
Replication would be desirable if downtime was a huge issue but I can
tollerate a small amount of downtime but not the loss of a days worth of
data.
The reason I'd rather not have full blown replication is that I'm going to
have a large cluster of postgres database machines acting as one large db
and if I use replication then I need a second instance of postgres for
each one. I'd much rather write a continuous recovery log to a buddy
machine for each one.
Thanks,
Alex.
On Fri, 2 Feb 2001, Alex Pilosov wrote:
> On Fri, 2 Feb 2001, adb wrote:
>
> > Is there any way to have up to the minute recovery from a disk
> > failure in postgres?
> RAID1? :)
>
> > Is there a timeframe for the recover from WAL feature?
> If you are asking if WAL logs can be reapplied to an database dump, the
> answer is currently no. I think it'd be a great idea though.
>
> One problem there is that WAL is very low-level currently. I.E. it details
> 'page modified, data modified'. When you restore from pg_dump, your pages
> will look totally different from the moment you dumped.
>
> You can try to solve it using a lvm snapshot to backup raw files, MAYBE
> it'll just work. But, we'll need to have a switch that will turn WAL
> delete-old-log-on-checkpoint off, and leave deletion to your backup tool..
>
> Vadim, comments? What'd happen if I start postgres using database files
> snapshotted at one point, PLUS all WAL write-ahead files? Would it realize
> it needs to reapply WAL? Is the "list of WAL files" kept somewhere or
> it'll look on disk for all files named *.chk?
>
> -alex
>