| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Kevin Kempter <kevink(at)consistentstate(dot)com> | 
| Cc: | pgsql-admin(at)postgresql(dot)org | 
| Subject: | Re: replay WAL segments without a "base backup" ? | 
| Date: | 2009-08-11 15:49:14 | 
| Message-ID: | 10039.1250005754@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-admin | 
Kevin Kempter <kevink(at)consistentstate(dot)com> writes:
> due to operator error at one of my client sites we're trying to restore a 
> deleted db.
> We did a restore with a pgdump that went fine but the dump is 3weeks old. they 
> do have WAL segments and they claim that the WAL segments are exactly in line 
> with the needed transactions - from a timing perspective.  However no base 
> backup with pg_start_backup() and pg_stop_backup() was ever run.
> Is there any way to trick postgres into thinking that it needs to play fwd 
> these WAL's?  Would it work to simply place them in a dir, create a 
> recovery.conf file pointing to that dir and restart the cluster?
No, there is exactly 0 hope here.  You would need a filesystem-level
backup to work from.  A restore from a pg_dump is not going to reproduce
any of the low-level details (such as OID assignments or tuple
placement) that WAL replay needs to have match.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Benjamin Krajmalnik | 2009-08-11 16:40:10 | Re: Max connections | 
| Previous Message | Kevin Grittner | 2009-08-11 15:49:04 | Re: replay WAL segments without a "base backup" ? |