On Thursday, April 03, 2014 02:48:03 PM Steven Schlansker wrote:
> On Apr 2, 2014, at 3:08 PM, Jacob Scott <jacob.scott@gmail.com> 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.
