ZCS Administrator's Guide 8.0.4
ZCS Administrator's Guide 8.0.4
Network Edition


Backup and Restore > General Steps for Disaster Recovery

General Steps for Disaster Recovery
Use the following steps to restore a mailbox store server in a general disaster scenario involving multiple machines.
Preparation
1.
2.
3.
Recovery
1.
2.
3.
4.
5.
Crash Recovery Server Startup
When your system unexpectedly stops and then restarts on startup, the server searches the redo log for uncommitted transactions and replays any that it finds. Replaying the redo logs brings the system to a consistent state.
Restore the VMware Zimbra Collaboration Server
If a complete machine failure occurs, use the following steps to restore to a new server.
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.
You do the following to restore to a new server:
1.
2.
3.
4.
5.
6.
Run zmrestoreldap to restore the global LDAP data.
7.
Run zmrestoreoffline to restore account data from the backup sessions.
8.
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 server is still running, to prepare the move to the new server:
1.
2.
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.
Install ZCS on a 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 VMware Zimbra Collaboration Server 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.
Note:
1.
2.
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.
Restoring a Backup to a New Server
1.
zmcontrol stop
2.
3.
rm -rf /opt/zimbra/db/data/*
/opt/zimbra/libexec/zmmyinit
The mySQL service is now running.
4.
5.
zmrestoreldap -lb <latest_label>
If you are restoring a large number of accounts, you might run a command such as the UNIX command, nohup, so that the session does not terminate before the restore is complete.
Note:
6.
Because some ZCS services are running at this point, type zmconvertctl start. This is required before running zmrestoreoffline.
7.
zmlocalconfig -f -e zimbra_ldap_password=<password>.
8.
zmrestoreoffline -sys -a all -c -br.
You might run a command such as nohup here also. To watch the progress, tail /opt/zimbra/log/mailbox.log.
Note:
9.
10.
rm -rf /opt/zimbra/redolog/* /opt/zimbra/backup/*
11.
zmcontrol start.
12.
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.
Restore When LDAP 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.
Restore After Replacing Corrupted Partitions
1.
2.
zmrestore -a all
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.
Restore After Corrupted or Unreadable Redo Log
If the redo log becomes unreadable, 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.
zmprov md <domain> zimbraDomainStatus maintenance
2.
zmrestoreoffline
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:
Because the redo log for current transactions is not available, the mailbox server is returned to the state of the last archived redo log.
3.
zmcontrol startup
4.
Change 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 might 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.
Copyright © 2013 VMware Inc.