Zimbra Backup Script ... Small Problem

[frankb]

Hello,

I have been working for about 3 hours on this problem now, any help would be greatly appreciated. I have a Zimbra server (latest version open source) running on Centos 5. Everything is great, except when I use the backup script that is posted on the wiki (a copy of mine is below) and schedule it through Cron to execute each night I cannot access the zimbra web pages until I manually perform a tomcat restart at the console. I can execute the script at the command line with no problems and have full access to the zimbra web pages except for the short time the zimbra is stoped and started during the script. I have checked to make sure that the cron job is running as the user root. I have attempted to restart tomcat through the script below however when I add those lines of code I receive the error that ldap might not be loaded. Please help.

backup script:

# Zimbra Backup Script
# Requires ncftp to run
# This script is intended to run from the crontab as root
# Free to use and free of any warranty! Daniel W. Martin, 27 Aug 2007

# Live sync before stopping Zimbra to minimize sync time with the services down
# Comment out the following line if you want to try single cold-sync only
rsync -avHK /opt/zimbra/ /backup/zimbra

# Stop Zimbra Services
sudo -u zimbra /opt/zimbra/bin/zmcontrol stop
sleep 15

# Sync to backup directory
rsync -avHK /opt/zimbra/ /backup/zimbra

# Restart Zimbra Services
sudo -u zimbra /opt/zimbra/bin/zmcontrol start

# Create archive of backed-up directory for offsite transfer
# cd /backup/zimbra
tar -zcvf /tmp/mail.backup.gz /backup/zimbra/*

# Transfer file to backup server
#ncftpput -u <username> -p <password> <ftpserver> /<desired dest. directory> /tmp/mail.backup.gz
ncftpput -u frankb -p bombay 192.168.0.50 /zimbra_backup /tmp/mail.backup.gz


Thanks!
Frank

[jholder]

# Live sync before stopping Zimbra to minimize sync time with the services down
# Comment out the following line if you want to try single cold-sync only
rsync -avHK /opt/zimbra/ /backup/zimbra

We generally do not recommend "live" syncing of the Zimbra server.

Such an action could result in a loss of data, and may be your current issue.

[dwmtractor]

# Live sync before stopping Zimbra to minimize sync time with the services down
# Comment out the following line if you want to try single cold-sync only
rsync -avHK /opt/zimbra/ /backup/zimbra

We generally do not recommend "live" syncing of the Zimbra server.

Such an action could result in a loss of data, and may be your current issue.

This is not a true "live" sync, and if anyone were to use only this portion of the script they would wind up with an ugly mess on their hands. I put this in the script (at the recommendation of another user) to minimize the amount of time that the server is down. The "live" rsync alone would, as you point out, contain some in-process files that we DON'T want to use as backups, but by pre-syncing the whole /opt/zimbra directory BEFORE stopping the Zimbra services, those files that do not change between the started and stopped states get updated. Then, with Zimbra services stopped, a second rsync cleans up those elements that are open during running services, which is why the resultant backup is truly a "cold" backup.

It is, of course, possible to comment out that "live" presync and run the script with the "cold" sync only, if you prefer.

I wonder, though about your suggestion that this would be what keeps frankb's Tomcat from restarting; it seems to me that the two things should be completely unrelated. Frankb, I'm curious; if you comment out all the backup lines and just use the zimbra stop and zimbra start lines, does Tomcat still fail to restart? For that matter, try the following:

Log on as root
su - zimbra
zmcontrol stop

(now wait half a minute or so)

zmcontrol start

Do your processes, including Tomcat, start properly? It may be that the issue is not the script at all. . .at least that's where I would start looking.

Cheers,

Dan

[frankb]

Please remember that the script works without errors from the command line. The problem only occurs when running through Cron.

I will try your suggestion regarding only creating a script stopping and then starting Zimbra and post the results.

Thanks for your replies ... Frank

[dwmtractor]

Frank, this may be a really dumb question, but I'm not afraid of looking dumb so here goes...

Is your Linux distro fully updated/patched? Is there any chance you're looking at a bug in either crontab or sudo which could be causing this failure?

I wrote and tested the script on Ubuntu 6.06 LTS (the server release) and I have no idea how it differs from other distros, other than that it is supposed to be pretty close to Debian.

I'm grasping at straws here, but if I had to guess I would wonder if there is something wrong permissions-wise -- that is, if the sudo command is somehow not properly emulating the Zimbra user for starting and stopping of the services. I know there are some funky differences between things working at the command line and running from crontab, and I am the wrong person to debug them because it's really over my head, but perhaps this'll give you some thoughts on how to proceed.

You might check out this link for more information about things working in bash but not in crontab and see if it gives you any help.

Dan

[dwmtractor]

A Linux friend of mine (not a Zimbra user yet!) corrected my tar command. It had been working fine at the command prompt but was not behaving when run from crontab, apparently because it wasn't properly going to the right source directory.

So here is the revised script, tested and working on Ubuntu 6.06:

#!/bin/bash

# Zimbra Backup Script
# Requires ncftp to run
# This script is intended to run from the crontab as root
# Free to use and free of any warranty!  Daniel W. Martin, 9 Sept 2007

# Live sync before stopping Zimbra to minimize sync time with the services down
# Comment out the following line if you want to try single cold-sync only
rsync -avHK /opt/zimbra/ /backup/zimbra

# Stop Zimbra Services
sudo -u zimbra /opt/zimbra/bin/zmcontrol stop
sleep 15

# Sync to backup directory
rsync -avHK /opt/zimbra/ /backup/zimbra

# Restart Zimbra Services
sudo -u zimbra /opt/zimbra/bin/zmcontrol start

# Create archive of backed-up directory for offsite transfer
# cd /backup/zimbra
tar -zcvf /tmp/mail.backup.gz -C /backup/zimbra .

# Transfer file to backup server
ncftpput -u <username> -p <password> <ftpserver> /<desired dest. directory> /tmp/mail.backup.gz

This revision has also been corrected on the wiki

[jholder]

A Linux friend of mine (not a Zimbra user yet!) corrected my tar command. It had been working fine at the command prompt but was not behaving when run from crontab, apparently because it wasn't properly going to the right source directory.

So here is the revised script, tested and working on Ubuntu 6.06:

#!/bin/bash

# Zimbra Backup Script
# Requires ncftp to run
# This script is intended to run from the crontab as root
# Free to use and free of any warranty!  Daniel W. Martin, 9 Sept 2007

# Live sync before stopping Zimbra to minimize sync time with the services down
# Comment out the following line if you want to try single cold-sync only
rsync -avHK /opt/zimbra/ /backup/zimbra

# Stop Zimbra Services
sudo -u zimbra /opt/zimbra/bin/zmcontrol stop
sleep 15

# Sync to backup directory
rsync -avHK /opt/zimbra/ /backup/zimbra

# Restart Zimbra Services
sudo -u zimbra /opt/zimbra/bin/zmcontrol start

# Create archive of backed-up directory for offsite transfer
# cd /backup/zimbra
tar -zcvf /tmp/mail.backup.gz -C /backup/zimbra .

# Transfer file to backup server
ncftpput -u <username> -p <password> <ftpserver> /<desired dest. directory> /tmp/mail.backup.gz

This revision has also been corrected on the wiki

AWESOME!

Thanks guys!

[dwmtractor]

jholder, the thread was originally posted by Frankb. I don't know if we can mark it solved just yet as he has not reported back if he's got this working on CentOS.

Frank, any luck?

[jholder]

Noted.
-john

[dwmtractor]

By the way Frank, one thing you might try to debug just what's going on (or not going on) with your cron job is to have the cron job record its output to a file. For example, if your script is /etc/zimbra.backup, load the cron job as

. /zimbra.backup > /tmp/backup.log

That way you can go thru /tmp/backup.log later and see what went right or wrong in the execution of the script.

Dan