"Another option is to use rsync to perform a file system backup. This is done by first running rsync while the database server is running, then shutting down the database server just long enough to do a second rsync. The second rsync will be much quicker than the first, because it has relatively little data to transfer, and the end result will be consistent because the server was down. This method allows a file system backup to be performed with minimal downtime."
Except that we plan on an initial rsync which we think might take a couple of days, then subsequent daily rsyncs for up to a week to keep it up to date till we stop the old database, rsync again, and start the new database.
We are performing backups to our production server exactly the same way. We have been through some problems while restoring and bringing up the database. If you are planning to take initial complete rsync with subsequent "incremental rsyncs", then you need to make sure that you have all the WAL archives starting from the initial rsync on Day 1.
Also are you doing the following?
1. pg_start_backup() - rsync - pg_stop_backup() ?
2. Please let us know your WAL Archive backup strategy.
Is there any way during that week, that we can verify whether our partially completed database move process is going to result in a database that starts up ok?
In general, yes, database can start up normally. Without WAL Archives, recovering to a particular time would not be possible.
Thanks
VB
