Re: database backup
От | Josh Jore |
---|---|
Тема | Re: database backup |
Дата | |
Msg-id | Pine.BSO.4.44.0207062333390.22974-100000@kitten.greentechnologist.org обсуждение исходный текст |
Ответ на | Re: database backup (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-general |
Hey - you *could* consider logging your commands elsewhere and use *that* for incrementals. It wouldn't have all the nice features of transactions so it might take some manual effor to recover but you may not need anything beyond a naive implementation. So alter your application to save all SQL that can modify the database and use that to augment your normal scheduled backups. Joshua b. Jore ; http://www.greentechnologist.org On Sun, 7 Jul 2002, Martijn van Oosterhout wrote: > On Sat, Jul 06, 2002 at 11:03:12PM -0400, Lamar Owen wrote: > > On Saturday 06 July 2002 10:59 pm, Doug Fields wrote: > > > If you want to "incrementalize" it, you could always keep a base, and diff > > > the new dump against it, and store just the diff. > > > > > Be sure to run the output through bzip2 (or gzip -9) to save space. > > > > This doesn't work as well in practice as it would seem. Due to funkiness, the > > output of pg_dump isn't (or wasn't the last time I tried diffing dumps) > > necessarily always in the same order. > > Not just that, diff wants to be able to read the whole file in. Last I tried > to diff two 500MB files on a 256MB machine it was not pretty. > > -- > Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > > There are 10 kinds of people in the world, those that can do binary > > arithmetic and those that can't. > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > >
В списке pgsql-general по дате отправления: