Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

We want to programmatically detect errors in cron scheduled pg_dumps.

Apart from cheking whether or not the log file ends in "pg_dump: saving database definition":

What other tell-tale string can I grep for in order to programatically check a dump is ok.

share|improve this question

1 Answer 1

The main indicator is the exit status of the pg_dump command. If it's non-zero, then something went wrong otherwise it worked all along. This is the implicit contract between any command and the shell, and breaching it would be a bug. And it's also testable when the sub-command could't be launched at all.

Here's a basic skeleton in Unix shell that tests the exit code and acts accordingly:

d=`date +%Y%m%d`
dump=/path/to/backups/daily-backup-"$d"
error=/path/to/backups/errors-backup-"$d".txt

pg_dump -U username dbname >$dump 2>$error
code=$?
if [ $code -ne 0 ]; then
  echo 1>&2 "The backup failed (exit code $code), check for errors in $error"
fi

It is necessary to keep the error messages in durable storage so that they can be analyzed later. When no error at all occurs, the file for errors should be there but empty, unless the -v option is used but it's intentionally not in the above script.

About the message: saving database definition

It is displayed along with lots of other informational messages only when using the verbose (-v) option. The problem is that in case of error, these messages will be mixed with error messages, and it requires some level of expertise to distinguish what's normal from what's not.

share|improve this answer
    
Would this: $pg_dump $BACKUP_OPTIONS --file $BACKUP_FILE $DATABASE >> $BACKUP_FILE.log 2>&1 do the same as this: pg_dump -U username dbname >$dump 2>$error ? If not, please explain. I have doubts about the 2>&1 part vs 2>$error. –  user1598390 Aug 14 '13 at 15:57
    
@user1598390: I believe it's the same in practice. But strictly speaking, when --file is used, the standard output channel is free for whatever message pg_dump could decide to output, so I wouldn't be too confident about it. In backup scripts especially, better safe than sorry. –  Daniel Vérité Aug 14 '13 at 16:10
    
I didn't understand "the standard output channel is free for whatever message pg_dump could decide to output". –  user1598390 Aug 14 '13 at 16:20
    
With pg_dump >file.dump the standard output is dedicated to the dump file. With pg_dump --file file.dump, it's not, so if it wanted, the program could print some messages to the standard output in addition to dumping the database into the file. –  Daniel Vérité Aug 14 '13 at 17:52
    
The problem is that I need to check for errors in the dump asyncronously. That's why I need to check a logfile. It's the only why to check for errors off-line. –  user1598390 Oct 8 '13 at 19:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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