Re: BAcking up a Postgres Database
От | Tim White |
---|---|
Тема | Re: BAcking up a Postgres Database |
Дата | |
Msg-id | 3A5DC9D6.6F3A32E0@kc.rr.com обсуждение исходный текст |
Ответ на | BAcking up a Postgres Database (D Johnson <dspectra@home.com>) |
Ответы |
Re: BAcking up a Postgres Database
Re: BAcking up a Postgres Database |
Список | pgsql-admin |
Does this provide true "point of failure" recovery? This sounds like no more than a cold backup, which does not provide "point of failure" recovery. I think the original question is very valid. Postgres does not, to my knowledge, support transaction logging, which is necessary for this style of recovery. In Oracle, you restore the data files from a previous backup and then re-apply the transaction (archive) logs, a process called "rolling forward", then you can open the database for use, and it is in the state just prior to the failure. I've seen some creative dialogue on this list about writing to multiple database instances to have a live backup, and some regarding logging each SQL statement, but the introduction of a transaction archiver into the engine itself would make this process much easier and make Postgres more attractive to sites currently using the major commercial database packages, IMHO. Let me know if any of this is blatantly incorrect. Tim White Ragnar Kjørstad wrote: > On Wed, Jan 10, 2001 at 05:57:21AM -0600, D Johnson wrote: > > Will the postgres community ever consider creating a decent backup > > capability. Currently the way to create backups is through a Cron job. > > For Postgres to ever be considered a true production systen then some > > sort of transactional tracing has to be done. Otherwise you risk the > > potential of losing quite a bit of data. > > You can take a snapshot of the database-device (while the database is > down), and backup from the snapshot to avoid this problem. > > You need a volum-manager that support snapshot, but AFAIK most do. > > -- > Ragnar Kjørstad > BigStorage
В списке pgsql-admin по дате отправления: