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?

export PATH


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.

  • Look at your cron logs. Is pg_basebackup on the PATH? is ts? Commented Jan 20, 2015 at 20:36
  • The only thing in the cron log is a single entry showing that the script is called. The cron is under the postgres user, which darn sure better have access to pg_basebackup. But again, the backup runs, it just doesn't work. I need to see the output to find out why.
    – epic_fil
    Commented Jan 22, 2015 at 19:05
  • Oh, if I run echo '' | ts '%F %T %Z' as the postgres user I see the timestamp, so ts seems to be reachable by that user.
    – epic_fil
    Commented Jan 22, 2015 at 19:06
  • cron overrides the PATH. It's a different envirionment and has nothing to do with what user is running. Please read "man cron" for more information. Commented Jan 22, 2015 at 22:13
  • Yes, I suppose you're right about the path. Other crons under pg user have no problem with ts, though, so I don't think that's it. And pg_basebackup runs, so that's not it either. I don't think it's a path problem.
    – epic_fil
    Commented Jan 22, 2015 at 23:09

2 Answers 2


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. =)


I would do this

Find out exactly where pg_basebackup is

#> which pg_basebackup 

Then add in the full paths in your cron job

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

Cron needs the full path to execute commands in the correct context.


Not sure if this will help you. Here is the backup command I typically used to backup a database.

usr/local/bin/pg_dump -Ft -c -p some_port -U username -h HOST database_name | gzip -9 > SOME_FILE

Keep in mind the following when using pg_dump

  1. If you backup with pg_dump (using other than the 'plain' format, ie. -Fp, which is the default) , you must restore the file with pg_restore

  2. The version of pg_dump must be newer or equivalent to the version of the server you are backing up.

  • I'll give that a try, but I'm a bit confused why that would affect the log output. The pg_basebackup does execute as seen by the (invalid) backup file that's created.
    – epic_fil
    Commented Jan 22, 2015 at 18:59
  • Hello @Phil, updated my answer Commented Jan 23, 2015 at 17:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.