Le 11/02/2010 à 20:39:30-0300, Alvaro Herrera a écrit > Albert Shih wrote: > > Le 11/02/2010 à 17:00:33-0600, Kevin Grittner a écrit > > > Albert Shih <albert.s...@obspm.fr> wrote: > > > > > > > I would like to known what's best way to manage the WAL. > > > > > > You should design a policy which meets your particular needs. We > > > keep two PITR base backups and all the WAL files from before the > > > start of the first (based on the information in the backup file) > > > through current. We also save monthly archival PITR base backups > > > with just the WAL files needed to restore them (again, based on the > > > backup files). Your needs may be different. > > > > Hum...I'm not sure I really understand what you doing. > > > > Maybe I'm doing everything wrong but this is what I did : > > > > t=0 SELECT pg_start_backup('label'); > > rsync /pgsql backup_server:/ > > SELECT pg_stop_backup(); > > > > t> 1 cron with rsync /WAL backup_server: > > > > but after some time the /WAL become big. So is it a solution to > > stop the database, delete everything in /WAL and begin a new cycle (t=0 > > select etc...) ? > > You could do that if you wanted, but there's a window during which you > have no backup at all. Perhaps it's better to take a second base > backup, start archiving to a different directory /WAL2, and when the > second base backup is done you can delete /WAL
Thanks for you help and advise. But for me that's not be a problem because I can stop the database when I want. And my database is huge (~800go) and important but not critical. The critical database is very small (~ 1Go) and for this I use pgdump. Regards. JAS -- Albert SHIH SIO batiment 15 Observatoire de Paris Meudon 5 Place Jules Janssen 92195 Meudon Cedex Heure local/Local time: Ven 12 fév 2010 12:38:53 CET -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin