| From: | Jeff <threshar(at)torgo(dot)978(dot)org> |
|---|---|
| To: | David Rees <drees76(at)gmail(dot)com> |
| Cc: | Matthew Wakeling <matthew(at)flymine(dot)org>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, A B <gentosaker(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: [PERFORMANCE] Buying hardware |
| Date: | 2009-01-26 19:58:05 |
| Message-ID: | 574C28BA-7A41-4134-92E6-49282D37903E@torgo.978.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Jan 26, 2009, at 2:42 PM, David Rees wrote:
>
> Lots of people have databases much, much, bigger - I'd hate to imagine
> have to restore from backup from one of those monsters.
>
If you use PITR + rsync you can create a binary snapshot of the db, so
restore time is simply how long it takes to untar / whatever it into
place. Our backup script basically does:
archive backup directory
pg_start_backup
rsync
pg_stop_backup
voila. I have 2 full copies of the db. You could even expand it a bit
and after the rsync & friends have it fire up the instance and run
pg_dump against it for a pg_restore compatible dump "just in case".
It takes a long time to restore a 300GB db, even if you cheat and
parallelify some of it. 8.4 may get a pg_restore that can load in
parallel - which will help somewhat.
--
Jeff Trout <jeff(at)jefftrout(dot)com>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2009-01-26 20:00:35 | Re: [PERFORMANCE] Buying hardware |
| Previous Message | David Rees | 2009-01-26 19:42:18 | Re: [PERFORMANCE] Buying hardware |