Re: Online Backup and WAL archives
От | Pallav Kalva |
---|---|
Тема | Re: Online Backup and WAL archives |
Дата | |
Msg-id | 4200E2DC.6020803@deg.cc обсуждение исходный текст |
Ответ на | Re: Online Backup and WAL archives (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Online Backup and WAL archives
|
Список | pgsql-admin |
Hi Tom, If I want to restore to a particular point in time lets say to the point in time like a day back when one of my table was dropped accidentally and if i want restore the archive log only to that particular archive log file . what is the procedure we should follow ? just keep the archive logs in the directory until the last archive log file i need or is there a command something like " restore only until at this archive log file " ? Also what happens to the transaction log files in pg_xlog directory in this scenario ? do i have to still keep them or they get created by themself since i am going a day back ? Is this possible in postgres 8 Thanks, Pallav Tom Lane wrote: >Morus Walter <morus.walter@tanto.de> writes: > > >>The documentation says >>' To make use of this backup, you will need to keep around all the >>WAL segment files generated at or after the starting time of the backup. ' >>Now I'm wondering how much of these WAL segment files do I really need >>in order to recover the databases to a consistent state. >> >> > >If you are satisfied with recovering to the state shortly after you >completed the backup, then it would be sufficient to have a set of WAL >files spanning the time period in which the backup is done. I'm dubious >that this is necessarily an improvement over a pg_dump backup, though. > > > >>I expect the online backup to faster on recovery than an SQL dump, since >>the latter would imply recreation of indexes during recovery. >> >> > >Is that assumption founded on any hard evidence? > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > > >
В списке pgsql-admin по дате отправления: