- Shut down and blow away the old stage.
- Move the pre-staged directory to take the place of the blown away one.
- Startup that directory, have it run through recovery, and open. At this point, the people who need to use stage can go on their merry way, and the next steps happen in the background.
- Recreate the new pre-staged directory by copying over (or untarring) the most recent base backup.
- create a new recovery.conf in the new pre-staged directory to tell it how to run through recovery once you get back to step 3 again. e.g. restore_command from a wal archive
- Wait until someone needs a fresh version of stage, and then go to step 1.
Of course the first time through all of this, you have to start at step 4, because the pre-stage doesn't yet exist until the first time it is created. Moving an entire directory, if you move it within a filesystem, is usually very fast even if the directory contains a lot of data. So steps 1-3 can be done very fast, often less than 30 seconds. Step 4 is slow, but no one has to wait for it, it happens in the background. Of course if you want to start a new step 1 before previous step 4 finishes, you have to wait.
Once step 3 becomes annoyingly slow, it is time to take a new base backup so that less WAL needs to be replayed.
A variant of this is that not only do you pre-stage the server, but you actually have it up and running as a warm standby on a variant port number. Then all you need to do is stop the old stage server, promote the pre-staged one, change its port number back to the main one, and bounce it to pick up that change. It could take less than a second, if the promotion checkpoint is fast enough. You can have stage_a and stage_b, where you are using one of them while the other is being rebuilt.
Of course to do this, the stage server needs to have enough space for two full copies of the database. And you have to have a wal archive, although it would be possible to modify this to use streaming with a carefully chosen value of wal_keep_segments.