Why won't pg_basebackup output go to log?

I run a nightly pg_basebackup from a cron job (Postgres 9.3 on debian "wheezy"), but the backup has been failing. It actually creates output, but the .tar file is corrupt and won't extract. I went to my log file, only to find it is 0 bytes. Could anybody tell me what is wrong with my setup? Why isn't the log file saving the output of pg_basebackup?

#!/bin/sh
PATH=$PATH:/usr/bin
export PATH

BASEBACKUP_LOG=/var/log/postgresql/basebackup.log
[ -f $BASEBACKUP_LOG ] && mv -f $BASEBACKUP_LOG $BASEBACKUP_LOG.old

BACKUP_PATH=/path/to/backup/$(date +%F)
pg_basebackup -D $BACKUP_PATH -Ft -z -v 2>&1 | ts '%F %T %Z' &> $BASEBACKUP_LOG

The way I'm reading the pg_basebackup line, I think it should redirect stderr to stdout, pipe the combined stream to the ts function (prepend timestamp to a line) and write that to the path at $BASEBACKUP_LOG. Am I missing something obvious here?

On advice given below, I added an explicit reference to the path for ts & pg_basebackup (both reside in /usr/bin). There was no change in behavior.

You specified #!/bin/sh in your script's shabang line. This gives you a POSIX shell. Under POSIX style shells you can only specify numbers for redirection, as noted in the documentation under section 2.7 Redirection.

&> is a "bashism", shown here in the bash documentation under io-redirection.

This can cause undefined behavior under POSIX compliant shells acting as /bin/sh, and by running shellcheck -s sh on the contents of the script in the above question, as stated under the warning for SC2039, which warns that &> is non-standard, and might fail under different contexts.

You might have better luck, if you specify #!/usr/bin/env bash, or if you change the way that you're doing the redirection, if you want to keep using the #!/bin/sh shell.

As for the $BACKUP_PATH, you might want to double-quote it to prevent any sort of weirdnesses with globbing or word splitting that can happen, which could also possibly explain the zero size tar file.

Hope that helps. =)

StackExchange Database Administrators Q#89730, answer score: 2