On Thursday, April 03, 2014 02:48:03 PM Steven Schlansker wrote: > On Apr 2, 2014, at 3:08 PM, Jacob Scott <jacob.scott@xxxxxxxxx> wrote: > • pg_start_backup > • Take a filesystem snapshot (of a volume containing postgres data but not > pg_xlog) • pg_stop_backup > • pg_ctl stop > • Bring a new higher performing disk online from snapshot > • switch disks (umount/remount at same mountpoint) > • pg_ctl start ... with a recovery.conf in place when starting the new instance. > > Assuming you ensure that your archived xlogs are available same to the new > instance as the old And make sure they're archived to a different disk. > Another option you could consider is rsync. I have often transferred > databases by running rsync concurrently with the database to get a “dirty > backup” of it. Then once the server is shutdown you run a cleanup rsync > which is much faster than the initial run to ensure that the destination > disk is consistent and up to date. This way your downtime is limited to > how long it takes rsync to compare fs trees / fix the inconsistencies. > This would be simpler. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general