Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am using automongobackup to, well, automate the backups of mongodb.

output from the script (to STDERR) has the following exceptions (but the backup completes, and the dump files are created)

###### WARNING ######
STDERR written to during mongodump execution. 
The backup probably succeeded, as mongodump sometimes writes to STDERR, but you may wish to scan the error log below:
exception: connect failed
exception: connect failed
exception: connect failed
exception: connect failed
exception: HostAndPort: bad port #
exception: connect failed
exception: connect failed
exception: connect failed
exception: connect failed
exception: connect failed
exception: connect failed

I know that the Host & Port are correct.

If I run mongodump --host=127.0.0.1:27017 --journal (which is the effective command from automongobackup based on the options set and my reading of the src code) everything runs clean without any error reporting and the dump files are created as expected.

Why would automongobackup report connection errors, even tho it does create the dump files, yet a straight call to mongodump does not?

  • Debian 6.0 Lenny (from Linode image: Latest 3.2 (3.2.1-x86_64-linode23))
  • AutoMongoBackup VER 0.9
  • mongodb v 2.0.2
share|improve this question
add comment

3 Answers 3

up vote 2 down vote accepted

I have dived into the code of automongobackup and while shell scripts are not my forte:

The short answer

Set the following in the config section:

# Choose other Server if is Replica-Set Master
REPLICAONSLAVE="no"

I had that set to 'yes' (since I hope to move to a replica set before long) - and was being emailed exactly the errors the OP provides, with another email containing the successful log from the script i.e. the same issue.

The long answer

The wording on that config option implies that the setting will only have an effect if this is in a replica set. But later in the code you see that having that config variable set to 'yes' makes it execute

mongo --quiet --eval       'rs.conf().members.forEach(function(x){ print(x.host) })'

i.e. it asks mongo what the members of the replica set are. However if you're not in a replicaset, that returns:

TypeError: rs.conf() has no properties

From there one thing leads to another inside the script and the errors are presumably the result. From the error messages I'm guessing it tries somewhere to connect to a secondary server that

  • doesn't exist..
  • because it isn't configured..
  • because there's no configuration.

I decided against using gWaldo's script because I think automongobackup is more likely to be maintained and improved into the future.

In summary the code that detects if you're in a replica set and how to handle it if you're not needs improving. Setting that option to 'no' will fix it until the script improves - which unfortunately I'm ill qualified to do.

share|improve this answer
    
Congratulatulations on finding the answer, but it doesn't appear that the automongobackup is being maintained; the last update is 3 months ago. With that said, I should put mine up on GitHub –  gWaldo Mar 27 '12 at 1:47
1  
Should, and have: github.com/gwaldo/mongoBackup –  gWaldo Mar 27 '12 at 2:05
1  
Great: thanks gWaldo! The maintainer of automonogbackup did respond saying s/he intends to update their script taking account of this 'bug'. But there are reasons to use either. –  Adam Knowles Mar 28 '12 at 13:05
add comment

Without diving into their code, I can't tell you why it's throwing errors.

What I can say is that you've already invested more effort in finding that (apparently broken) tool than if you'd just written a quick shell script to call mongodump (even with rotations) and add it to your crontab.

Here's an example of what you can do if you want to have a daily backups for one week, but keep the Sundays in perpetuity:

#!/bin/bash

## Determine day of week. If Sunday, do an archival backup.
## Otherwise, do by day of week.

DOW=`/bin/date +%a`
REPLSET="mlg0"

if [ $DOW == "Sun" ]; then
  DSTRING=`/bin/date +%Y-%m-%d`
  ARCHSTRING="$REPLSET.$DOW.$DSTRING.tgz"
else
  ARCHSTRING="$REPLSET.$DOW"

fi

BACKUP_DIR="/var/shared/backup/mongodb/$ARCHSTRING"

CRON="backup.$ARCHSTRING"
LOCKFILE="/tmp/cron.$CRON.lock"

if [ -f "$LOCKFILE" ]; then
    /usr/bin/logger -t mongodb_backup "$ARCHSTRING locked; skipping"
    exit 0
fi

touch "$LOCKFILE"
/usr/bin/logger -t mongodb_backup "$ARCHSTRING started"
rm -f $BACKUP_DIR
mkdir $BACKUP_DIR
/opt/mongodb-2.0.1/bin/mongodump --host server.domain --out $BACKUP_DIR
rm -f "$LOCKFILE"
/usr/bin/logger -t mongodb_backup "$ARCHSTRING finished"

Now a git repo: https://github.com/gwaldo/mongoBackup

share|improve this answer
    
Thanks for the script, I'll take a look at it. Since the automongobackup was referenced on the mongoDB site, I was hoping to use it, as it seemed to be a good standard approach. <shrug> Not sure about accepting this as an answer, since my question is more about the errors in the automongobackup script, but I do appreciate it. –  lhagemann Feb 4 '12 at 21:24
    
I hope it helps, but if you think that you're doing everything right and automobgobackup is throwing errors, the only ways to go are to 1) dig into the source code, 2) file a bug report with them, or 3) make or move on to something that works. It's entirely up to you how you'd like to proceed, but as I see it, these three things are the only real options. –  gWaldo Feb 5 '12 at 15:20
    
accepting this answer, as the alternative script is valid. –  lhagemann Feb 13 '12 at 2:29
    
Another upvote for this answer. I was having the exact same problem. Decided to use this script instead in the end. Does exactly what I was looking for –  Patrick O'Doherty Mar 22 '12 at 1:51
    
I'm happy that you found it helpful. –  gWaldo Mar 22 '12 at 14:50
show 5 more comments

So, you want to have the benefit of having Replica Sets, but not quite yet as you do not really run in such mode at the moment. Then again, you complain about there errors?

What did you expect to happen? :)

Obviously, if you put "yes" into "REPLICAONSLAVE", then the code would assume that what you want is to find first available slave to take the backup from.

Anyhow, I will add relevant Replica Sets detection code at some point (if the spare time permits) as per issue that somebody opened via github :-)

KW

share|improve this answer
    
nothing about the error output suggests its from the Replication code. So, I'd say what I was expecting was a slightly more informative error message. I thank you for your answer that the configuration needs to be set. I don't recall documentation about the config vars being present at the time I asked this question. –  lhagemann Mar 27 '12 at 1:18
1  
@chakram88 in the end, you are very right. This project needs to be updated in terms of getting better documentation and finally a decent re-write. I will look into this :) Meanwhile, I welcome any ideas and/or critique -- especially based on the use-cases (real life, or possible ones). Again, thank you for reporting this :) –  Krzysztof Wilczynski Mar 29 '12 at 9:30
add comment

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.