Re: Remote On-line Backup

On Tue, 2006-03-28 at 14:31 -0600, Thomas F. O'Connell wrote:

> Here are the steps I'm proposing:
>
> 1. Set up archive_command in postgresql.conf on oldhost to archive to
> remote repository on newhost.
> 2. Perform base backup on oldhost. (I'll probably just use rsync to
> backup directly to newhost.)
> 3. On newhost, remove postmaster.pid from $PGDATA, disable
> archive_command in postgresql.conf, and create clean pg_xlog tree.
> 4. Stop the postmaster on oldhost.
> 5. If the WAL file referenced by the backup file in my archive
> directory on newhost is not archived when the postmaster is stopped,
> copy it from oldhost to pg_xlog on newhost.
> 6. Create recovery.conf on newhost.
> 7. Start the postmaster on newhost.
> 8. Rejoice when recovery.done appears.
>
> The part I most want to make sure I understand well enough is step 5,
> which I'm understanding to be a modification of steps 2 and 6 from
> section 23.3.3 in the docs. As I understand it, there's a pretty good
> possibility that the WAL file referenced by stop_backup() will not be
> archived by the time I stop the postmaster on oldhost. In which case,
> I should be in good shape to recover if I have a base backup, the
> archived WAL files up to that final file referenced by stop_backup(),
> and the partial segment file referenced by stop_backup(), which
> should be the only unarchived WAL segment file and just needs to
> exist in pg_xlog on newhost for things to run smoothly.
>
> Does this seem right? Or will I rather want to copy all the contents
> of pg_xlog from oldhost as they represent current (as of stopping the
> postmaster) unarchived WAL activity?

The steps above show a one-time migration. If that is what you want then
I suggest that the steps are:

1. Shutdown oldhost cleanly.
2. Copy all data directory and all files to newhost.
3. Edit any configuration file changes required
4. Startup on newhost
5. Delete files on oldhost so it is not started up again.

This will be slower, but has less risk if you are unsure of the process.

I'd suggest you follow your own procedure on a test box without step
(4), so you can check you've done it right before you stop oldhost for
good. Once you are happy with that, go for it in live.

Best Regards, Simon Riggs