Overview
In this post, I’m going to cover the topic on how to backup and restore LDAP database and config in case of disaster. If you’re a Zimbra administrator, this is a must have knowledge. This can be useful for anyone with an interest in system administration and mail servers.
The reason I’m writing this blog is to help others in quickly recovering from a disaster, based on my personal experiences. I understand how it feels to have your system damaged or lost and have no official support or help to get past through. This happens all the time to people, especially when they’re working with open-source solutions. But this has never stopped the progression of open-source evolution. In fact, this is the reason why open-source is getting stronger. Personally, I’ve faced numerous problems while working with open-source and that really hurts. However, I’ve always found a way to get through them, either by my own innovation or by suggestions of various community members (which is mostly 🙂 ). Although the path is difficult, when we get to the other side of it, we become a completely different person, a better person actually. And I believe that is what Open-Source is all about.
Back to the topic, there are a bunch of issues which can wreck havoc in your job of administration. Some of the common ones are damaged filesystem, disk failure, database corruption, misconfigurations, security breaches, and the list goes on. There are guidelines and best practices to prevent these scenarios, however there isn’t any hard-and-fast rule to cover ’em all. So, proactive administration and management are the only effective ways to protect our precious systems. I hope to cover all the major disaster incidents in future, but for now, I’m sticking with LDAP recovery which is one of the main issues faced during Zimbra administration.
Zimbra LDAP Backup
With all the talking, let’s now begin the backup task. In fact, it’s too easy as well because Zimbra itself comes up with a tool to do that for us. Here’s how the LDAP database and its configuration can be backed up:
[code language=”bash”]
[root@zimbra ~]# mkdir /tmp/Backup
[root@zimbra ~]# su zimbra
[zimbra@zimbra root]# /opt/zimbra/libexec/zmslapcat /tmp/Backup
[zimbra@zimbra root]# /opt/zimbra/libexec/zmslapcat -c /tmp/Backup
[/code]
In this config, I’m going to keep the backup files in a folder called Backup in /tmp directory. However, it’ll be better if we could put them in a remote location, maybe via NFS share, FTP, SCP, or with any other method. It’ll also be a lot better if we could automate this whole backup procedure and keep our system safe. This is my script to do this task:
[code language=”bash”][root@zimbra ~]# vi backup-ldap.sh[/code]
[code language=”bash”]
#!/bin/sh
DIR="/tmp/Backup"
# Check existence of backup folder, otherwise, create it
if [ ! -d "$DIR" ]
then
mkdir "$DIR"
chown -R zimbra:zimbra "$DIR"
fi
echo Backing up LDAP DB…
su – zimbra -c "/opt/zimbra/libexec/zmslapcat $DIR"
if [ $? -eq 0 ]
then
echo "Succeeded!"
else
echo "Backup fialed!"
fi
echo Backing up LDAP Config…
su – zimbra -c "/opt/zimbra/libexec/zmslapcat -c $DIR"
if [ $? -eq 0 ]
then
echo "Succeeded!"
else
echo "Backup Failed!"
fi
[/code]
In this case, I’m going to perform daily backup of my Zimbra’s LDAP DB and config in the /tmp/Backup directory. As I’ve told earlier, we can also backup these files in network location as well. To complete this script, let’s add an execution permission to it and add it to cronjob.
[code language=”bash”][root@zimbra ~]# chmod +x backup-ldap.sh
[root@zimbra ~]# crontab -e
@daily /root/backup-ldap.sh
[/code]
Zimbra LDAP Restore
Now, let’s say we’re come across a disaster and have somehow lost or corrupted our LDAP database. In this case, even though all of the other components of Zimbra are good, the whole mail system will fail to work because LDAP is that important to it. Here’s how the LDAP database and config can be restored from the last working backup:
[code language=”bash”]
[root@zimbra ~]# su zimbra
[zimbra@zimbra root]# zmcontrol stop
[zimbra@zimbra root]# rm -rf /opt/zimbra/data/ldap/config/*
[zimbra@zimbra root]# rm -rf /opt/zimbra/data/ldap/mdb/*
[zimbra@zimbra root]# mkdir -p /opt/zimbra/data/ldap/mdb/db /opt/zimbra/data/ldap/mdb/logs
[zimbra@zimbra root]# chown -R zimbra:zimbra /opt/zimbra/data/ldap
# For ZCS versions older than and equal to 8.02
[zimbra@zimbra root]# /opt/zimbra/openldap/sbin/slapadd -q -n 0 -F /opt/zimbra/data/ldap/config -cv -l /tmp/Backup/ldap-config.bak
[zimbra@zimbra root]# /opt/zimbra/openldap/sbin/slapadd -q -b "" -F /opt/zimbra/data/ldap/config -cv -l /tmp/Backup/ldap.bak
#For ZCS versions newer than 8.02
[zimbra@zimbra root]# /opt/zimbra/libexec/zmslapadd -c /tmp/Backup/ldap-config.bak
[zimbra@zimbra root]# /opt/zimbra/libexec/zmslapadd /tmp/Backup/ldap.bak
[/code]
In above configuration, I first stopped the zimbra, in case other services were running. Then, removed the contents within config and mdb directories of Zimbra ldap. This mdb is where the LDAP database is stored and config folder is where its configurations are stored. If you think removing these data isn’t a safe way to do it, you can simply rename these folders to something different as well. Once the data of mdb and config folders are deleted or renamed, we need to create these folders manually and change their ownership to zimbra user. Finally, the last two commands restore the LDAP config and database from the backup folder.
I hope this has been helpful and informative for you. If you ever come across any LDAP related disaster or want to prepare yourself for the one, this article can be very useful for you. Please let me know your suggestion or questions in the comments section below. Thank you for reading!
Leave a Reply