ZCS Administration Guide Network Edition 6.0.6 March 2010
Table of Contents Previous Next Index


Backup and Restore : Disaster Recovery for Specific Situations

Disaster Recovery for Specific Situations
This section provides general guidelines for disaster recovery. You can get more information from this wiki page http://wiki.zimbra.com/index.php?title=Network_Edition_Disaster_Recovery .
General Steps for Disaster Recovery
The sequence of events to restore your mailbox store server in a general disaster scenario involving multiple machines would be as follows:
Preparation
1.
2.
3.
Recovery
4.
5.
6.
7.
8.
Crash Recovery Server Startup
When your system is unexpectedly stopped and then restarted, on startup, the server automatically searches the redo log for any uncommitted transactions, and replays any that it finds. Replaying the redo logs brings the system to a consistent state.
Restore the Zimbra Collaboration Suite Servers
This direction would be in the case of complete machine failure.
Important: The ZCS version you install on the new server must be the same version as installed on the old server. The server can have a different operating system.
The new server hardware must meet the requirements described in the Installation Prerequisites section of the ZCS Single Server Installation Guide. Install the new operating system, making any necessary OS configuration modifications as described in the installation guide.
Disaster Recovery Changing Servers
You do the following to restore to a new server:
Run zmrestoreldap to restore the global LDAP data
Run zmrestoreoffline to restore account data from the backup sessions
Old Server Status
Two scenarios for disaster recovery are the server has died and the ZCS files cannot be accessed, or ZCS is still running, but the server hardware needs to be replaced.
If the server is not running:
1.
2.
If ZCS is still running, to prepare the move to the new server:
1.
2.
Run a full backup of the old service, or if the backup is recent, run an incremental backup to get the most current incremental backup session.
3.
Run zmcontrol stop, to stop ZCS. In order to restore to the most current state, no new mail should be received after the last incremental backup has run.
4.
Preparing the New Server
Before you begin, make sure that the new server is correctly configured with the IP address and hostname and that ZCS is installed and configured with the same domain, hostname, passwords, etc. as the previous server. See the ZCS installation guide for more information about preparing the server. Before you begin to install ZCS, note the information you need from the old server including: admin account name and password, LDAP, Amavis, and Postfix passwords, spam training and non-spam training user account names, exact domain name, and the global document account name.
Installing ZCS on new server
Note: Make sure the computer time is set to the same time as the old server. Verify that the old hostname and MX DNS records resolve to the new server.
1.
Copy your ZCSLicense.xml file to a directory on the new server. You will not be able to complete the ZCS installation if the license is not on the new server.
2.
Run ./install.sh and follow the directions in the installation guide to install ZCS. Make sure that you configure the same domain, hostname, passwords as on the old server. During ZCS install, the following settings must be changed to match the original server settings:
a.
Zimbra LDAP Server. For Domain to create, identify the same default domain as on the old server.
b.
Zimbra Mailbox Server. An administrator’s account is automatically created.
Make sure that the account name for Admin user to create is the same name as on the original server.
Change the Spam training user and the Non-spam (HAM) training user account names to be the same as the spam account names on the old server.
Global Document Account – This account name is automatically generated and is usually named wiki. If you changed this, change the Global Document Account name to be the same account name as on the original server.
c.
d.
In the main menu, set the default backup schedule and the automatic starting of servers after the configuration is complete to NO.
Restoring to the new server:
1.
2.
3.
Delete the mysql data and re initialize an empty data directory. If you do not do this, zmrestoreoffline will have errors. As zimbra, type
a.
b.
The mySQL service is now running.
4.
5.
To restore the LDAP, type
zmrestoreldap -lb <latest_label>.
If you are restoring large number of accounts, you may want to run a command such as the UNIX command, nohup, so that the session does not terminate before the restore is complete.
Note: To find the LDAP session label to restore, type zmrestoreldap –lbs.
6.
Because some ZCS services are running at this point, type zmconvertctl start. This is required before running zmrestoreoffline.
7.
Sync your LDAP password from backup directory to the new production servers LDAP config. type
zmlocalconfig -f -e zimbra_ldap_password=<password>.
8.
To start the offline restore, type
zmrestoreoffline -sys -a all -c -br. You may want to run a command such as nohup here also. To watch the progress, tail /opt/zimbra/log/mailbox.log.
Note: Use –c on the command line so that accounts will be restored even if some accounts encounter errors during the offline restore process.
9.
10.
Remove any old backup sessions because these sessions are no longer valid. Type rm -rf /opt/zimbra/redolog/* /opt/zimbra/backup/*
11.
To start ZCS, type zmcontrol start.
12.
Now run a full backup, type zmbackup -f -a all.
13.
Restoring from Different Failure Scenarios
The restoration steps are similar for most server failures you may encounter. If a failure occurs, review the disaster recovery section to understand the process and then follow the steps below for the specific type of failure.
Zimbra LDAP server is corrupted
1.
2.
Find the label for the LDAP session to restore. Run the zmrestoreldap -lb <label> command, with no arguments to restore all accounts, domains, servers, COS, etc. for the LDAP server.
3.
Partitions become corrupted
If any partition becomes corrupted, replace the failed disk(s), then run zmrestore, to restore the latest full and incremental backup files. The zmrestore process automatically retrieves the list of all mailboxes on the specified mail host from the backup date and iterates through each mailbox to restore the mailboxes to the last known good state.
Redo log is corrupted or unreadable
If the redo log becomes unreadable for any reason, the mailboxd service stops and cannot restart. If this happens, inspect the hardware and software to find the source of the problem before proceeding.
Without the latest redo log, the Zimbra mailbox server cannot be returned to the most current state. The Zimbra mailbox data can be restored to the latest archived redo log state. A new redo log for current transactions is created after the Zimbra mailbox server is restored.
Important: The mailboxd service must not be running and all accounts must be in maintenance mode before beginning.
1.
To put all accounts into maintenance mode, from the command line, type zmprov md <domain> zimbraDomainStatus maintenance
2.
The offline restore process begins by retrieving the list of all mailboxes on the specified mail host from the backup.
The offline restore than iterates through each mailbox to:
Restore all incremental backups for that mailbox in order, since the last full backup. This involves replaying the redo logs from the backup target area
Since the redo log for current transactions is not available, the mailbox server is returned to the state of the last archived redo log.
3.
4.
Once the Zimbra mailbox server is up, run a full backup of the Zimbra server. The full backup must be run immediately to have the latest data backed up, as the latest redo log is not available.
Changing Local Configuration Files after Restoring Zimbra
The localconfig.xml file, located in the /opt/zimbra/conf directory, includes the core Zimbra server configuration, such as paths and passwords, This file is backed up in full and incremental backups. When you run an incremental or full restore, the backed-up version of the localconfig.xml is renamed localconfig.xml.restore and is copied to the /opt/zimbra/conf directory.
If you have made changes since the last backup, you may need to replace the localconfig.xml file with the restored copy. Compare these files, and if the .restore file has the latest local configuration data, delete the localconfig.xml file and rename the file with the .restore extension to localconfig.xml.

Backup and Restore : Disaster Recovery for Specific Situations

Table of Contents Previous Next Index
ZCS Administration Guide Network Edition 6.0.6 March 2010
Copyright © 2010 Zimbra Inc.