Look into using the --xlog-method=stream (-Xs) option to pg_basebackup. That opens up a second replication stream and keeps all the WAL files generated during the basebackup so that you can bring up your basebackup to a consistent state at the point when the backup finishes. You'll have to be sure --max_wal_senders is set high enough to allow 2 replication connections during the backup.
hmm.. that's a better idea! I was using with the fletch mode.
You then also have to bring that slave up before the master removes all the WAL files from the pg_xlogs folder that that slave may need for replay to sync itself with the master. If you're not going to be bringing that slave up rather quickly after the base-backup, then you're going to have to archive your WAL files off somewhere else that the slave will have access to until its ready.
I store the wal_files into each server (3 slaves).
So each slave has the wal_files for 24h and them delete them.
If you can get upgraded to 9.4, you can use replication slots and not have to worry about the master removing WALs from pg_xlog when the associated slave is down.
I can't now.. it's a plan but only for the future (migration to AWS).