Zimbra Open Source Edition Backup Procedure

Backup Scripts

The following script can be called from the command line or crontab, and relies only on rsync, tar, and a scriptable ftp client. I used but you can use others and modify the syntax accordingly. This script was written and tested in Ubuntu 6.06 LTS server. I cannot confirm if it requires any modification to work in other distros but would appreciate feedback if necessary to make it more general.

#!/bin/bash
 
 # Zimbra Backup Script
 # Requires ncftp to run
 # This script is intended to run from the crontab as root
 # Date outputs and su vs sudo corrections by other contributors, thanks, sorry I don't have names to attribute!
 # Free to use and free of any warranty!  Daniel W. Martin, 5 Dec 2008

 
 # Outputs the time the backup started, for log/tracking purposes
 echo Time backup started = $(date +%T)
 before="$(date +%s)"

 # 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 --delete /opt/zimbra/ /backup/zimbra

 # which is the same as: /opt/zimbra /backup 
 # Including --delete option gets rid of files in the dest folder that don't exist at the src 
 # this prevents logfile/extraneous bloat from building up overtime.

 # Now we need to shut down Zimbra to rsync any files that were/are locked
 # whilst backing up when the server was up and running.
 before2="$(date +%s)"

 # Stop Zimbra Services
 su - zimbra -c"/opt/zimbra/bin/zmcontrol stop"
 sleep 15

 # Kill any orphaned Zimbra processes
 kill -9 `ps -u zimbra -o "pid="`

 # Only enable the following command if you need all Zimbra user owned
 # processes to be killed before syncing
 # ps auxww | awk '{print $1" "$2}' | grep zimbra | kill -9 `awk '{print $2}'`
 
 # Sync to backup directory
 rsync -avHK --delete /opt/zimbra/ /backup/zimbra

 # Restart Zimbra Services
 su - zimbra -c "/opt/zimbra/bin/zmcontrol start"

 # Calculates and outputs amount of time the server was down for
 after="$(date +%s)"
 elapsed="$(expr $after - $before2)"
 hours=$(($elapsed / 3600))
 elapsed=$(($elapsed - $hours * 3600))
 minutes=$(($elapsed / 60))
 seconds=$(($elapsed - $minutes * 60))
 echo Server was down for: "$hours hours $minutes minutes $seconds seconds"

 # Create a txt file in the backup directory that'll contains the current Zimbra
 # server version. Handy for knowing what version of Zimbra a backup can be restored to.
 su - zimbra -c "zmcontrol -v > /backup/zimbra/conf/zimbra_version.txt"
 # or examine your /opt/zimbra/.install_history

 # Display Zimbra services status
 echo Displaying Zimbra services status...
 su - zimbra -c "/opt/zimbra/bin/zmcontrol status"
 
 # Create archive of backed-up directory for offsite transfer
 # cd /backup/zimbra
 tar -zcvf /tmp/mail.backup.tgz -C /backup/zimbra .
 
 # Transfer file to backup server
 ncftpput -u  -p   / /tmp/mail.backup.tgz

 # Outputs the time the backup finished
 echo Time backup finished = $(date +%T)

 # Calculates and outputs total time taken
 after="$(date +%s)"
 elapsed="$(expr $after - $before)"
 hours=$(($elapsed / 3600))
 elapsed=$(($elapsed - $hours * 3600))
 minutes=$(($elapsed / 60))
 seconds=$(($elapsed - $minutes * 60))
 echo Time taken: "$hours hours $minutes minutes $seconds seconds"
 # end

One further note: I have observed some odd behavior in this and other scripts that, when run from the command line work flawlessly, but when run from crontab the script may get ahead of itself and, for example, try to ftp the file before tar is done creating it; resulting in a useless backup. Loading the script into crontab with the parameters to create a log file, for example

. /etc/zimbra.backup > /temp/zbackup.log 2>&1

seems to solve this problem (while creating the log, or showing the output on the screen, the script seems to follow the sequence more carefully), while giving you a line-by-line record of the backup procedure. In my installation with just over 3GB backed up, the logfile is 2.5 mb and is overwritten each night.

NB You may find that using su on your operating system has problems and some services don't start or stop correctly. If that's the case use 'sudo -u zimbra' in the following format for the commands:

sudo -u zimbra zmcontrol start

Emergency Repairs

Preparing to Back Up

Before we begin, make sure that you are logged in as a user that can perform the tasks outlined here.

It is always good practice to backup your copy of Zimbra in the event of unforeseen circumstances.

To prevent changes to any Zimbra databases during the backup processes you may wish to use:

>su zimbra

>zmcontrol stop

to terminate Zimbra.

If you get some kind of error, you may want to make sure that Zimbra has completly stopped by running:

>ps auxww | grep zimbra

and kill any left over processes such as the log.

Alternatively as root you could run the following command to kill all Zimbra user owned processes instantly (use wisely):

>ps auxww | awk '{print $1" "$2}' | grep zimbra | kill -9 `awk '{print $2}'`

Backing Up

Make sure that the copy location has enough space to support your backup copy (i.e. the /tmp folder probably isn't the best location).

Since all of the components Zimbra needs are stored in the Zimbra folder itself, you can simply copy the folder to a safe location.

It may be possible to create a cron job to do these tasks automatically.

Copy Command: cp -Rp /opt/zimbra [location path]

Depending on your hardware and the amount of data contained in your Zimbra installation, this process can take a while.

Note: It is a very good idea to tag your installation with the version/build of zimbra that will be backed up (ie 3.0.0_GA_156) and the date of backup. You'll need this later.

Restoring

Before restoring, you should make sure that all of the processes accociated with the damaged/failed Zimbra installation are terminated. Failure to terminate all of the processes could have dire consquences. See "Preparing to Backup" for additional info.

====Rename your "broken" Zimbra installation.'

You may be able to scavenge data, if needed. If you simply do not want the old data, you can skip this part.

>mv /opt/zimbra [new location i.e. /tmp/zimbra-old]

You may want to move it completly out of the /opt folder just to be safe.

Copy your backup Zimbra installation to the /opt folder and name it "zimbra".

>cp -rp [location of backup] /opt

>mv /opt/[backup name] /opt/zimbra

Restore to Existing/Backup Zimbra Server

In the event of a failure, you can either restore your /opt/zimbra folder to a server that is not currently running Zimbra and download a dummy copy of Zimbra and run an upgrade in order to clean everything up and make it run correctly again (see next section), or you may restore the backup to an existing Zimbra server. This will only work if the existing server is running the EXACT SAME VERSION of Zimbra as the backup you want to restore. Also, this has been tested and seems to work well with CE 4.5.8, but did not work with 4.5.7. This may be, for example, a backup email server that you want to always keep current with last night's backup, so it can replace the production server on short notice in the event of a disaster.

Simply set up your backup server identical to your production server (preferably the same OS, but necessarily the exact same version of Zimbra). Any modifications you made or packages you added for your production server with regards to extra anti-spam protection, etc., should also be added to this server. Shut down Zimbra on the backup server. Copy /opt/zimbra from your backup to the backup server.

chown -R zimbra:zimbra /opt/zimbra
/opt/zimbra/libexec/zmfixperms

Start Zimbra. Everything should work. The advantage to this method is that you can retain all your customizations (anti-spam modifications, for example) that would otherwise have been lost in the "upgrade" method. Also, this allows you to use a script to keep a backup server current without having to reinstall Zimbra after each time the backup server is made current, or before putting the backup server into production in the event of a failure.