Zimbra Backup Question

[Sir Bob]

Good day,

We are finalizing our migration from one O/S to another and found an oddity within the process that I am hoping someone can shed light on. Version of Zimbra is 5.0.4 on OpenSuse 10.2

For our backups of Zimbra, we rsync the entire /opt/zimbra directory to the backup server with the following options: rsync -avHK. While testing our migration, we rsynced (rsync -avH) the /index, /store, /db/data and /logger/db directories from our backups to a separate hard drive then used this information to restore Zimbra with a script we came up with. The script will rsync the data again into the new installation of Zimbra (rsync -avH --delete) This all works fine except for one issue.

Last month, we had the entire company go through a password change. When we do the migration/restore on a test box, we end up with a working server, but using the old passwords. Backups run nightly and the four directories were rsynced (several times) from the backups after the password change so we would have expected our backups to contain the correct information.

The backup script is more defined here:
MAX_ROTATIONS=20
ROOT_DIR=/backup
SSH_KEY=/root/.ssh/id_dsa_backup.key
doitLinux () {
local LOG_FILE=$ROOT_DIR/${HOSTNAME}.${SHARE}.log

rm -rf $ROOT_DIR/$HOSTNAME/$SHARE.$MAX_ROTATIONS
for c in $( seq $MAX_ROTATIONS -1 2 ); do
mv -f $ROOT_DIR/$HOSTNAME/$SHARE.$((c-1)) $ROOT_DIR/$HOSTNAME/$SHARE.$((c)) 2> /dev/null
done

# Create the initial backup and difference directories if they don't exist.
mkdir -p $ROOT_DIR/$HOSTNAME/$SHARE
mkdir -p $ROOT_DIR/$HOSTNAME/$SHARE.1

echo "#########################################" > $LOG_FILE
echo "# Backup started for $HOSTNAME on `date` " >> $LOG_FILE
echo "#########################################" >> $LOG_FILE

rsync -avH $OPTIONS \
--partial \
--delete \
--backup --backup-dir=$ROOT_DIR/$HOSTNAME/$SHARE.1 \
-e "ssh -i $SSH_KEY" \
$SOURCE_DIR \
$ROOT_DIR/$HOSTNAME/$SHARE \
>> $LOG_FILE

############################
# ZIMBRA
############################
HOSTNAME=ZIMBRA
SHARE=zimbra
SOURCE_DIR=10.2.32.8::zimbra
OPTIONS=-K

doitLinux


So, what are we missing? Is the issue with how we are backing up the data?

Sir Bob

[bdial]

passwords are stored in ldap, you probably need to get /opt/zimbra/openldap too

still not a very good method of doing backups, copying databases taht are running just by copying the flat files can lead to problems.

[Sir Bob]

Thank you for the quick response.

To expand on the backup solution we use, Zimbra services are stopped when the backup server connects through an authenticated key. This key runs a script that shuts down Zimbra (so no changes can occur to LDAP or MYSQL), starts a rsync server instance on the email server, then the /opt/zimbra directory is rsynced to the backup server before restoring the Zimbra services. Most of the forums we had read on backups state all that is needed is to shut down Zimbra then back up the /opt/zimbra directory and you are good to go.

If you could suggest a better way of doing our backups, please do so. To date (knock on wood), we have not had a need to restore from backups so this issue is opening our eyes to potential problems.

And, yes, your idea of bringing over the ldap for the migration makes sense.

Sir Bob

[bdial]

if you're stopping zimbra you're probably fine then. there are several threads on this forum about backup scripts for the oss version if you wanted to look at what others are doing. you should try to do a full recovery test though as you said it points out flaws you may not have known about.