On Tuesday 11 August 2009 09:49:14 Tom Lane wrote: > Kevin Kempter <kevink@xxxxxxxxxxxxxxxxxxx> 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 What if we could do a pg_start_backup on the running cluster (the one that's 3 weeks behind, tar up the file system, do a pg_stop_backup and walk thru the recovery steps? Would there be a way to force postgres to recognize the wal segments that werte created earlier (which according to the client include all tx from 3 weeks ago thru today) ? -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
